Why accounting AI should show its evidence

A confident answer is not evidence

ICAEW advises accountants to treat AI output as a starting point and validate technical claims against trusted sources. It warns that generated content can be inaccurate, outdated, or fabricated while sounding convincing. Professional scepticism—the habit of questioning information before relying on it—still applies. [1] ICAEW: Using AI with confidence: how to validate AI content (opens in a new tab)

NIST describes this problem as confabulation: confidently presenting incorrect or false content. Its generative AI risk profile also warns that supporting logic and citations can themselves be fabricated. Asking a model to explain an answer does not establish that the explanation is true. [2] NIST: Generative Artificial Intelligence Profile (NIST AI 600-1) (opens in a new tab)

That distinction matters in accounting. “This payment belongs to invoice A” is a claim. The bank line, invoice, customer record, and comparison of their details are things a reviewer can inspect. A confidence label can help prioritise work, but it should never stand in for those checks.

What a reviewer should see

For BLVNK, showing evidence means making the basis of a recommendation accessible at the point of review. We propose five practical questions:

• Which records support it? Link to the relevant bank line, ledger entry, invoice, or receipt, with the client and accounting period visible.
• What was compared or calculated? Show amounts, dates, references, inputs, and calculation steps that a person can check.
• Which rule or assumption was applied? Identify the basis of the suggestion. For technical guidance, show the source, jurisdiction, and relevant date rather than a detached quotation.
• What is missing or contradictory? Distinguish a retrieved fact from an inference, and show gaps that could change the result.
• What needs a decision? Make it clear whether the practitioner is being asked to approve, correct, request evidence, or investigate.

A link alone is not enough. The source must exist, support the particular claim, and apply to the case. Nor does attaching a document establish that it is complete or reliable. These are checks for the reviewer, supported by the interface.

A match you can challenge

Consider an illustrative reconciliation: a R12,000 bank receipt appears to match an open R12,000 invoice. The amount agrees, but the payment reference points to another customer. A suggestion based on amount alone would hide the detail that matters.

This is the value of evidence in the workflow: the practitioner can challenge the suggestion without reconstructing the entire case. The system helps assemble the comparison; the person decides whether it holds.

Make the gaps visible

“No supporting invoice found” is useful information. “A possible match was found, but the customer differs” is more useful than a reassuring label that omits the conflict. Missing evidence should lead to a visible question, not be filled in by a plausible narrative.

The same principle applies to technical research. A source from another jurisdiction, an old version of guidance, or a passage that does not support the conclusion should be surfaced for review. ICAEW’s validation guidance reinforces the need to move from generated answers to trusted technical material. [1] ICAEW: Using AI with confidence: how to validate AI content (opens in a new tab)

Evidence also needs boundaries. A reviewer should see the records relevant to their client and decision, with access controlled appropriately. More context is helpful only when it is relevant and available to the right person.

Keep the decision traceable

Evidence supports a decision; it does not remove the need for judgement. In the adjacent field of audit, IAASB has published guidance on the risk of overreliance on automated tools and on information produced by an entity’s systems. That guidance is non-authoritative and does not replace the auditing standards. [3] IAASB: Addressing Risk of Overreliance on Technology (opens in a new tab)

Our design conclusion is that a review should leave a usable trail: the recommendation, the source records and versions considered, the practitioner’s decision, any correction, and when it happened. If a record later changes, the team should be able to distinguish what was reviewed then from what is available now.

For BLVNK, this is a principle for accounting intelligence: keep available evidence close, expose uncertainty, and make the practitioner’s decision explicit. It is a direction for how we build and evaluate the product; availability depends on the workflow and enabled features.

The useful question is not only “Can AI produce an answer?” It is “Can an accountant inspect its basis, challenge it, and explain the decision that followed?”