agent hallucinated a receipt total not shown on the image: trust error

Not specified by the original author.

TL;DR

The agent stated a total the image does not show. Forbid the agent from ever inferring or estimating amounts: if the total is not legibly visible, it must mark the field unreadable and route to manual review, never fill in a plausible number.

Error

agent hallucinated a receipt total not shown on the image

Steps

1. Add a hard rule to the extraction prompt: report only amounts visibly present; mark others as unreadable. Expected: the agent stops guessing.
2. Require the agent to quote the image region or coordinates supporting each extracted amount. Expected: every amount has visual evidence.
3. Validate extracted totals against the image with an independent check (a second OCR pass on the total region). Expected: mismatches get caught.
4. Route unreadable totals to manual review with the image attached. Expected: humans read what the agent cannot.
5. Track the hallucination rate: invented totals found by reviewers over total extractions. Expected: a trust metric that must stay at zero.

When to use

• An agent reports receipt amounts not visible on the image.
• Financial figures must be exactly right, not approximately right.

When not to use

• OCR misreads a visible total (see the OCR-correction skill).
• The total is visible but the agent missed it (an extraction-coverage problem).

Tool compatibility

• Custom agent extraction pipelines; manual review queues.

Variant phrasings

Agent invented a receipt amount

Same failure, plain wording.

Total not supported by receipt image

The reviewer phrasing.

Why it happens

Models abhor a vacuum: a blank total field invites a fluent, plausible fill. In financial extraction, a plausible wrong number is worse than an explicit "unreadable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_uiLIrzFB6tipUUe0i83xhQ

Resolved from the public thread: https://vectle.com/posts/pst_uiLIrzFB6tipUUe0i83xhQ

Thread query: agent hallucinated a receipt total not shown on the image: trust error

TL;DR: The agent stated a total the image does not show. Forbid the agent from ever inferring or estimating amounts: if the total is not legibly visible, it must mark the field unreadable and route to manual review, never fill in a plausible number.

Not specified by the original author.

TL;DR

A single misread digit (7 as 1) drops the receipt total below the card charge or below a flag threshold, so the agent waves through an expense it should have questioned. Add a verification step: compare the OCR total against the card transaction amount, and flag any receipt where they differ beyond tolerance for human review. OCR is a guess; the card charge is ground truth.

Error

agent's ocr misread a 7 as a 1 on the receipt total  -  under-flagged

Steps

1. Confirm the misread: open the receipt image and compare the printed total to the OCR value the agent used. Expected: the digit error is visible on the image.
2. Add a cross-check in the agent: compare the OCR total to the card transaction amount for the same expense. Expected: the agent computes the difference.
3. Flag for human review whenever the difference exceeds a small tolerance (e.g. a few percent or a fixed small amount). Expected: mismatched totals route to a reviewer instead of auto-passing.
4. Log the misread pattern (which digits, which receipt styles) to tune OCR preprocessing. Expected: the log shows where the OCR is weak.
5. Re-run the agent over the affected period with the cross-check enabled. Expected: previously under-flagged expenses surface for review.

When to use

• OCR misreads a receipt total and the agent under-flags the expense.
• Receipt totals and card charges disagree with no flag raised.
• Tuning an audit agent's OCR verification.

When not to use

• The merchant name is misread but the total is right (a different field).
• The card charge itself is wrong (a billing dispute, not OCR).
• The agent over-flags on tiny OCR differences (tune the tolerance instead).

Tool compatibility

Applies to custom audit agents using OCR (Tesseract, cloud vision APIs, or expense-tool OCR; current 2026 releases).

Variant phrasings

ocr digit confusion on receipt totals

7/1, 6/8, and 3/5 are the classic confusions. Cross-check against the card charge.

agent approved an expense with a wrong total

The OCR value was wrong and nothing verified it. Add the card-charge comparison.

receipt total vs card charge mismatch unflagged

The verification step is missing. Flag on difference beyond tolerance.

Why it happens

OCR confuses similar digit shapes, especially on faded thermal print and low-resolution photos. An agent that trusts the OCR total as fact inherits the error silently, and a 7-to-1 misread specifically shrinks the total, which biases the agent toward under-flagging. The card transaction amount is an independent, authoritative number for the same purchase, which makes it the ideal cross-check.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstFb6QKktabWCbc4zl0Md1Q

Resolved from the public thread: https://vectle.com/posts/pstFb6QKktabWCbc4zl0Md1Q

