Executive Summary

The digitization of the global financial supply chain represents one of the most significant structural shifts in modern commerce. At the forefront of this transformation is the Pan-European Public Procurement Online (Peppol) network, a framework that has evolved from a regional European Union project into a global standard for the secure, interoperable exchange of business documents. This report provides an exhaustive technical and operational analysis of the Peppol ecosystem, specifically addressing the mechanisms of the Four-Corner Model, the cryptographic assurance of the AS4 transport layer, the semantic rigor of the Business Interoperability Specifications (BIS) Billing 3.0, and the strategic integration of these protocols into major Enterprise Resource Planning (ERP) systems including SAP S/4HANA, Microsoft Dynamics 365 Finance, and Oracle NetSuite.

The analysis synthesizes technical specifications, legislative mandates, and integration methodologies to offer a roadmap for enterprise architects and financial officers. Central to this report is the examination of the „Connect Once, Reach All“ paradigm, which replaces fragmented Electronic Data Interchange (EDI) connections with a dynamic, discovery-based network.¹ Furthermore, the report critically assesses the impending infrastructure migration from CNAME to NAPTR DNS lookups, the transition from European-centric standards to the Peppol International (PINT) model, and the operational imperatives driven by government mandates in jurisdictions such as Germany, Singapore, and Belgium.

Part I: The Peppol Interoperability Framework

1.1 The Evolution of Interoperability: Breaking the Walled Gardens

Historically, electronic invoicing was characterized by the „Three-Corner Model,“ a topology where the buyer and supplier were required to connect to the same service provider or where distinct service providers established bilateral roaming agreements. This architecture, often referred to as a „walled garden,“ created significant friction; suppliers were frequently forced to maintain multiple connections—one for each major customer’s preferred network—resulting in high costs and technical redundancy.

Peppol addresses this fragmentation through the implementation of the Four-Corner Model. This topology mimics the telecommunications industry’s roaming infrastructure, decoupling the sender’s service provider from the receiver’s service provider. By standardizing the technical interfaces (Corner 2 and Corner 3), Peppol allows any registered participant to exchange documents with any other participant without prior technical negotiation or direct peering agreements.¹

1.2 The Four-Corner Model Architecture

The Four-Corner Model is the structural foundation of the Peppol network. It distributes responsibilities across four distinct entities, ensuring scalability and security.

1.2.1 Corner 1: The Originator (Supplier)

Corner 1 (C1) represents the economic operator issuing the business document. In an invoicing scenario, this is the supplier. The primary technical responsibility of C1 is the extraction of invoice data from the internal ERP system. Whether the source system is SAP, Oracle, or a custom accounting platform, the data is typically generated in a proprietary or semi-structured format (e.g., SAP IDoc, CSV, JSON, or XML). C1 is responsible for mapping this internal data to the canonical standard required by the network—typically the Universal Business Language (UBL)—before transmission to Corner 2.¹ C1 does not communicate directly with the Peppol network but relies on a contracted service provider (Corner 2).

1.2.2 Corner 2: The Sending Access Point (C2)

Corner 2 (C2) is a service provider accredited by a Peppol Authority. C2 acts as the gateway to the network. Upon receiving the payload from C1, C2 performs a sequence of critical operations:

1. Semantic Transformation and Validation: While C1 may provide the data, C2 often performs the final transformation into the compliant Peppol BIS Billing 3.0 format. Crucially, C2 must validate the document against the rigorous Schematron rules defined by OpenPeppol. If a document fails this validation (e.g., mathematical errors in tax totals), it is rejected at this stage, preventing invalid data from polluting the network.¹
2. Dynamic Discovery: C2 queries the Service Metadata Locator (SML) and Service Metadata Publisher (SMP) to locate the correct endpoint for the intended recipient.⁶
3. Encryption and Encapsulation: C2 packages the validated document into an AS4 message envelope, signs it with a PKI certificate issued by a Peppol Authority, and establishes an encrypted TLS tunnel to Corner 3.⁶

1.2.3 Corner 3: The Receiving Access Point (C3)

Corner 3 (C3) is the service provider for the receiver. Its function is the mirror image of C2. C3 receives the AS4 transmission, decrypts the payload, and verifies the digital signature of C2. This step ensures Non-Repudiation of Origin—the receiver has cryptographic proof of the sender’s identity. C3 sends a synchronous transport acknowledgement (SignalMessage) back to C2 to confirm technical receipt.⁸ C3 then routes the decrypted business document to the final recipient (Corner 4).

1.2.4 Corner 4: The Recipient (Buyer)

