When an Update Changes Your Invoices: A Records-Integrity Risk

A case from practice, anonymised and stripped down to what is instructive: a software update retroactively changes invoices that had already been finalised and sent. Not the layout. The content. In the case I encountered, it hit four documents at once, re-sent to customers through a single update and altered in substance.

The vendor's response missed the point entirely. In essence: it was an isolated case, only one document, and in any event the invoice had not been flagged as "printed" in the system. But what matters is not what the system claims. What matters is what actually exists: the documents were created, sent, posted to the books, processed by the customer and filed with the tax adviser. A print status inside the system changes none of that.

I look at something like this through two lenses: as a managing director who knows what it means to answer for his own books, and as an auditor who has made the integrity of data his profession. Both lenses show the same picture. This is not a cosmetic flaw in the software. It is a compliance problem waiting to happen.

What makes an invoice an invoice

An outgoing invoice is not a draft. Once it has been issued and locked into the accounting records, it is a booking document, and in Germany such documents fall under the GoBD, the principles for the proper keeping and retention of books, records and documents in electronic form. GoBD is the German bookkeeping-records standard, but the underlying idea travels well beyond Germany: it is essentially a codified expectation that electronic accounting records stay complete, orderly and, above all, unchangeable after the fact. One of the load-bearing pillars of these principles is immutability.

Immutability does not mean that nothing may ever be corrected. It means this: once a posting or a document has been locked, it may not be changed in a way that makes the original content disappear without the change remaining visible. Corrections run through a traceable path, a cancellation, a correction document, a logged change carrying a date and the person responsible. Never silently. Never covertly. Never through an update running in the background.

What a clean version looks like is no great mystery. If it turns out that a sent invoice was wrong, it is not overwritten. It is cancelled, the original document is preserved and remains visible, and a new, corrected invoice is created with its own number and its own date. In the end any inspector sees both: the error and the correction. That very trail is the heart of the matter. An update that simply replaces the old content erases the trail, and with it the traceability.

An invoice that can still change its content after it has been sent is no longer an invoice. It is a draft with a letterhead.

That is exactly what happened here: the content of finalised documents was overwritten after the fact. With that, the original trail is gone, and with it the traceability a tax inspector will want to see if it ever comes to that. Under German rules, booking documents such as invoices now have to be retained for eight years, previously it was ten; for books, inventories and annual financial statements the ten-year period remains. Either way, a document like this accompanies the business owner for the better part of a decade. So this is not a theoretical risk.

And an altered invoice rarely stands alone. It relates to what the customer has already received, to the payment that came in against it, to the receivable that was posted and to the VAT reported to the tax authority. If the document changes after the fact, it suddenly no longer matches everything built on top of it. An overwritten document quickly turns into a chain of discrepancies that someone has to explain. And that someone, in the end, is the business owner, not the software.

"Only one document, not printed": why neither counts

Two objections that come up in almost every such case deserve a second look, because many business owners make the same reasoning error. First: it was only one document. In this case it was four. But even if it had been one, the principle of immutability for locked documents recognises no threshold of triviality. An altered document is an altered document.

Second: the invoice had not even been flagged as printed in the system. That is the logic of the software, not the logic of the tax authority. Whether a document exists for tax purposes is not decided by a technical checkbox in the ERP. It is decided by reality: the invoice was created, sent, posted, processed by the customer, filed with the tax adviser. A system status does not decide what documents are there for.

Why this is an integrity issue, not just a tax issue

Information security has three protection goals: confidentiality, integrity, availability. In the audits I have carried out, almost everyone looks first at confidentiality, who is allowed to see what. The middle goal is the one most often underestimated: integrity. Is the data correct, complete and protected against unnoticed change?

An update that changes records without anyone having approved, tested or logged it is a textbook integrity incident. ISO/IEC 27001:2022 provides concrete controls for exactly this: orderly change management (A.8.32 Change management), so that no update runs into production uncontrolled. Complete logging (A.8.15 Logging), so that every change leaves a traceable trail. And anyone who sources their software from the cloud additionally keeps an eye on information security for the use of cloud services (A.5.23).

