Peppol Invoice API for BIS Billing compliance
Every document entering the Peppol network is checked at the gate: access points run the BIS Billing rule set, and one missing electronic address sends an invoice straight back. InvoiceXML runs the same published checks 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.
curl -X POST https://api.invoicexml.com/v1/create/ubl \ -H "Authorization: Bearer YOUR_API_KEY" \ -d '{ "invoice": { ... } }'
{
"valid": true,
"data": {
"profile": "peppol-bis-3",
"customizationId": "urn:cen.eu:en16931:2017#compliant#
urn:fdc:peppol.eu:2017:poacc:billing:3.0"
}
}
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 UBL from invoice JSON, totals and VAT breakdown computed
- Validate against the exact rule sets access points enforce, national overlays included
- Electronic-address (EAS) pre-checks at create time: retired scheme codes are rejected up front with the current 9930, 0204, or 0088 replacement named
- 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.
One network, five rulebooks
BIS Billing 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 | peppol-bis-3Default | The gate every access point enforces, EU-wide | The current BIS Billing release, enforced network-wide |
| EHF Billing | 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, the Dutch Peppol Authority's own artifact |
| Peppol PINT | pint | The network beyond Europe: Australia, New Zealand, Singapore, Japan, Malaysia | PINT Billing, the current release |
| EN 16931 core | en16931 | The exit ramp: invoices that never touch the network | CEN artifacts with no network overlay, so the electronic-address rules don't apply |
PROFILE-DETECTION warning, never a false rejection. The syntax underneath all of this is UBL, covered in depth on the UBL hub, and what the BIS CustomizationID and ProfileID pair actually declare is unpacked on the identifier reference page.
From JSON to network-ready, and back
Each endpoint has a free in-browser companion. One key, one validation engine, the same BIS rules at every step of the pipeline.
Create BIS
Post your invoice JSON; what comes back is a validated Peppol BIS Billing document.
Open toolValidate Peppol
Run the access-point checks before you send, or audit what suppliers send you.
Open toolConvert CII → UBL
Lift CII documents into the UBL syntax the network speaks.
Open toolRender → PDF
A readable PDF preview of any BIS document, for approvals and archives.
Open toolExtract JSON
BT-mapped JSON out of every received network invoice, ready for your ERP.
Open toolMCP server
Let AI agents draft, validate, and fix Peppol invoices over MCP.
Open toolOpenPeppol 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 nowThe Peppol November 2026 release becomes mandatory across the network on the day OpenPeppol publishes with it, and goes live here the same day.
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.
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.
{
"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"]
}
]
}
Validation errors in German, French and English
Ask for German, French or English and every finding comes back as a plain-language explanation of what is wrong and how to fix it, ready to show in your app as it is. Each finding also carries its rule id, Business Term code and field path, so you can highlight the form field that caused it.
-
One field, three languages
Send validationLanguage with the upload, or options.validationLanguage with a create call: German, French or English. Validate, create, embed, convert and transform all speak it, with no translation layer to build or maintain on your side.
-
Every rule explained, not just translated
Every EN 16931 business rule, the XRechnung and Peppol BIS rules and the French BR-FR rules each have their own reviewed message, written for the people who fix invoices rather than for Schematron authors. No rule codes in the text, just what to change.
-
A PDF report in the same language
The printable report follows the same setting: verdict, field names, dates and every finding, in the language your reader works in.
The seller's VAT identifier must start with the code of the country that issued it, for example DE123456789. Greece uses EL.
{ "rule": "BR-CO-09", "btCodes": ["BT-31"], "fields": ["seller.vatIdentifier"], "message": "The seller's VAT identifier must start with the code of the country that issued it, for example DE123456789. Greece uses EL." }
rule, btCodes and fields stay the same in every language
The PDF report, as your reader gets it
POST /v1/validate/…/report
One finding, three languages
The same finding as each language returns it.
The seller's VAT identifier must start with the code of the country that issued it, for example DE123456789. Greece uses EL.
Die USt-IdNr. des Verkäufers muss mit dem Code des ausstellenden Landes beginnen, z. B. DE123456789. Griechenland verwendet EL.
Le numéro de TVA du vendeur doit commencer par le code du pays qui l'a attribué, par exemple DE123456789. La Grèce utilise EL.
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.
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, and everything this API covers across Europe sits in one table on the European coverage page.
Everything you need to go live
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.
- Encrypted in transit. TLS on the request and on the response stream.
- Our own code, end to end. No subprocessor ever sees an invoice.
- Signed DPA and SLA available. For Enterprise customers, on request.
- Disknever
- Queuenever
- Backupnever
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.
Compliance Overview
Formats, validation and data protection on four pages. Ready to forward to your procurement, legal or IT team.
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?
Always the release currently mandatory on the network. Each new OpenPeppol release is applied on its mandatory date, and the exact release in force is listed in the reference.
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, on the release current on the network, 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.