UBL 2.1 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"
}
}
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 3.0 | peppol-bis-3Default | The Peppol network: Belgium B2B, Nordics, cross-border EU | EN 16931 + Peppol BIS 3.0.20, the same checks your access point runs |
| EN 16931 | en16931 | Plain European core, no network overlay | CEN artifacts 1.3.16 |
| NLCIUS | nlcius | Netherlands, public sector and Peppol NL | SI-UBL 2.0.3.12 from the Dutch Peppol Authority |
| EHF Billing 3.0 | ehf | Norway | Peppol rules incl. the Norwegian NO-R set, as EHF specifies |
| XRechnung 3.0 | xrechnung | German B2G in UBL syntax | EN 16931 + KoSIT Schematron 2.5.0, Leitweg-ID included |
| Peppol PINT | pint | Peppol International: AU/NZ, Singapore, Japan, Malaysia | Official PINT Billing 1.1.2 rules |
PROFILE-DETECTION notice.
Six focused endpoints, each with a free companion tool. Same auth, same validation engine, same profile detection across all of them.
JSON in, validated UBL 2.1 out. Profile-stamped, rule-checked before delivery.
Open toolDrop any UBL file; the profile is detected and the verdict names the rule set it applied.
Open toolSame invoice, other syntax, revalidated on the way out.
Open toolLift a UBL invoice to German B2G requirements.
Open toolA human-readable preview of any UBL file, for approvals and archives.
Open toolTurn received UBL into clean JSON your ERP can import.
Open toolOpenPeppol 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 May 2026 release and SI-UBL 2.0.3.13 both become mandatory on this date, and will be live that day.
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"]
}
]
}
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.
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.
Processed in volatile memory only. Never written to disk, never queued, never backed up.
Servers in Frankfurt, Germany. No transfers outside the European Economic Area.
Never used for analytics, never to train AI models, never shared with third parties.
SOC 2 Type II, ISO/IEC 27001 and PCI-DSS at the platform layer, held by our infrastructure provider.
GDPR compliant by design · nothing stored on our servers
UBL 2.1, the version EN 16931 binds to and every European CIUS builds on, covering both Invoice and CreditNote document types.
UBL is the XML syntax; Peppol is a delivery network with its own rule overlay (BIS Billing 3.0) 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.
No. One create endpoint with options.profile, one validate endpoint with automatic detection. Each profile gets its authority's official rule set.
You get Peppol BIS Billing 3.0, 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.
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.
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.
Validate, convert and embed compliant e-invoices through one API. Start your 30-day free trial. No credit card required.