E-invoicing has quietly become one of the most consequential integration problems in European and North African software. What used to be a PDF attached to an email is turning into structured, validated, often digitally signed XML that flows through government platforms and certified networks. If your product touches invoicing at all — ERP, accounting, procurement, a marketplace with billing — you now own a standards problem, a cryptography problem, and a jurisdiction problem at the same time.
The good news is that the landscape has consolidated around a small set of standards. The bad news is that every country wires them together differently. This post maps the pieces we work with weekly at TuniCyberLabs: the EN 16931 world on the European side of the Mediterranean, Tunisia's TTN-operated el-fatoora system on the other, and an invoice architecture that survives both.
The semantic core: EN 16931
The European Norm EN 16931 defines a semantic model for an invoice: what a line item is, how tax categories and exemption reasons are expressed, which fields are mandatory. It deliberately separates meaning from serialization. Two syntaxes are blessed: UBL 2.1 and UN/CEFACT Cross Industry Invoice (CII). Hybrid formats such as Factur-X and ZUGFeRD embed CII XML inside a PDF/A-3, so a single file is simultaneously human-readable and machine-processable.
Two consequences are worth internalizing early:
- ▸Validate in layers: XSD validation only proves the XML matches the syntax. The business rules — tax totals must reconcile, credit notes need a preceding invoice reference — live in the Schematron artefacts published for EN 16931. Run XSD first, Schematron second, and your own business checks third, before anything leaves your system.
- ▸Keep semantics, not syntax, in your core: if your internal invoice model mirrors EN 16931 semantics rather than one serialization, supporting a new national format becomes a mapping exercise at the edge instead of a schema migration in your database.
Transport: Peppol and the four-corner model
Peppol solves distribution. Your system talks to an Access Point, the recipient talks to theirs, and the network handles discovery through SMP and SML lookups and delivery over the AS4 messaging protocol. Peppol BIS Billing 3.0 is the profile that pins EN 16931 down to something implementable. The pitch is real: connect once, reach every registered participant.
The mandate map keeps tightening. Italy has run clearance through its SdI platform since 2019. Germany made B2B e-invoice reception mandatory in January 2025, with issuance obligations phasing in through 2028. France begins its phased rollout in September 2026. The EU's ViDA package points intra-EU B2B invoicing toward structured formats and digital reporting by the end of the decade. If you sell software into Europe, none of this is optional roadmap material anymore.
Clearance versus post-audit
Regulators follow one of two philosophies. Post-audit lets trading partners exchange invoices freely and prove compliance later during inspection. Clearance requires the state, or a platform it operates, to register or approve invoices at issuance time. Italy is clearance; Tunisia leans clearance as well.
The architectural implication is easy to underestimate: under clearance, a government platform becomes a runtime dependency of your billing. It will have maintenance windows, throttling, and error codes that no documentation fully explains. Design for it the way you would design for any unreliable upstream — queues, retries with backoff, idempotent submission, and a degraded mode where invoices are prepared and held rather than silently lost.
Tunisia: el-fatoora and TTN
Tunisia routes electronic invoices through el-fatoora, operated by Tunisie TradeNet (TTN). It is mandatory for B2G exchanges and large taxpayers, and the direction of travel is broader coverage. The invoice is XML in the national format, digitally signed with a certificate chained to the national certification authority (ANCE), then submitted to TTN, which registers it and returns a unique reference that must appear on the human-readable rendering.
Field notes from implementations:
- ▸The signature is the hard part: plan for certificate lifecycle management, secure key storage on tokens or an HSM, and renewals that do not silently break invoice issuance on a weekend.
- ▸Test against the real platform early: local schema validation will not catch platform-side rejections, and the error feedback loop is slower than you want.
- ▸Archive from day one: retain the signed originals, not regenerated copies. Ten-year retention is the safe default across the jurisdictions we deal with.
An architecture that survives both shores
The design that has held up for us: one canonical invoice model aligned to EN 16931 semantics; per-jurisdiction mappers at the edge; a three-stage validation pipeline; submission workers behind a queue with idempotency keys; and a write-once archive for signed artifacts.
A rollout sequence that works for an SME:
1. Inventory every invoice flow: B2G, domestic B2B, cross-border, self-billing. 2. Define the canonical model against EN 16931 semantics, not against your current PDF template. 3. Wire XSD and Schematron validation into CI so mapping regressions fail fast. 4. Decide whether to run your own Peppol Access Point or buy access as a service — for most SMEs, buy. 5. For Tunisia, register with TTN, procure ANCE-chained certificates, and rehearse the full sign-submit-reference loop in a test environment. 6. Stand up archival and audit trails before the first production invoice, not after.
The compliance deadline is the stick, but the carrot matters more. Once invoices are structured data, reconciliation stops being a manual job, payment cycles compress, and financing products can price receivables against verified records. Teams that treat e-invoicing as an architecture investment rather than a checkbox will close their books faster and get paid sooner — on both sides of the Mediterranean.