Corner 4 (C4) is the entity receiving the document. Upon receipt from C3, the structured data (XML) is ingested into the C4 ERP or Accounts Payable (AP) system. Because the data is structured and pre-validated by the network, C4 can employ automated reconciliation processes (3-way matching) to approve the invoice for payment without manual data entry.³

1.3 The Dynamic Discovery Infrastructure (SML and SMP)

The scalability of Peppol relies on the absence of static routing tables. In traditional EDI, C2 would need a hardcoded IP address for C3. In Peppol, C2 discovers C3 dynamically at the moment of transmission. This is achieved through a distributed registry system comprising the Service Metadata Locator (SML) and the Service Metadata Publisher (SMP).

1.3.1 Service Metadata Publisher (SMP): The Decentralized Directory

The SMP functions as a decentralized address book. Every participant in the network must be registered in an SMP. This registry stores the metadata required for technical interoperability. When C2 queries an SMP for a specific participant, the SMP returns an XML response containing:

• Document Capabilities: A list of document types the participant is capable of receiving (e.g., Invoice, Credit Note, Despatch Advice).
• Process Identifiers: The specific business processes the participant supports (e.g., urn:fdc:peppol.eu:2017:poacc:billing:01:1.0).
• Access Point Endpoint: The URL of the Access Point (C3) that serves the participant.
• Public Certificate: The X.509 certificate of C3, which C2 uses to encrypt the message payload.¹

Insight: This architecture allows for a „publish-subscribe“ model of capabilities. If a receiver upgrades their ERP to support Order Responses, they simply update their SMP record. The entire network immediately becomes aware of this new capability without any manual configuration by the thousands of suppliers who might wish to send them an Order Response.

1.3.2 Service Metadata Locator (SML): The DNS Root

The SML is a centralized lookup service managed by OpenPeppol (specifically, by the European Commission’s DG DIGIT). It acts as the bridge between a business identifier (such as a VAT number or GLN) and the specific SMP where that business’s metadata is hosted.¹ The SML utilizes the Domain Name System (DNS) to function.

The lookup logic follows a precise algorithm:

1. Identifier Normalization: The participant identifier (e.g., 0088:123456789) is normalized and hashed.
2. DNS Query Construction: C2 constructs a domain name by prepending the hash to the SML’s zone (e.g., edelivery.tech.ec.europa.eu).
3. Resolution: The global DNS infrastructure resolves this domain name to the URL of the specific SMP.¹²

1.3.3 Infrastructure Migration: CNAME to NAPTR

A critical evolution is currently underway in the Peppol infrastructure. Historically, the SML utilized CNAME records pointing to MD5 or SHA-1 hashes of participant IDs. This legacy approach is being deprecated in favor of NAPTR (Name Authority Pointer) records using SHA-256 hashes.

Feature	Legacy Approach (Deprecating Feb 2026)	New Approach (Mandatory Feb 2026)
DNS Record Type	CNAME	NAPTR (U-NAPTR)
Hashing Algorithm	MD5 / SHA-1	SHA-256
Encoding	Hexadecimal	Base32
Protocol Support	HTTP (Limited)	HTTP and HTTPS
Security Resilience	Vulnerable to collision attacks	High collision resistance

Strategic Implication: This migration, which becomes mandatory in February 2026, requires all SMPs and Access Point software to be updated. The shift to NAPTR allows for more complex regular expression rewriting in the DNS lookup, facilitating a seamless transition to HTTPS-only communication for SMPs, thereby securing the metadata retrieval process against man-in-the-middle attacks.¹³ Organizations running proprietary or self-hosted Access Points must prioritize this upgrade to avoid a total loss of connectivity.

1.4 Transport Protocol: The Move to AS4

The transport layer of Peppol has evolved from the AS2 protocol to AS4. AS4 is a profile of the OASIS ebMS 3.0 specification and provides a secure, payload-agnostic delivery mechanism.⁷

1.4.1 AS4 Technical Profile

The Peppol AS4 profile mandates specific configurations to ensure interoperability:

• Topology Enhancement: The AS4 message header must include a finalRecipient property. This ensures that even if C3 serves thousands of customers, it can route the incoming packet to the correct C4 entity.¹⁵
• Compression: GZIP compression is mandatory. Crucially, compression must be applied before encryption. Compressing encrypted data is mathematically inefficient and ineffective; AS4 optimizes bandwidth by compressing the payload first.⁸
• Security (WS-Security): The protocol uses WS-Security 1.1.1. Payloads are signed using the sender’s private key (SHA-256) and encrypted using the receiver’s public key (AES-128-GCM). This dual-layer cryptography ensures that only the intended C3 can read the message and that C3 can cryptographically prove the message came from C2.¹⁶

