Peppol vs PINT: The Difference in E-Invoicing Explained

Peppol is the network. PINT and BIS Billing 3.0 are two invoice specifications that travel on it. The difference that matters in practice is not the shape of the document — both are UBL — but which rule set checks it when it arrives. A PINT invoice is validated against the PINT rules and deliberately not against the European EN 16931 rules. A BIS Billing 3.0 invoice is validated against EN 16931 with the Peppol rules on top. One string in the file, the CustomizationID, decides which.

If the four-corner model is new, start with how e-invoicing works over Peppol and what a Peppol Access Point is. This article is about the two document specifications, written from the PINT rule packs and profile registry that run in our own production system.

What is the difference between Peppol and PINT?

Peppol is the governance framework and the four-corner delivery network. PINT — the Peppol International model — is a billing specification that travels on it, alongside the older Peppol BIS Billing 3.0. Peppol decides how a document moves and who is allowed to move it. PINT and BIS decide what the document must contain and which rules check it.

The confusion is understandable, because for the first decade of Peppol's life there was effectively one answer to both questions. If you were on the network, you sent BIS Billing 3.0. PINT exists because that stopped being true once jurisdictions outside Europe began adopting Peppol and needed a base that did not assume European VAT.

So "Peppol vs PINT" is not a choice between two networks. It is a question about which document specification a particular receiver expects, on a network that carries both.

What is Peppol BIS Billing 3.0?

BIS Billing 3.0 is Peppol's original billing profile: a UBL 2.1 invoice and credit note aligned to the European standard EN 16931. It declares the CustomizationID urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0, and it is validated against two rule sets — the CEN EN 16931 Schematron, and the Peppol BIS Schematron layered on top of it.

That layering is worth noticing, because PINT copies the idea and changes the layers. BIS Billing 3.0 has never been a single rule set: it is a European semantic standard plus a Peppol restriction of it. Its document ProfileID is urn:fdc:peppol.eu:2017:poacc:billing:01:1.0, and in our own profile registry it is the value returned for every receiver country that is not explicitly mapped to something else.

It remains the default for the EU, and it is not going anywhere. See the Peppol onboarding checklist for finance teams for the rollout view.

What does a PINT specialisation actually add?

A specialisation is a second rule pack layered on a shared PINT base, not a new document format. In our production validator, Oman's profile ships as two Schematron packs for each document type: a PINT base pack carrying 170 assertions, and a jurisdiction pack carrying 154. The base is common; the second pack is the country.

Both packs run against the same UBL document, in that order. The base pack asks whether this is a well-formed PINT invoice at all. The jurisdiction pack asks whether it satisfies the national tax rules — and it is the one that carries the authority's name. Ours is titled PINT Oman E-Invoice Validation Rules (IBR-OM), version 1.0.1, authority "Tax Authority Oman".

The same pair exists for each of the four document types we handle in Oman: invoice, credit note, self-billing invoice and self-billing credit note. Four document types, two packs each, compiled at build time — which is the practical shape of "supporting PINT OM" for a service provider, and it is a good deal more than a template change.

How does the CustomizationID name a specialisation?

The CustomizationID is a structured name, not an opaque string. In urn:peppol:pint:billing-1@om-1, the part before the @ names the PINT model and its version — billing-1 is the PINT billing base, version 1. The part after names the jurisdiction and its version — om-1 is Oman, version 1.

Two consequences follow from that shape, and both catch people out.

The two version numbers move independently. A jurisdiction can issue a new version of its own rules without the PINT base changing, and the base can move without every jurisdiction following on the same day. Build against the version the jurisdiction has actually adopted, not the newest one published — Oman's own progression is traced in PINT OM version updates.

Self-billing is a different specification, not a flag. Where a normal invoice declares urn:peppol:pint:billing-1@om-1, a self-billed one declares urn:peppol:pint:selfbilling-1@om-1. Our validator detects the jurisdiction with a single pattern that allows for both — urn:peppol:pint:(?:self)?billing-\d+@(\w+)-\d+ — and that pattern is what tells the system it is looking at a PINT document at all. Six jurisdiction codes are recognised by it today: eu, jp, sg, aunz, my and om.

