Validate the German XRechnung CIUS of EN 16931 (CII or UBL, auto-detected) against the EN 16931 Schematron and the KoSIT BR-DE national rules, returned as structured JSON in under two seconds. XRechnung is mandatory for invoices to German federal, state, and municipal public authorities.
The InvoiceXML XRechnung validation API runs the same two-layer checks the German public sector portals ZRE and OZG-RE apply before accepting an invoice. Every rule violation is reported with its rule ID, the validation layer it came from (en16931 or cius), and the XPath location. The KoSIT ruleset is maintained for you and switched on each official effective date.
curl -X POST https://api.invoicexml.com/v1/validate/xrechnung \ -H "Authorization: Bearer YOUR_API_KEY" \ -F "[email protected]"
{ "valid": true, "data": { "profile": "xrechnung", "detectedSyntax": "cii", "customizationId": "urn:cen.eu:en16931:2017#..." }, "errors": [], "warnings": [] }
This runs the same POST /v1/validate/xrechnung endpoint your integration will call. Drop any XRechnung XML, CII or UBL, to see the full two-layer validation response.
Drop your XRechnung XML here
POST /v1/validate/xrechnung · Accepted format: XML (CII or UBL, auto-detected) · Max 20 MB
XRechnung rejection at ZRE or OZG-RE usually means re-reading raw Schematron output to work out which field tripped a German national rule. The InvoiceXML XRechnung API returns a complete report array instead: one row for every Business Term it found, covering both EN 16931 core terms and the German national fields such as the Leitweg-ID (BT-10), each with the extracted value and a pass or fail verdict. It is the ideal input for a pre-flight check before you submit to a German B2G portal or hand the document to a Peppol access point.
xrechnung.xml · XRechnung (CII syntax)
| Status | Business Term | Field | Value |
|---|---|---|---|
| BT-1 Invoice number | invoiceNumber | RE-2026-04417 | |
| BT-5 Invoice currency | currency | EUR | |
| BT-27 Seller name | seller.name | Bauer Infrastruktur GmbH | |
| BT-31 Seller VAT identifier | seller.vatIdentifier | DE811234567 | |
| BT-10 Buyer reference (Leitweg-ID) | buyerReference | Missing. BR-DE-15 requires a Leitweg-ID for German B2G invoices. | |
| BT-112 Invoice total with VAT | totals.grandTotalAmount | 14280.00 | |
| BT-115 Amount due for payment | totals.duePayableAmount | Inconsistent. BR-CO-16 expects this to reconcile with the document totals. |
Rendered from the report array. Each row is one object: code, name, section, path, value, isValid, and error. Example shows supplier Bauer Infrastruktur GmbH (VAT DE811234567) invoicing a German public authority on Leitweg-ID 991-12345-67.
Run the report before every submission to ZRE or OZG-RE and block the upload while any row is red. Your team catches a missing Leitweg-ID (BR-DE-15) or absent seller tax registration (BR-DE-17) on screen, instead of waiting days for a portal rejection notice and re-keying the invoice.
The Leitweg-ID (BT-10) is the routing identifier that tells a German authority which agency the invoice belongs to. The report exposes its value and pass or fail state on the buyerReference path, so you can confirm a Leitweg-ID is present and well-formed before the document is handed to a portal or a Peppol access point for delivery.
The report spans both the European core terms and the German national fields in one array, so a single compliance view shows EN 16931 and the KoSIT BR-DE requirements together. No need to cross-reference the European standard and the XRechnung CIUS by hand, and no surprise when a document passes the core but fails a German-only rule.
Ask for German 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.
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 EN 16931 business rule, the full KoSIT XRechnung rule set and the Peppol BIS 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.
The printable report comes out in German too: verdict, field names, dates and every finding. Hand it to your tax advisor or file it with the invoice for GoBD.
Leitweg-ID, payment details, seller contact: every check of the German XRechnung rules comes back in German and names the field to fill, the way public-sector recipients check them.
Die USt-IdNr. des Rechnungsstellers muss mit dem Code des ausstellenden Landes beginnen, z. B. DE123456789. Griechenland verwendet EL.
{ "rule": "BR-CO-09", "btCodes": ["BT-31"], "fields": ["seller.vatIdentifier"], "message": "Die USt-IdNr. des Rechnungsstellers muss mit dem Code des ausstellenden Landes beginnen, z. B. DE123456789. Griechenland verwendet EL." }
rule, btCodes and fields stay the same in every language
POST /v1/validate/…/report
Every KoSIT check names the field to fill, Leitweg-ID included.
Eine XRechnung braucht die Käuferreferenz, bei öffentlichen Auftraggebern die Leitweg-ID.
Geben Sie die Kontaktdaten des Rechnungsstellers an: Ansprechpartner, Telefonnummer und E-Mail-Adresse (Pflichtangaben in der XRechnung).
KoSIT (Koordinierungsstelle fur IT-Standards) maintains the XRechnung specification and publishes a new Schematron release on a roughly twice-yearly cadence. Each release carries a hard, defined effective date (Gultigkeitstermin) on which the German public sector portals begin enforcing it. There is no grace period for the ruleset: the rules that applied yesterday can reject the same document tomorrow.
InvoiceXML ships the updated XSD schema and Schematron artifacts ahead of time and switches POST /v1/validate/xrechnung to them on the exact KoSIT effective date. Your integration keeps calling the same endpoint and is always validating against the rules currently in force. You do not track KoSIT, monitor Gultigkeitstermin announcements, upgrade a validator library, or schedule a redeploy.
When KoSIT moves from one specification to the next, the endpoint validates against the old ruleset up to the Gultigkeitstermin and the new ruleset from that date forward, automatically.
A self-hosted KoSIT validator or a Mustang deployment stays on whatever ruleset you last installed. The day BR-DE rules change, that integration can fall out of compliance without a single error in your logs. This endpoint cannot.
Tracking KoSIT releases, re-testing artifacts, and coordinating each cutover is a recurring compliance-maintenance burden. Moving it to InvoiceXML removes that ongoing cost from your roadmap.
Validating an XRechnung document programmatically takes a single API call, the CII or UBL syntax is detected automatically:
$ curl -X POST https://api.invoicexml.com/v1/validate/xrechnung \ -H "Authorization: Bearer YOUR_API_KEY" \ -F "[email protected]"
You only send the file. The API detects the syntax automatically, applies the KoSIT XRechnung rules currently in force, and reports the applied rule set and the declared specification identifier back in data.profile and data.customizationId.
Both valid and invalid invoices return HTTP 200. Branch on the valid boolean to determine compliance. The response reports the applied rule set in data.profile, the detected CII or UBL binding in data.detectedSyntax, echoes the declared specification identifier in data.customizationId, and tags every finding with the validation layer it came from: xsd, en16931, or cius for the KoSIT BR-DE rules.
Validation errors come in two formats: raw Schematron codes with their layer identifier for programmatic handling, and a friendly error message array with plain-language descriptions ready to display directly to end users or route into a no-code notification workflow.
Each friendly error also carries btCodes and a fields array, the dotted JSON paths the error maps to. A front-end form can read fields to highlight the exact input that failed, for example buyerReference for a missing Leitweg-ID, and show the message right beside it. Every response, valid or not, also includes a report array: one row per EN 16931 Business Term with its value and a pass or fail flag, ready to render as a compliance table.
// 200 OK { "valid": true, "detail": "Your invoice is XRechnung compliant (EN16931 + CIUS-XR)", "data": { "schemaValid": true, "schematronValid": true, "conformanceLevel": "XRechnung", "detectedSyntax": "cii", "profile": "xrechnung", "customizationId": "urn:cen.eu:en16931:2017#..." }, "errors": [], "warnings": [], "report": [ { "code": "BT-10", "name": "Buyer reference (Leitweg-ID)", "section": "header", "path": "buyerReference", "value": "991-12345-67", "isValid": true, "errors": [], "warnings": [] } // one row per EN 16931 business term, see the compliance report section below ] }
// 200 OK { "valid": false, "detail": "Validation failed with 3 error(s)", "data": { "schemaValid": true, "schematronValid": false, "conformanceLevel": "XRechnung", "detectedSyntax": "cii", "profile": "xrechnung", "customizationId": "urn:cen.eu:en16931:2017#..." }, "errors": [ { "rule": "BR-DE-15", "layer": "cius", "line": null, "message": "The buyer reference (Leitweg-ID) is required. German public authorities use it to route the invoice; without it ZRE and OZG-RE will reject the document.", "btCodes": ["BT-10"], "fields": ["buyerReference"], "raw": "[BR-DE-15] CIUS: Das Element \"BT-10 Buyer reference\" muss uebermittelt werden. (at /*:CrossIndustryInvoice/*:SupplyChainTradeTransaction/*:ApplicableHeaderTradeAgreement)" }, { "rule": "BR-DE-17", "layer": "cius", "line": null, "message": "The seller tax registration must include a VAT identifier or tax number (BT-31 or BT-32).", "btCodes": ["BT-31", "BT-32"], "fields": ["seller.vatIdentifier"], "raw": "[BR-DE-17] CIUS: Das Element \"Seller VAT identifier\" (BT-31) oder \"Seller tax registration identifier\" (BT-32) muss uebermittelt werden. (at /*:CrossIndustryInvoice/*:SupplyChainTradeTransaction/*:ApplicableHeaderTradeAgreement/*:SellerTradeParty)" }, { "rule": "BR-CO-14", "layer": "en16931", "line": null, "message": "The invoice total VAT amount does not match the sum of VAT breakdown amounts. Check that all VAT calculations are consistent.", "btCodes": ["BT-110"], "fields": ["totals.taxTotalAmount"], "raw": "[BR-CO-14] Invoice total VAT amount must equal the sum of VAT breakdown amounts (at /*:CrossIndustryInvoice/*:SupplyChainTradeTransaction/*:ApplicableHeaderTradeSettlement)" } ], "warnings": [], "report": [ // full field-by-field report, see the compliance report section below { "code": "BT-10", "name": "Buyer reference (Leitweg-ID)", "section": "header", "path": "buyerReference", "value": null, "isValid": false, "errors": ["The Leitweg-ID is missing. This routing identifier is required (BR-DE-15)."], "warnings": [] } ] }
Validates the XRechnung XML against the correct schema for its detected syntax: UN/CEFACT CII for rsm:CrossIndustryInvoice documents, OASIS UBL for Invoice documents. Catches malformed XML, incorrect data types, missing required elements, and namespace errors before Schematron runs. Both bindings are legally equivalent under XRechnung and accepted by ZRE and OZG-RE.
Validates the EN 16931 business rules (BR-xx codes) that XRechnung builds on. Includes arithmetic rules like BR-CO-14 (invoice total VAT must equal sum of VAT breakdown amounts), reverse charge rules like BR-AE-05, and party rules like BR-01. Errors from this layer mean the invoice fails the European core standard and would be rejected on any compliant platform, not only in Germany.
Validates the German-specific extension rules (BR-DE-xx codes) that KoSIT layers on top of EN 16931 to form the XRechnung CIUS. These include BR-DE-15 (Leitweg-ID required), BR-DE-17 (seller VAT or tax number required), and BR-DE-19 (IBAN required for SEPA credit transfer). Errors from this layer cause rejection at ZRE and OZG-RE even when EN 16931 passes.
Automatically detects whether the document uses CII or UBL syntax from the root element and applies the correct XSD schema and Schematron artifacts. The rules applied are the XRechnung specification in force on the day of the request. When KoSIT publishes a new specification, the endpoint switches to it on its official effective date; documents declaring a retired 2.x identifier are reported as non-compliant with a clear finding on the specification identifier.
Unlike formats that ship a ladder of profiles, XRechnung is a single national CIUS of EN 16931, XML only, with no PDF container. What varies is the syntax binding the document uses and the KoSIT specification version it declares. This endpoint resolves both for you: it detects the syntax, applies the version in force, and reports what it found in data.detectedSyntax and data.customizationId.
UN/CEFACT Cross Industry Invoice, root element rsm:CrossIndustryInvoice, validated against the CII schema. The customizationId carries the xeinkauf.de:kosit:xrechnung_3.0 identifier.
OASIS UBL Invoice, root element Invoice, validated against the UBL schema. Legally equivalent to CII under XRechnung and accepted by the same German B2G portals and Peppol access points.
XRechnung is enforced through the BR-DE rule set. The endpoint applies the version effective on the request date and advances to the next KoSIT release on its Gultigkeitstermin, automatically.
Both valid and invalid invoices return HTTP 200. Use the valid boolean to branch your logic. The layer field on each error tells you whether the violation came from EN 16931 (european standard) or cius (German national rules), critical for diagnosing portal rejections. Create/convert endpoints return HTTP 400 with the same errors structure on validation failure.
| Field | Type | Description |
|---|---|---|
| Always present | ||
| valid | boolean | Primary flag to branch on. true when compliant with both EN 16931 and the KoSIT German CIUS (BR-DE), false when errors found. |
| detail | string | Human-readable summary, e.g. "Your invoice is XRechnung compliant…" or "Validation failed with 2 error(s)". |
| data.conformanceLevel | string | Conformance label of this endpoint, always XRechnung. |
| data.detectedSyntax | string | Detected XML syntax binding, cii or ubl, read from the document root element. |
| data.schemaValid | boolean | XSD schema check passed for the detected syntax (CII or UBL). |
| data.schematronValid | boolean | Both EN 16931 and KoSIT German CIUS (BR-DE) Schematron checks passed. |
| Findings (errors and warnings) | ||
| errors | object[] | Flat array of finding objects, one per failed rule. Empty array when the invoice is valid. |
| warnings | object[] | Flat array of finding objects for non-blocking issues. May contain entries even when the invoice is valid. |
| [].rule | string | Rule identifier, e.g. BR-DE-15, BR-CO-14. |
| [].layer | string | Validation layer that fired: en16931 (European standard) or cius (German national rules). |
| [].line | int? | Invoice line item number, or null for document-level findings. |
| [].message | string | Human-readable, friendly description suitable for end users. |
| [].btCodes | string[] | EN 16931 Business Term codes the rule references, e.g. ["BT-10"]. |
| [].fields | string[] | Dotted JSON paths the finding maps to, e.g. ["buyerReference"]. Use them to highlight the exact form input that failed. |
| [].raw | string | Verbatim technical validator output, e.g. "[BR-DE-15] CIUS: raw schematron text (at /*:CrossIndustryInvoice...)". Useful for logging and programmatic handling. |
| Compliance report (always present) | ||
| report | object[] | One row per EN 16931 Business Term found on the invoice, with its value and a pass/fail flag. null if the report could not be built. |
| report[].code | string | Business Term code, e.g. BT-10. |
| report[].name | string | Human-readable term name, e.g. Buyer reference (Leitweg-ID). |
| report[].section | string | Grouping for display: header, seller, buyer, lines, payment, totals, or tax. |
| report[].path | string | Dotted JSON path to the field, e.g. lines[0].priceDetails.netPrice. |
| report[].value | string? | Current value of the term, or null when absent. |
| report[].isValid | boolean | false when a validation error references this term, otherwise true. |
| report[].errors | string[] | All error messages on this Business Term, empty array when none. |
| report[].warnings | string[] | All warning messages on this Business Term, empty array when none. |
Call POST /v1/validate/xrechnung from any language. CII and UBL syntax detected automatically. Returns structured JSON in under 2 seconds, branch on valid to gate portal submission and on errors[].layer to distinguish EN 16931 violations from German-specific KoSIT BR-DE failures such as a missing Leitweg-ID.
API docsAdd a pre-submission validation step to your no-code B2G invoicing workflow. Route invalid invoices to a Slack notification or email with the friendly errors[].message values before they reach ZRE or OZG-RE, avoiding portal rejection and the multi-day correction loop entirely.
Automation integrationsValidate XRechnung output on every build of your invoice generation pipeline. When KoSIT publishes a new BR-DE ruleset, the endpoint switches to it on the official effective date, so your pipeline starts catching regressions against the new rules the moment they take effect, with no library bump on your side.
View cURL exampleEverything you need to create, convert, validate, and preview XRechnung invoices, via REST API or online.
The API validates against the XRechnung specification legally in force in Germany, in both CII and UBL syntax. The version and syntax are detected automatically from the specification identifier and root element. Documents declaring a retired 2.x identifier are reported as non-compliant with a clear finding on the specification identifier; legacy 2.x rules remain available for archive validation use cases.
No. This is the core reason teams use the endpoint instead of self-hosting a validator. KoSIT publishes a new XRechnung specification and Schematron release on a roughly twice-yearly cadence, each with a hard effective date (Gultigkeitstermin). InvoiceXML ships the updated artifacts and switches POST /v1/validate/xrechnung to them on that exact date. Your code never changes, you never monitor KoSIT, and your integration cannot silently fall out of compliance the day the BR-DE rules change. A self-hosted KoSIT validator or Mustang deployment stays on whatever ruleset you last installed until you update it yourself.
EN 16931 errors (layer: en16931) mean the invoice fails the European core standard and would be rejected on any compliant platform. German CIUS errors (layer: cius) mean the invoice passes EN 16931 but fails a German national extension rule published by KoSIT, for example BR-DE-15 (Leitweg-ID missing) or BR-DE-17 (seller tax registration absent). Both layers are run automatically, and a CIUS failure is exactly what triggers a rejection at ZRE or OZG-RE even when the European core is satisfied.
Yes. XRechnung supports two XML syntax bindings, CII (root element rsm:CrossIndustryInvoice) and UBL (root element Invoice). The API detects the syntax automatically from the document structure and applies the correct XSD schema and Schematron artifacts. Both syntaxes are legally equivalent and accepted by German public sector portals including ZRE and OZG-RE, and for Peppol delivery.
The Leitweg-ID is the buyer reference (BT-10) that routes an invoice to the correct German public authority. BR-DE-15 makes it mandatory for B2G invoices, so a document without it passes EN 16931 but is rejected at ZRE and OZG-RE. The API checks it on the cius layer and exposes its value and pass or fail state on the buyerReference path in the report array, so you can confirm it is present before submission or Peppol handoff.
Two packages per language, one for the German formats and one for Factur-X. Install yours in one line.
.NET 8 and .NET Standard 2.0, including .NET Framework 4.6.2+
German B2B and public-sector invoicing: hybrid ZUGFeRD PDFs and XRechnung XML in UBL or CII.
Package
InvoiceXml.Zugferd.XRechnung
$dotnet add package InvoiceXml.Zugferd.XRechnung
.NET 8 and .NET Standard 2.0, including .NET Framework 4.6.2+
The French e-invoicing mandate: Factur-X PDFs, with the French BR-FR rules on request.
Package
InvoiceXml.FacturX
$dotnet add package InvoiceXml.FacturX
Java 11 or later, with Jackson as the only dependency
German B2B and public-sector invoicing: hybrid ZUGFeRD PDFs and XRechnung XML in UBL or CII.
Package
com.invoicexml:invoicexml-zugferd-xrechnung
$implementation("com.invoicexml:invoicexml-zugferd-xrechnung:latest.release")
Java 11 or later, with Jackson as the only dependency
The French e-invoicing mandate: Factur-X PDFs, with the French BR-FR rules on request.
Package
com.invoicexml:invoicexml-facturx
$implementation("com.invoicexml:invoicexml-facturx:latest.release")
PHP 8.1 or later, Guzzle or any PSR-18 HTTP client
German B2B and public-sector invoicing: hybrid ZUGFeRD PDFs and XRechnung XML in UBL or CII.
Package
invoicexml/zugferd-xrechnung
$composer require invoicexml/zugferd-xrechnung
PHP 8.1 or later, Guzzle or any PSR-18 HTTP client
The French e-invoicing mandate: Factur-X PDFs, with the French BR-FR rules on request.
Package
invoicexml/facturx
$composer require invoicexml/facturx
Node.js 18 or later, ESM and CommonJS, plus Deno, Bun and edge runtimes
German B2B and public-sector invoicing: hybrid ZUGFeRD PDFs and XRechnung XML in UBL or CII.
Package
@invoicexml/zugferd-xrechnung
$npm install @invoicexml/zugferd-xrechnung
Node.js 18 or later, ESM and CommonJS, plus Deno, Bun and edge runtimes
The French e-invoicing mandate: Factur-X PDFs, with the French BR-FR rules on request.
Package
@invoicexml/facturx
$npm install @invoicexml/facturx
Python 3.10 or later, standard library only
German B2B and public-sector invoicing: hybrid ZUGFeRD PDFs and XRechnung XML in UBL or CII.
Package
invoicexml-zugferd-xrechnung
$pip install invoicexml-zugferd-xrechnung
Python 3.10 or later, standard library only
The French e-invoicing mandate: Factur-X PDFs, with the French BR-FR rules on request.
Package
invoicexml-facturx
$pip install invoicexml-facturx
Validate, convert and embed compliant e-invoices through one API. Start your 30-day free trial. No credit card required.