What does not add up does not go in: sums, duplicates and dates

Reading the invoice is the easy part. What decides whether the automation survives is what happens when the reading is wrong: four checks that need no knowledge of the business, the rules only yours knows, and what stops for a person to look at.

DocFlow · September 2026 · ~6 min read

Reading the invoice is the easy part

Any tool can demonstrate reading: point it at a PDF and out come the supplier, the date, the total and the lines. That is what demos show, and it is not what decides whether the automation survives its first month. What decides is a different question: what happens when the reading is wrong.

An invoice read with a quantity taken from the next column, or with the due date where the issue date should be, raises no error at all. It goes into the ERP looking like a correct invoice, and it only surfaces at month end, when it is expensive to find and more expensive to explain. So the rule worth imposing on any automation is easy to state: what does not add up does not go in. It stops, and a person looks.

The first invoice passes the four checks and goes through. The second fails the sums and stops for review, instead of going in wrong.

Four checks that need to know nothing about your business

Some things can be checked on an invoice without knowing the company receiving it. They come first, and they catch most reading errors.

1. The tax ID belongs to the supplier, not to you

On a purchase invoice the issuer cannot be your own company. It sounds obvious and it is not: a reading model that swaps the two parties puts your name in the issuer field, and a check that only confirms «has a tax ID» lets it through. The check that catches this compares the issuer's tax ID with yours, and stops if they match.

An honest note: the check digit that discards a misread number before anything else is a Portuguese thing, and it is the first check we run in Portugal. Elsewhere the tax ID is extracted and compared with yours; its format is not validated.

2. The sums add up, to the cent

The lines of an invoice have to add up to the printed total, and the net amount plus the tax has to give the total. When they do not, it is almost always a quantity or an amount read from the wrong column, and the whole document is wrong. We measured this on dozens of real invoices from different suppliers: on the ones read correctly, the difference was zero cents on every one.

The case that forced us to take it seriously was an electricity bill with a column of days, which the model read as a discount percentage and then applied to the lines. Each line was consistent with itself, and the document total was hundreds of euros short. No field-by-field check would catch it; the arithmetic did.

One detail separates a useful rule from a rule everyone switches off: the settlement discount at the bottom. The lines add up to the gross amount and the printed total is after the discount, so the rule has to subtract the discount before comparing. Without that it raises a false alarm on every discounted invoice, and a queue of false alarms stops being read.

3. The same document does not go in twice

The same invoice arrives twice with surprising ease: resent by the supplier, forwarded by two people, scanned from paper after it came in by email. Two things are checked. The file itself, by the fingerprint of its bytes. And the combination of supplier tax ID, document number and date, within a window of days you choose, which catches the same invoice in two different files.

A duplicate is never rejected on its own. It stops, with a link to the original next to it, and a person decides whether it is the same or a similar new invoice. It is a two-second decision, and not one to hand to a machine.

4. The dates make sense

A purchase invoice dated in the future is a date read wrong, almost always day and month swapped. A due date before the issue date, likewise. These are one-line rules, and they keep a wrong due date from deciding a payment.

In Portugal there is one more check that most countries do not have: by law, every invoice carries a QR code with the issuer's and the buyer's tax IDs, the date and the totals, already structured. When it exists, what the QR says beats what the model read.

In Portugal every invoice carries a tax authority QR code. The model misread one digit of the tax ID; the QR carries the right one, and the QR is what goes through.

The rules only your business knows

The four above hold for any company. Then come yours, and this is where a tool differs from a demo.

A real example: the cost centre is mandatory for service suppliers, and for no one else. A rule without a condition held the steel supplier with the same conviction it held the electricity one. The right rule has a condition, «only when the supplier is a services supplier», and reads the field after the supplier table has filled it in, because the invoice does not print it.

Another: the supplier's item reference is not yours. A lookup table translates one into the other, and when a reference is not in the table the document should not go in with a blank line. It stops, with the line number, someone adds the item to the table and approves. Next time, that reference goes in on its own.

What we do not check, and why you should know

None of these checks tells you whether the supplier really exists or whether the invoice is legitimate. None tells you whether the goods arrived, because that means matching the invoice against the order and the delivery note, and that is a different job. And none decides the accounting account: that belongs to the ERP and to whoever keeps the books, and an automation that promises it is promising what is not its own.

What happens to what stops

A document that fails a check does not disappear or sit in a technical queue. It appears to the reviewer with the reason written out, the field that failed, the value read and the value expected, and the option to correct it right there. Once corrected, it is checked again and goes to the ERP by the same route. If the failure came from a table, the table is corrected, and stays corrected for the invoices that follow.

Two minutes of one person, today, in exchange for the error hunt at month end. That is the trade the sentence stands for, and the reason to impose it on any automation, ours or anyone else's.

To see how invoices get here in the first place, the article on invoices by email covers the way in. And to put a number on what typing them costs, there is a four-line sum for that.