An invoice total can look right and still be the wrong number

Treat an extracted invoice amount as unverified until it is tied to the source document, interpreted with the correct currency and number format, and checked against the intended transaction. OCR confidence can help route review; it does not establish that an invoice is valid, payable or correctly understood by a downstream AI tool.

India-based shared-service teams often process invoices for several markets. A decimal convention, credit-note sign or currency symbol can change the meaning of an otherwise readable field. This guide focuses on that handoff. It is not a GST compliance checklist or a claim about any specific finance platform's accuracy.

Preserve the original evidence and raw extracted text. Separate normalisation from interpretation. Validate critical fields individually, and prevent uncertain values from flowing into approvals or payment instructions. Keep a visible route for a reviewer to correct the value and explain the decision.

Assign each document a unique identifier and record its version, received date, page count and source. Keep the original file in the approved document store. If a supplier sends a replacement, link both versions and mark which one controls the current transaction; do not silently overwrite the evidence.

Before using a third-party tool, follow the organisation's approved data-sharing and retention arrangements. Invoices may contain personal contact information and financial identifiers. Apply redaction and data minimisation to test samples where appropriate, without removing fields needed to validate the extraction.

For invoice number, supplier identifier, currency, subtotal, tax, total and bank-related fields, preserve the source location, the raw extracted text and the proposed normalised value. A reviewer should be able to open the relevant page and identify the field that produced the value.

For example, keep “1.234,50” as raw text alongside a proposed value and the locale rule used to interpret it. Do not let an AI silently choose a decimal convention because it seems likely. A blank field, an unreadable field and an explicit zero need different statuses.

Microsoft's Document Intelligence guidance explains that confidence scores relate to model predictions and may differ by field and model. Some outputs may not have a confidence score. This vendor-specific guidance supports using confidence with other checks; it does not establish a universal score above which financial data is safe to accept.

Define critical fields before testing. A wrong invoice number can undermine duplicate detection; a wrong currency can change the payment; a lost minus sign can turn a credit into a charge. Treat these as separate failure cases rather than reporting only one average extraction accuracy.

Check arithmetic using the invoice's stated basis, including discounts, freight, tax and rounding. An arithmetic mismatch is a reason to investigate, not permission to alter the source amount until the numbers fit. Match supplier and purchase-order information to trusted records through the normal finance controls.

Use format and range checks as alerts. A plausible account number or total is not proof of a legitimate transaction. Keep bank-change verification and payment authorisation outside the extraction model's authority.

Create a labelled test set from permitted, appropriately protected documents. Include different suppliers, currencies, layouts, scans, credit notes, multi-page invoices and low-quality images that resemble the actual workload. Record the expected values independently before comparing model output.

Measure errors and review rates for critical fields separately. Record the document and model versions, configuration, date and known exclusions. Set acceptance and escalation criteria proportionate to the consequence of failure; there is no single confidence threshold suitable for all organisations.

When the supplier layout or extraction system changes, repeat the relevant tests before expanding automatic processing. Preserve a manual route for exceptions and identify who owns the queue so that a held invoice does not simply disappear.

A shared-service team in India processes a euro invoice containing a total of “1.234,50”. The extraction output proposes 1.23450 without currency context. A format check holds the field. The reviewer compares the original invoice, confirms EUR 1,234.50 against the supporting lines and records the locale interpretation before releasing the value downstream.

The document and figures are invented. This example illustrates evidence retention and a review decision, not a measured error rate or a rule that every comma is a decimal separator.

Extend the fictional euro invoice with these invented source values: net amount EUR 1,000.00, stated tax EUR 234.50 and stated total EUR 1,234.50. The tax figure is simply a source value for this exercise, not a tax rate or a conclusion about tax validity.

The control calculation is 1,000.00 + 234.50 = 1,234.50 EUR. If OCR instead supplies 1.23450, the mismatch is 1,233.26550 EUR before currency rounding. That is evidence of a parsing problem to investigate, not a legitimate adjustment to the invoice.

The completed fictional handoff is amount interpretation checked; payment not authorised. It carries the source version and reviewer rationale. If currency is missing, the amount remains held even when addition works. If the document is a credit note, the sign and downstream accounting treatment need their own check. Arithmetic agreement cannot establish supplier identity, authenticity, tax validity or the bank account's legitimacy.

Send an explicit status with the value: verified, held, rejected or superseded. Configure the downstream workflow to stop when required fields remain held. Avoid prompts that encourage a model to fill missing financial values from general knowledge.

If verified values feed a spreadsheet, test the spreadsheet calculations separately. At approval, retain the connection between the final number, source version and human decision. Extraction accuracy does not establish invoice authenticity, tax treatment or approval to pay.

Only the organisation's validated, risk-based workflow can determine the level of review. A score alone does not validate a transaction or its business context.

Preserve the source. Record a reviewed value and explanation in the processing record, with access controls and change history, rather than editing the original to match the output.

Use the other evidence and validation controls, and route uncertainty to review. Do not invent a confidence value.

AI assistance was used in preparing this article. No tool benchmark, client implementation or firsthand test result is claimed.

This article is general information. Verify current requirements and seek qualified advice for your specific circumstances.

Spotted an issue? Contact our editorial desk.