Then there is a third form you will meet in the SMP: the document type identifier, which wraps the CustomizationID together with the UBL root element and the UBL version — urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:peppol:pint:billing-1@om-1::2.1. That is the string a receiver's capability is published under, and it is the one that has to match for a send to start at all.

Is the ProfileID the same as the CustomizationID?

No, and mixing them up is a genuine integration failure rather than a pedantic distinction. A Peppol document carries two identifiers of its own — CustomizationID and ProfileID — and the transport layer uses a third, the process identifier in the SMP. In PINT OM those last two are not the same value.

Set out plainly, from our own profile registry:

Read the PINT OM column again: the value rendered into the document is urn:peppol:pint:billing, and the value used for SMP and AS4 routing is urn:peppol:bis:billing. They differ by one word. An implementation that assumes a single "profile" value will render one of them into the wrong place, and the failure appears either as a validation error on a document that looks correct or as a routing failure on a document that never validates at all.

Note also that PINT A-NZ and PINT OM disagree with each other here. Both are PINT; their document ProfileIDs are different values. "It works for Australia" is not evidence about Oman.

What changes in the SMP entry?

The SMP is where a receiver advertises what it can accept, and the profile changes both what is published and under which scheme. BIS Billing 3.0 document types are published under the busdox-docid-qns scheme. PINT A-NZ is published under peppol-doctype-wildcard only — the PINT A-NZ Billing BIS forbids busdox-docid-qns for that profile.

There is a second detail we learned through accreditation testing rather than from reading: for PINT A-NZ we register both the exact document type identifier (ending @aunz-1::2.1) and the wildcard form (ending @aunz-1*::2.1). The ATO TestBed's test 2 fails without the exact entry and test 1 fails without the wildcard one, so publishing only one of them passes half an accreditation.

This is the part of "supporting a profile" that has nothing to do with the invoice. If the SMP entry is wrong, a technically perfect PINT document is never sent, because the sending access point cannot find a capability that matches.

What changes at validation when a document is PINT?

Everything about which rules run. Our validator reads the CustomizationID, and where it names a PINT jurisdiction it runs only the PINT rule packs for that jurisdiction. The reason sits in the code as a comment: "CEN EN16931 assumes EU VAT context and must NOT be run on PINT invoices." A non-PINT document takes the other branch entirely.

This is the single most consequential difference between the two specifications, and it is invisible in any comparison table that only lists "UBL, AS4, Peppol" on both sides. The European rules encode European VAT assumptions — category codes, exemption reasons, the arithmetic of a VAT breakdown. Running them over an Omani or Malaysian invoice produces failures that are not defects in the invoice.

On the receiving side the layers run in a fixed order, and the order exists so that one broken document produces one class of error rather than a pile of them:

1. Is the XML well-formed? If not, that is a syntax failure and nothing further runs.
2. Does it satisfy the UBL 2.1 XSD for its root element — UBL-Invoice-2.1.xsd or UBL-CreditNote-2.1.xsd? A structural failure here is reported as syntax, and Schematron is deliberately skipped so the same broken document is not also counted as a business-rule failure.
3. The PINT base pack, then the jurisdiction pack, in that sequence.

Two behaviours around that sequence are worth stating because they are policy decisions rather than mechanics. Our receiving pipeline fails open on an infrastructure fault — if the validator itself cannot run, a good invoice is not rejected because our machinery broke. And a document that genuinely fails Schematron is answered with a message-level status carrying response code RE, which is the receiving corner telling the sender, in the network's own vocabulary, that the document was rejected rather than lost.

Which rules does the PINT base actually enforce?

The base pack is 170 assertions, every one flagged fatal, in four families. There are 109 ibr-* rules covering structure and content, 33 ibr-sr-* syntax-binding rules, 18 ibr-cl-* code-list rules and 10 ibr-co-* calculation rules. Nothing in the base is advisory: if a base rule fails, the document fails.