Part II: Semantic Standards and Data Validation

2.1 The Semantic Challenge

While AS4 ensures the truck arrives at the destination, it does not guarantee the cargo is usable. If a German supplier sends an invoice with a date format DD.MM.YYYY to an American system expecting MM/DD/YYYY, the process fails. Peppol solves this via Semantic Interoperability.

2.2 Peppol BIS Billing 3.0

The core standard for invoicing in the network is Peppol BIS Billing 3.0. This specification is a Core Invoice Usage Specification (CIUS) of the European Standard EN 16931.¹⁷

2.2.1 UBL 2.1 vs. UN/CEFACT CII

EN 16931 allows for two syntactic bindings (formats):

1. UBL 2.1 (Universal Business Language): Maintained by OASIS. This is the dominant format in the Peppol network.⁴
2. UN/CEFACT CII (Cross Industry Invoice): Maintained by the UN. While compliant with EN 16931, it is less frequently used in Peppol but is relevant for the German XRechnung standard.⁴

Peppol BIS Billing 3.0 maps the abstract semantic model of EN 16931 (which defines „what“ data is needed, e.g., „Buyer Name“) to the specific XML tags of UBL 2.1 (e.g., <cac:AccountingCustomerParty>).

2.3 The Defense Architecture: Validation Layers

To maintain the integrity of the network, Peppol employs a „defense in depth“ validation strategy. Access Points are required to validate every message before it enters the network.

2.3.1 Syntactic Validation (XSD)

The first layer is XML Schema Definition (XSD) validation. This checks the structural correctness of the file.

• Does the file follow the UBL 2.1 structure?
• Are dates in YYYY-MM-DD format?
• Are mandatory XML tags present?
  If an invoice fails XSD validation, it is rejected immediately as „malformed“.4

2.3.2 Semantic Validation (Schematron)

The second, more rigorous layer is Schematron. Schematron is a rule-based validation language that asserts business logic that XSD cannot enforce.

• Business Rule Example: „The sum of the invoice line net amounts must equal the Tax Exclusive Amount.“ (Rule BR-CO-10).
• Conditional Logic: „If the Tax Category is ‚Reverse Charge‘ (AE), the Tax Amount must be 0.00.“
• Implementation: OpenPeppol publishes official Schematron artifacts (XSLT files) on GitHub. Access Points must execute these XSLT scripts against the invoice XML. If any „Fatal“ rule is triggered, the invoice is rejected.⁴

2.3.3 Country-Specific Rules

While BIS Billing 3.0 is a common standard, tax laws differ by country. Peppol handles this via National Rules, which are additional Schematron files triggered by the country code of the supplier.

• Sweden (SE): Validates that the Swedish Organization Number (Org.nr) follows the correct Luhn algorithm check digit.²²
• Netherlands (NL): Enforces rules regarding the OIN (Overheidsidentificatienummer) for government entities.
• Italy: Ensures compatibility with the FatturaPA standard used by the SdI (Sistema di Interscambio).

Insight: This hierarchical validation—Global (UBL) -> European (EN 16931) -> Peppol (BIS 3.0) -> National (Country Rules)—ensures that a single document format can be compliant across dozens of jurisdictions without changing the underlying technical structure.

2.4 Peppol International (PINT)

As Peppol expands beyond Europe to Singapore, Australia, New Zealand, and Japan, the EU-centric constraints of BIS Billing 3.0 (tied to EU VAT Directives) became a limitation. The solution is PINT (Peppol International Invoice).²³

• The Wildcard Mechanism: PINT introduces a „Wildcard“ customization ID (urn:peppol:pint:billing-1@*). This allows specific regions to swap out the VAT-centric tax category codes for local equivalents (e.g., GST in Australia, Consumption Tax in Japan) while keeping the rest of the invoice structure identical to the standard.²³
• Migration Roadmap: Starting May 2025, support for PINT wildcard reception becomes mandatory for all Service Providers. By 2026, OpenPeppol aims to converge PINT and BIS 3.0 into a unified BIS 4.0 standard, creating a truly global invoicing language.²³

Part III: Integration with ERP Solutions

Integrating Peppol into an enterprise environment requires bridging the gap between internal ERP data structures and the external XML standards. The following sections detail the technical integration strategies for SAP, Microsoft, and NetSuite.

3.1 SAP S/4HANA Peppol Integration

SAP offers one of the most comprehensive integration frameworks for Peppol, centered on the Document and Reporting Compliance (DRC) solution (formerly the eDocument Framework).

3.1.1 The eDocument Framework Architecture

