What is the difference between XSD validation and Schematron validation for e-invoices?

XSD (XML Schema Definition) validation checks the structural format of an XML file — element names, types, and hierarchy. Schematron validation checks business rules defined by the EN 16931 standard, such as whether the VAT breakdown is mathematically consistent (BR-CO-10), whether mandatory payment terms are present (BR-CO-25), or whether the IBAN is correctly formatted for SEPA transfers (BR-S-08). All modern e-invoicing mandates (Factur-X, XRechnung, ZUGFeRD, Chorus Pro) require both XSD and Schematron compliance.

Can the validator check both PDF and pure XML e-invoices?

Yes. The /v1/validate endpoint accepts both PDF/A-3 files (Factur-X or ZUGFeRD, where the XML is embedded as an attachment) and raw CII XML files (XRechnung). For PDFs, the engine first extracts the embedded factur-x.xml attachment, then runs Schematron validation on it. For raw XML files, validation is applied directly.

Which EN 16931 profiles are supported for validation?

The Factur-X Engine validates all CII (Cross-Industry Invoice) profiles defined by the EN 16931 standard: MINIMUM, BASIC WL, BASIC, EN 16931 (comfort), and EXTENDED. It also validates XRechnung 3.0 XML files using the official KoSIT Schematron rules. Profile detection is automatic — the engine reads the GuidelineSpecifiedDocumentContextParameter from the XML to determine which ruleset to apply.

How do I integrate e-invoice validation into a CI/CD pipeline?

Run the Factur-X Engine as a Docker service in your CI environment (docker run -d -p 8000:8000 facturxengine/facturx-engine), then call POST /v1/validate from your test suite or shell script. The response returns is_valid: true/false and a structured list of Schematron errors with rule codes. Exit the pipeline with a non-zero code if is_valid is false.

Tools

Factur-X XML Validator

Ensure your e-invoices are strictly compliant with the European EN16931 standard. Validate Factur-X, ZUGFeRD, XRechnung and Chorus Pro XML files seamlessly using the Factur-X Engine API.

Why XML Validation is Painful

Generating an XML file named factur-x.xml is only 10% of the work. The real challenge for developers is ensuring that this XML passes Schematron validation.

A simple XSD check is not enough for modern E-Rechnung mandates. You must validate hundreds of business rules (like `BR-CO-10` or `BR-S-08`) which natively requires fragile Java binaries (like SaxonC) and immense memory overhead in your application.

The Factur-X Engine Solution

Don't build your own validator. Run the Factur-X Engine via Docker and instantly validate pure XML files or full PDF/A-3 documents via a simple REST API.

cURL Example - Validating a PDF

curl -X 'POST' \
  'http://localhost:8000/v1/validate' \
  -H 'accept: application/json' \
  -H 'Content-Type: multipart/form-data' \
  -F 'file=@invoice.pdf;type=application/pdf'

Response - Clean JSON Errors

{
  "is_valid": false,
  "errors": [
    {
      "code": "BR-CO-16",
      "message": "Payment means IBAN is missing."
    }
  ]
}

Validating XML vs PDF: What's the Difference?

The /v1/validate endpoint accepts both input types without any configuration change. For PDF/A-3 files (Factur-X, ZUGFeRD), the engine first extracts the embedded factur-x.xml attachment, then runs Schematron rules on it. For raw CII XML (XRechnung), validation is applied directly. Profile detection is automatic — the engine reads the GuidelineSpecifiedDocumentContextParameter node to determine which ruleset (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED) applies.

cURL — Validating raw XRechnung XML

curl -X POST 'http://localhost:8000/v1/validate' \
  -H 'accept: application/json' \
  -F 'file=@xrechnung.xml;type=application/xml'

What Schematron Rules Actually Check

A plain XSD check verifies structure. Schematron validates business rules — the 300+ constraints that make an e-invoice legally compliant. A few common ones:

Rule	What it checks	Profile
BR-CO-10	VAT category tax amount = taxable amount × VAT rate	All
BR-CO-16	Payment means IBAN must be present when payment code is 58	All
BR-S-08	Standard VAT lines must have a non-zero tax rate	All
BR-DE-17	German XRechnung: buyer reference (Leitweg-ID) is mandatory	XRechnung
BT-1-FORMAT	Invoice number must not be empty or contain only whitespace	All

Integrating Validation into a CI/CD Pipeline

Run the engine as a sidecar Docker service, then call /v1/validate from your test suite. The structured JSON response (with is_valid and errors[]) makes it trivial to fail a build on non-compliant invoices:

GitHub Actions — validate before release

services:
  facturx:
    image: facturxengine/facturx-engine:latest
    ports: ["8000:8000"]

steps:
  - name: Validate e-invoice
    run: |
      RESULT=$(curl -s -X POST http://localhost:8000/v1/validate \
        -F 'file=@invoice.xml')
      echo $RESULT | jq -e '.is_valid == true'

Frequently Asked Questions

Does validation require an internet connection?

No. The Factur-X Engine is 100% air-gapped. All Schematron rulesets (EN 16931, XRechnung KoSIT, Chorus Pro) are bundled inside the Docker image. Validation runs entirely offline — no external schema downloads, no telemetry.

Which profiles are supported?

All CII profiles: MINIMUM, BASIC WL, BASIC, EN 16931 (Comfort), and EXTENDED. Also XRechnung 3.0 via KoSIT Schematron. Profile detection is automatic from the XML header — no configuration required.

What is the maximum file size for validation?

The default upload limit is 10 MB, which comfortably covers any real-world e-invoice PDF or XML. For bulk validation of large batches, use concurrent requests — the engine handles multiple Gunicorn workers out of the box.

Struggling with cryptic errors?

Errors like [BR-CO-17] or [BT-1-FORMAT] are notoriously difficult to debug. The Factur-X Engine Pro edition includes an embedded Smart Diagnostics Engine that translates rigid Schematron errors into human-readable, actionable advice for developers.

Get Evaluation Key Read Error Guide