UBL Invoice API:
six CIUS profiles,
one endpoint
UBL is one syntax wearing many uniforms: Peppol BIS in Belgium and the Nordics, NLCIUS in the Netherlands, EHF in Norway, XRechnung in German procurement, PINT beyond Europe. InvoiceXML speaks all of them through one endpoint: you pick the profile when creating, we detect it when validating, and the rules applied are always the ones legally in force.
curl -X POST https://api.invoicexml.com/v1/create/ubl \ -H "Authorization: Bearer YOUR_API_KEY" \ -d '{ "invoice": { ... }, "options": { "profile": "nlcius" } }'
{
"valid": true,
"data": {
"profile": "nlcius",
"customizationId": "urn:cen.eu:en16931:2017#compliant#
urn:fdc:nen.nl:nlcius:v1.0"
}
}
Six profiles. One endpoint. Zero guesswork.
Set options.profile when creating; validation reads the CustomizationID and picks the rule set itself. The identifier stamped into the XML is always exactly the rule set the document survived.
| Profile | Slug | Where it rules | What we run |
|---|---|---|---|
| Peppol BIS Billing | peppol-bis-3Default | The Peppol network: Belgium B2B, Nordics, cross-border EU | EN 16931 + Peppol BIS Billing, the same checks your access point runs |
| EN 16931 | en16931 | Plain European core, no network overlay | CEN artifacts |
| NLCIUS | nlcius | Netherlands, public sector and Peppol NL | SI-UBL from the Dutch Peppol Authority |
| EHF Billing | ehf | Norway | Peppol rules incl. the Norwegian NO-R set, as EHF specifies |
| XRechnung | xrechnung | German B2G in UBL syntax | EN 16931 + KoSIT Schematron, Leitweg-ID included |
| Peppol PINT | pint | Peppol International: AU/NZ, Singapore, Japan, Malaysia | Official PINT Billing rules |
PROFILE-DETECTION notice.
Everything UBL, one API
Six focused endpoints, each with a free companion tool. Same auth, same validation engine, same profile detection across all of them.
Create UBL
JSON in, validated UBL out. Profile-stamped, rule-checked before delivery.
Open toolValidate UBL
Drop any UBL file; the profile is detected and the verdict names the rule set it applied.
Open toolConvert UBL ↔ CII
Same invoice, other syntax, revalidated on the way out.
Open toolUBL → XRechnung
Lift a UBL invoice to German B2G requirements.
Open toolRender UBL → PDF
A human-readable preview of any UBL file, for approvals and archives.
Open toolExtract JSON
Turn received UBL into clean JSON your ERP can import.
Open toolThe rules change twice a year. Your integration doesn't.
OpenPeppol ships rule releases every spring and autumn, each with a mandatory date (see the official Peppol BIS release notes). The Dutch Peppol Authority refreshes SI-UBL on the same calendar, CEN patches the EN 16931 artifacts, and KoSIT revs XRechnung annually. Every one of those updates lands here on its legal effective date, server-side.
Read the update policy and the exact artifact versions running nowThe Peppol November 2026 release and the matching SI-UBL refresh become mandatory on the day OpenPeppol publishes with the release, and will be live here that day.
Findings that say which rulebook
Every finding carries a layer field, plus the EN 16931 BT codes, the JSON field path to highlight in your form, and the raw Schematron rule for your logs.
"Passes EN 16931 but dies at the access point" is a debugging genre we retired.
{
"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-R010",
"layer": "cius",
"message": "Peppol BIS requires a buyer
electronic address. Add the buyer's
electronic address (a buyer VAT
identifier is used as a fallback), or
use the plain en16931 profile if the
invoice is not meant for Peppol.",
"btCodes": ["BT-49"],
"fields": ["buyer.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 UBL is mandatory
The same EN 16931 core, enforced country by country. Pick the profile; the local rule set comes with it.
European public-sector e-invoicing runs on Directive 2014/55/EU; the B2B mandates now arriving country by country build on the same EN 16931 core. See the Mandate Map for the full timeline, and the European coverage page for what this API supports in each country.
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
Questions teams ask before they build
Which UBL version does the API use?
The UBL schema release EN 16931 binds to and every European CIUS builds on, covering both Invoice and CreditNote document types. The exact release is listed in the reference.
What's the difference between UBL and Peppol?
UBL is the XML syntax; Peppol is a delivery network with its own rule overlay (BIS Billing) on top of EN 16931 and UBL. We create network-ready BIS documents by default, and the dedicated Peppol page covers the network side in depth.
Do I need different endpoints for NLCIUS or EHF?
No. One create endpoint with options.profile, one validate endpoint with automatic detection. Each profile gets its authority's official rule set.
What happens if I omit the profile?
You get Peppol BIS Billing, the broadest interoperable choice: stamped and validated. If your invoice never touches Peppol, set profile en16931 and the network-only requirements (like electronic addresses) don't apply.
Can you validate UBL files we receive from suppliers?
Yes, that's what detection is for: whatever profile the sender declared, the matching rules run and the response names them in data.profile. Unknown profiles fall back to the EN 16931 core with an explicit notice instead of a false rejection.
How current are the validation rules?
Current as of their legal effective dates: Peppol BIS, EN 16931 artifacts, SI-UBL, PINT, and the KoSIT XRechnung Schematron. The versioning page lists the exact versions publicly.