AI Invoice Extraction Must Not Invent Missing Facts

AI Trust & Governance

31 October 2026 | By Ashley Marshall

A blank field can be the correct answer. Your invoice automation should not hide missing evidence behind a plausible number.

A complete-looking invoice record can be the wrong result

The dangerous invoice extraction error is not always a scrambled number. Sometimes it is a sensible-looking answer to a question the source never answered. A model sees a UK supplier address and fills in GBP. It sees a familiar product and supplies a VAT rate. It sees a subtotal and calculates a missing tax amount. The resulting record looks tidier than the original document, which makes the unsupported parts harder to spot.

None of those operations is automatically useless. The problem is presenting them as the same kind of evidence. Copying a printed currency code, converting an unambiguous date into a standard format, calculating a reconciliation difference and guessing a tax treatment are four different activities. Your accounting workflow should preserve that distinction before anyone approves a transaction. Otherwise an apparently successful integration quietly changes what the business believes the supplier actually said.

This matters because modern document tools explicitly support inference. Google's derived-field documentation distinguishes direct extraction from values generated using document context. Its examples include inferring a currency from an ambiguous symbol or address. That is a named product capability, not evidence that every inferred currency is suitable for posting to your ledger. The documentation also identifies the feature as public preview.

For a UK finance manager, the useful question is therefore not simply whether AI can read invoices. It is whether the exported record tells you which values were printed, which were transformed and which were suggested. Make missing information visible. A blank that sends the invoice to the right reviewer is often a better operational result than a confident answer that bypasses them. This is a provenance decision, not a competition to produce the fullest spreadsheet.

Give extracted, calculated and suggested values separate homes

Start with a field policy rather than a longer prompt. For each piece of information, decide whether it must come from the document, may be normalised under a stated rule, may be calculated for checking, or may be suggested for review. Invoice number, payment destination and printed totals normally need direct evidence. A proposed cost category may legitimately use business context, provided it remains visibly a proposal rather than an approved accounting decision.

The record should retain the original value, the standardised value where appropriate, and a source reference. For a date, that might mean preserving the printed text alongside its interpreted date and the assumption used. An ambiguous date should not become certain merely because the destination system requires a date field. If the interface cannot represent uncertainty, hold the document outside the automatic posting route until the ambiguity is resolved.

Google explains that directly extracted fields can include text and page anchors, while derived fields do not have those anchors because the value is not directly present in the text. Its response documentation describes the relationships between recognised text, layout and source positions. Use the evidence your selected processor actually provides; do not invent page citations for generated values.

What this means in practice is straightforward. Ask your supplier to demonstrate an invoice with no currency code, an unreadable invoice number and a tax line that does not reconcile. Watch the exported record, not just the review screen. Each unresolved field should remain unresolved after export. Calculated checks should sit beside the source facts, and a review decision should identify who accepted the correction. Test that separation in your accounting system before discussing higher automation volumes or additional model features.

Confidence is a routing signal, not permission to pay

Confidence scores are useful, but they answer a narrower question than many buying conversations suggest. A tool can be confident that it read a number correctly while the business still has no evidence that the invoice is genuine, the purchase was authorised or the payment destination is legitimate. Those are separate checks against separate records. A crisp scan of a fraudulent invoice can produce an excellent extraction.

Microsoft's Document Intelligence confidence guidance, updated in October 2026, describes field confidence on a scale from 0 to 1. It uses 0.95 as an estimated probability example, not a guarantee for your invoice population. The same guidance says that not all fields return confidence and recommends human review for critical workflows. A vendor score is not your independently measured error rate.

The documentation also makes a particularly useful distinction between cells, rows and tables. An individual cell can have high confidence while its row or table is less reliable. A correctly read price is not enough if the quantity belongs to the next product. Ask reviewers to inspect relationships as well as values, especially where descriptions wrap over several lines or a table continues on another page.

Set review rules around consequences. Missing invoice identifiers, changed payment details, unresolved currency and failed reconciliation deserve an explicit hold. Lower-risk descriptive fields can follow a different route. Where a score is unavailable, record it as unavailable rather than asking a language model to make up a percentage. Never treat a high score as a substitute for supplier verification or payment authorisation. Your finance owner should approve the routing policy and see evidence that holds survive every subsequent export and integration step.

Arithmetic can expose a problem without settling its cause

Simple arithmetic remains one of the strongest controls available, provided its purpose is clear. Compare line totals with the stated subtotal, and compare the stated components with the final amount. A mismatch is a reason to investigate. It is not permission for the model to silently repair the invoice. The missing explanation might be a discount, delivery charge, credit, rounding convention or a row the extraction missed.

Consider an illustrative invoice showing a £1,000 subtotal and £1,200 total but no readable VAT line. A system can calculate a £200 difference. It should label that as a calculated difference, not as £200 of verified recoverable VAT. The same arithmetic could conceal a charge or an extraction error. Keeping those categories separate prevents a mathematically neat result from becoming unsupported accounting evidence.

