XRechnung Validation API
The InvoiceXML XRechnung validation API validates any XRechnung XML against the official EN 16931 Schematron and CIUS-REC-DE national extension rules — the same two-layer checks run by German public sector portals ZRE and OZG-RE before accepting invoices.
Drop your XRechnung XML here
or browse files to upload
POST /v1/validate/xrechnung · Accepted format: XML (CII or UBL) · Max 20 MB
Validate XRechnung REST API Request
Validating an XRechnung document programmatically takes a single API call — syntax and version are detected automatically:
$ curl -X POST https://api.invoicexml.com/v1/validate/xrechnung \ -H "Authorization: Bearer YOUR_API_KEY" \ -F "[email protected]"
Validate XRechnung API Response
Both valid and invalid invoices return HTTP 200. Branch on the valid boolean to determine compliance. The response includes the detected syntax (CII or UBL), the XRechnung version, and which validation layer each error came from — EN 16931 or CIUS-REC-DE.
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.
Valid XRechnung Response
// 200 OK { "valid": true, "detail": "Your invoice is XRechnung compliant and meets the EN 16931 and CIUS-REC-DE specifications.", "data": { "schemaValid": true, "schematronValid": true, "conformanceLevel": "XRechnung 3.0.2", "detectedSyntax": "cii" } }
Invalid XRechnung Response
// 200 OK { "valid": false, "detail": "Validation failed with 3 error(s)", "data": { "conformanceLevel": "XRechnung 3.0.2", "detectedSyntax": "cii" }, "errors": { "xml": [ "[BR-DEX-05] XRechnung invoices must contain a BuyerReference (Leitweg-ID).", "[BR-DEX-04] The seller must provide a VAT ID or tax registration number.", "[BR-CO-14] Invoice total VAT amount must equal the sum of VAT breakdown amounts." ], "friendly": [ { "rule": "BR-DEX-05", "layer": "cius-rec-de", "message": "The Leitweg-ID is missing. This routing identifier is required." }, { "rule": "BR-DEX-04", "layer": "cius-rec-de", "message": "The seller must include a VAT identification number." }, { "rule": "BR-CO-14", "layer": "en16931", "message": "The invoice total VAT amount does not match the sum of VAT breakdown." } ] } }
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.
EN 16931 Schematron
Validates all 200+ EN 16931 business rules (BR-xx codes). 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.
CIUS-REC-DE National Rules
Validates the 20+ German-specific extension rules (BR-DEX-xx codes) published by KoSIT on top of EN 16931. These include BR-DEX-05 (Leitweg-ID required), BR-DEX-04 (seller VAT or tax number required), and BR-DEX-09 (IBAN required for SEPA payment). Errors from this layer will cause rejection at ZRE and OZG-RE portals even if EN 16931 passes.
Syntax and Version Detection
Automatically detects whether the document uses CII or UBL syntax from the root element, and reads the specification identifier to determine the XRechnung version. The correct XSD schema and Schematron artefacts are applied for each combination. Supports XRechnung 2.x through 3.0.2, in both syntax bindings.
REST API 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-rec-de (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 CIUS-REC-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 | Detected XRechnung version, e.g. XRechnung 3.0.2. |
| data.detectedSyntax | string | Detected XML syntax binding — cii or ubl — read from the document root element. |
| Valid only | ||
| data.schemaValid | boolean | XSD schema check passed for the detected syntax (CII D16B or UBL 2.1). |
| data.schematronValid | boolean | Both EN 16931 and CIUS-REC-DE Schematron checks passed. |
| Invalid only | ||
| errors.xml | string[] | Raw Schematron messages with rule codes, e.g. "[BR-DEX-05] XRechnung invoices must contain a BuyerReference (Leitweg-ID)." |
| errors.friendly | object[] | Plain-language error objects for UI display. |
| friendly[].rule | string | Rule identifier, e.g. BR-DEX-05, BR-CO-14. |
| friendly[].layer | string | Validation layer that fired: en16931 (European standard) or cius-rec-de (German national rules). |
| friendly[].line | int? | Invoice line item number, or null for document-level errors. |
| friendly[].message | string | Human-readable error description suitable for end users. |
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 CIUS-REC-DE failures.
API docsZapier / 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 entirely.
Automation integrationsCI/CD Pipeline
Validate XRechnung output on every build of your invoice generation pipeline. When KoSIT publishes a new CIUS version, the API validation rules update automatically — your pipeline catches regressions before they reach production and cause portal rejections.
View cURL exampleComplete XRechnung Toolkit
Everything you need to create, convert, validate, and preview XRechnung invoices — via REST API or online.
Build a validated XRechnung 3.0 CII XML from structured data — ready for ZRE, OZG-RE, or Peppol.
Validate XRechnung XML against EN 16931 and KoSIT CIUS Schematron rules.
Convert any PDF invoice into a validated XRechnung XML using AI extraction.
Render an XRechnung XML as a human-readable PDF for review and approval.
Frequently Asked Questions
Which XRechnung versions does the API validate?
The API validates all current XRechnung versions: 3.0, 3.0.1, and 3.0.2 in both CII and UBL syntax. The version and syntax are detected automatically from the specification identifier and root element. Legacy versions 2.x are also accepted for archive validation use cases.
What is the difference between EN 16931 errors and CIUS-REC-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. CIUS-REC-DE errors (layer: cius-rec-de) mean the invoice passes EN 16931 but fails a German-specific national extension rule — for example BR-DEX-05 (Leitweg-ID missing) or BR-DEX-04 (seller tax number absent). Both layers are run automatically.
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 artefacts. Both syntaxes are legally equivalent and accepted by German public sector portals including ZRE and OZG-RE.