SealDoc Blog
In-depth articles on PDF/A-3, e-invoicing, audit trails and compliance.
E-invoicing in Belgium from 2026: what every business needs to know
Belgium mandates structured e-invoicing via Peppol from 1 January 2026. This is what it means for your business, your suppliers, and your invoicing software.
Read moreFrom data to sealed PDF in one API call
Render Markdown or a JSON invoice straight into a Factur-X PDF/A-3 in a single API call. No intermediate step, no third-party tool, evidence pack included.
Read morePDF/UA-1 accessibility, on by default, via API
Since the EU Accessibility Act took effect on 28 June 2025, every customer-facing PDF a bank, telco, or e-commerce business sends out must be screen-reader-accessible. SealDoc now produces PDF/A-3 + PDF/UA-1 hybrid documents through `/api/documents/generate` and `/api/invoices/generate` with one flag.
Read moreCommon Peppol BIS 3.0 validation errors and how to fix them
Peppol BIS 3.0 Schematron validation produces error messages that reference BR codes, BT numbers, and XPath locations. This article maps the most common validation failures to their root causes and fixes, covering arithmetic rules, mandatory field errors, and country-specific extension failures.
Read moreHow to generate a compliant Peppol invoice with n8n and SealDoc
Step-by-step guide to automating Factur-X e-invoice generation in n8n using the SealDoc nodes. No code required.
Read moreFactur-X vs ZUGFeRD vs UBL, a practical guide for European invoicing
Three names, two formats, one specification underneath. Here is how Factur-X, ZUGFeRD, and UBL actually relate, when to use which, and why most cross-border pipelines need to handle all three.
Read moreFrance's e-invoicing mandate, what changes on 1 September 2026
On 1 September 2026, every business in France has to be able to receive structured electronic invoices. The send obligation phases in through 2027. Here is what the calendar actually looks like, what to do now, and where cross-border senders fit in.
Read morePoland KSeF goes live 2 April 2026, what cross-border senders need to know
Poland's national e-invoicing system KSeF becomes mandatory for large taxpayers on 2 April 2026, with smaller taxpayers following in 2026 and 2027. Here is what KSeF actually is, how it differs from Peppol, and what foreign suppliers invoicing Polish buyers need to set up.
Read moreThree n8n nodes, one compliance-ready archive
How to wire SealDoc into an n8n workflow that turns any incoming PDF into a Factur-X-embedded, RFC 3161-timestamped PDF/A-3 archive in three connected nodes. With a working configuration you can copy.
Read morePDF/A-3 vs PDF/A-1: which archival format does EU e-invoicing require?
EU e-invoicing mandates require PDF/A-3B specifically. Here is why PDF/A-1 and plain PDF are not enough, and what the difference means in practice.
Read moreRFC 3161 timestamps: what they are, why they matter, and when they are legally required
An RFC 3161 timestamp proves a document existed at a specific point in time and has not been altered since. Here is why that matters for EU e-invoicing compliance and legal archival.
Read moreXRechnung 3.0: what changed and how to comply
XRechnung 3.0 introduced new mandatory fields and tightened validation. Here is what changed, who is affected, and how to generate compliant invoices.
Read moreLegal document retention periods in the EU: which document, how long, which law
EU member states set their own document retention requirements on top of EU-level rules. This article provides a practical reference for retention periods by document type and jurisdiction, covering invoices, contracts, employment records, and accounting documents across Germany, France, the Netherlands, Belgium, and Poland.
Read moreDocument pipelines: from DOCX to PDF/A-3 to signed archive in one API call
Converting a DOCX to a compliant PDF/A-3 archive is a multi-step process where each step can fail silently. This article walks through what the full conversion chain looks like, what breaks at each step, and how to build a pipeline that produces verifiable archival output reliably.
Read moreHallucination-safe document workflows: using AI in legally sensitive contexts
AI systems produce plausible-looking output that may be factually wrong without signalling that anything is wrong. In legally sensitive document workflows, this requires specific architectural choices. This article describes patterns that make AI-assisted document generation safe for compliance use.
Read moreAI-generated documents and legal validity: the compliance gap
AI can generate contracts, reports, invoices, and compliance documents faster than any human. What it cannot do is guarantee that the output is legally valid. This article examines the compliance gap between AI-generated text and legally admissible documents, and what infrastructure is needed to close it.
Read moreLong-term PDF validation: why a compliant PDF today may fail verification in 2035
A PDF/A-3 file that validates correctly today may fail verification in ten years if the signing certificate has expired, the timestamp TSA certificate chain is no longer available, or the cryptographic algorithms have been deprecated. This article explains what long-term validation requires and how to build archives that remain verifiable for decades.
Read moreDigital sovereignty in document infrastructure: what it means and why it matters
Digital sovereignty for document infrastructure means controlling where your documents are stored, who can access them, and whether you can retrieve and verify them independently of any vendor. This article explains what genuine sovereignty requires and where most cloud-based document platforms fall short.
Read moreWORM storage and legal hold: when you need write-once archives
WORM storage prevents any modification to archived data at the storage layer. Legal hold suspends deletion for documents under investigation or litigation. This article explains both mechanisms, when they are legally required, and how they relate to hash-chain integrity.
Read moreTamper detection in document archives: how hash chains work
Hash chains make tampering with archived documents mathematically detectable. This article explains how SHA-256 hash chaining works, why it is tamper-evident, and how it compares to other integrity mechanisms for long-term document archives.
Read moreChain of custody for digital documents: what auditors and tax authorities actually require
Chain of custody for a digital document means being able to prove what happened to it, in what order, and by whom, from creation to archive. This article explains what tax authorities and auditors look for, and what technical mechanisms satisfy those requirements.
Read moreRFC 3161 timestamps explained, how to make a digital signature legally durable
A digital signature proves who signed a document. An RFC 3161 timestamp proves when. Here is how trusted timestamps work, why every long-term archive needs them, and how to verify one without trusting the timestamping authority more than necessary.
Read moreWhat is a Legal Evidence Pack and what goes in it?
A Legal Evidence Pack is a structured archive that proves a document existed in a specific form at a specific time and was processed correctly. This article explains what it contains, when you need one, and what the difference is between storing a document and having legally admissible proof.
Read moreXML Signature validation pitfalls in Peppol
Validating XMLDSig signatures on Peppol SMP responses is harder than it looks. Dynamic namespace prefixes, namespace promotion during re-serialization, and C14N canonicalization interact in ways that break standard .NET and Java XML signature verifiers.
Read moreHow Peppol SMP and SML discovery actually works
Peppol uses a DNS-based discovery chain to route invoices to the right Access Point. This article explains how SML and SMP discovery works, what the DNS lookup produces, and what the SMP response contains.
Read moreUBL vs CII: which invoice XML syntax should you choose?
UBL 2.1 and UN/CEFACT CII are both EN16931-compliant XML syntaxes for electronic invoices. This article explains the structural differences, which formats mandate which syntax, and the practical consequences for developers building invoice pipelines.
Read morePeppol mandate Belgium, what changed on 1 January 2026
As of 1 January 2026, every B2B invoice in Belgium has to be sent over Peppol in a structured format. Here is what that means in practice, and how to check whether your trading partners are ready.
Read moreHow to generate Peppol BIS 3.0 invoices in C#
A practical guide to generating valid Peppol BIS Billing 3.0 UBL 2.1 invoices in C#, covering mandatory fields, namespace setup, line items, tax totals, and Schematron validation with Saxon HE.
Read moreUnderstanding EN16931: Europe's invoice data model
EN16931 is the European standard that defines what an e-invoice must contain. This article explains Business Terms, Business Groups, Business Rules, and how the semantic model maps to UBL and CII, from an engineering perspective.
Read moreFactur-X vs ZUGFeRD vs XRechnung vs Peppol: what is the difference?
Factur-X, ZUGFeRD, XRechnung, and Peppol BIS 3.0 are all built on the same underlying standard but serve different markets and delivery channels. Here is a plain-language comparison.
Read moreWhat is PDF/A-3 and why it matters for e-invoicing
PDF/A-3 is the archival PDF format that lets you embed structured XML inside a long-term-readable invoice. Here is what it actually guarantees, what it does not, and why it is the default container for Factur-X and ZUGFeRD.
Read moreWhat is Peppol BIS 3.0? A practical developer introduction
Peppol BIS Billing 3.0 is the XML invoice standard used across European e-invoicing networks. A plain-language technical introduction covering UBL, EN16931, SMP discovery, and validation pitfalls.
Read moreNo articles yet — check back soon.