The integration is not a simple file export; it is a managed process within the SAP core.

1. Source Document Trigger: When a billing document (VF01) or Financial Posting (FB70) is created, the system checks the customer master data.
2. eDocument Creation: If the customer is flagged for e-invoicing, an entry is created in the eDocument Cockpit (EDOC_COCKPIT). This serves as the central management console.²⁴
3. Application Interface Framework (AIF): This is the semantic engine. AIF maps the internal SAP structures (based on IDocs or CDS views) to the target XML format. SAP delivers pre-packaged „Standard Content“ for Peppol UBL, ZUGFeRD, and XRechnung, reducing the need for custom ABAP mapping.¹⁰

3.1.2 The Peppol Exchange Service (Cloud Edition)

For the transport layer, SAP recommends the Peppol Exchange Service, a SaaS offering on the SAP Business Technology Platform (BTP).

• Reverse Invoke Proxy: To connect the on-premise S/4HANA system to the cloud without opening inbound firewall ports, SAP utilizes the Cloud Connector. This establishes a secure tunnel from the intranet to the BTP tenant.²⁵
• Managed Access Point: The Peppol Exchange Service acts as the Access Point (C2/C3). It handles the AS4 encryption, certificate management, and SMP lookups automatically. The ERP user effectively outsources the complexity of „Corner 2“ to SAP.²⁵

3.1.3 Handling German Mandates: XRechnung vs. ZUGFeRD

Germany’s e-invoicing landscape is complex, requiring specific handling in SAP.

• XRechnung: This is a pure XML format mandatory for Federal B2G transactions. SAP AIF generates the UBL or CII XML directly.
• ZUGFeRD: This is a hybrid format (PDF + XML) used in B2B. SAP can generate the PDF/A-3 file and embed the XML. However, when transmitting via Peppol, the system is typically configured to strip the PDF visual layer and transmit only the XML payload, as Peppol is optimized for structured data. The Peppol network can support binary attachments, but the core „Invoice“ is the XML data.²⁶
• Incoming Processing: When receiving Peppol invoices, SAP DRC ingests the XML. It utilizes the „Incoming Automation“ solution to map the XML fields to the SAP Incoming Invoice (MIRO), often achieving high rates of automated posting.²⁸

3.2 Microsoft Dynamics 365 Finance Integration

Microsoft’s integration strategy leverages the Regulatory Configuration Service (RCS) and the Electronic Reporting (ER) module, providing a highly configurable, low-code approach.

3.2.1 Electronic Reporting (ER): The Configuration Engine

Instead of hard-coded formats, Dynamics 365 uses ER configurations.

• Global Repository: Microsoft publishes ER configurations for „Peppol BIS Billing 3.0“ in the LCS (Lifecycle Services) repository. Administrators import these configurations directly into the environment.²⁹
• Model Mapping: The „Invoice Model“ is mapped to the internal Dynamics tables (CustInvoiceJour, ProjInvoiceJour). This abstraction allows users to modify mappings (e.g., binding a custom field to a UBL note tag) without developer intervention.²⁹

3.2.2 The Electronic Invoicing Service (Microservice)

Dynamics 365 offloads the heavy lifting of signing and transmission to the Electronic Invoicing Service, a microservice hosted in Azure.

• RCS Setup: The service environment is configured in RCS. This includes defining the „Processing Pipeline“—the sequence of actions (Transform, Sign, Send) the service performs on the data.³⁰
• Azure Key Vault: Security is managed via Azure Key Vault. The digital certificate required for the AS4 signature is stored in the Key Vault. Dynamics 365 is configured with a secret reference, allowing the Electronic Invoicing Service to access the certificate securely at runtime without the private key ever touching the ERP database.²⁹

3.2.3 Feature Management and Country Specifics

Microsoft releases Peppol capabilities as „Features.“ Administrators must enable „Electronic invoicing integration“ in the Feature Management workspace.³³

• Italy (FatturaPA): Specific configurations exist to handle the CIG and CUP codes required for public procurement in Italy. These are mapped in the ER configuration to specific XML tags required by the SdI.³⁴
• Australia/NZ: The system supports mapping UN/ECE Rec 20 unit codes (e.g., EA for Each) to internal units, a requirement for PINT compliance in the APAC region.³⁵

3.3 Oracle NetSuite Integration

NetSuite’s approach differs from SAP and Microsoft. Rather than a monolithic native framework, it relies heavily on the SuiteApp ecosystem and partner integrations.

3.3.1 Electronic Invoicing SuiteApp