The code-list family is the most immediately useful to anyone mapping an ERP, because it is a list of external standards the document has to obey:

• ibr-cl-01 — the document type code must come from the invoice and credit note code lists of UNTDID 1001.
• ibr-cl-03 and ibr-cl-04 — currency identifiers must use ISO 4217 alpha-3.
• ibr-cl-10 and ibr-cl-11 — party and registration identifier schemes must come from the ISO 6523 ICD list.
• ibr-cl-14 — country codes must use ISO 3166-1.
• ibr-cl-23 — unit codes must follow UN/ECE Recommendation 20 with the Rec 21 extension.

The calculation family is short and is the one most likely to fail on a real ERP export, because it is where rounding lives. ibr-co-15 requires that the invoice total with tax equals the total without tax plus the total tax amount. ibr-co-16 requires that the amount due for payment equals the total with tax, minus the paid amount, plus the rounding amount. These are not new ideas — they are the ordinary invoice arithmetic — but they are checked to the decimal by a machine that does not accept "near enough".

How do PINT rule numbers map to the EN 16931 rules you already know?

They are deliberately parallel. Where EN 16931 has BR-CO-15, the PINT base has ibr-co-15 expressing the same total; where EN 16931 has BR-CL-01, PINT has ibr-cl-01 on the same code list. The semantic terms follow the same pattern: EN 16931's BT-112 appears as ibt-112, and BG-14 as ibg-14.

The wording changes in one systematic way, and it is the whole point of PINT existing. EN 16931 says VAT; the PINT rules say Tax. ibr-co-15 reads "Invoice total amount with Tax (ibt-112) = Invoice total amount without Tax (ibt-109) + Invoice total Tax amount (ibt-110)". A jurisdiction with a sales tax, a goods and services tax or a consumption tax fits that sentence; it does not fit a rule that says VAT.

One honest limit on that mapping. The parallel holds rule for rule in the families we run in production, and I have read them. It is not a promise that every EN 16931 rule has a PINT twin with the same number, and it is not a substitute for checking. If you are porting a validation suite from BIS to PINT, treat the numbering as a strong hint and the pack as the authority.

What does the jurisdiction pack add that the base cannot?

National tax facts. Oman's pack carries 106 IBR-nnn-OM rules of its own, 30 ALIGNED-IBRP-* rules that restate the PINT tax-category logic in Omani terms, and 10 CL-nn-OM national code lists. Of its 154 assertions, 152 are fatal and 2 are warnings — so it is almost entirely made of rules that stop a document.

These rules are where a country expresses things the base could never know: which transaction types exist, which combinations of them are contradictory, which national identifiers are mandatory on which party, and which of its own code lists a field must be drawn from. The pack is also written to be read by whoever has to fix the invoice — each rule emits a stable rule identifier and a structured diagnostic in four parts: Why, Found, Expected, Action.

The Oman-specific answers — what the transaction-type flags mean, which combinations are refused, what the identifiers are made of — belong on their own page rather than this one. They are in the PINT OM CustomizationID reference, and the Oman Fawtara 5-corner model covers the clearance step that sits alongside them.

Which countries run PINT, and which run BIS Billing 3.0?

In our production profile registry the mapping is done by receiver country at send time. Australia and New Zealand resolve to PINT A-NZ. Oman resolves to PINT OM, with a separate self-billing variant. Every other receiver country resolves to BIS Billing 3.0, which is the default rather than a fallback.

Separately, the validator recognises six jurisdiction codes inside a PINT CustomizationID — eu, jp, sg, aunz, my, om — because recognising a document is a different problem from deciding what to send. If a PINT document arrives for a jurisdiction whose rule pack we do not hold, the system says so explicitly with a PINT-SCHEMATRON-UNAVAILABLE warning and falls back to CEN plus BIS validation, rather than silently passing the document.

What this table is not. It is what our system does, which is a matter of record. It is not a claim about what every jurisdiction requires today: profile adoption is the jurisdiction's own decision, published by its tax authority or Peppol Authority, and it moves. Before building for a country, read the authority's current specification — and if you want the country-by-country mandate picture rather than the profile picture, our 2026 e-invoicing mandates tracker keeps that separately.

