AI invoice checking: separate sums from evidence

Correct totals do not prove a correct invoice

AI invoice checking needs separate results. Do the numbers add up? Do the price and quantity agree with the order and delivery? A business should see both answers before anyone approves the invoice. One green tick hides the question that is still unresolved.

Consider a fictional invoice for twelve filters at EUR 18.50 each, excluding tax. A net total of EUR 222.00 and gross total of EUR 264.18 add up with an assumed 19 percent tax rate. The goods-receipt record confirms only ten filters, however. Two items, worth EUR 37.00 net, remain unexplained. The calculator has not seen the boxes.

Microsoft describes this separation in its invoice, purchase-order and receipt matching documentation. Our recommendation is to start with recurring goods purchases for which all three records are available.

Step 1: The input determines how you capture the data

The business separates structured data from document images. An electronic invoice contains machine-readable fields; a plain PDF does not meet that structured-format definition under the German finance ministry guidance. Process existing structured invoice data directly and validate its format instead of converting it into an image first.

For scans and plain PDFs, a document model can extract fields. Microsoft’s AI Builder invoice model returns items such as the invoice number, purchase-order reference and line quantities, units and unit prices. This captures the claim; it does not confirm that anyone ordered or received the goods.

Keep the original, extracted value and correction separate. Our German guide to preparing incoming invoices with AI covers capture from PDF to accounting list. This guide starts after that step.

Step 2: Fixed rules handle the arithmetic

The arithmetic check uses formulas rather than free-form AI answers. For each line, compare quantity times unit price with the stated amount, including agreed discounts, charges and price units. A price per hundred items must not be treated as a price per item. Leave missing values unresolved. First check whether the extracted unit price includes tax.

For the filters, calculate 12 × 18.50 = 222.00; 222.00 × 0.19 = 42.18; 222.00 + 42.18 = EUR 264.18. We checked this calculation using decimal arithmetic in Python. The same formulas in a spreadsheet are enough for a first trial. They do not establish which tax treatment applies to the transaction.

Define the rounding rule too: round each line or each tax group? Mixed tax rates, credit notes and advance payments need their own rules. Unknown variants stop the comparison. The e-invoice validation described by the German finance ministry checks format and business rules; it does not provide evidence of delivery.

Step 3: Orders and receipts provide the comparison

Document matching needs trustworthy reference records. Store the order line with its agreed price and unit, together with the confirmed receipt allocated to this invoice. Two-way matching compares prices against the order; three-way matching also checks quantities against goods received. This is the distinction in Microsoft’s Dynamics 365 Finance documentation. You do not need that particular product to apply it.

In our example, the invoice stays on hold because two filters are unaccounted for. The responsible person checks whether a receipt was not recorded, a partial delivery occurred or the invoice needs correcting. AI may summarise the discrepancy. It must not invent a missing delivery note or adjust the receipt to fit the invoice.

For services, use a confirmed record of work instead of a goods receipt. Our German guide to comparing supplier offers with AI in Excel shows how purchasing can prepare comparable data earlier. Define acceptable price variances explicitly rather than adopting a percentage from a vendor’s example.

Step 4: Five test cases expose different exceptions

The test starts with known expected results. We ran these synthetic records through fixed Python rules: one clean case and four deliberately introduced discrepancies were separated as expected. This tests the reference rules, not an AI recognition rate. Use the same cases as an acceptance checklist for your own workflow.

• Case A, clean: 12 received, 12 invoiced, agreed unit price EUR 18.50, net EUR 222.00 and gross EUR 264.18. Expected: the arithmetic and document comparisons tested here pass; approval remains separate.
• Case B, arithmetic error: as A, but net EUR 220.00, tax EUR 41.80 and gross EUR 261.80. Expected: hold the line amount; checking net plus tax alone would miss the error.
• Case C, quantity discrepancy: invoice as A, but only 10 items on the confirmed receipt. Expected: two items unresolved even though every total adds up.
• Case D, price discrepancy: 12 items at EUR 19.50, net EUR 234.00 and gross EUR 278.46; order price EUR 18.50. Expected: price exception despite correct invoice arithmetic.
• Case E, possible duplicate: as A, with supplier, invoice number, currency and gross amount already in the register. Expected: hold and inspect the original transaction; do not delete automatically.

Step 5: Approval shows the reason and the owner

The checklist exposes each unresolved question. Copy these fields into your accounting test workflow: document ID; order line; allocated receipt; expected value; actual value; arithmetic check; order match; receipt match; possible duplicate; hold reason; responsible person; decision and date. For case C, the reason is “12 invoiced, 10 confirmed, 2 unresolved”, rather than “AI uncertain”.

A high extraction score is not payment approval. Microsoft describes confidence as an estimate about a predicted field. A correctly read number may still describe something that did not happen. Review every invoice during the supervised trial and give the capture tool no permission to pay or change supplier bank records.

Start with fictional documents. Before using real data, establish the permitted purpose, provider agreement, access and deletion arrangements; the German data protection authorities’ guidance sets out the framework. Text inside an invoice must not become an instruction to the workflow.

Review time determines the cost case

Review time drives the calculation. Our illustrative month assumes 240 invoices that currently take four minutes each: 960 minutes. With capture and rules, assume one and a half minutes of checking per invoice, plus 80 minutes for exceptions and maintenance. That leaves 440 minutes of work and a calculated 520 minutes available for other tasks.

At an assumed EUR 42 per working hour, that time is worth EUR 364. Subtract illustrative recurring software and operating costs of EUR 180 and EUR 184 remains before setup costs. If checking takes two and a half minutes instead, just EUR 16 remains. These are checked assumptions, not vendor prices or measured savings.

Ask for total costs covering capture, integration, users, storage and maintenance. Released time creates economic value only if the business can use it elsewhere. With few invoices and missing purchase records, I would improve document handling before buying another application.

The first run produces an exception list

The business starts with five cases and no payment access. Enter the expected values above, run them through the existing workflow and compare every result. An incorrectly passed exception stops expansion. Only after the cases are handled correctly should a supervised trial with approved documents begin.

What about partial invoices? Include quantities already invoiced and confirmed, so the same receipt is not counted repeatedly. What if there is no purchase order? Mark the order comparison as OPEN and route it to the responsible person. A missing reference record is not a passed comparison.

If you want to connect this process to existing software, our internal automation services describe relevant work. Start by preparing the five test documents, their reference records and one named owner. The first run should leave you with a checked exception list.