Peppol PINT Migration 2026: ERP API Prep for ViDa 2030

• Peppol PINT Migration is the mandatory transition from national CIUS extensions of Peppol BIS 3.0 to the internationally harmonised PINT (Peppol International) standard, with 2026 marking the critical preparation window.
• PINT serves as the technical backbone for ViDa 2030 Digital Reporting Requirements (DRR), meaning any ERP API not updated for PINT-compliant UBL will fail cross-border validation by the time the EU mandate is fully in force.
• Tax scheme and VAT category mapping differences between BIS 3.0 and PINT are the single most common source of API-level rejections in cross-border e-invoicing today.
• Kleinkode’s Peppol API abstracts this semantic complexity so European SMBs and software vendors do not need to rebuild their document pipelines from scratch for every new jurisdiction.

The e-invoicing landscape is splitting in two directions at once. On one side, national governments are accelerating their own mandates — Germany, France, and the Nordic countries all tightening deadlines. On the other side, the EU is demanding a single, interoperable standard that works across every member state. Peppol PINT Migration is where those two pressures collide, and 2026 is the year your ERP API either adapts or starts generating rejected invoices at the border. This article explains exactly what is changing, why the timeline matters, and what your integration layer must do to stay compliant.

What Is Peppol PINT? The International Model Replacing Regional BIS 3.0

Peppol BIS 3.0 — the current dominant e-invoicing specification used across Belgium, the Netherlands, Germany, and Scandinavia — was never designed to be a single global standard. It was built on top of the EN 16931 European semantic data model, but every country was allowed to layer its own CIUS (Core Invoice Usage Specification) on top. The result: a patchwork of technically compatible but practically divergent document structures.

PINT (Peppol INTernational) is OpenPeppol’s answer to that fragmentation. Rather than treating each country’s CIUS as the starting point, PINT defines a globally consistent semantic core. National extensions still exist, but they are now subordinate to the international model — not the other way around. APAC countries (Japan, Singapore, Malaysia, Australia) are already live on PINT. Europe is next.

For a deeper look at how national CIUS extensions have been complicating cross-border flows in the run-up to this transition, see our earlier piece on navigating local CIUS extensions in a pre-ViDa Europe.

The ViDa 2030 Connection: PINT as the Technical Foundation for DRR

ViDa 2030 — VAT in the Digital Age — is the EU regulation that will make structured, machine-readable e-invoicing mandatory for all intra-EU B2B transactions by 2030. At its core, ViDa introduces Digital Reporting Requirements (DRR): real-time or near-real-time VAT data transmission to national tax authorities, triggered at the moment of invoice issuance.

For DRR to work across 27 member states, the underlying invoice format must be semantically unambiguous. A VAT category code in Germany must mean exactly the same thing when it arrives at a French tax portal. PINT provides that guarantee. Its standardised code lists, mandatory fields, and validation rules eliminate the interpretive gaps that currently exist between national CIUS implementations.

This is not a theoretical alignment. OpenPeppol has explicitly positioned PINT as the specification that will underpin intra-EU DRR data flows once ViDa is fully operational. If your API still speaks BIS 3.0 dialects in 2028 or 2029, you will be generating invoices that cannot be automatically validated by cross-border DRR infrastructure. We cover the broader DRR architecture in detail in our post on why your ERP needs a real-time Peppol API for ViDa 2030.

Why 2026 Is the Critical Preparation Year

Three major markets are converging on timelines that make 2026 the last realistic moment for calm, deliberate API migration:

• Germany: The B2B e-invoicing mandate comes into force for all companies in 2027–2028, with large enterprises already required to receive structured invoices from January 2025. The German CIUS (XRechnung) will need to align with PINT semantics for cross-border flows. See our analysis of Germany’s 2028 B2B deadline as a rehearsal for EU-wide ViDa compliance.
• France: The Chorus Pro / PPF migration is underway, with mandatory B2B e-invoicing phased in from 2026 onward. French invoices flowing through Peppol must comply with the French CIUS — but outbound invoices to non-French EU buyers increasingly require PINT-compatible formatting.
• Nordic countries: Denmark, Sweden, and Finland have operated on Peppol BIS 3.0 since the NESUBL era. OpenPeppol’s migration roadmap anticipates Nordic CIUS retirement in favour of PINT extensions within the 2026–2027 window.

Waiting until a mandate deadline is announced is the wrong strategy. API migrations that touch VAT logic, document schema, and access point routing typically take three to six months to test properly. Starting in late 2026 leaves no buffer.

Technical Deep Dive: VAT Category and Tax Scheme Mapping from BIS 3.0 to PINT

The hardest part of the Peppol PINT Migration is not switching XML namespaces. It is the semantic layer: ensuring that every structured value your ERP writes into a UBL document maps correctly to PINT’s code lists and business rules.

VAT Category Codes

BIS 3.0 uses UNCL5305 VAT category codes (S, Z, E, AE, K, G, O, L, M). PINT retains these but applies stricter validation rules around their combination with TaxScheme/ID and TaxExemptionReasonCode. An invoice with category code AE (reverse charge) that omits a valid TaxExemptionReason will pass BIS 3.0 validation in several national contexts but will fail PINT schematron rules. If your API auto-generates these fields from ERP tax settings without a PINT-aware mapping layer, you will see validation rejections the moment you send cross-border.

Tax Scheme Identifiers

PINT enforces a controlled vocabulary for TaxScheme/ID. The value must be VAT for standard transactions. Several BIS 3.0 national implementations have tolerated custom values here — a practice PINT explicitly prohibits. Your ERP’s tax configuration table may be writing non-compliant scheme identifiers without anyone realising it. We explored practical ERP field mapping issues in our post on aligning ERP fields with EN 16931 for ViDa 2030.

