The invoice errors worth catching before payment are line items that don't add up, tax calculated at the wrong rate or on the wrong amount, a total that doesn't equal subtotal plus tax, and bank details that are invalid or have changed. Almost all of them can be caught with plain arithmetic and format checks. Those checks should overrule an AI model's confidence, because a model can read a wrong invoice perfectly.
What invoice errors should you check before paying?
Here is a checklist you can run on any supplier invoice. The first five are arithmetic. The last three are about who you are paying and how.
- Each line: quantity x unit price = line total
- Line totals add up to the subtotal
- Discounts and freight are applied once, in the right place
- Tax uses the right rate on the right base
- Subtotal + tax = invoice total, allowing only for rounding of a cent or two
- Invoice number is not a duplicate for this supplier
- Currency matches the PO or contract
- Bank details are valid and match your vendor file
None of these needs judgement. They need a calculator and attention, which is exactly what goes missing on the 60th invoice of the afternoon.
Why don't invoice line items add up?
Suppliers are people with spreadsheets and billing systems that get edited by hand. The usual causes:
- A line total typed instead of calculated. Someone overrides a cell and the formula is gone.
- Transposed digits. 408.00 becomes 480.00.
- A line added after the subtotal was calculated. Common when an extra charge gets added at the last minute.
- Rounding. Unit prices with four decimals, rounded per line, can leave the total a cent or two away from the sum.
Check both levels. If you only check that the lines add up to the subtotal, a wrong line that was carried into the subtotal will pass. Recalculating quantity x unit price for each line catches it.
How do you spot a tax miscalculation?
Tax errors usually come from one of three places:
- Wrong rate. The supplier applied a rate that does not match your location or the goods.
- Wrong base. Tax charged before a discount instead of after, or freight taxed when it should not be (or the other way round).
- Rounding method. Tax rounded per line versus on the total can differ by a cent or more on long invoices.
The quick test: divide the tax amount by the taxable base. If you expect 5% and get 5.31%, something on the invoice is off.
What if the subtotal and total don't match?
If subtotal plus tax does not equal the total, the invoice is contradicting itself, and you cannot know what you owe without asking. Do not pick the number you like. Check the lines first, because the lines often tell you which figure is right. Then either correct it with a clear note or send it back for a corrected invoice.
How do you catch wrong bank details on an invoice?
Bank details on an invoice are the easiest place for a costly mistake, whether it is a typo or a fraud attempt. Three checks:
- Compare with your vendor master file. If the invoice shows different details from the ones you have on file, stop.
- Validate the routing number. US routing numbers have a built-in ABA checksum. A number that fails it is wrong.
- Call back on a known number. Any change to bank details gets confirmed by phone, using a number you already have, never one from the same email.
Why should arithmetic checks beat AI confidence?
Here is an illustrative invoice for packing supplies. Everything on it is printed clearly. Nothing is smudged.
| Line | Description | Qty | Unit price | Line total (as printed) |
|---|---|---|---|---|
| 1 | Stretch wrap rolls | 40 | 18.75 | 750.00 |
| 2 | Corrugated boxes | 500 | 2.15 | 1,075.00 |
| 3 | Packing tape | 120 | 3.40 | 480.00 |
| Subtotal (as printed) | 2,233.00 | |||
| Tax at 5% (as printed) | 111.65 | |||
| Total (as printed) | 2,344.65 |
An AI model reading this page will be very confident about every value, and it should be: it read them correctly. Every field looks fine on its own.
Now add up the line totals: 750.00 + 1,075.00 + 480.00 = 2,305.00. The printed subtotal is 2,233.00. The invoice disagrees with itself by 72.00.
Go back to line 3: 120 x 3.40 = 408.00, not 480.00. Someone transposed two digits on the line total. The subtotal, tax and total were calculated from the correct figure, so the amount due is actually right. But the line item is wrong, and if you load the lines into your system for matching or cost coding, you would book 72.00 against packing tape that never existed. A careless fix could make it worse: "correcting" the subtotal to 2,305.00 to make the page tidy would mean overpaying.
This is the whole point. Confidence measures how sure a model is that it read the page correctly. It says nothing about whether the page is correct. Only arithmetic can tell you that, so when the sum fails, the sum wins.
What does this look like in SensiDocs?
SensiDocs runs deterministic checks next to the AI read. Line items must add up to the totals, allowing only for rounding of a cent or two, and US routing numbers are validated against the ABA checksum. When a check fails, the field is flagged no matter how confident the model was.
For the invoice above, the subtotal would be flagged as failed a check, with a plain reason along the lines of "line items sum to 2,305.00; subtotal reads 2,233.00". Every other field is either accepted or flagged with its own reason: not found, contradicted, bad format, not grounded in the document, or low confidence. Doubtful fields also get a second, independent read that never sees the first answer, and a value is only accepted when both reads agree.
In review, the person sees the highlighted field and the reason, looks at the lines, spots line 3, and fixes it in place. That is a short job. Finding the same error after payment takes a lot longer.
The Accounts payable pack covers supplier invoices and receipts from PDFs, scans and phone photos.