AI Hallucinations in Accounting: Catch Them Before Posting

In a survey of 100 mid-market CFOs, 86% said their finance team had run into inaccurate or hallucinated data while using AI. The error itself is not the problem. The problem is an error that reaches the general ledger, where it flows into reconciliations, reports and the audit.

TL;DR: Put a posting gate between AI and the general ledger. Every AI-proposed entry should tie to a source record, balance, hit a valid open period, pass a duplicate check, clear your auditor's red-flag screen and route to a named reviewer above set thresholds. Log each check so the decision can be replayed later.

What does an AI hallucination look like in accounting?

An AI hallucination in accounting is a figure, account, date or explanation the model produced that no source record supports. In a chat window it is an annoyance. In a journal entry it is a misstatement waiting for a reviewer to miss it.

In finance work, hallucinations rarely look strange. They look like normal entries. The common shapes are:

• Invented amounts: a number with the right number of digits and the wrong value, often a round figure the model "estimated."
• Phantom support: a description that cites an invoice, PO or contract that does not exist in your systems.
• Wrong account or period: a plausible GL account that is inactive, or a date in a period that is already closed.
• Arithmetic that does not foot: lines that do not sum to the stated total, or a split that loses a few cents.
• Confident explanations: a memo that sounds right ("per the signed SOW") with nothing behind it.

The 86% figure comes from a Maximor-commissioned survey run by Wakefield Research in late September 2025, so treat it as a vendor survey. The same survey found 97% of respondents call human oversight critical for accuracy (Journal of Accountancy, Feb 2026; CFO Dive, Jan 2026). Oversight is the right instinct. The question is what the overseer actually checks.

Why is the general ledger the right place for the gate?

You could review AI output everywhere: in the chat, in the draft workpaper, in the final report. That spreads attention thin. The ledger is the one choke point every error must pass through before it can cause damage. Catch it there and the error never reaches a reconciliation, a flux review, a board pack or an auditor's sample.

It is also where your auditor already looks. Under PCAOB AS 2401, auditors examine journal entries because "material misstatements of financial statements due to fraud often involve the manipulation of the financial reporting process by... recording inappropriate or unauthorized journal entries" (PCAOB AS 2401.58). An AI-proposed entry is not fraud, but it gets tested with the same lens. If you have not screened it, they will.

For a broader view of why controllers hold back on AI autonomy, see why finance teams are still wary of giving AI control.

What controls catch AI errors before they reach the general ledger?

A posting gate is a set of automated checks every AI-proposed entry must pass before it can post, with failures routed to a person. Seven checks cover most hallucination patterns:

• 1. Source tie-out: every line references a source record (bank line, invoice, contract) that exists, and the amounts match; catches invented amounts and phantom support.
• 2. Balance and foot: debits equal credits and lines sum to the stated total; catches arithmetic errors.
• 3. Account and period validity: the account is active and the date falls in an open period; catches wrong account or closed-period entries.
• 4. Duplicate check: no prior entry with the same source reference, amount and account; catches double-booking.
• 5. Red-flag screen: the AS 2401.61 characteristics (rare accounts, period-end entries with thin descriptions, round numbers); catches entries an auditor will pull.
• 6. Threshold routing: entries above an amount, in sensitive accounts, or below a confidence floor go to a named reviewer; catches what the rules cannot.
• 7. Decision log: every check result, the model version, inputs and the approver are recorded; makes the decision replayable later.

Checks 1 through 4 are deterministic. They do not need judgment, so they should never depend on someone remembering to look. Checks 5 and 6 decide what a human sees. Check 7 is what lets an auditor reperform the work.

This lines up with COSO's February 2026 publication, Achieving Effective Internal Control Over Generative AI, which lists "output validation and exception handling" and "logging/traceability (model/version, prompts, key inputs/outputs, approvals)" among its control building blocks (Deloitte Heads Up summary).

Want every proposed entry to arrive with its source rows, the checks it passed and the SQL behind them? Join the Yoraito waitlist for early access.

How do you test an AI-proposed entry with SQL?

The checks above are only controls if they run the same way every time. Written as SQL against a staging table of proposed entries, they become repeatable and reviewable. Here is the source tie-out and balance check in one query:

SELECT p.entry_id,
SUM(p.debit) - SUM(p.credit) AS imbalance,
COUNT(*) FILTER (WHERE s.source_id IS NULL) AS lines_without_source,
COUNT(*) FILTER (WHERE s.amount <> p.debit + p.credit) AS amount_mismatches
FROM proposed_entry_lines p
LEFT JOIN source_records s ON s.source_id = p.source_ref
GROUP BY p.entry_id
HAVING SUM(p.debit) <> SUM(p.credit)
OR COUNT(*) FILTER (WHERE s.source_id IS NULL) > 0
OR COUNT(*) FILTER (WHERE s.amount <> p.debit + p.credit) > 0;

Any entry this query returns does not post. It goes to the exception queue with the failing check named.

A worked example (illustrative). On the last day of the month, an AI agent proposes an accrual: debit 6420 Consulting Expense $48,000, credit 2100 Accrued Liabilities $48,000, memo "Accrued consulting per PO 7731." The gate runs:

• Source tie-out: fail; PO 7731 does not exist in the purchasing system.
• Balance and foot: pass; debits equal credits.
• Account and period validity: pass; account active, period open.
• Duplicate check: pass; no matching prior entry.
• Red-flag screen: flag; period-end entry, round amount, seldom-used account.
• Threshold routing: routed to the controller; amount above the review limit.
• Decision log: rejected by the reviewer, reason recorded, entry never posted.

The memo read like a normal accrual. Only the tie-out exposed it. That is the point: a reviewer skimming 200 entries at month-end would likely have approved it.

Which auditor red flags apply to AI-proposed entries?

AS 2401.61 lists the characteristics auditors use to select journal entries for testing. Each one maps cleanly onto AI output, and one maps uncomfortably well:

• Unrelated, unusual or seldom-used accounts: models pick plausible accounts, not necessarily the ones your team uses.
• Made by individuals who typically do not make journal entries: an AI service account is, by definition, a new preparer. Give it its own user ID so its entries are easy to isolate.
• Period-end or post-closing entries with little explanation: AI accruals cluster at period end. Require a source reference, not just a memo.
• Entries without account numbers: block any proposed line that maps to a name and not an account ID.
• Round numbers or consistent ending numbers: estimates from a model often land on round figures. Flag them for tie-out.

Running this screen yourself before posting means you see the same list your auditor will pull, months earlier. Our AI accounting software RFP questions cover how to check whether a vendor logs enough to support it.

How do you know the posting gate is working?

A gate that never rejects anything is either perfect or broken. Track a few measures each close:

• Rejection rate by check: which check fails most tells you where the model is weak.
• False-positive rate: flags a reviewer clears with no change. Too many and reviewers start rubber-stamping.
• Reviewer time per exception: if this climbs, the queue is not giving reviewers enough context.
• Errors found after posting: corrections to AI-proposed entries that passed the gate. This should trend toward zero; each one is a missing check.

These are the same measures worth tracking in a trial. Our 30-day AI accounting pilot scorecard shows how to set baselines before you start, and why AI journal review needs governance covers who owns the review once you scale.

FAQ

Can AI make mistakes in accounting?

Yes. Language models can produce amounts, accounts or explanations that no source record supports. In a Maximor-commissioned survey, 86% of mid-market CFOs said their team had encountered inaccurate or hallucinated AI data. The fix is not avoiding AI but checking its output before it posts.

Who is responsible when an AI-proposed entry is wrong?

The company is. Management owns its financial statements and its internal controls, whoever or whatever prepared the entry. That is why AI-proposed entries need the same review and approval evidence as any other entry, plus a log of what the AI did.

Should AI be allowed to post journal entries directly?

Only behind a posting gate. Low-risk entries that pass every deterministic check can post with a logged approval rule. Entries that fail a check, hit a red flag or exceed a threshold should wait for a named reviewer.

How do you stop AI from hallucinating financial data?

You cannot fully stop it, so design for detection. Make the AI retrieve figures from source records instead of generating them, require a source reference on every line, and run deterministic checks (tie-out, balance, period, duplicates) before anything reaches the ledger.

See the checks behind every entry

Before your next close, write the seven checks next to your AI workflow and mark which ones run automatically today. Any check that depends on a reviewer remembering to look is a gap. Yoraito is built so finance teams and auditors can check AI output, not trust a black box. To hear when it opens up, join the waitlist.