AI-powered invoice recognition: how to catch numerical errors

It is impossible to guarantee that the model will never make a mistake in the amount. Neither an expensive model, nor a detailed prompt, nor a strict answer format provides such a guarantee. What makes the process reliable is a set of safeguards: extracted fields are checked arithmetically, matched against reference data, and screened for duplicates; anything uncertain is sent to a person before the invoice is entered into the accounting system or sent for payment.

The main condition is simple. The AI is responsible for reading the document, and the "accept or stop" decisions are made by rules that you can check. After this article, you'll be able to determine what checks are needed for your invoice flow, where to set the threshold for automatic processing, and how to calculate how much it will cost to manually check exceptions. We do not promise zero recognition errors. We explain how to prevent an error from slipping through into the accounting system.

Why numerical errors are more dangerous than typos

A typo in the vendor name is usually noticeable. An error in a number looks like a normal number. It passes the format check, is not highlighted by any field validator, and is easily missed by an accountant who reviews a hundred documents a day.

Here are the typical cases that occur in non-standard scans:

• Decimal separator shift. “1,440.00” becomes "144000" or "14400" because the model treated the comma as a thousands separator or failed to detect it in a blurry scan.
• Sign missing. A credit note with a negative amount is interpreted as a standard invoice payable.
• Wrong currency. The currency symbol appears in the header but not in the line items. The model substitutes the default currency.
• Confused fields. "Amount without tax" is written in the "To Pay" field, or a previous balance is added to the current amount.
• Bank details. One changed digit in the IBAN does not affect the arithmetic, but the money will go to the wrong place.
• Confused dates. "03.04" could mean April 3rd or March 4th depending on the supplier’s country-specific date format. Payment deadlines, reporting periods, and duplicate detection all depend on the date, so an error here can cause further errors.
• Unit price instead of row sum. In tables without clear column boundaries, the model sometimes takes the adjacent number. The line total then looks plausible, but doesn't match quantity multiplied by price.

All of these cases have one thing in common: the value has the correct type and a plausible appearance. Therefore, it is necessary to check not "does it look like a number", but "does this number agree with other numbers in the document and with what we know about the supplier".

Extraction and normalization: keep the source fragment next to the value

First, a model or specialized document-recognition service extracts the fields. Prebuilt invoice models can already identify common fields. For example, the out-of-the-box invoice processing model in Microsoft AI Builder can extract the invoice number, date, supplier, tax-exclusive amount, tax amount, total amount, amount due, payment details such as IBAN, and item lines with quantity and unit price. The model also returns a confidence score for these fields.

The second step is often overlooked: normalization. The recognized text “UAH 1,440.00” must be normalized to the numeric value 1,440.00 and the currency code UAH. This is where many mistakes are born, so keep three things together:

1. Source fragment, as read from the document: "1,440.00 UAH".
2. Normalized value: 1440.00, UAH.
3. Location in the document: page, area, table row.

When an accountant sees both the source text and the normalized value in the exception queue, they can quickly tell where the problem occurred: whether the model misread the digits or the code parsed the format incorrectly. Without the source fragment, a person is forced to open the scan and search for the field manually, which erodes the savings from automation.

A note about structured output: if you ask a language model for JSON that follows a schema, Structured Outputs guarantees schema conformance only for a successful, complete response that is neither a refusal nor truncated because of a token limit: all required keys are present and the data types match. It does not guarantee that the total field contains the correct amount. Handle refusals and truncated responses separately in code. Correct JSON only means correct form, not correct content.

Arithmetic checks: let the invoice check itself

Most invoices contain overlapping information. Quantity, price, line total, subtotal, discount, tax, and total are all related. Use this overlap as a built-in check.

A basic set of checks:

• Line item: quantity × unit price = line total.
• Subtotal: the sum of all line items = the amount before tax.
• Discount: subtotal minus discount = taxable base, if the discount applies before tax.
• Tax: taxable base × tax rate = tax amount, subject to rounding rules.
• Total: taxable base + tax = total amount.
• Amount due: total amount ± previous balance or advance payment = amount due, if these fields appear in the document.

Rounding deserves special attention. Tax may be rounded for each line item or once for the entire document. The difference between the two methods is sometimes a few cents. Therefore, the check should allow an error you specify, for example up to 0.01 per line or a few cents per document, but no more. Write down the tolerance rule clearly and agree with the accounting department, and do not make it up in the code "by eye".

An important caveat: the tax rate in the examples is hypothetical. Rates and rules vary by country, provider status, and type of transaction. Your system should use the rate from its own settings or from the document, not from an illustrative example.

Example: a correctly formatted number that fails validation

This hypothetical invoice was created for illustration and is not from a real project:

The value 14400 has a valid numeric format, and the model's structured response with it is perfectly valid. However, the arithmetic of the document refutes it: 1200 + 240 equals 1440. The document is sent to the exception queue with the reason "discrepancy of the total amount", and the accountant sees the original fragment "1,440.00 UAH" and the normalized 14400.

