📊 e-Invoicing Standards & Peppol

Peppol BIS Billing 3.0 & Universal Business Language (UBL 2.1) Architecture

The Global Shift from Visual Documents to Interoperable Data

For over three decades, business-to-business commerce relied on paper invoices or unstructured digital documents (such as PDF attachments sent over email). While PDFs provide an acceptable visual representation for human readers, they are opaque to computers, requiring brittle OCR scraping, manual data entry, and continuous reconciliation friction. Furthermore, tax authorities worldwide lose hundreds of billions annually to VAT fraud and under-reporting in opaque manual billing environments.

To eliminate friction and combat the tax gap, governments across the European Union, Australia, New Zealand, Singapore, and Japan have enacted statutory mandates requiring structured electronic invoicing (e-Invoicing). The recognized international gold standard for interoperable public procurement and B2B billing is Peppol (Pan-European Public Procurement On-Line) and its core invoice specification: Peppol BIS Billing 3.0, implemented using Universal Business Language (UBL 2.1) XML.

The Peppol 4-Corner Network Architecture

Traditional electronic data interchange (EDI) required costly point-to-point bilateral integrations: if a supplier sold to 100 enterprise customers, they were forced to configure 100 separate AS2 connections or custom API mappings. Peppol eliminates bilateral complexity through an open, federated 4-Corner Model:

[ Corner 1: Sender / Supplier ERP ]
               |
               v (Proprietary API / Cloud Webhook)
[ Corner 2: Sender Certified Access Point ]
               |
               | (Secure AS4 Protocol over TLS 1.3)
               v (Target SMP/SML Dynamic Directory Lookup)
[ Corner 3: Receiver Certified Access Point ]
               |
               v (Local ERP Ingestion API / Queue)
[ Corner 4: Receiver / Buyer ERP System ]

The core innovation of the 4-Corner Model is Dynamic Discovery:

  1. Service Metadata Locator (SML): A centralized DNS-based top-level registry. When Corner 2 needs to send an invoice to buyer identifier 0192:987654321, it issues a DNS lookup to locate the buyer's authoritative SMP server.
  2. Service Metadata Publisher (SMP): A distributed metadata directory containing the buyer's supported document profiles (e.g. whether they accept Peppol BIS 3.0 invoices, credit notes, or dispatch advices), public encryption certificates, and technical AS4 endpoint URLs.
  3. Certified Access Point (AP): Regulated network gateways that guarantee transport security, validate document schemas, and enforce non-repudiation using electronic delivery receipts.

Anatomy of a UBL 2.1 Peppol BIS 3.0 XML Document

A compliant Peppol BIS Billing 3.0 document is authored in strict XML conforming to the OASIS UBL 2.1 specification. Notice the explicit customization identifiers linking the document to European Standard EN 16931:

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <!-- Peppol Customization & Profile Specification Identifiers -->
  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
  <cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
  <cbc:ID>INV-2026-00481</cbc:ID>
  <cbc:IssueDate>2026-09-21</cbc:IssueDate>
  <cbc:DueDate>2026-10-21</cbc:DueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode> <!-- 380 = Commercial Invoice -->
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cbc:BuyerReference>PO-49102-CORP</cbc:BuyerReference>

  <!-- Accounting Supplier Party (Corner 1) -->
  <cac:AccountingSupplierParty>
    <cac:Party>
      <cbc:EndpointID schemeID="0192">987654321</cbc:EndpointID>
      <cac:PartyName>
        <cbc:Name>FreeInvoicer Global Systems AS</cbc:Name>
      </cac:PartyName>
      <cac:PostalAddress>
        <cbc:StreetName>Technologiveien 12</cbc:StreetName>
        <cbc:CityName>Oslo</cbc:CityName>
        <cbc:PostalZone>0150</cbc:PostalZone>
        <cac:Country>
          <cbc:IdentificationCode>NO</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>NO987654321MVA</cbc:CompanyID>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:PartyTaxScheme>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <!-- Legal Monetary Totals -->
  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="EUR">1250.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="EUR">1250.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>
</Invoice>

Two-Stage Validation: XSD & Schematron Engine

