How do you prove an e-invoice was validated?

Keep the validation response. A useful one carries a fingerprint of the exact bytes that were judged and of the rules that judged them, both reproducible on your own machine years later.

Most validation tools hand you a verdict and nothing else. Months later, when someone questions an invoice, a verdict is worth very little: it does not say which file was judged, and it does not say which version of the rules judged it. Proving validation means keeping evidence you can re-check without asking anyone.

“This invoice was validated in March” is a claim resting on two unstated assumptions: that the tool judged the exact file you have in your records, and that it judged it against the rules it says it used. Neither is observable from a stored valid: true. If the file was re-encoded in transit, or the tool quietly upgraded its rulebook, the stored verdict still reads the same.

Both assumptions can be turned into something checkable, and the mechanism is ordinary hashing.

A hash is a short fingerprint of some bytes. The same bytes always produce the same fingerprint, any change at all produces a completely different one, and you cannot work backwards from the fingerprint to the data. That last property is why a hash is safe to store in a ledger, print in an audit file, or email to a counterparty.

A Beliq validation response carries two:

• sha256 is the fingerprint of the exact request body that was validated. Run sha256sum on your own copy of the file. If it matches, the verdict applies to your precise bytes, with no truncation, re-encoding or substitution in between.
• rulesetSha256 is a single fingerprint of the whole set of rule artifacts that judged the document, and rulesetArtifacts lists the components it was built from, each with its key, version and own file hash.

1. Confirm the file. Hash your invoice locally and compare it to sha256.
2. Reproduce the ruleset fingerprint. Format each artifact row as key@version=fileSha256, sort the lines, join them with newlines and hash the result. It equals rulesetSha256. This is deterministic, so the same document and the same pinned rules always give the same value.
3. Cross-check against the public catalog. The keyless GET /v1/rulesets endpoint lists every artifact that can run, with the same versions and hashes. Each component in your response should appear there byte for byte, which is what turns “these are the rules Beliq says it used” into “these are the rules Beliq publishes to everyone”.

Steps one and two need nothing but the response and the standard hashing tools already on your machine. Step three is one unauthenticated HTTP call that costs no quota. None of it requires Beliq to still be online, or to vouch for anything after the fact.

Being precise about the ceiling matters more here than a stronger claim would.

For the national formats validated against a published schema (Italy, Spain, Slovenia), the pinned artifact is the authority’s own file, vendored byte for byte, so you can reproduce its fingerprint straight from the authority’s download.

For the EN 16931 Schematron families, the pinned artifact is a compiled form that Beliq builds from the authority’s published rule sources. Its fingerprint proves the artifact Beliq ran is the one Beliq pins and re-verifies, not something you can reproduce by hashing the authority’s raw source file yourself, because the compilation step is Beliq’s. That is the honest boundary: the ruleset that judged you is transparent, self-consistent and tied to a value published for everyone, and it is not a chain of custody back to CEN’s own bytes.

A pin proves stability, which is exactly what you want in an audit trail and exactly not what you want if the authority quietly republished the rules last week. So a response can also carry driftCheckedAt: not a hash but a timestamp, reporting when the artifacts that judged your document were last confirmed to still match their upstream sources. Read it as a lower bound, “confirmed at least this recently”. It is omitted rather than guessed when that confirmation is not current, so it is never falsely fresh.

Store the validation response next to the invoice, in whatever your records already are. It is small, it contains no invoice content beyond a hash, and it is the artifact that lets you answer, years later and without a support ticket, both halves of the question: this exact file, judged by these exact rules.