Invoice audit trail: who changed what, and when

A supplier emails to say their bank account has changed, please pay the new one. The invoice looks right – same company details, same logo, same line items. It gets entered, approved and paid. A month later the real supplier says the money never arrived, and there is exactly one question worth asking: who changed that bank account, and when? In most accounting processes there is no answer, because all anyone can see is the final record.

Why "approved" is not the same as "checked"

Your accounting system shows you the outcome: the total, the VAT code, the dimensions, the supplier. It does not show you the route the outcome took – and the route is usually the interesting part. Was the total corrected by the system because the line items did not add up to the header? Was it retyped by a person? Was the supplier assigned by one of your own rules? Those are three different events with three different levels of risk, and in the final record they look identical.

Three changes worth looking at first

• •The supplier's bank account – the classic fraud target: an email from an almost-correct address, a convincing invoice and a new account number
• •The invoice number or date – they decide whether the same document lands in your books twice, and which VAT period it falls into
• •The total or the supplier, changed after the invoice was already read – rarely an accident

These fields deserve attention not because you distrust your team, but because they are precisely what fraudsters aim at and precisely where an ordinary mistake costs the most.

What the invoice history shows

Every invoice in Ezura has a history panel: a list of entries showing who changed what, when, and from which value to which. It is not limited to human actions:

• •Human changes – header fields, line items, dimensions, approval and rejection
• •Rule actions – when one of your own rules assigned a project or a cost centre, or merged lines
• •System corrections – when mismatched totals were reconciled or a currency was corrected

The difference between "the system corrected the total because the lines did not match the header" and "a user retyped the total" is the whole difference between automation working as intended and something that needs a conversation. Until now that distinction had to be reconstructed from emails and memory, if it could be reconstructed at all.

An invoice approved by mistake

Approval is no longer a one-way action. An invoice can be sent back for review – it becomes editable again, and the reversal itself stays in the history along with who performed it. One warning matters and it is shown openly: if the invoice has already been passed to your accounting system, the document sitting there does not disappear. It has to be dealt with in that system. Ezura cannot, and should not, quietly change something already booked in your ledger.

When the invoice was read badly

Separate from edits there is a simpler case: the invoice was read wrong in the first place. It can be flagged with a reason – wrong total, wrong company details, wrong line items, wrong number or dates – and re-read on the spot. Re-reading does not wipe the history: you keep both what was there before and what came after. That layer of detail is what later lets you say whether the problem was in the document or in the process.

What this is worth at month-end

• •"Who changed this?" is answered in seconds instead of reconstructed from an email thread
• •An auditor, a manager or a client sees the route, not just the final number
• •You can see which suppliers need constant manual fixes – the most accurate shortlist there is for new automation rules

That last point surprises people most. A change history is not only a control measure – it is a list of work that can still be automated. If you are making the same correction for the same supplier for the third month running, that is already a rule; it just has not been written down yet.

Control and speed are usually presented as a trade-off: check more and you go slower. A trail that records itself removes the trade-off, because nobody has to keep the log. It is simply there when a question comes up – and most months, no question comes up at all.