Keeping records tamper-proof (GoBD)

The most common misconception is that it comes down to the file format – a document in an archive format is supposedly safe, a spreadsheet file isn't. What's actually required is something else: the process has to be designed so that a later change is either impossible or detectable. A locked file that someone with administrator rights can quietly swap out doesn't meet that; a database in which every change leaves a trace does.

It follows that corrections are allowed, and even expected. Nobody demands that you never make a typo. What's required is that the original content stays recognisable and the correction is visible as such. Overwriting an entry is a problem; reversing an entry and recording it again is not.

In practice, that means the archive isn't what decides – it's the path along which a record is created, changed and finalised. It's exactly that path you have to be able to describe.

Traceability is usually thought of in one direction – every entry has a supporting document. But both directions are required. For every document, it has to be findable where it was booked; for every entry, what it's based on. Only once the path works both ways is the record complete.

In practice, this rarely fails for lack of good will, but for missing references. A document sits in a folder, the entry sits in the program, and the link exists only in the head of whoever recorded both. If that person leaves the farm, the bridge is gone – and an inspection doesn't ask about the bridge, it asks for the document.

The most common blind spot is documents that never led to an entry. A quote you didn't accept, an order confirmation, a complaint, a termination letter – such received and sent business correspondence is subject to the retention duty even though no amount ever changed hands. It explains business transactions, and that's exactly why an inspection wants to see it.

This applies especially to emails. A message that settles a business transaction is business correspondence, not private correspondence – the means of transmission changes nothing about that. If the email only serves as a carrier for an attachment, it's closer to an envelope; if it settles something itself, it has to be retained.

Because these documents carry no amount, they fall through any system built around entries. They need a place of their own, with direction, date, correspondence partner and subject – otherwise they only sit in a mailbox that gets tidied up sooner or later.

The e-invoice looks like an extra duty, but it's mainly a formal requirement. What an invoice has to contain was already set out in VAT law before; what's new is that the content has to sit in a structured data set a program can read – not merely in an image that a person reads.

For retention, a clear rule follows from that: what governs is the structured data set, not the human-readable view generated from it. Anyone who archives the viewable file and discards the data has lost the original. The rollout is staggered and the transitional periods keep changing – take the binding current state from the linked sources.

The practical benefit sits exactly where the duty hurts: a structured incoming invoice can be checked before it's booked. An invoice that doesn't meet the requirements stands out on arrival, not only later at the input tax deduction stage.

The procedural documentation is the record that's missing most often and costs the least. It describes how documents arrive at the farm, who records them, where they're kept, how long they stay, and what ensures nobody can change them unnoticed. Without it, even the cleanest data management stands without an explanation.

It doesn't have to be extensive. What matters is that it describes the actual process, not the intended one – and that it's kept up to date when the process changes. Documentation that describes a different program than the one actually in use is worse than none at all.

Three things are asked about: access, evaluability and readability across the entire retention period. Access means the data sits in the system and an auditor can inspect it. Evaluability means it can be sorted and filtered by machine – a stack of image files can't. Readability means you can still open the data even once today's program has long been replaced.

The underestimated part is the last one. Retention periods outlast software changes, and an export nobody has ever tested is no safeguard. Anyone who checks once a year whether the data can actually be pulled out and read again has answered the question before it's asked.