Why your ERP generates invoices, not evidence
ERP and accounting software are remarkably good at the job they were designed for: processing transactions at scale, enforcing approval workflows, and producing structured output that other systems can consume. Millions of invoices are generated this way every day without incident.
But there is a separate job that ERP software was never designed to do, and that distinction matters when a tax authority, court, or regulatory body asks a harder question than “show me the invoice.”
The question most software cannot answer
When a routine invoice is disputed, producing the PDF is usually sufficient. The buyer recognises it, the seller confirms it, and the matter is resolved. That workflow is what ERP software optimises for.
A harder question looks like this: “Prove that this invoice existed in exactly this form on this date, that it has not been altered since, and that the person who claims to have sent it actually sent it through your system.”
That is not a document question. It is an evidence question. And evidence has different requirements from documents.
A document is a record of a transaction. Evidence is a verifiable record that can withstand independent scrutiny — including scrutiny from someone who is actively trying to dispute it.
What ERP software does provide
To be precise about the gap, it helps to be clear about what ERP software does well.
Most modern ERP systems provide:
Structured invoice data. Invoices are stored in a database with clear relationships between buyers, sellers, line items, totals, and dates. This makes them queryable, auditable through the ERP’s own interface, and exportable in standardised formats like UBL or CII XML.
Approval and audit logs. Most ERP systems record who approved what and when. These logs are useful for internal control reviews and can demonstrate that proper process was followed.
Format compliance. For Factur-X, ZUGFeRD, XRechnung, and Peppol output, modern ERP software generates XML that validates against the relevant schema. This covers the format requirement under EU e-invoicing mandates.
Export and portability. Invoices can typically be exported in bulk, either as XML, PDF, or both. This covers the data portability use case.
None of this is trivial. Format compliance is a genuine engineering problem that ERP vendors have invested significant effort in solving. The point is not that ERP software is deficient. The point is that format compliance is necessary but not sufficient for legal evidence.
What ERP software does not provide
The gap appears when you ask for independent verification of three things that legal proceedings often require.
Proof of existence at a specific time. A timestamp stored inside your own system is only as trustworthy as your system. If you control the system, an adversary can argue you also controlled the timestamp. An RFC 3161 timestamp from an independent Time Stamping Authority is cryptographically signed by a third party and cannot be forged retroactively without invalidating the signature. Most ERP systems do not issue or store RFC 3161 timestamps.
Proof of integrity since that time. A PDF or XML file stored in a database can be modified. A database record can be updated. Without an independent hash commitment — a cryptographic fingerprint made at the time of creation and stored somewhere outside your control — you cannot prove the document has not been altered since. Most ERP systems do not produce or store cryptographic hash commitments tied to their records.
An independent chain of custody. Knowing that a document exists in a specific state today is different from knowing how it arrived in that state. A chain of custody records every action taken on a document — who accessed it, what was done, and in what sequence — in a tamper-resistant log. This is standard in legal and regulatory proceedings but is not typically how ERP audit logs are implemented.
When this matters in practice
The gap between document and evidence is not academic. Here are the contexts where it surfaces.
Tax authority investigations. In several EU jurisdictions, tax authorities have the power to demand that companies demonstrate the integrity of their electronic invoicing records. A company that can produce invoices but cannot demonstrate that they have not been altered since issuance is in a weaker position than one that can produce a cryptographic proof of integrity alongside the invoice.
Commercial disputes. When a buyer disputes an invoice — claiming it was modified after the fact, or that the amounts do not match what was agreed — the seller needs to demonstrate that the document is authentic and unchanged. An RFC 3161 timestamp and hash chain provides that demonstration. A PDF from an ERP system without independent verification does not.
Regulatory audits in financial services. Firms subject to MiFID II, Solvency II, or equivalent frameworks are required to maintain records in a way that demonstrates integrity and authenticity. The specific requirements vary, but the general expectation is that records cannot be altered without detection. This is a higher bar than typical ERP storage.
Contract disputes involving long retention periods. Invoice retention requirements in the EU range from 7 years (the common standard for VAT invoices) to 20 years for certain public sector records under Dutch law. Over a 7-year window, a lot can change: the ERP system can be replaced, the database can be migrated, the PDF files can be re-exported. Without a timestamp and hash chain anchored at the time of creation, proving that a 7-year-old invoice has not been modified becomes difficult.
The format compliance misconception
A common assumption is that if an invoice is Factur-X or Peppol compliant, it is legally admissible. Format compliance means the invoice validates against the schema and contains the required fields. It says nothing about when the document was created, whether it has been modified, or whether the record can be independently verified.
Factur-X is a file format. RFC 3161 is an evidence protocol. They operate at different layers of the compliance stack and one does not substitute for the other.
To use a physical analogy: a notarised document and a printed document are both documents. The notarisation adds a layer of independent verification — a trusted third party attesting to when and by whom the document was signed. Format compliance is closer to printing than to notarisation.
What the evidence layer actually requires
Producing legally admissible evidence for a digital document requires three things at minimum.
A trusted timestamp. An RFC 3161 timestamp from a Time Stamping Authority provides a cryptographic proof of existence at a specific point in time. The TSA is an independent party whose signature can be verified by anyone using standard tools. The timestamp cannot be forged after the fact without invalidating the signature chain.
A hash commitment. Before the document is timestamped, its content is hashed using a cryptographic algorithm — SHA-384 in SealDoc’s case. The hash is a fingerprint of the content. If one byte of the document changes after the hash is computed, the fingerprint no longer matches. The hash is stored independently of the document, so the document and the fingerprint can be checked against each other at any point in the future.
A chain of custody record. Every action taken on the document after creation is logged — access, conversion, archival, retrieval — with the actor’s identity, timestamp, and IP address, written to a tamper-resistant audit log.
Together these three elements answer the questions that legal proceedings ask: did this document exist in this form at this time, has it been changed since, and who handled it.
The practical question
Most organisations generating invoices through ERP software are not in immediate need of forensic-grade evidence infrastructure. For routine B2B transactions, the existing process works well.
The question becomes relevant in a narrower set of circumstances: regulated industries, high-value transactions, long retention windows, disputed invoices, or any context where an adversary might have an incentive to challenge the integrity of your records.
For those use cases, the gap between “we have the invoice” and “we can prove the invoice is authentic” is real, and it is not closed by format compliance alone.
The most practical approach is to build the evidence layer in at the point of document creation rather than retroactively. An RFC 3161 timestamp and hash chain added at the time of generation costs nothing at audit time. Adding them retroactively, or attempting to argue that existing records are sufficient without them, is harder.
SealDoc adds the evidence layer to every document processed through the pipeline: RFC 3161 timestamp from a trusted Time Stamping Authority, SHA-384 hash chain, chain of custody log, and a Legal Evidence Pack bundled as a single auditable archive.