Historical accounting records can help an AI system identify recurring treatments, but they do not automatically represent approved or consistently applied policy. They may preserve errors, temporary workarounds and outdated decisions. Before an AI system learns from past entries, finance leaders need to decide which precedents are valid, which are mistakes and which still require human judgment.
That distinction is central to the proposition from Madrid-based Talky Labs. EU-Startups reported in October 2026 that the company had raised €1.5 million in pre-seed funding after closing the round in September. Talky says accounting criteria are often scattered across enterprise systems, spreadsheets, emails, contracts and employees’ knowledge. Its platform reportedly extracts criteria from historical records, applies them to new transactions and consults an appropriate employee when information is insufficient.
The company also claims to have processed more than 1.8 million documents and over €2 billion in client expenditure, with 86%–93% of accounting documents processed without human intervention. Those figures have not been independently verified in the cited reporting. Neither the funding round nor the claimed automation rate proves that the product will be effective in another organisation. The more useful question for CFOs and controllers is how any system attempting this work should be governed.
Start with the decision, not the document
“Invoice processing” sounds like one process, but it contains tasks with different risk profiles. Reading supplier details, extracting dates and matching a purchase-order number are relatively routine. Choosing the correct account, deciding whether expenditure should be capitalised, determining tax treatment or resolving an unusual allocation may depend on policy, context and professional judgment.
Finance teams should map the process at decision level. For each step, document the inputs used, the rule applied, the person accountable and the consequence of an incorrect result. This reveals which activities are candidates for straight-through automation and which should remain recommendations or human-controlled decisions.
- Deterministic work: The answer follows an approved rule and all required data are present.
- Context-dependent work: The answer depends on a contract, prior approval, business purpose or another source beyond the document.
- Judgment-heavy work: Several treatments may be plausible, or the decision affects reporting, tax, cash or a material estimate.
- Prohibited automation: Policy or segregation-of-duties requirements reserve the action for an authorised person.
The goal is not to maximise the first category. It is to make the boundaries explicit enough that the system knows when it must stop.
Convert precedent into reviewed policy
An AI system trained on historical transactions can reproduce both institutional knowledge and institutional mistakes. Prior entries may contain inconsistent coding, temporary workarounds, obsolete approval routes or treatments that were corrected outside the source system. A frequent historical choice shows what happened, not necessarily what should happen again.
Before using records as examples, finance should assemble representative cases and reconcile them with current policies, contracts and the chart of accounts. Reviewers should identify contradictory treatments and record why one precedent is authoritative. If no approved rule exists, the right output from the implementation project may be a policy decision rather than another training example.
Each codified criterion should state its scope, required evidence, owner, effective period and exceptions. It should also have a version history. That allows the business to distinguish a system following an outdated rule from one making an unsupported inference.
Test whether the source data can support the rule
A rule can be clear while the available data remain inadequate. For example, a classification may depend on the purpose of a purchase, but the invoice description may be too vague to establish that purpose. Automating the decision from the invoice alone would create false confidence.
For each proposed rule, test whether the relevant information is present, reliable and current across the intended transaction population. Include incomplete documents, new suppliers, credit notes, changed contracts and conflicting master data in the test set. Do not evaluate only clean examples that the system is expected to pass.
Finance should compare the AI output with a reviewed reference decision rather than treating the existing ledger entry as unquestioned truth. Classify disagreements as model error, poor source data, ambiguous policy or incorrect historical treatment. Each category requires a different remedy.
Use confidence thresholds to control actions
A confidence score may help determine what the system is permitted to do, but it is not proof that an accounting treatment is correct. Finance should validate thresholds against reviewed cases and set them according to the risk and consequence of the action. An uncertain cost-centre suggestion may be acceptable as a draft, while a transaction affecting cash, tax or period-end reporting may require explicit approval regardless of the score.
Design at least three operational outcomes:
- Automatic processing: Reserve this for approved, low-risk scenarios with complete evidence, a validated threshold and no conflicting signals.
- Human confirmation: The system proposes a treatment and shows the evidence and rule behind it.
- Specialist escalation: Ambiguous, unusual or policy-sensitive cases go to a designated owner rather than a general queue.
Exception routing should reflect why the case failed. Missing purchase-order data may belong with procurement; an unclear accounting treatment may belong with the controller; a supplier-bank change may require a separate fraud-control process. Sending every exception to accounts payable merely relocates work and can weaken accountability.
Preserve approval boundaries and restrict ERP access
Automation must not collapse preparation, approval and posting into one uncontrolled action. Define the system’s role separately for data extraction, coding recommendations, entry creation, approval and final posting. Service accounts should receive only the permissions required for the approved use case.
A staged rollout can begin with read-only analysis, move to draft entries and permit automated posting only after control owners accept the observed results. High-risk actions may remain outside the automated path. The related financial-permissions control framework for AI agents explains why the ability to recommend a transaction should not automatically include authority to execute it.
Controls should also cover changes to supplier records, bank details, approval thresholds and the chart of accounts. An apparently sound transaction decision can still become dangerous if the system relies on manipulated master data or can alter the environment against which its own controls operate.
Make every output reviewable
An audit trail should show the source document, data extracted, policy or criterion applied, supporting evidence, confidence or exception status, model or rules version, reviewer actions and final ERP result. Where a person overrides the recommendation, capture a reason that can be analysed later.
Evidence retention matters because a plausible output is not the same as a reproducible decision. A reviewer should be able to determine what information was available at the time and why the transaction took its eventual path. Logs also need access controls and retention arrangements appropriate to the underlying financial records.
Monitor errors, overrides and changing conditions
An automation percentage is incomplete as a standalone measure. It can rise because the system has improved, because thresholds have been loosened or because difficult cases are being excluded. Finance leaders should review outcomes by process and risk category instead.
Monitoring can cover the frequency and reasons for exceptions, human overrides, corrections after posting, unsupported recommendations and differences between business units or suppliers. Sample both automatically posted transactions and escalated cases. Random sampling can detect ordinary errors, while targeted sampling should concentrate on new rules, unusual values, changed master data and areas with repeated overrides.
Changes to policies, contracts, ERP configuration or the chart of accounts should trigger reassessment. If reviewers repeatedly override one criterion, investigate whether the system, source data or policy is at fault rather than training the system blindly on the latest outcome.
A controlled pilot should answer three questions
- Can the system identify the evidence required by the approved rule? Test incomplete, conflicting and unusual cases as well as routine transactions.
- Does it remain within its authority? Confirm that recommendations, approvals and ERP posting rights remain separate where required.
- Does it fail safely? Missing evidence, conflicting precedents and low-confidence outputs should stop or route the transaction instead of producing an unsupported posting.
Select a bounded process with an accountable owner, reviewed examples and a reversible posting method. Define acceptance criteria and escalation routes before measuring results. Expansion should depend on observed outcomes by risk category, not simply on the share of documents processed automatically.
The final decision should not rest on how impressively the system handles normal invoices. It should rest on what happens when evidence is missing, precedents conflict or a proposed action crosses an approval boundary. Unwritten knowledge can be valuable input, but finance must turn it into reviewed, versioned and enforceable policy before allowing software to act on it.
