A finance manager asks the AI assistant how many customer invoices are more than ninety days overdue and gets a clean, confident answer. It goes into the board pack. Three weeks later the external auditor asks a plain question: which invoices? If the answer is "the AI said so", the figure is not evidence. It is an assertion with no owner.
This is the problem of provenance, and it decides whether AI output can be used in accounting and audit at all. This article sets out the rule we apply, evidence or silence, and the trail that makes it testable. It is part of our series on AI in accounting.
What is AI provenance in accounting and audit?
AI provenance is the recorded chain from an AI output back to the exact records it read, the instruction and run that produced it, and the person who accepted or rejected it, so that a reviewer can re-perform the work. An audit trail does the same for transactions: who created, changed, approved and posted what, and when. AI provenance extends that trail to a new kind of preparer. Without it, an AI finding cannot be traced to source, and an AI-drafted entry has a record of what was posted but not of why.
Why is an AI answer not audit evidence on its own?
ISA 500 requires sufficient appropriate audit evidence, and appropriateness depends on relevance and reliability. ISA 230 requires documentation that lets an experienced auditor with no prior connection to the engagement understand the work done and the evidence obtained. A fluent paragraph from a language model meets neither test unless it points to records that can be inspected. The standards are moving with the technology: in August 2026 the IAASB issued exposure drafts revising ISA 500, ISA 330 and ISA 520 to address the increased use of technology, with comments due 15 December 2026. They are not final, but the direction is clear.
Hallucination is the specific risk. A model can produce a number, a vendor name or a date that reads correctly and exists nowhere in the books. In finance this is worse than an obvious error, because it looks like the output of a calculation.
What does "evidence or silence" mean?
It is the operating rule of MFT Intelligence: every finding must cite the record ids the agent actually retrieved, and a finding that cites nothing, or contains a number that is not in the cited records, is rejected. Rejected findings are shown struck through, never presented as facts. The agent either shows its evidence or says nothing.
Note what the rule does not claim. It does not claim the model never errs. It moves zero hallucination from a property of the model, which nobody can guarantee, to a property of the process, which can be tested: unsupported output cannot pass as a finding.
If the agent cannot point to the record, the finding does not exist.
How the check works, step by step
- The agent retrieves records through the API, and the id of every record returned is logged.
- The agent drafts a finding and lists the record ids it relies on.
- A validation step checks that every cited id was actually retrieved in that run.
- It then checks that every number, date and name in the finding appears in the cited records.
- Any finding that fails is struck through and kept, so the reviewer sees what was rejected and why.
- A named reviewer accepts, edits or rejects the surviving findings, and the decision is recorded.
A worked example
An agent reports that two bills from the same vendor carry the same reference, were posted four days apart and were both paid. It cites the two bill records and the two payment records. The validator confirms all four ids were retrieved and that the reference, dates and payment status appear in them, so the finding stands for review. In the same run the agent adds that the vendor was created by the user who approved both payments, but cites no vendor record or user log. That sentence is struck through. It may be true; it is not yet evidence, so the reviewer pulls the vendor change history before saying it.
What should an AI audit trail record?
| Element | Why it matters | Practical note |
|---|---|---|
| Instruction version | The same question under a different instruction gives a different answer | Odoo 20 default prompts accept context and dynamic values; version them like a policy |
| Records retrieved | The basis for re-performance | Log record ids, not only a summary of the query |
| Provider and model | Explains differences between runs | Odoo 20 selects the model automatically once you choose a provider; confirm what your database records |
| Output as delivered | Shows what the user actually saw | Keep the original, including struck-through findings |
| Reviewer and decision | Accountability sits with a person | A named, registered approver; the requester does not approve their own run |
| Resulting entry | Links the finding to the books | Draft, approval, posting; corrections by reversal, never deletion |
| Retention | Evidence must outlive the chat | Stored conversations are kept up to 30 days after the last message; copy what you need into the record or working papers |
Where does Odoo 20 help, and where are the gaps?
According to Odoo’s 20 release notes, several AI features point the right way. AI-powered financial insights answer questions about the company’s finances based solely on accounting data in your database, and can review suspected reconciliation errors and return findings and recommendations. Agents show live progress, can reprocess sources manually, ask before exceeding their tool call limit and request permission through buttons. Outside AI, cash journal entries are hashed on reconciliation, user group changes are logged in the user’s chatter, and bank statement attachments are available in Accounting and Documents, which keeps the source document close to the entry.
The gaps are about evidence, not capability. Conversations are kept up to 30 days, shorter than any audit cycle. Automatic model selection means a re-run may not use the same model, so re-performance should re-check the cited records rather than re-ask the question. And an answer based on accounting data is only as good as that data: if bills are miscoded, the insight repeats the error with confidence. Confirm in your own database which AI features your edition and plan include and what each run logs. More on agent behaviour in Odoo 20 AI agents under finance controls.
How should an auditor test an AI-generated finding?
- Re-perform from the cited records: open each record id and confirm the facts in the finding.
- Trace to source documents: the bill, the bank statement line and the approval, not only the ledger.
- Test completeness: confirm the run covered the whole population for the period, not a filtered view. This is what makes full-population testing with AI defensible.
- Review rejected findings too: a pattern of struck-through claims tells you something about the instruction or the data.
- Document under ISA 230: what was run, on which records, who reviewed it and what was concluded.
A finding that survives these steps is a lead with evidence. It is still not a conclusion about fraud or misstatement; that judgment stays with the auditor, as we stress in AI-based fraud detection.
What about corrections drafted by AI?
Provenance matters most when AI moves from finding to fixing. Our rule set: agents draft correcting entries and adjustments; a named, registered person approves; above the client’s ISA 320 materiality threshold a second approver is required; corrections are made by reversal, never deletion; nothing is auto-posted. The trail then reads end to end: records retrieved, finding, draft entry, approver, posted reversal. Who may approve what is a segregation question, covered in AI and segregation of duties, and the principle is set out in agents draft, people approve.
Where to start on Monday
- Pick one AI output your team already uses, such as an overdue receivables answer, and ask for the record ids behind it. If they cannot be produced, stop using it in reports.
- Write a one-page AI evidence standard: what each run must log, who reviews it, how long evidence is kept.
- Move any AI output used in a report or entry into the record or a working paper within the 30-day window.
- Version the instructions of every agent that touches finance, and review changes before they go live.
- Add a re-performance check on a few AI findings to each month-end close review.
This is the discipline behind seg-audit, MFT’s continuous audit platform. It reads the books straight from the ERP, read-only, scores every transaction by risk, and works to one rule: "No number without evidence". Findings stay on record with evidence and severity, repeats are linked to earlier findings, a finding cannot be closed without a named, registered approver, and the evidence trail is usable by external auditors. The Auditor agent applies evidence or silence today as a managed service and is being integrated into seg-audit’s report pipeline, where its output will enter a two-stage human approval chain as a draft; that integration is in final review, not yet live. For the case for continuous evidence, read what the annual audit misses in eleven months, or talk to our internal audit team.