NetSuite provides a foundation called the Electronic Invoicing SuiteApp. This tool allows administrators to define XML or JSON templates using the Freemarker templating engine.

• Role: It generates the e-document file from the Transaction record but does not inherently include the AS4 transport mechanism or the Peppol network connection.³⁶

3.3.2 The Partner Ecosystem (Link4, Avalara, Storecove)

For Peppol connectivity, the majority of NetSuite customers utilize certified partner SuiteApps (e.g., Link4, Cegedim, Storecove).

• Integration Flow:

1. Creation: An invoice is saved in NetSuite.
2. Trigger: The Partner SuiteApp detects the transaction and uses the Freemarker template to generate a JSON payload.
3. API Transmission: The payload is sent via REST API to the Partner’s external Access Point (C2).
4. Network Handling: The Partner AP converts the JSON to Peppol UBL, handles the SML lookup, signs the message, and transmits it via AS4.³⁷
5. Feedback: The Partner AP pushes the status (e.g., „Sent,“ „delivered,“ „Rejected“) back into NetSuite, updating custom fields on the Invoice record so the user has visibility within the ERP.³⁹

3.3.3 Singapore and PINT Support

NetSuite has released a specific „Singapore Peppol-Ready“ SuiteApp.

• PINT Compliance: This app is pre-configured with templates for the PINT-SG standard. It supports both the „PINT-SG“ (domestic) and „PINT Wildcard“ (cross-border) formats.
• Inbound Automation: Uniquely, this SuiteApp also handles inbound processing, converting incoming Peppol XMLs into NetSuite „Vendor Bills“ automatically, streamlining the Accounts Payable workflow.⁴⁰

Part IV: Operational Considerations and Best Practices

4.1 Message Level Responses (MLR): Closing the Feedback Loop

A critical operational blind spot in many implementations is the handling of Message Level Responses (MLR).

• The Issue: The AS4 „SignalMessage“ only confirms that Corner 3 received the file. It does not confirm that Corner 4 accepted it. The invoice could be rejected hours later due to business rules (e.g., „PO Number not found“).
• The Solution: Peppol defines a specific MLR document type. When C4 processes the invoice, it sends an MLR back to C1.
• Status Codes: The MLR contains status codes such as AP (Accepted), RE (Rejected), or UQ (Under Query).
• ERP Configuration: Advanced integrations (like SAP DRC) are capable of ingesting the inbound MLR and automatically updating the Invoice Status in the cockpit. If an MLR with status RE is received, the invoice in SAP turns red, alerting the AR clerk to investigate. Without this, the supplier wrongly assumes the invoice is being processed for payment.⁹

4.2 Access Point Selection Criteria

Selecting the right Access Point (Corner 2) is a strategic decision. While all accredited APs can connect to the network, their capabilities differ significantly.

1. Technology Stack: Does the AP support the new NAPTR/SHA-256 lookup standard? If not, they will face obsolescence in 2026.¹⁴
2. Validation Engines: Does the AP perform rigorous Schematron validation before attempting to send? „Silent failures“ occur when an AP accepts a bad invoice from the ERP and then fails to send it without notifying the sender.⁵
3. ERP Connectivity: Does the AP offer a native API or connector for your specific ERP? Reliance on archaic SFTP file drops increases latency and reduces visibility compared to real-time API integrations.⁴³
4. Global Reach: For multinational corporations, does the AP support PINT and the specific tax compliance rules of non-EU jurisdictions (e.g., Singapore, Japan, Australia)?.⁴⁴

4.3 Common Integration Pitfalls

4.3.1 Master Data Quality

The most common point of failure is master data. Peppol routing is entirely dependent on identifiers. If the Customer Master in the ERP does not contain the correct Peppol Participant ID (e.g., VAT number) and the correct Scheme ID (e.g., 0088 for GLN, 0184 for Danish CVR), the SML lookup will fail.

• Best Practice: Implement mandatory field validation in the ERP to ensure no customer can be flagged for e-invoicing without a valid Endpoint ID and Scheme ID.⁴⁵

4.3.2 The PDF Dependency

Many organizations attempt to treat Peppol as a „digital courier“ for their traditional PDF invoices, embedding large PDF files as attachments to the XML.

• Constraint: Peppol is data-centric. While attachments are allowed, they are secondary. Large attachments (>10MB) often cause AS4 transmission failures.
• Risk: „Shadow IT“ scenarios where the data in the XML differs from the data in the PDF. In Peppol, the XML is the legal original.
• Solution: Focus on the XML data quality. Ensure the ERP’s rounding logic matches the strict Peppol requirements (line-level rounding) to prevent „1 cent“ discrepancies that lead to rejection.⁴⁶

