POST /v1/validate/xrechnung

XRechnung Validation REST API for German B2G

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.

Get API Key Try it live →

Bash

curl -X POST https://api.invoicexml.com/v1/validate/xrechnung \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -F "[email protected]"

200 OK · Application/JSON

{
  "valid": true,
  "data": {
    "profile": "xrechnung",
    "detectedSyntax": "cii",
    "customizationId": "urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0"
  },
  "errors": [],
  "warnings": []
}

Try it live, no API key required

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

or browse files to upload

POST /v1/validate/xrechnung · Accepted format: XML (CII or UBL, auto-detected) · Max 20 MB

Upload any XRechnung XML file, CII or UBL syntax, and receive a structured JSON compliance report. The API auto-detects the syntax from the root element, then runs both the EN 16931 Schematron and the KoSIT BR-DE national rules (the XRechnung CIUS) currently in force. Every rule violation is returned with its rule ID, the validation layer it came from, and the XPath location. The ruleset tracks KoSIT releases automatically, so the live demo always reflects the rules in effect today.

Validation report

Not just pass or fail. A full XRechnung compliance report.

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 Compliance Report

xrechnung.xml · XRechnung 3.0 (CII syntax)

164 terms 162 passed 2 failed

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.

Pre-flight ZRE and OZG-RE checks

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.

Leitweg-ID routing validation

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.

EN 16931 and KoSIT national coverage

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.

KoSIT ruleset, maintained for you

The strongest auto-update story in e-invoicing: KoSIT effective dates, handled for you

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.

Cutover on the effective date

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.

No silent non-compliance

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.

0.3 to 0.5 FTE removed

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.

Validate XRechnung REST API Request

Validating an XRechnung document programmatically takes a single API call, the CII or UBL syntax is detected automatically:

Request

$ 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.

Full API reference: POST /v1/validate/xrechnung

Validate XRechnung API Response

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.

Valid XRechnung Response

Response, valid invoice

// 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#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0"
  },
  "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
  ]
}

Invalid XRechnung Response

Response, invalid invoice

// 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#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0"
  },
  "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": [] }
  ]
}

What the XRechnung validation API checks

CII and UBL XSD Schema

Validates the XRechnung XML against the correct schema for its detected syntax: UN/CEFACT CII D16B for rsm:CrossIndustryInvoice documents, OASIS UBL 2.1 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.

EN 16931 Schematron

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.

KoSIT BR-DE National Rules

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.

Syntax Detection and Effective-Date Versioning

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 (currently 3.0, enforced by the BR-DE rule set since February 2024). 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.

XRechnung is one profile, two syntaxes, and a dated ruleset

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.

CII syntax

UN/CEFACT Cross Industry Invoice, root element rsm:CrossIndustryInvoice, validated against the CII D16B schema. The customizationId carries the xeinkauf.de:kosit:xrechnung_3.0 identifier.

UBL syntax

OASIS UBL 2.1 Invoice, root element Invoice, validated against the UBL 2.1 schema. Legally equivalent to CII under XRechnung and accepted by the same German B2G portals and Peppol access points.

Specification 3.0, dated

XRechnung 3.0 has been in force since February 2024 under 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.

Validation Response schema

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 D16B or UBL 2.1).
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.

Integrate XRechnung validation into your workflow

REST API

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 docs

Zapier / Make / n8n

Add 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 integrations

CI/CD Pipeline

Validate 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 example

Complete XRechnung Toolkit

Everything you need to create, convert, validate, and preview XRechnung invoices, via REST API or online.

Create XRechnung API Build validated XRechnung 3.0 Validate XRechnung API EN 16931 + KoSIT CIUS rules PDF to XRechnung API AI extraction to XRechnung Preview XRechnung as PDF Human-readable rendering

Frequently Asked Questions

Which XRechnung version does the API validate against?

The API validates against XRechnung 3.0, the specification legally in force in Germany since February 2024, 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.

Do I have to track KoSIT releases and update my integration when the rules change?

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.

What is the difference between EN 16931 errors and German CIUS (BR-DE) errors in the response?

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.

Does the API validate both CII and UBL XRechnung syntax?

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.

What is the Leitweg-ID and does the API check it?

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.

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.

Get Started For Free Get in Touch

GDPR Compliant No credit card required Setup in minutes

Peppol UBL

Factur-X

EN 16931

142 / 142 passed

Compliant

PDF/A-3 embedded