A second check in this example finds that the accounting system already contains an invoice from the same supplier with the same invoice number. Even if all amounts match, the document is held as a possible duplicate.

None of these checks confirm payment details. If the IBAN on the invoice has changed, the arithmetic will remain flawless. Payment details require a separate check, described below.

Supplier reference data and duplicate checks

Arithmetic catches the document's internal contradictions. Reference data helps catch inconsistencies between the document and your records.

Supplier. Look it up in the directory by tax identification number, not just by name. A supplier’s name can be written in many ways, but its tax ID is unique. If the supplier is not in the directory, it's not necessarily an error, but it's definitely not a reason for automatic recording.

Payment details. Compare the recognized IBAN with the one stored in the supplier’s record. Any change of details must be confirmed separately, preferably through a channel not related to the account itself: a call to a contact listed in your directory, not to the number in the email. This rule protects not only against recognition errors, but also against fraudulent emails with "updated details".

Duplicates. Search for matches using a combination of fields: supplier + invoice number + date + amount. Check separately for near-duplicates: the same supplier and amount on close dates with different numbers. It happens that the same document may arrive by email and through a portal, then be scanned twice.

Purchase orders and delivery records. If you have a purchase order, reconciling it provides another layer of control: whether the quantities, prices, and items match. Here, AI is not needed at all, ordinary business logic is enough.

All these rules live outside the model. The model should not decide whether an invoice is a duplicate, and should not be allowed to change the vendor details in the directory.

Exception queue: where anything uncertain goes

The exception queue is the heart of the process. A document goes to the queue if any one of these conditions is met:

• critical field recognition confidence is lower than your threshold;
• fails any arithmetic check;
• the supplier is not found in the directory;
• the details differ from the saved ones;
• a possible duplicate was found;
• the model refused to answer or the answer is incomplete.

It is worth saying more precisely about the confidence threshold. In Document Intelligence, the confidence field is a probability estimate between 0 and 1: a value of 0.95 means the prediction is likely to be correct about 19 times out of 20. For scenarios where accuracy is critical, confidence can be used to accept a result automatically or flag it for human review. Text-recognition confidence and key-value extraction confidence are different measures, and both should be checked.

The threshold is therefore a routing tool, not a guarantee. High confidence does not prove that the amount is correct. It only means that the model is "confident". Arithmetic verification and reference checking are still required for each document, regardless of confidence.

Choose the threshold based on observed results. Take a sample of documents where the correct values ​​are known. See how many errors the model makes at different confidence levels. The working threshold is the one at which the share of errors that slip through becomes acceptable for your business. Use a higher threshold for critical fields such as the amount due or IBAN than for a shipping address.

The queue interface should show the person the reason for the stop, the output fragment, the normalized value and the results of the checks. A person corrects the field, the system reruns the checks, and only after that the document moves on. Log every correction: it provides evidence for assessing quality.

Measuring quality: three metrics instead of one “accuracy” score

A common mistake when launching is talking about "98% accuracy" without specifying what exactly is being measured. In fact, you need at least three separate metrics.

Field-level accuracy. The share of individual fields recognized correctly. Calculate separately for each critical field: account number, date, amount due, tax, IBAN. The total figure for all fields hides the problem, because addresses and names make up the majority of fields, and errors in sums occur less often, but cost more.

Document-level accuracy. The share of documents in which all critical fields are correct at the same time. If there are ten critical fields in a document and each one is recognized correctly 98% of the time, the share of fully correct documents is considerably lower. If field errors are independent, the probability that all ten are correct is 0.98 to the tenth power, or about 0.82. This is a conditional calculation for illustration: in practice, errors are often related to each other, because a bad scan corrupts several fields at the same time. Therefore, the accuracy of the document is almost always lower than the accuracy of the fields.

Share processed without manual review. The share of documents that passed all checks and were entered into the accounting system without human intervention. This is a key business metric, but should be read in conjunction with the first two. A high rate of automated processing while errors remain unchecked is not a saving; it is a problem deferred until month-end.

Another metric worth tracking is missed errors. They are found later, when reconciling with the supplier or closing the period. Each such error is a signal that validation is missing or the threshold is too low.

Calculate the cost of manual review realistically: number of documents in the queue × average review time × the specialist’s hourly cost. Compare it with the cost of an error that would have passed without inspection. Then the decision about the threshold becomes economic rather than intuitive.

What to do in your process

1. Collect a sample of real invoices, including the worst scans and non-standard forms, and label the correct values for critical fields.
2. Determine the list of critical fields and calculate the recognition accuracy for each one separately.
3. Calculate document-level accuracy: the fraction of documents that have all critical fields correct.
4. Record the arithmetic rules, the rounding tolerance and the source of the tax rates together with the accounting department.
5. Set up supplier-directory matching, payment-detail checks, and duplicate detection outside the model.
6. Set confidence thresholds based on sample results, not defaults.
7. Calculate the share of documents sent to the exception queue and the cost of reviewing those documents.
8. Keep a log of fixes and errors discovered later and review thresholds monthly.
9. Leave payment decisions to a separate process with its own powers.

Frequently asked questions