Tamper-evident records: how hash chains protect data

Did this invoice change since it was sent? A tamper-evident record answers that, because it cannot be changed without leaving a trace. A hash chain stores, with each record, a fingerprint of its contents plus the previous record's fingerprint, so editing an earlier invoice breaks every later link.

Invoices are records other people rely on: customers, accountants, auditors and tax authorities. Many systems let an administrator edit data somewhere, which is useful until someone asks whether an invoice still says what it said on the day it was sent. Tamper evidence answers that question with arithmetic rather than trust.

What a hash is

A cryptographic hash function turns any input, such as the full text of an invoice, into a short fingerprint of fixed length. SHA-256 is a widely used example. Three properties make it useful:

• The same input always gives the same fingerprint. Anyone can recompute it and compare.
• A tiny change gives a completely different fingerprint. Changing one digit of an amount changes the whole hash.
• The fingerprint does not reveal the input. In practice, you cannot work backwards from the hash to the invoice.

How a hash chain links records

A single hash proves that one record has not changed since the hash was taken, but someone who can edit the record could simply recompute its hash too. A chain makes that much harder by tying each record to the one before it.

1. When the opening record is saved, its hash is computed from its contents.
2. When the next record is saved, its hash is computed from its own contents together with the previous record's hash.
3. Every later record repeats the step, so each hash depends on everything before it.
4. To check the chain, recompute every hash from the start and compare it with the stored one.

Record	Hash is computed from	If an earlier record is edited
Invoice A	Invoice A's contents	Its own hash no longer matches
Invoice B	Invoice B's contents and A's hash	B's stored hash no longer matches
Invoice C	Invoice C's contents and B's hash	C's stored hash no longer matches either

An edit in the middle of the chain therefore breaks every link after it. Hiding the change means rebuilding the rest of the chain, which is exactly what the next safeguard is for.

What a hash chain does not do

• It detects, it does not prevent. The data can still be changed; the change simply becomes visible on the next check.
• It needs an outside anchor. Whoever controls the whole chain could rebuild it from the edited point onwards. Keeping the latest hash somewhere else, such as with an auditor, in a separate system or with a trusted timestamping service, closes that gap.
• It does not prove the contents were right. A wrong amount entered on day one is faithfully preserved. Review before an invoice is issued still matters.
• It has to be checked. A chain nobody verifies protects nothing. Regular checks, and a clear process when one fails, are part of the design.

Tamper-evident, write-once and signed records

Approach	What it gives you	Limits
Write-once storage	Records can be added but the system refuses edits and deletions	Someone with enough access to the storage itself can still change it
Hash chain	Any later edit becomes visible on the next check	Needs an outside anchor and regular checks
Electronic signature	Shows who issued a document and that it has not changed since signing	Protects each document on its own, not the completeness of the series

Many systems combine them: write-once storage for day-to-day protection, a hash chain to make edits visible, and signatures where the law or a customer asks for them. Sequential invoice numbers add another layer, because a missing number is a visible gap; see invoice numbering rules.

What EU VAT rules say

In the EU, Article 233 of the VAT Directive (Council Directive 2006/112/EC) requires the authenticity of origin, the integrity of content and the legibility of an invoice to be ensured from the moment it is issued until the end of the period it must be stored. Businesses can do this in several ways, for example through business controls that create a reliable audit trail between an invoice and the supply, an advanced electronic signature or electronic data interchange.

The Directive does not name hash chains. A hash chain is one technical way to support an audit trail, not a legal requirement in itself. Some countries set stricter rules for invoicing or till software, such as requiring that records cannot be changed without leaving a trace, so check the rules where you trade. For the contents every invoice needs, see what an invoice must include.

Questions to ask about any system

1. Can an issued invoice be edited or deleted, and by whom?
2. Is every change recorded, with who made it and when? What a good audit trail records covers the basics.
3. Is there a mechanism that makes edits visible, such as a hash chain, and is it checked?
4. Is the latest fingerprint anchored somewhere outside the system?
5. Which records does the protection cover? Invoices, payments and approval decisions may be treated differently; hash-chained approval logs shows how the same idea applies to approvals.

Frequently asked questions

Is a hash chain the same as a blockchain?

A blockchain uses hash chaining, but adds copies held by many parties and rules for agreeing on new entries. A hash chain inside one business system is much simpler: one keeper, with an outside anchor for the latest hash.

Can a hash-chained record still be changed?

Yes. The chain does not lock the data; it makes a change visible, because recomputing the hashes no longer matches what was stored. That is why it is called tamper-evident rather than tamper-resistant.

Do EU rules require tamper-evident invoices?

The VAT Directive requires the integrity and authenticity of invoices to be ensured until the end of the storage period, but leaves the method open. Some countries set stricter technical rules, so check local guidance.