4.3.3 Environment Contamination

A frequent operational error is the mismatch of environments. A supplier might register a customer in the SMK (Peppol Test SML) but attempt to send an invoice from their Production ERP. The Production Access Point will query the Production SML, find no record, and fail.

• Best Practice: Maintain strict separation. Test ERP connects to Test AP (SMK). Production ERP connects to Production AP (SML). Never cross the streams.¹²

Part V: The German Context – A Case Study in Transition

Germany represents one of the most significant immediate drivers for Peppol adoption in Europe, characterized by a complex transition from legacy formats to strict standards.

5.1 The 2025 Mandate

The „Growth Opportunities Act“ (Wachstumschancengesetz) mandates a paradigm shift for German B2B transactions.

• January 1, 2025: All German businesses must be capable of receiving electronic invoices compliant with EN 16931. This effectively ends the era of paper/PDF exclusivity.
• 2027/2028: The mandate to issue e-invoices phases in, starting with companies having a turnover > €800,000.⁴⁸

5.2 Technical Standards: XRechnung vs. ZUGFeRD

German companies must navigate two competing yet compliant standards:

1. XRechnung: The „pure“ XML standard (UBL or CII). This is mandatory for federal public procurement (B2G). It is machine-readable only, making visualization tools necessary for human verification.⁵⁰
2. ZUGFeRD 2.x (Factur-X): A hybrid format consisting of a PDF/A-3 file with an embedded XML. This is popular in B2B because it is human-readable (PDF) and machine-processable (XML).

• Peppol Implementation: When using Peppol, the visual PDF component of ZUGFeRD is often discarded or treated as a binary attachment, with the XML payload taking precedence as the primary data carrier. For federal B2G (e.g., via the ZRE portal), Peppol transmission of XRechnung is the preferred, and often mandatory, automated channel.²⁶

5.3 Leitweg-ID

For B2G transactions in Germany, routing requires a Leitweg-ID. This is a specific routing code for public entities.

• Peppol ID Construction: The Peppol Participant ID for a German public entity typically follows the format 0204:Leitweg-ID. ERP systems must be configured to store this Leitweg-ID in the customer master data to ensure correct routing through the SML.⁵²

Part VI: Future Outlook – From 4-Corner to 5-Corner

The evolution of Peppol is moving towards Continuous Transaction Controls (CTC). Governments are increasingly unsatisfied with post-audit models and are moving toward real-time tax clearance.

6.1 The 5-Corner Model

In the 5-Corner Model, the Tax Authority acts as a fifth corner.

• Workflow: When C2 sends an invoice to C3, it simultaneously reports a subset of that data (or the full invoice) to the Tax Authority’s platform (Corner 5) for real-time validation and VAT recording.³
• ViDA (VAT in the Digital Age): The European Commission’s ViDA proposal aims to standardize this across the EU, likely utilizing the Peppol infrastructure as the transmission layer for these real-time reports.

6.2 Conclusion

Peppol has matured from a European procurement project into the critical infrastructure of global digital trade. For enterprise architects and financial leaders, the integration of Peppol into the ERP landscape is no longer an optional „add-on“ but a fundamental requirement for business continuity. Success requires a holistic approach that combines technical rigor (AS4, NAPTR, PINT) with operational excellence (Master Data governance, MLR handling). As mandates like Germany’s 2025 laws and global shifts to CTC accelerate, the organizations that embed these standards deep into their ERP core will gain a significant competitive advantage in the automated economy.

Referenzen