HMRC's VAT guidance lists three rates: standard, reduced and zero-rated. The standard rate is currently 20% and the reduced rate 5%, but those figures are not a licence to assume the treatment of an individual purchase. Exempt and other situations require their own consideration. Use the applicable rules and appropriate invoice evidence, with your accountant resolving uncertainty where necessary.

What this means in practice is to store both the supplier's printed amounts and the results of your deterministic checks. Define sensible rounding tolerances with finance rather than letting the model choose one on each run. Route unexplained differences to a reviewer who can see the original pages. If a supplier issues a corrected invoice, preserve the relationship between versions instead of rewriting history. Bank-detail changes should follow a separate trusted verification process even when every total adds up perfectly. Numerical consistency and commercial authenticity are different controls, and a good workflow needs both.

Test whether the system can leave a question unanswered

A demonstration built entirely from clean, complete invoices cannot show whether the system handles missing evidence responsibly. Build a small representative test set from documents you are entitled to use, with finance-approved expected results. Include clean digital PDFs, scans, multi-page tables and relevant supplier formats. Then deliberately include cases where the correct outcome is a hold, a blank or a request for clarification rather than a completed record.

Useful cases include an ambiguous currency symbol, a missing purchase order, an unreadable VAT registration number, a duplicate attachment and an invoice with a changed payment destination. Include credit notes and mixed tax treatments if they occur in your business. Do not quietly exclude difficult documents because they make the automation rate look worse. They tell you where the boundary should be drawn.

Current October 2026 commercial comparisons, including RevExOS's invoice parsing review, stress that published benchmark datasets differ from a buyer's own invoice mix. Treat such comparisons as leads for testing, not a universal supplier ranking. We would not turn a field-level research result into a promise that your invoices can safely go straight through to payment.

Measure unsupported values as their own error category. Also count missing rows, wrong assignments, required holds that were bypassed and reviewer corrections that failed to reach the destination. Separate recognition quality from the proportion of invoices that complete the approved workflow without intervention. For example, a proposed pilot might test 100 documents before any live posting; that is an illustrative starting point, not a statistical guarantee. Increase coverage according to variety and consequences. Keep a protected set of difficult cases for regression testing, and rerun it when a processor, prompt, schema or integration changes. The aim is not to prove that the system can always answer. It is to verify that it knows when the business must ask someone else.

Buy the evidence trail before buying more automation

You may not need a custom build. Start by checking the capture and approval features in the accounting or accounts-payable platform you already use. Ask whether it preserves originals, distinguishes suggested coding from extracted facts, and lets reviewers inspect the source. If specialist extraction is needed, compare established document processors against your test set. A general-purpose model is one option, not the default answer to every unreadable PDF.

The procurement conversation should cover export behaviour as carefully as the review interface. Can the system represent a missing value without converting it to zero? Can it retain the raw currency symbol separately from a proposed currency code? Does it preserve the source file and processing version? What happens if the destination rejects a field? An attractive screen is not enough if uncertainty disappears when the record reaches Xero, QuickBooks or another ledger.

The strongest counterargument is that people already infer missing information every day. That is true. An experienced accounts assistant may recognise a supplier's standard arrangement and resolve an omission quickly. But the appropriate comparison is not human intuition versus rigid software. It is an accountable person applying known context versus a generated value whose origin becomes invisible. Let the system suggest, then give an authorised person the context and a clear acceptance decision.

For the first rollout, keep extraction separate from payment release. Name the finance owner, agree hold conditions, test the review route and record how corrections flow downstream. Retain source documents according to your existing legal and business requirements, with access limited to those who need them. Review a sample of automatically accepted records as well as exceptions, because silent errors will not volunteer themselves. The commercial benefit is less avoidable rekeying without losing the distinction between evidence and assumption. If your supplier cannot demonstrate that distinction on a deliberately incomplete invoice, delay expanding the workflow. A faster guess is still a guess, however polished the dashboard looks.

Frequently Asked Questions

Should an AI invoice tool ever calculate missing amounts?

It can calculate a check or propose a value, but should label that separately from amounts printed on the invoice. Finance must approve how any proposal can be used.

Is a confidence score of 0.95 enough for automatic posting?

Not by itself. Validate performance on your invoice mix and combine field confidence with source evidence, reconciliation, supplier checks and an approved review policy.

What should happen when the currency is missing?

Preserve the missing value and hold the invoice unless an authorised process resolves it using reliable evidence. A supplier address alone is not a printed currency code.

Can I assume 20% VAT on a UK supplier invoice?

No. The standard rate does not establish the treatment of a particular transaction or provide the invoice evidence needed for a claim. Refer uncertain cases to finance or your accountant.

Do we need a custom AI system?

Not necessarily. Test the capture, evidence and approval features of your existing accounting platform before commissioning custom integration.

What source evidence should reviewers see?

Provide the original invoice and relevant page or text location where supported, plus raw values, checks, changes and the reason for any hold.

How do we test whether AI invents missing values?

Include documents with intentionally absent or ambiguous fields and define the expected blank or hold in advance. Count unsupported populated values separately from ordinary recognition errors.

Should invoice extraction also release payments?

Keep those responsibilities separate during initial rollout. Extraction quality does not prove supplier authenticity or payment authorisation.