Automation MCP Server Features Blog Pricing Contact
BIS Billing 3.0.20 · mandatory since 23 Feb 2026 · PINT 1.1.2

Peppol Invoice API for BIS Billing compliance

Every document entering the Peppol network is checked at the gate: access points run the BIS Billing 3.0 rule set, and one missing electronic address sends an invoice straight back. InvoiceXML runs the same published checks, BIS 3.0.20, before the file ever leaves your stack. Invoices come out network-ready by default, received documents are matched to their rule set automatically, and new releases go live here on their mandatory dates.

POST /v1/create/ubl · BIS 3.0 default
curl -X POST https://api.invoicexml.com/v1/create/ubl \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{ "invoice": { ... } }'
200 OK · network-ready
{
  "valid": true,
  "data": {
    "profile": "peppol-bis-3",
    "customizationId": "urn:cen.eu:en16931:2017#compliant#
      urn:fdc:peppol.eu:2017:poacc:billing:3.0"
  }
}
Architecture

Where this API fits in your Peppol integration

Every Peppol integration has two halves, and conflating them is where projects stall. Documents are one half; delivery is the other. This API is the document half, complete, and it pairs with whichever access point you already use.

The document layer This API

  • Generate BIS Billing 3.0 UBL from invoice JSON, totals and VAT breakdown computed
  • Validate against the exact rule sets access points enforce, national overlays included
  • Read received network invoices into BT-mapped JSON for your ERP
  • Convert CII to UBL, render human-readable previews
  • Rule releases go live server-side on their mandatory dates, nothing to redeploy

The transport layer Your access point

  • Delivery to the recipient's access point over the four-corner network
  • Participant discovery and routing by electronic address
  • Network registration, message-level acknowledgements

Handled by whichever registered access point or service provider you contract. The contract between the halves is simple: what you hand over for transport has already passed the checks the network runs.

Working walkthroughs of the document half, end to end, in your stack: C# / .NET, Node.js, Python, and PHP.

Network rule sets

One network, five rulebooks

BIS Billing 3.0 is the gate, but it is not alone: national siblings and the international PINT family ride the same rails. Create with options.profile, or send nothing and get BIS. On validation, the document's own CustomizationID decides which rulebook runs.

Rule set Slug Where it applies What we run
Peppol BIS Billing 3.0 peppol-bis-3Default The gate every access point enforces, EU-wide BIS 3.0.20, the November 2025 release with the 2025-Q4 hotfix, enforced network-wide since 23 February 2026
EHF Billing 3.0 ehf Norway's national flavor of BIS The BIS artifact including the Norwegian NO-R rules, which trigger on Norwegian suppliers
NLCIUS nlcius Peppol NL and the Dutch public sector SI-UBL 2.0.3.12, the Dutch Peppol Authority's own artifact
Peppol PINT pint The network beyond Europe: Australia, New Zealand, Singapore, Japan, Malaysia PINT Billing 1.1.2, mandatory since 9 March 2026
EN 16931 core en16931 The exit ramp: invoices that never touch the network CEN artifacts 1.3.16 with no network overlay, so the electronic-address rules don't apply
Validation never needs to be told which rulebook applies: BT-24, the CustomizationID, is read straight from the document. Identifiers we hold no dedicated rules for fall back to the EN 16931 core with a PROFILE-DETECTION warning, never a false rejection. The syntax underneath all of this is UBL 2.1, covered in depth on the UBL hub, and what the BIS CustomizationID and ProfileID pair actually declare is unpacked on the identifier reference page.
Release autopilot

OpenPeppol ships twice a year. You ship nothing.

Every spring and fall OpenPeppol publishes a new BIS release, and each one carries the date the network starts enforcing it (tracked in the official release notes). Miss that date and invoices that were compliant yesterday start bouncing. We vendor the artifacts unmodified, regression-test them against OpenPeppol's own examples, and flip the switch server-side on the mandatory day. Your integration stays untouched.

See the update policy and the exact artifacts live right now
Next mandatory switch
17 August 2026

The Peppol May 2026 release becomes mandatory across the network and goes live here the same day, alongside SI-UBL 2.0.3.13 for NLCIUS.

peppol-bis-3 ehf Scheduled
Anatomy of an access-point rejection

Know exactly which rulebook said no

A raw network rejection is a rule ID with no bedside manner. Our findings translate it: a plain-language message, the business terms involved, and the JSON field path to highlight in your UI. The layer field names the rulebook that objected.

layer: ciusThe Peppol overlay objected. Fine by the European core, but the network wants more: classically the BT-34 and BT-49 electronic addresses.
layer: en16931The core itself objected. This invoice has a problem everywhere, not just on Peppol.
layer: xsdThe XML structure is broken; nothing further was evaluated.