Does the choice of profile change how the invoice is transmitted?

No. Transmission is identical: AS4 over the Peppol four-corner network, with SMP and SML discovery finding the receiver, and the same certificates securing the hop. A PINT document and a BIS Billing 3.0 document travel the same way, through the same access points, with the same delivery guarantees. Nothing in the profile touches the transport layer.

What changes is on either end of that journey. The document changes, the rules that validate it change, and the SMP entry that advertises the receiver's capability changes. The pipe does not. This is why "we support Peppol" is a weaker statement than it sounds — transport support is the easy half, and the profiles are where the work is.

What actually goes wrong when the profile is wrong?

Four distinct failures, and the reason they are hard to diagnose is that they surface at different moments in the journey. One stops the send before it starts, one produces validation errors that look like invoice defects, one comes back as a formal rejection from the receiver, and one produces no error at all:

• The send never starts. The receiver's SMP advertises a document type identifier the sender cannot match, so there is nothing to send to. This looks like a discovery problem, not a format problem.
• The document is validated against the wrong rules. A document declaring BIS Billing 3.0 while carrying national fields gets the European Schematron, and fails on rules that do not apply to it.
• The receiver rejects it. Where a PINT document fails the jurisdiction pack, the receiving corner returns a message-level status with response code RE. That is a proper rejection with rule identifiers in it, which is the best of these outcomes because it tells you exactly what to fix.
• A silent downgrade. Where the profile is recognised but its rule pack is not held, a well-built system warns and falls back. A less careful one simply validates less and passes the document on.

How should a multi-country integration handle this?

With one integration and no hard-coded profile. The profile is resolved from the receiver's country and the document type at the moment of sending, the matching validation runs before transmission, and any clearance step the jurisdiction requires is added on top. The sending business supplies an invoice; the access point decides what it must become.

The temptation with several countries is to standardise on one format and add exceptions. It does not survive contact with the rules: a German buyer and an Omani buyer need different specifications, with different validation and different SMP entries, as a matter of law rather than convenience. The architecture that works is described in the multi-country e-invoicing API.

What should you check before your first PINT invoice?

Six things, in the order they tend to bite. The first three concern the document, and reading the jurisdiction's specification settles them. The last three concern your own plumbing — the SMP registration, the rule packs your validator holds, and the external code lists your ERP maps onto — and each of those has failed a real integration:

1. The exact CustomizationID the jurisdiction has adopted, including both version numbers — the PINT base version and the jurisdiction version.
2. Whether self-billing is in scope, because it is a separate specification with its own identifier and its own rule pack.
3. The document ProfileID and the transport process identifier separately, since in PINT OM they are different values.
4. The SMP registration: the right scheme, and every document type identifier the receiver must accept — including wildcard forms where the profile requires them.
5. Which rule packs your validator actually holds, and what it does when it does not hold one.
6. The code lists — UNTDID 1001, ISO 4217, ISO 6523, ISO 3166-1, UN/ECE Rec 20 — because a mapping that is right in every other respect fails on a unit code.

If your validation errors read like ibr-co-15 or IBR-043-OM, you are being told which rule and which pack. Those identifiers are stable, and they are the fastest route to the fix. The common ones are collected in invoice validation errors you can prevent.

How does GoRoute handle both?

GoRoute (POP000991) is an accredited Peppol Access Point and SMP running BIS Billing 3.0 and PINT side by side. The profile is resolved from the receiver, the matching rule packs are compiled into the service, and SMP entries are published in the scheme each profile requires. The Oman packs described here are in production, not on a roadmap.

Book a demo, or read how to choose a Peppol Access Point if you are still comparing providers.

---

Sources: Peppol BIS Billing 3.0; OpenPeppol PINT; EN 16931. Rule counts, identifiers and validation behaviour are read from the PINT Oman E-Invoice Validation Rules (IBR-OM) v1.0.1 packs and the profile registry running in GoRoute production, August 2026.

Primary source: OpenPeppol — the authority that publishes the rules referenced here.