Allowance and Charge Sequences

PINT tightens the sequencing and calculation consistency rules for document-level and line-level allowances. The BaseAmount field, optional in some BIS 3.0 profiles, becomes effectively mandatory when MultiplierFactorNumeric is present. APIs that calculate discounts inline and omit the base amount will trigger BR-CO-21 rule violations.

The practical solution is a dedicated semantic transformation layer between your ERP’s internal data model and the UBL output. This layer must be version-aware — capable of generating BIS 3.0 for domestic flows where still required, and PINT for cross-border flows, from the same source record. For teams already working with Factur-X alongside Peppol, see how we approach this in solving cross-border e-invoicing with Factur-X and Peppol.

Risk Assessment: What Happens If Your ERP Fails PINT Validation?

The consequences of PINT non-compliance are not abstract. They hit cash flow directly. A PINT-invalid invoice rejected by a cross-border access point does not generate a payment cycle — it generates a support ticket, a manual correction process, and a delayed payment. In high-volume environments, even a 2% rejection rate translates to significant working capital friction.

Beyond the operational cost, there is the ViDa DRR dimension. An invoice that cannot be validated at the format level also cannot be auto-reported to the relevant tax authority. Under ViDa’s DRR rules, the reporting obligation falls on the issuer. A failed transmission is not a neutral event — it is a reporting gap that tax authorities will eventually reconcile. The risk profile of persistent PINT non-compliance after 2028 is therefore both financial and regulatory.

Our detailed analysis of how Peppol validation errors affect cash flow is available in the Dutch-language post on why rejected invoices hurt your cash flow in 2026. The mechanics apply equally to PINT-era rejections.

How Kleinkode’s Peppol API Handles PINT Complexity

Rebuilding a semantic transformation layer in-house is feasible — but it requires ongoing maintenance as PINT specification updates are released, as national extension profiles are revised, and as access point routing tables change. For most European SMBs and software vendors, that ongoing maintenance cost is the real argument against a self-built approach.

Kleinkode’s Peppol API integration handles the PINT transformation server-side. Your ERP or accounting system sends invoice data in its native format through our API endpoint; our layer generates the correct UBL output — BIS 3.0 or PINT, depending on the recipient’s registered profile — validates against the relevant schematron rules, and routes through the appropriate Peppol access point. When PINT specification updates are published by OpenPeppol, we update the transformation rules without requiring changes on your side.

For teams managing multiple ERP systems, accounting platforms, or webshop integrations, our ERP, accounting, and webshop Peppol connectors provide the same PINT-aware layer across every integration point — ensuring consistent document output regardless of which system originates the invoice.

The bottom line: PINT is not a minor format update. It is a semantic realignment that touches VAT logic, code list governance, and validation rule architecture. The 2026–2027 window is the time to assess your current API’s exposure and build the mapping layer that will carry you through ViDa 2030 compliance.

Frequently Asked Questions

What is the difference between Peppol BIS 3.0 and PINT?

Peppol BIS 3.0 is a European e-invoicing specification built on EN 16931, with country-specific CIUS extensions layered on top. PINT (Peppol International) is a globally harmonised standard where the international core takes precedence over national extensions. PINT applies stricter semantic validation rules, particularly around VAT category codes, tax scheme identifiers, and allowance calculation fields.

Is Peppol PINT Migration mandatory for EU businesses?

While there is no single EU-wide PINT mandate with a specific enforcement date yet, OpenPeppol’s roadmap designates PINT as the successor to national CIUS profiles for cross-border transactions. Combined with ViDa 2030 DRR requirements — which demand semantically unambiguous invoice data for real-time tax reporting — PINT compliance will be effectively mandatory for any business sending or receiving cross-border Peppol invoices in the ViDa era.

What ERP API changes are required for PINT compliance?

At minimum, your API’s UBL generation layer must be updated to enforce PINT code list constraints (VAT category codes, tax scheme IDs), populate previously optional fields that PINT schematron rules now require (such as TaxExemptionReasonCode for reverse-charge transactions), and apply consistent BaseAmount values in allowance/charge structures. A version-aware transformation layer that can output either BIS 3.0 or PINT depending on the recipient’s profile is the recommended architecture.

When will national CIUS profiles like XRechnung be phased out?

OpenPeppol has not published a hard end-of-life date for all national CIUS profiles. However, the published migration guidance indicates that PINT-aligned extensions will replace standalone CIUS profiles for cross-border transactions in the 2026–2028 window. Germany’s XRechnung and Nordic profiles are expected to transition first. Domestic-only transactions may continue using national profiles longer, but any invoice crossing a border should be PINT-compliant.

How does ViDa 2030 DRR depend on PINT?

ViDa’s Digital Reporting Requirements mandate near-real-time VAT data transmission to national tax authorities for all intra-EU B2B transactions. For this infrastructure to function across 27 member states without manual reconciliation, the invoice format must be semantically consistent end-to-end. PINT provides that consistency by enforcing a shared semantic core, making it the de facto technical standard for DRR-compliant cross-border e-invoicing.

Can a Peppol API handle both BIS 3.0 and PINT simultaneously?

Yes — and this is the recommended approach during the transition period. A well-designed Peppol API should detect the recipient’s registered document profile via SMP lookup and generate the appropriate UBL variant (BIS 3.0 for recipients not yet on PINT, PINT for those that are) from the same source invoice data. Kleinkode’s API layer does this automatically, removing the routing and transformation burden from the sending ERP system.

Ready to find out whether your current Peppol setup is prepared for the PINT transition and ViDa 2030? Plan je gratis Peppol risico-scan and get a concrete assessment of your API’s compliance gaps before the migration window closes.