How Does E-Invoicing Work? A 2026 Technical Guide

How does e-invoicing work? A plain explanation

<div class="post-intro"> E-invoicing replaces paper and PDF invoices with structured data that moves directly between business systems. Instead of emailing a PDF, your ERP produces a machine-readable XML invoice, validates it against agreed rules, and sends it over a secure transport network such as <a href="/peppol.html">Peppol</a>. The receiving system parses the same structure, posts it into accounts payable, and confirms delivery with a signed receipt — no human re-keying required. </div>

The five stages of an e-invoice

Every compliant e-invoice flows through the same five stages, regardless of country:

1. Creation — the ERP or billing system generates a structured invoice (UBL 2.1 or UN/CEFACT CII).
2. Validation — the document is checked against XSD, business math, Peppol BIS rules, and any jurisdiction Schematron.
3. Discovery — an SMP lookup finds the receiver's Access Point, supported documents, and certificate.
4. Transmission — an AS4 message is signed, encrypted, and delivered between Access Points.
5. Response and reconciliation — a Message Level Response (MLR) and, where required, a clearance receipt are returned and stored as the audit trail.

Stage 1: Structured invoice creation

An e-invoice is not a scanned document. It is XML with well-defined fields: supplier, customer, line items, tax breakdown, payment terms, and references. The two dominant syntaxes are UBL 2.1 and UN/CEFACT CII. On Peppol, most jurisdictions use UBL, often wrapped by a specific profile such as Peppol BIS Billing 3.0 or a PINT jurisdiction pack (for example PINT OM for Oman Fawtara).

Because the content is structured, every field is unambiguous — a tax category code cannot be mistyped as a free-text label, and totals cannot disagree with line math without triggering a rule violation.

Stage 2: Validation gates

Before any invoice leaves your boundary, it should pass a layered validation gate:

• Structural: UBL XSD must parse cleanly.
• Business math: line totals, tax calculations, rounding, allowances and charges must reconcile.
• Profile: Peppol BIS 3.0 Schematron rules must pass.
• Jurisdiction: PINT or national CIUS (XRechnung, NLCIUS, Fawtara, etc.) where applicable.
• Code lists: process IDs, document type IDs, and party identifiers must match current eDEC code lists.

Treat every Schematron error as a hard stop. Warnings may pass only under documented policy. GoRoute's validation engine applies these checks automatically for every send and receive.

Stage 3: SMP discovery — finding the receiver

Peppol is a four-corner model. You do not email the invoice to a person — you address it to a participant identifier such as 0192:123456789. To route a message, your Access Point:

1. Queries the SML (Service Metadata Locator) DNS to find the receiver's SMP.
2. Fetches the SMP record to learn which document types and processes the receiver supports.
3. Retrieves the receiver's Access Point URL and certificate from the SMP.

If your receivers' SMP records are wrong, every downstream step fails silently. This is why SMP registration is a first-class operational concern, not a one-time setup task.

Stage 4: AS4 transmission between Access Points

AS4 is the secure transport profile Peppol standardized on. Your Access Point:

• Signs the payload with your Peppol G3 certificate.
• Encrypts it to the receiver's certificate.
• Posts it over HTTPS to the receiver's AS4 endpoint.
• Retries on transient failure with idempotent message IDs.

The receiver's Access Point unpacks the message, verifies signatures, and hands the invoice to the receiver's ERP or tax platform. A cryptographic receipt is returned immediately so both sides share a non-repudiable audit trail.

Stage 5: Responses, clearance, and reconciliation

Depending on the jurisdiction, one or more of the following happens next:

• Message Level Response (MLR) — the receiver accepts or rejects the document with a reason.
• Invoice Response — the receiver confirms booking status (accepted, conditionally accepted, rejected).
• Clearance — in countries that operate a CTC clearance model, the tax authority must approve the invoice before or as it is delivered. Oman Fawtara, Italy SdI, and India IRP are examples.
• Reporting — some countries require a parallel real-time or near-real-time tax report even if the document is not formally cleared.

Your ERP reconciles each outcome against the original invoice using the message ID and a correlation ID.

Clearance versus post-audit models

E-invoicing regulation follows two broad patterns:

• Post-audit (much of the EU, UK, US): invoices flow between parties; authorities audit later.
• Clearance / CTC (Oman, Italy, India, many LATAM countries): the tax authority is in the path and must see or approve each invoice. In Oman, this includes submission of a Tax Data Document (TDD) alongside the PINT OM invoice.

A compliant platform must support both patterns from the same pipeline, because most multinationals send into both.

Where providers like GoRoute fit

You can build all of this in-house, but the operational surface is significant: certificates rotate, Schematron versions change every quarter, SML DNS must be monitored, AS4 libraries receive security updates, and clearance rules evolve per country. A managed provider absorbs that surface so your finance team owns the business process, not the protocol.

GoRoute operates a certified Peppol Access Point and SMP, layered validation (CEN + Peppol BIS + PINT + national CIUS), and jurisdiction-aware clearance flows (including Oman Fawtara TDD submission), so the five stages above run as a single API call for you.

Frequently asked questions

<!-- Rendered from frontmatter faq block by post.html -->