When invoice totals don't add up: the export check

An invoice whose lines don't add up to its own grand total looks perfectly ordinary. Supplier, date, VAT – everything in place. The difference is often just a few euros, and it is not noticed while the invoice is being entered. It is noticed much later: at import, when the accounting system rejects the document. Or, worse, when it doesn't.

Where a self-contradicting invoice comes from

Almost never from an accountant being careless. The document arrives the way it is, and the mismatch is already inside it.

• •A discount or rounding applied to the invoice as a whole at the bottom, not to the lines
• •A delivery, packaging or deposit charge printed outside the line table
• •A multi-page invoice whose summary contains more than the lines list
• •A foreign-currency invoice whose total was converted at a different rate than the lines
• •One line corrected by hand while the header amount was left alone
• •A scanned or photographed document where a single line was misread

The result is the same in every case: the line sum doesn't equal the net amount, or net plus VAT doesn't equal the grand total. The invoice contradicts itself, and at a glance it doesn't show.

Why the error is found somewhere else entirely

The mismatch is rarely caught during review. It is caught in another system, the following week. The better outcome is that the accounting system refuses the document at import. The accountant gets a message about an amount but not about a cause, and the source document is no longer in front of them. A two-minute correction turns into half an hour of looking.

The worse outcome is that the document imports cleanly. Then the supplier balance no longer ties to the document the supplier issued, and the period's VAT is wrong. That kind of error surfaces during reconciliation or while preparing the i.SAF return, and fixing it is no longer an edit – it takes a reversal and a fresh entry.

Money that doesn't add up doesn't travel any further

Before an invoice can be marked as ready to hand over to the accounting system, its arithmetic is recalculated. Two things are checked: does net plus VAT make the grand total, and do the line amounts make the net. If either one fails, the invoice goes no further.

The important part is not the stop itself – it is the message. It names exactly what disagrees and by how much: not "validation error", but "the lines come to one figure and the net amount is another". The accountant can see immediately whether a delivery charge is missing or a single line was misread.

It is calculated from what is in the invoice at that moment, not from an earlier stored check. A line corrected a minute ago is already counted.

What to do when the check stops you

The repair paths are the ones an accountant already uses – there is nothing new to learn.

• •Reconcile the line amounts to the header in one click when the difference is rounding or a discount
• •Correct the specific line when it is clear which one is wrong
• •Re-read the invoice when the document came through badly
• •After the fix the check re-runs on its own and the invoice moves on

There is no separate step to confirm that it has been sorted out. The next attempt simply succeeds.

Where the check deliberately stays out of the way

• •Credit notes and returns pass normally – a minus sign is not an error; what matters is that the document agrees with itself
• •An invoice that doesn't need to go to the accounting system at all can be marked as such: that is a decision, not an accident
• •Cash rounding at payment doesn't trip it – the grand total is still net plus VAT
• •A foreign-currency invoice is checked in the currency it was issued in
• •Invoices already handed over are untouched – the check applies at the moment an invoice is marked ready

Small rounding differences stay visible as a warning even when they don't block. Nothing is hidden below a threshold; the only thing that differs is whether a mismatch stops you or merely tells you.

Why this one is a hard stop and not another warning

Ezura deliberately blocks very little. A possible-duplicate warning, for instance, does not block an invoice at all – the system sees a match but doesn't know the context, so the decision stays with the accountant.

Arithmetic is a different matter. There is no context here: if the lines don't make the net amount, the document is wrong regardless of who sent it or why. And at month-end, when a few hundred invoices go through in a couple of days, a warning that can be ignored is in practice a warning nobody reads.

What it changes in practice

The benefit here is not measured in hours saved but in errors that never reached the ledger. A wrong amount stopped before export is a two-minute correction on your own screen. The same amount found in the accounting system is half an hour. Found while preparing the i.SAF return, it is a reversal, a new entry and an explanation to the client.

It also changes what export rests on: what goes to accounting is no longer everything that was approved, but only what adds up. The errors that used to be caught by an import dialog in somebody else's system now stop where they can still be fixed cheaply.