Transmitting a non-compliant XML document across the Peppol network results in an immediate message rejection by the Access Point. Compliant invoicing platforms implement automated two-phase validation pipelines. The first phase validates structural conformity against the OASIS UBL 2.1 XSD schemas, verifying well-formedness, tag namespaces, and mandatory container nodes.

The second phase executes Schematron rule assertions developed by the European Committee for Standardization (CEN). For instance, rule PEPPOL-EN16931-R001 verifies that business process identifiers strictly match registered profiles, while rule PEPPOL-EN16931-R008 mandates that payment due dates cannot precede invoice issue dates. Catching these semantic discrepancies before network dispatch prevents costly message dropouts and audit rejections.

export interface ValidationResult {
  isValid: boolean;
  xsdErrors: string[];
  schematronErrors: string[];
}

export async function validatePeppolInvoice(xmlPayload: string): Promise<ValidationResult> {
  const xsdErrors: string[] = [];
  const schematronErrors: string[] = [];

  // Stage 1: Structural XSD Validation (UBL 2.1 Schema)
  // Verifies correct XML syntax, closing tags, and element sequences
  const isXsdValid = await runXsdValidator(xmlPayload, 'UBL-Invoice-2.1.xsd', xsdErrors);
  if (!isXsdValid) {
    return { isValid: false, xsdErrors, schematronErrors };
  }

  // Stage 2: Business Rule Schematron Validation (CEN/TC 434 & Peppol BIS 3.0)
  // Evaluates complex rules (e.g. BR-CO-15: Tax inclusive amount must equal tax exclusive + tax total)
  const isSchematronValid = await runSchematronValidator(xmlPayload, 'PEPPOL-EN16931-UBL.sch', schematronErrors);

  return {
    isValid: isSchematronValid,
    xsdErrors,
    schematronErrors
  };
}

The AS4 Protocol: High-Assurance Secure Transport

Unlike standard unauthenticated webhooks or plain email, Peppol Corner 2 and Corner 3 Access Points communicate exclusively via the Applicability Statement 4 (AS4) profile. AS4 is a modular OASIS standard built upon SOAP and Web Services Security (WS-Security):

  • Payload Encryption: The entire invoice XML payload is encrypted using AES-128 or AES-256 GCM using the recipient Access Point's public X.509 certificate.
  • Cryptographic Non-Repudiation: The sending Access Point signs the payload with its private certificate. Upon receipt, the recipient Access Point computes an HMAC digest and returns a cryptographically signed Message Disposition Notification (MDN). This serves as legally binding proof of receipt in international commercial disputes.

Peppol Directory Governance & Continuous SMP Polling

In a global trading mesh, company capabilities change dynamically: an enterprise may register for domestic e-invoices today and activate cross-border procurement profiles next month. Corner 2 Access Points must never cache SMP lookup records permanently. Production dispatch pipelines query the global Peppol SML (managed by OpenPEPPOL) using SHA-256 hashed participant identifiers, retrieving real-time X.509 certificates and endpoint addresses with short 24-hour TTL caching bounds.

Electronic Credit Notes, Dispatch Advices & Invoice Response Messages

Peppol BIS Billing 3.0 is not limited to outbound invoices. It orchestrates a complete bidirectional commercial procurement lifecycle:

  • Credit Notes (InvoiceTypeCode 381): Formally reverses or adjusts an erroneous or disputed invoice line item, preserving legal audit trails without mutating historical records.
  • Invoice Response Message (MLR / IMR): Transmits automated structured status updates from buyer to seller (e.g. AB for Acknowledged, IP for In Process, AP for Approved, or RE for Rejected with specific reason codes).
  • Despatch Advice (UBL 2.1 DespatchAdvice): Links physical logistics and shipping manifests directly to the electronic invoice for instant 3-way matching.

By implementing Peppol BIS Billing 3.0, UBL 2.1 syntax, continuous SMP discovery, and automated Schematron compliance, billing architectures ensure frictionless interoperability across global supply chains and full regulatory compliance with worldwide e-invoicing mandates.

FreeInvoicer Treasury Council

Written by FreeInvoicer Treasury Council

Senior fintech software architect and corporate treasury consultant specializing in Peppol BIS 3.0 electronic invoicing, automated 3-way matching algorithms, and enterprise ERP integration.