Fix what the layer names, or switch to the en16931 profile if the document was never meant for the network.

The finding shown here, PEPPOL-EN16931-R020, has its own reference page, as do the other common network rules.

422 · the access point would bounce this
{
  "valid": false,
  "data": {
    "profile": "peppol-bis-3",
    "customizationId": "urn:cen.eu:en16931:2017#compliant#
      urn:fdc:peppol.eu:2017:poacc:billing:3.0"
  },
  "errors": [
    {
      "rule": "PEPPOL-EN16931-R020",
      "layer": "cius",
      "message": "Peppol BIS requires a seller
        electronic address. Add the seller's
        electronic address (a seller contact
        email is used as a fallback), or use
        the plain en16931 profile if the
        invoice is not meant for Peppol.",
      "btCodes": ["BT-34"],
      "fields": ["seller.electronicAddress"]
    }
  ]
}
Coverage

Where Peppol is the law of the land

Country mandates increasingly name the network itself, and one multi-country e-invoicing API covers every rail below: same endpoint, same default, the national rules ride along automatically.

Belgium
B2B e-invoicing runs over Peppol since January 2026
peppol-bis-3
Denmark · Finland · Sweden
The Nordic default rails for BIS Billing
peppol-bis-3
Norway
EHF Billing 3.0 with the NO-R national rules
ehf
Netherlands
Peppol NL, NLCIUS in the public sector
nlcius
Australia & New Zealand
PINT billing across the Tasman
pint
Singapore
InvoiceNow, built on Peppol
pint
Malaysia
PINT billing on the network
pint
Japan
PINT billing for JP invoicing
pint

Directive 2014/55/EU made EN 16931 the European baseline; the Peppol network is how a growing list of countries delivers on it. The Mandate Map tracks every timeline.

Compliance

Secure by Architecture

Your invoices are processed in memory and returned in the same response. Zero data retention is not a policy we enforce, it is an architecture we built.

Zero data retention

Processed in volatile memory only. Never written to disk, never queued, never backed up.

EU-only processing

Servers in Frankfurt, Germany. No transfers outside the European Economic Area.

No use of your data

Never used for analytics, never to train AI models, never shared with third parties.

Certified infrastructure

SOC 2 Type II, ISO/IEC 27001 and PCI-DSS at the platform layer, held by our infrastructure provider.

Read the full security overview

GDPR compliant by design · nothing stored on our servers

What teams ask before connecting

Is InvoiceXML a Peppol access point?

No, and that is deliberate. Access points move documents; we make sure the documents survive the move. Keep your access point or service provider and put our create and validate calls in front of it, so what you hand over is already BIS-clean.

Which Peppol BIS version do you validate against?

BIS Billing 3.0.20, the November 2025 release including the 2025-Q4 hotfix, enforced network-wide since 23 February 2026. The May 2026 release follows automatically on 17 August 2026, its mandatory date.

Why do access points reject invoices that pass EN 16931?

Because the network adds its own overlay on top of the European core: electronic addresses for both parties (BT-34, BT-49), endpoint identifier schemes, business process metadata, and national rule sets such as Norway's NO-R. Findings carry layer: cius when it is the overlay objecting.

Do you support PINT for Australia, New Zealand, Singapore, Japan, or Malaysia?

Yes. PINT Billing 1.1.2, mandatory on the network since 9 March 2026, is available as profile pint. Jurisdiction variants exist (AU and NZ share one; Singapore, Japan, and Malaysia have their own); the base PINT rules are what we run today.

What about invoices that never travel over Peppol?

Set options.profile to en16931 and the network-only requirements drop away while the European core still applies. The CustomizationID stamped into the document then matches exactly what was validated.

Can I check the Peppol invoices my suppliers send me?

Post the file to the validate endpoint. BT-24 tells us whether it declares BIS, EHF, or something else, and the verdict names the applied rule set in data.profile. Unknown identifiers get the EN 16931 base check plus a PROFILE-DETECTION warning instead of a hard fail.

How does this API fit into a Peppol integration?

As the document layer. A complete Peppol integration has two halves: documents (generating BIS-compliant UBL, validating it, reading what you receive) and transport (delivery through an access point via the network's discovery infrastructure). InvoiceXML covers the document half completely and pairs with any access point, so what you hand over for transport has already passed the checks the network runs.

Start free today

Ready to automate your invoices?

Validate, convert and embed compliant e-invoices through one API. Start your 30-day free trial. No credit card required.

GDPR Compliant No credit card required Setup in minutes
Peppol UBL
Factur-X
EN 16931
142 / 142 passed
Compliant
PDF/A-3 embedded