At its core, this is a testing and release problem. An update that touches production records belongs in a test environment first, with realistic sample data, with a check of the results, with a plan for how to roll it back if something goes wrong. If instead it is deployed straight into live operation and reaches already-closed documents in the process, it overwrites content that no one should be touching any more. The point is not the control number. The point is the attitude behind it: whoever processes data must ensure that it does not change unnoticed. A mechanism that can silently alter finalised documents is a structural risk regardless of quantity, whether it hits one document or a hundred.

That is precisely why "isolated case" is not a reassuring phrase for me but a warning sign. If an update was able to touch four closed documents, it was not because those four were special, but because the barrier that should have prevented it was missing. At this point an auditor never asks first about the damage, but about the missing control. The damage is the symptom. The missing barrier is the cause.

"That is your perception": and why that sentence is wrong

Then, in essence, comes the line that this is just one's own perception. With several altered documents sitting there in black and white, that is not a perception. Those are facts. But the line points to a bigger misunderstanding, namely the question of who is ultimately responsible.

And the answer is uncomfortable for anyone who hoped that responsibility had been bought and handed over along with the software licence: responsibility for orderly books lies with the business owner. Not with the vendor. The GoBD are unambiguous here, whoever outsources recording and retention duties to a service provider or a piece of software remains responsible for them. The vendor may be liable under civil law for its error. Towards the tax authority, it is the business owner who answers.

You cannot hand over responsibility for orderly books through a software licence. It stays with you.

The right response is therefore not to back down, but to demand a documented root-cause analysis. Not out of a need to be right. But because in the end it is the business owner who has to explain why finalised documents changed after the fact. No one wants to have to improvise that explanation.

What this has to do with supplier audits

Here the loop back to the audit closes. Your ERP vendor, your cloud provider, your accounting system, these are suppliers. And suppliers who process your documents, your postings and your customer data are part of your own compliance. If their system alters your data, that is your problem, not just theirs.

This is exactly where a supplier or second-party audit comes in. The term sounds cumbersome but means something simple: you examine a supplier you yourself depend on, not in order to issue a certificate, but in order to understand your own risk. That is something different from a third-party audit, in which an independent certification body examines a company for a certificate. A supplier audit is not about the stamp, but about your security, and not about whether the software looks pretty, but about whether the vendor takes the integrity of your data seriously. Best done before signing the contract, not after the damage.

The questions are simple and still rarely asked:

• Is there procedural documentation showing how the system creates, stores and keeps documents immutable?
• How does change and update management work? Are updates tested before they touch production data?
• Are outgoing documents protected against silent retroactive change, what the industry calls audit-proof?
• Is every change to a record logged, with timestamp and the person responsible?
• Who bears what responsibility in the event of an error, and is that in the contract, not just in the sales pitch?

And if the vendor has no clear answers to these questions? Then that is already the answer. No vendor has to be perfect, but it must be able to show how it handles your documents. Whoever clarifies this before the purchase holds the conversation calmly. Whoever clarifies it only after a faulty update holds it under pressure, with a vendor that did not initially grasp the scale of what happened.

What you should take away from this case

You do not have to be an auditor to protect yourself. You only have to stop trusting your software blindly. Software is a tool. It is no substitute for diligence and no substitute for the responsibility that stays with you.

If you take away only one thing, let it be this: take a hard look at your own accounting and ERP landscape and ask the uncomfortable question, could an update do the same thing to you? Have them give you the procedural documentation. Test on a sample document whether a locked invoice can be silently changed. Clarify whether every change is logged. And secure outgoing documents independently of the system, so that you have a second trail. If you do not know the answers, you do not know a risk. And unknown risks, in an audit as in operations, are always the most expensive in the end.