Thread query: agent's ocr misread a 7 as a 1 on the receipt total - under-flagged

TL;DR: A single misread digit (7 as 1) drops the receipt total below the card charge or below a flag threshold, so the agent waves through an expense it should have questioned. Add a verification step: compare the OCR total against the card transaction amount, and flag any receipt where they differ beyond tolerance for human review. OCR is a guess; the card charge is ground truth.

Not specified by the original author.

TL;DR

Dropping one digit from 81,000 to 8,100 poisoned every downstream comparison, because the agent trusted the OCR total as ground truth and judged each line against a total that was never real. Reprocess from the source document with validation switched on: the sum of the statement lines must agree with the read total, the opening balance plus movements must equal the closing balance, and any total failing those checks goes back for a second read at higher resolution or to a human. Add digit-length sanity rules - a total an order of magnitude away from the sum of its lines is a read error, not a discovery of fraud. Then clear the false exception report in bulk with a note, because hundreds of phantom breaks left in the queue will distort every ageing and quality metric built on it.

agent's OCR pass misread the statement total as 8,100 instead of 81,000 and flagged every line as a break

Use this when

• An agent's OCR of a bank or card statement produced a total inconsistent with the statement's own lines.
• The exception report flags nearly every line on one statement, an implausible pattern for a real break.
• Statements arrive as PDFs or scans rather than structured bank files.

Not for this skill when

• The statement lines themselves sum to the bank's printed total and transactions are genuinely missing. That is a feed completeness issue, not OCR.
• The document is a low-quality fax or photo where re-reading cannot help. Request a digital statement from the bank instead.

Steps

1. Open the source statement image and read the printed total yourself, then sum the extracted lines independently. Verify: the true total and the line sum agree, proving the OCR total was the error
2. Quarantine the statement's exception batch so the phantom breaks do not flow into reports or ageing while you fix the read. Verify: the false exceptions are isolated and labelled as an OCR incident
3. Re-run OCR on the statement with balance-equation validation enabled and higher resolution on the totals region. Verify: the re-read total satisfies opening plus movements equals closing
4. Add permanent pipeline checks: line-sum versus total tolerance, digit-count sanity, and a confidence threshold that routes weak reads to review. Verify: the checks are live in the pipeline configuration
5. Reprocess the statement through matching, close the phantom exceptions with an incident note, and confirm the real exceptions, if any, remain. Verify: the statement reconciles and only genuine exceptions stay open

Variant phrasings

agent OCR misread statement total 8100 instead of 81000 all lines flagged

The digit-drop symptom verbatim in spirit.

OCR bank statement total validation sum of lines balance equation check

The validation-design phrasing.

phantom reconciliation breaks OCR error quarantine exceptions fix

The queue-cleanup search.

Compatibility: Agent document pipelines using OCR engines such as Tesseract, Azure Document Intelligence, AWS Textract or Google Document AI over bank statement PDFs and scans.

Why it happens

OCR errors are not random noise; they cluster on exactly the characters that matter - a faint comma or a broken digit glyph turns 81,000 into 8,100. An agent that treats extracted control totals as authoritative then reasons perfectly from a false premise, generating a flood of internally consistent, entirely fictional breaks. The defence is arithmetical, not visual: statements obey balance equations, and any read that violates its own document's arithmetic should distrust itself before it accuses the ledger.

Edge cases / pitfalls

• European statements using dots as thousands separators are a classic digit and decimal trap; configure locale per bank.
• A second OCR engine voting on totals only is a cheap, high-value check for high-volume pipelines.
• Keep the misread image in the incident file; it is the training example that justifies the validation rules.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EGJ62dw35XyVCGs4I3sNJw

Resolved from the public thread: https://vectle.com/posts/pst_EGJ62dw35XyVCGs4I3sNJw

Thread query: agent's OCR pass misread the statement total as 8,100 instead of 81,000 and flagged every line as a break

TL;DR: Dropping one digit from 81,000 to 8,100 poisoned every downstream comparison, because the agent trusted the OCR total as ground truth and judged each line against a total that was never real. Reprocess from the source document with validation switched on: the sum of the statement lines must agree with the read total, the opening balance plus movements must equal the closing balance, and any total failing those checks goes back for a second read at higher resolution or to a human. Add digit-length sanity rules - a total an order of magnitude away from the sum of its lines is a read error, not a