A tamper-evident audit trail is one where any modification to historical data is detectable. The classic technique — borrowed from blockchain but vastly simpler — is the hash chain: each record contains the cryptographic hash of the previous one. Mess with any historical record and every subsequent hash changes.
The recipe
For each invoice, compute:
hash_n = SHA256(prev_hash || canonicalize(payload_n))
// where canonicalize() produces a deterministic byte sequence
// (sorted keys, no whitespace, stable number formatting).Store the hash on the invoice itself. To prove the integrity of any single invoice, you only need to verify that its hash equals the recomputed hash given the prior invoice's hash and the canonicalized payload. ZATCA Phase-2 mandates exactly this scheme.
Why canonicalization is everything
Two byte-different JSON serializations of the same logical object produce different hashes. RFC 8785 (JCS — JSON Canonicalization Scheme) is the standard approach: keys are sorted lexicographically, no insignificant whitespace, numbers in shortest unique form, strings escaped per RFC 8259.
Per-tenant chains, not global
Run a separate chain per tenant rather than one global chain. Two reasons: (1) you can shard storage and compute per tenant without coordinating writes, and (2) a corruption in one tenant's chain doesn't poison everyone's audit trail.
Verifying after the fact
An auditor (or you, defensively) can replay the chain from genesis: hash the first invoice's payload with no prev_hash, check it matches the stored hash, then iterate. Any deviation localizes the tampered record. Web Crypto's subtle.digest gives you SHA-256 in any modern runtime — Node, Deno, or the browser.
Invocie writes a chained hash on every invoice and on every ComplianceLog entry. The two chains are independent: invoices for ZATCA-style proof, logs for operational audit.