1. Peppol Explained · Arratech AB, Zugriff am November 29, 2025, https://www.arratech.com/peppol-explained
2. Peppol Interoperability Framework – OpenPeppol, Zugriff am November 29, 2025, https://peppol.org/learn-more/peppol-interoperability-framework/
3. The Peppol 4-corner model and the 5-corner Peppol CTC | EDICOM Global, Zugriff am November 29, 2025, https://edicomgroup.com/blog/peppol-4-corner-5-corner-ctc
4. Peppol Document Formats – an introduction – Ionite, Zugriff am November 29, 2025, https://ionite.net/news-articles/2025-03-07_peppol_document_formats/
5. Seven Things to Consider When Selecting a Peppol Access Point – ecosio, Zugriff am November 29, 2025, https://ecosio.com/en/blog/7-things-to-consider-when-selecting-a-peppol-access-point/
6. An introduction to PEPPOL – GS1, Zugriff am November 29, 2025, https://www.gs1.org/sites/default/files/openpeppol_gs1_standards_conference_2019-09-10.pdf
7. Peppol AS4 Profile, Zugriff am November 29, 2025, https://docs.peppol.eu/edelivery/as4/specification/
8. eDelivery AS4 – 1.14 – European Commission, Zugriff am November 29, 2025, https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eDelivery+AS4+-+1.14
9. Peppol Message Responses – A Helpful Guide – ecosio, Zugriff am November 29, 2025, https://ecosio.com/en/blog/peppol-message-responses-a-helpful-guide/
10. How to integrate PEPPOL with SAP for the exchange of e-invoices, Zugriff am November 29, 2025, https://www.pikon.com/en/blog/peppol-sap-document-compliance-edocuments-exchange-einvoice/
11. REST API – Peppol Practical, Zugriff am November 29, 2025, https://peppol.helger.com/public/menuitem-tools-rest-api
12. SML AND SMP EXPLAINED BY BASWARE – IMDA, Zugriff am November 29, 2025, https://www.imda.gov.sg/-/media/imda/files/industry-development/infrastructure/technology/nationwide-e-invoicing-framework/basware-singapore-e-invoice-industry-workshop-jul-2018.pdf
13. Document exchange explained – Peppol Practical, Zugriff am November 29, 2025, https://peppol.helger.com/public/menuitem-docs-doc-exchange
14. Peppol Service Metadata Publisher Updates – Arratech, Zugriff am November 29, 2025, https://www.arratech.com/blog/peppol-service-metadata-infrastructure-updates-must-do-s-before-the-deadline
15. eDelivery SMP – 2.0 (2024 PR draft) – European Commission, Zugriff am November 29, 2025, https://ec.europa.eu/digital-building-blocks/sites/pages/viewpage.action?pageId=708412335
16. How to Setup a Peppol AS4 Access Point – Loren Data, Zugriff am November 29, 2025, https://www.ld.com/wp-content/uploads/2020/01/How-to-Setup-a-Peppol-AS4-Access-Point-3.pdf
17. PEPPOL BIS Billing 3.0 – A real EN 16931 invoice | B2Brouter, Zugriff am November 29, 2025, https://www.b2brouter.net/global/peppol-bis-billing-3-0-a-real-en-16931-invoice/
18. Peppol BIS Billing, Zugriff am November 29, 2025, https://docs.peppol.eu/poacc/billing/3.0/bis/
19. PEPPOL Tools REST API – Ademico Software, Zugriff am November 29, 2025, https://ademico-software.com/peppol-tools-api/
20. Validator Configuration Peppol BIS Billing 3.0 [MIRROR OF GitLab] – GitHub, Zugriff am November 29, 2025, https://github.com/itplr-kosit/validator-configuration-bis
21. Validating Peppol Documents – Ionite, Zugriff am November 29, 2025, https://ionite.net/news-articles/2023-08-17_validating_peppol_documents/
22. Release notes for Peppol BIS Billing v3, Zugriff am November 29, 2025, https://docs.peppol.eu/poacc/billing/3.0/2024-Q4/release-notes/
23. Peppol Document Types & Standards, Zugriff am November 29, 2025, https://www.peppol.nu/more-about-einvoicing/document-types-standards/
24. Integration | SAP Help Portal, Zugriff am November 29, 2025, https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/5127da8a114f4f3eb134546b9f1722d0/17f07aced86d454786ebc355c14c3429.html?locale=en-US&state=PRODUCTION&version=2025.000
25. Integrating with SAP S/4HANA and SAP ERP – SAP Help Portal, Zugriff am November 29, 2025, https://help.sap.com/docs/peppol-exchange/peppol-exchange/integrating-with-sap-s-4hana-and-sap-erp
26. SAP E-Invoice – Solution for XRechnung & ZUGFeRD – munich enterprise, Zugriff am November 29, 2025, https://www.munich-enterprise.com/en/sap-e-invoice
27. Electronic invoicing in Germany – Business Central | Microsoft Learn, Zugriff am November 29, 2025, https://learn.microsoft.com/en-us/dynamics365/business-central/localfunctionality/germany/germany-einvoicing
28. Receiving Electronic Incoming Purchase Orders Using SAP Document and Reporting Compliance, Cloud Edition, Zugriff am November 29, 2025, https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/465960d40f864a17973671fa0a48967a/f17002883a514181afbd5acd61eedfbd.html?locale=en-US&state=PRODUCTION&version=2025.000
29. Configure Electronic invoicing parameters – Finance | Dynamics 365 – Microsoft Learn, Zugriff am November 29, 2025, https://learn.microsoft.com/en-us/dynamics365/finance/localizations/global/gs-e-invoicing-set-up-parameters
30. Electronic invoicing configuration – Finance | Dynamics 365 – Microsoft Learn, Zugriff am November 29, 2025, https://learn.microsoft.com/en-us/dynamics365/finance/localizations/global/gs-e-invoicing-set-up-overview
31. Get started with electronic invoicing for Saudi Arabia – Phase one – Finance | Dynamics 365, Zugriff am November 29, 2025, https://learn.microsoft.com/en-us/dynamics365/finance/localizations/mea/e-invoicing-sa-get-started-phase-one
32. Electronic invoicing for Belgium – Finance | Dynamics 365 – Microsoft Learn, Zugriff am November 29, 2025, https://learn.microsoft.com/en-us/dynamics365/finance/localizations/belgium/emea-bel-e-invoices
33. Activate and set up integration with Electronic invoicing – Finance | Dynamics 365, Zugriff am November 29, 2025, https://learn.microsoft.com/en-us/dynamics365/finance/localizations/global/e-invoicing-activate-setup-integration
34. Customer electronic invoices – Finance | Dynamics 365 – Microsoft Learn, Zugriff am November 29, 2025, https://learn.microsoft.com/en-us/dynamics365/finance/localizations/italy/emea-ita-e-invoices
35. Get started with Electronic invoicing for Australia and New Zealand – Finance | Dynamics 365 | Microsoft Learn, Zugriff am November 29, 2025, https://learn.microsoft.com/en-us/dynamics365/finance/localizations/apac/gs-apac-aus-nzl-electronic-invoices
36. NetSuite Applications Suite – Electronic Invoicing Overview – Oracle Help Center, Zugriff am November 29, 2025, https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_4536869579.html
37. Link4 for NetSuite – SuiteApp.com, Zugriff am November 29, 2025, https://www.suiteapp.com/Link4-for-NetSuite
38. Cegedim e-business – Netix Flow for NetSuite – SuiteApp.com, Zugriff am November 29, 2025, https://www.suiteapp.com/Cegedim-Netix-Flow
39. Electronic Invoicing – NetSuite Applications Suite – Oracle Help Center, Zugriff am November 29, 2025, https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/chapter_4536869488.html
40. NetSuite Applications Suite – Singapore PEPPOL-Ready e-Invoicing – Oracle Help Center, Zugriff am November 29, 2025, https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_1003105713.html
41. Peppol BIS Message Level Response 3.0, Zugriff am November 29, 2025, https://docs.peppol.eu/poacc/upgrade-3/profiles/36-mlr/
42. PEPPOL e-invoicing: how it works (and why it changes EVERYTHING) – YouTube, Zugriff am November 29, 2025, https://www.youtube.com/watch?v=4vG7IuodS84
43. How to choose a Peppol partner? Here are 10 key aspects – Qvalia, Zugriff am November 29, 2025, https://qvalia.com/how-to-choose-a-peppol-partner-here-are-10-key-aspects/
44. 7 Factors To Consider When Selecting A PEPPOL Access Point Provider – B2BE, Zugriff am November 29, 2025, https://www.b2be.com/blog/7-factors-to-consider-when-selecting-peppol-access-point-provider/
45. The 5 biggest e-invoicing mistakes (and how to avoid them) – Nymus, Zugriff am November 29, 2025, https://nymus.be/en/the-5-biggest-e-invoicing-mistakes-and-how-to-avoid-them/
46. What is Peppol BIS Billing 3.0: Specifications, Format, Example, Benefits – ClearTax, Zugriff am November 29, 2025, https://www.cleartax.com/be/peppol-bis-billing
47. 10 most common e-invoicing errors and mistakes in Peppol – Qvalia, Zugriff am November 29, 2025, https://qvalia.com/10-most-common-e-invoicing-errors-and-mistakes-in-peppol/
48. eInvoicing in Germany – European Commission, Zugriff am November 29, 2025, https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467108886/eInvoicing+in+Germany
49. E-Invoicing in Germany: Peppol Compliance & B2B Mandate – HubBroker ApS, Zugriff am November 29, 2025, https://hubbroker.com/blog/e-invoicing-in-germany/
50. e-Invoicing in Germany | EDICOM Global, Zugriff am November 29, 2025, https://edicomgroup.com/electronic-invoicing/germany/1000
51. E-invoicing for software companies and developers | E-Rechnung in der Bundesverwaltung, Zugriff am November 29, 2025, https://e-rechnung-bund.de/en/e-invoicing-for-software-companies/
52. The transmission method: Peppol – E-Rechnung-Bund.de, Zugriff am November 29, 2025, https://e-rechnung-bund.de/en/transmission-methods/peppol/