XRechnung Validator and Generator (EN 16931)

This XRechnung validator checks e-invoices against the official KoSIT rules and returns a pass or fail verdict with every failing rule ID, its message and its XPath. It covers XRechnung 3.0.2 and EN 16931 invoices in UBL or CII, and ZUGFeRD or Factur-X PDFs in the EN 16931 profile. The same actor also generates XRechnung XML and Factur-X (ZUGFeRD) PDFs from plain JSON, and extracts an existing e-invoice back into JSON.

Auf Deutsch: E-Rechnungen per API prüfen (XRechnung und ZUGFeRD) mit dem offiziellen KoSIT-Validator, mit Regel-ID für jeden Fehler, und XRechnung oder ZUGFeRD aus JSON erstellen.

It runs the reference implementations, unmodified: the KoSIT Validator 1.6.3 with the XRechnung 3.0.2 configuration released 2026-08-31, and Mustang 2.26.0 for Factur-X and ZUGFeRD PDFs. Every answer names those versions, so a verdict can be reproduced later.

Not legal or tax advice. This is technical validation against the published rule sets. Sending an invoice to a buyer, a tax authority or a Peppol Access Point is outside this actor, and so is deciding what your business is required to do.

Who it is for

• Billing and ERP developers who must send XRechnung or ZUGFeRD invoices and want to catch BR-DE-15 (missing Leitweg-ID) or BR-CO-16 (wrong amount due) before the buyer does.
• Accounts payable teams who receive e-invoices and need to know, rule by rule, why one was rejected.
• Tax advisers and bookkeepers who check many client invoices at once and want a written verdict per file.
• AI agents that need a deterministic e-invoice check as a tool, through MCP or the Apify API.

What it does

Operation	Input	Output	Price
validate	UBL or CII XML, or a ZUGFeRD or Factur-X PDF	valid, the matched profile, and every failing rule with its ID, severity and XPath	from $0.02 per document
generate	canonical invoice JSON	XRechnung or EN 16931 XML, validated before it is returned	from $0.03 per document
generate-pdf	canonical invoice JSON, optionally your own visual PDF	PDF/A-3 with the invoice XML embedded (Factur-X, also known as ZUGFeRD 2)	from $0.05 per document
extract	UBL or CII XML, or a ZUGFeRD or Factur-X PDF	canonical invoice JSON, each field named after its EN 16931 business term	from $0.01 per document

generate validates its own output at no extra charge. If the document it would produce breaks a rule, you get the failing rules instead of an invoice your buyer would reject.

How to use the XRechnung validator

1. Put one or more documents in Documents: a url, the XML as a string in xml, or any file (PDFs included) as base64.
2. Pick the Operation. A single document can override it with its own operation, and set its own profile, pdfProfile or language.
3. Start the run and read the dataset: one row per document, in input order.

The smallest input, which is also the prefilled example:

{
  "operation": "validate",
  "documents": [
    {
      "name": "xrechnung-ubl-valid.xml",
      "url": "https://raw.githubusercontent.com/itplr-kosit/xrechnung-testsuite/v2026-08-31/src/test/business-cases/standard/01.01a-INVOICE_ubl.xml"
    }
  ]
}

A mixed batch:

{
  "operation": "validate",
  "documents": [
    { "name": "1001.xml", "url": "https://example.com/invoices/1001.xml" },
    { "name": "1002.pdf", "base64": "JVBERi0xLjcK..." },
    { "name": "1003", "operation": "generate", "profile": "xrechnung-ubl", "invoice": { "number": "1003" } },
    { "name": "1004.xml", "operation": "extract", "url": "https://example.com/invoices/1004.xml" }
  ]
}

• Generated files are saved in the run's key-value store. The dataset row carries the key in fileKey, plus xmlFileKey for generate-pdf. Two documents with the same name never overwrite each other: the second file gets a numbered key such as inv-1-2.xml.
• The run also writes an OUTPUT record: documents delivered, charged events per type, documents not evaluated, and whether the run stopped at your maximum cost.

Output example

These rows come from a real run on build 0.1.6 (2026-10-08). A document that breaks a rule:

{
  "index": 1,
  "name": "broken-payable-amount.xml",
  "operation": "validate",
  "ok": true,
  "charged": false,
  "result": {
    "valid": false,
    "profile": "EN16931 XRechnung (UBL Invoice)",
    "syntax": "ubl",
    "errors": [
      {
        "ruleId": "BR-CO-16",
        "severity": "error",
        "message": "[BR-CO-16]-Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Paid amount (BT-113) +Rounding amount (BT-114).",
        "xpath": "/Q{urn:oasis:names:specification:ubl:schema:xsd:Invoice-2}Invoice[1]/Q{urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2}LegalMonetaryTotal[1]",
        "step": "val-sch.1"
      }
    ],
    "warnings": [],
    "notices": [
      {
        "ruleId": "BR-DE-TMP-32",
        "severity": "information",
        "message": "[BR-DE-TMP-32] Eine Rechnung sollte zur Angabe des Liefer-/Leistungsdatums entweder BT-72 \"Actual delivery date\", BG-14 \"Invoicing period\" oder in jeder Rechnungsposition BG-26 \"Invoice line period\" enthalten.",
        "xpath": "/Q{urn:oasis:names:specification:ubl:schema:xsd:Invoice-2}Invoice[1]",
        "step": "val-sch.2"
      }
    ],
    "steps": [
      { "id": "val-xsd", "valid": true },
      { "id": "val-sch.1", "valid": false },
      { "id": "val-sch.2", "valid": true },
      { "id": "val-xml", "valid": true }
    ],
    "validatorVersions": {
      "kositValidator": "1.6.3",
      "xrechnungConfiguration": "xrechnung-3.0.2 release 2026-08-31",
      "xrechnungSpecification": "3.0.2",
      "en16931Schematron": "as bundled in the KoSIT XRechnung configuration 2026-08-31",
      "mustang": "2.26.0",
      "actor": "0.1.6"
    },
    "specificationId": "urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0",
    "durationMs": 47,
    "source": "xml",
    "document": {
      "name": "broken-payable-amount.xml",
      "bytes": 6743,
      "sha256": "f19a443b30559134824b6adcf8cf3a524cbb5cc02629d3dd5ea5030d3b00582d"
    }
  }
}

A generated XRechnung, from the same run (validatorVersions left out here):

{
  "index": 4,
  "name": "2026-0001",
  "operation": "generate",
  "ok": true,
  "charged": false,
  "result": {
    "profile": "xrechnung-ubl",
    "profileLabel": "XRechnung 3.0.2, UBL syntax",
    "syntax": "ubl",
    "bytes": 4632,
    "sha256": "8366555eeca12c411e7f991e74ef960d26d12007b843b437b4aff3b220f2b2ee",
    "validation": { "valid": true, "matchedProfile": "EN16931 XRechnung (UBL Invoice)", "warnings": [], "notices": [] },
    "fileKey": "2026-0001.xml"
  }
}

charged tells you whether the row was billed. That sample run was a test run without billing, so it reads false; on your runs it is true for every evaluated document.

valid is the KoSIT report's own verdict, not one this actor computes. Some rules are classified as warnings in the XRechnung configuration and still make the report reject the document. When that happens you get valid: false with an empty errors array and the reason in warnings.

When a document fails

A failed document gets a row with ok: false and an error object. It is not charged, and the run carries on with the next document.

error.code	Meaning
fetch_failed	the url could not be downloaded, answered an HTTP error (the status is in the message), or did not finish downloading within 120 seconds
invalid_url	the url is not an http or https address
invalid_document	the document is not well-formed XML, not valid base64, or empty
invalid_xml, unknown_syntax	extract was given XML that is broken, or that is not a UBL or CII invoice
no_embedded_invoice	extract was given a PDF that carries no invoice XML
document_too_large	the document is over 32 MB
invalid_entry	an entry in documents is not an object
unknown_operation, unknown_profile	the entry's operation or profile is not one this actor knows
missing_field, invalid_number, invalid_line, invalid_invoice	the invoice JSON for generate or generate-pdf lacks a required field or holds a value that is not a number; the message names the field
generated_document_invalid	the invoice you sent for generate would produce a document the rule set rejects; the failing rules are in error.details

Which profiles are validated

The bundled configuration carries XRechnung 3.0 (UBL and CII, invoice and credit note, plus the Extension and CVD variants) and EN 16931 core (UBL and CII). A ZUGFeRD or Factur-X PDF is validated when its embedded XML declares one of those, which in practice means the EN 16931 (COMFORT) or XRechnung profile.

A document that declares anything else, such as Factur-X MINIMUM, BASIC WL or BASIC, or an XRechnung version before 3.0, matches no scenario. You get valid: false with the rule ID no_matching_scenario and the specification the document declares in specificationId, and you are not charged, because no rule was evaluated. A PDF that carries no invoice at all answers no_embedded_invoice, also free.

The canonical invoice JSON

One shape for generate, generate-pdf and extract. Every field is named after its EN 16931 business term, so you map your own system against the standard rather than against this actor.

{
  "number": "2026-0001",
  "issueDate": "2026-09-01",
  "dueDate": "2026-10-01",
  "typeCode": "380",
  "currency": "EUR",
  "buyerReference": "04011000-12345-03",
  "deliveryDate": "2026-08-31",
  "seller": {
    "name": "Nordlicht Elektrotechnik GmbH",
    "vatId": "DE123456789",
    "electronicAddress": { "value": "rechnung@nordlicht-elektro.example", "schemeId": "EM" },
    "address": { "line1": "Werftstrasse 14", "city": "Kiel", "postcode": "24143", "country": "DE" },
    "contact": { "name": "Buchhaltung", "phone": "+49 431 1234567", "email": "rechnung@nordlicht-elektro.example" }
  },
  "buyer": {
    "name": "Stadtwerke Musterstadt AoeR",
    "vatId": "DE987654321",
    "electronicAddress": { "value": "erechnung@musterstadt.example", "schemeId": "EM" },
    "address": { "line1": "Rathausplatz 1", "city": "Musterstadt", "postcode": "12345", "country": "DE" }
  },
  "payment": {
    "meansCode": "58",
    "iban": "DE79000000001234567890",
    "terms": "Zahlbar innerhalb von 30 Tagen ohne Abzug."
  },
  "lines": [
    {
      "name": "Schaltschrankmontage",
      "quantity": 12,
      "unitCode": "HUR",
      "unitPrice": "78.50",
      "vat": { "categoryCode": "S", "rate": 19 }
    }
  ]
}

• Required: number, issueDate, currency, seller and buyer (each with a name and an address) and at least one line. XRechnung also needs buyerReference (BT-10, the Leitweg-ID for German public buyers), payment, and a seller contact with name, phone and email. The example above carries every field XRechnung asks for; leave one out and generate returns the failing rule instead of an invoice.
• Optional: orderReference, contractReference, projectReference, precedingInvoiceReference (for a credit note), invoicePeriod, deliverTo and note.
• Computed when you leave them out: line net amounts, the VAT breakdown (grouped by category code and rate) and every total. The arithmetic is decimal with two places and half-up rounding, because float arithmetic on money is what makes a total miss by a cent and fail BR-CO-15. Supply any of them and your value is used, which is how you model an allowance, a charge, a prepayment or a rounding line.
• Credit notes use type code 381, which produces a UBL CreditNote and sets the CII type code accordingly.
• The test set behind this actor covers two VAT rates in one invoice, reverse charge, a credit note, a foreign currency, zero rated and intra-community supplies, a partial payment, a price base quantity and a rounding amount.

profile for generate	What it writes
xrechnung-ubl	XRechnung 3.0.2, UBL 2.1 Invoice or CreditNote
xrechnung-cii	XRechnung 3.0.2, UN/CEFACT CII D16B
en16931-ubl	EN 16931 core, UBL 2.1
en16931-cii	EN 16931 core, CII D16B

pdfProfile for generate-pdf	What it writes
facturx-xrechnung	PDF/A-3 with CII carrying the XRechnung profile
facturx-en16931	PDF/A-3 with CII carrying the EN 16931 (COMFORT) profile

If you do not send your own visual PDF to generate-pdf (as visualPdfBase64 on the document), a page is rendered from the invoice in English, German or French. The German and French templates come from Mustang and have not been reviewed by a native speaker.

Pricing

You pay per document, by event. There is no start fee, and the platform compute is included in the event price.

Event	Price
Validated document (validate)	from $0.02
Generated XML invoice (generate)	from $0.03
Generated Factur-X PDF (generate-pdf)	from $0.05
Extracted invoice (extract)	from $0.01

Prices are lower on the Bronze, Silver and Gold plans. A batch of 100 XML invoices validated costs at most $2.00.

Not charged: a document that errors, a validation that never reached a rule set (no_matching_scenario, no_embedded_invoice), and the validation that generate and generate-pdf run on their own output. A document that is evaluated and fails is charged, because the failing rules are the answer you paid for.

Your maximum cost is respected. Before each document the actor checks that the run's maximum cost still covers that document's event. When it does not, the run stops, keeps what it finished, and says so in its status message, for example "Stopped at your maximum cost: 12 of 40 documents delivered, 12 charged."

Use it from Claude, Cursor or any MCP client

Add this URL as a remote MCP server in Claude, Cursor, VS Code or any MCP client:

https://mcp.apify.com?tools=omargnagy/einvoice-en16931

For clients configured with JSON:

{
  "mcpServers": {
    "einvoice": {
      "url": "https://mcp.apify.com?tools=omargnagy/einvoice-en16931"
    }
  }
}

Connect your Apify account when the client asks. The agent then sees one tool, omargnagy--einvoice-en16931, that takes operation and documents and returns the rows above.

From any HTTP client, one call runs the actor and returns the rows:

curl -X POST "https://api.apify.com/v2/acts/omargnagy~einvoice-en16931/run-sync-get-dataset-items" \
  -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"operation": "validate", "documents": [{"url": "https://example.com/invoice.xml"}]}'

From Python:

from apify_client import ApifyClient

client = ApifyClient("YOUR_APIFY_TOKEN")
run = client.actor("omargnagy/einvoice-en16931").call(run_input={
    "operation": "validate",
    "documents": [{"name": "1001.xml", "url": "https://example.com/invoices/1001.xml"}],
})
for row in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(row["name"], row.get("result", {}).get("valid"), row.get("error"))

The run-sync endpoint waits up to 300 seconds. For PDF batches, start the run normally and read the dataset when it finishes.

Speed and limits

• XML is fast once the validator is up. Each run starts the KoSIT validator once. On 2026-10-08 that took between 5 and 95 seconds, depending on how busy the host was. The first document after the start can take several seconds while the validator warms up. After that, an XML document usually takes well under a second: a valid XRechnung in 227 ms, a broken one in 47 ms. Put many documents in one run rather than one run per document.
• PDFs are slower. Every Mustang step starts its own Java process, and CPU on Apify scales with memory. At the default 1024 MB, validating a ZUGFeRD PDF took about 45 to 60 s and generate-pdf about 100 s; at 2048 MB, generate-pdf took 32 s. For PDF batches, set the run memory to 2048 MB.
• Documents up to 32 MB each. A url download stops at 32 MB, has to finish within 120 seconds, and fails if the server sends nothing for 60 seconds.
• No Peppol BIS Billing 3.0 and no French national rules (BR-FR). Only XRechnung 3.0 and EN 16931 core are carried, so Peppol and French CTC checks are not done.
• No Factur-X MINIMUM, BASIC WL or BASIC scenario, and no XRechnung before 3.0. These are read and extracted, not validated (see above).
• No transmission. No Peppol Access Point, French PDP, KSeF, myDATA or SdI, and no digital signatures or archiving.
• Allowances and charges at document or line level are carried through the totals if you supply them, but there is no structured allowances array yet.
• German rule messages are passed through exactly as the validator wrote them, because that wording is what you look up.

How your documents are handled

• What the actor writes. A validate row carries the file name, the byte count, a sha256 and the verdict, never the whole document. An extract row does contain the invoice content (seller, buyer, bank details, lines), because returning it is what extract is for. Files from generate and generate-pdf are stored in the run's key-value store so you can download them.
• What the actor never writes. Document content never goes to the log. Java stack traces and raw validator process output are never passed through; they are mapped to an error code. The rule messages in a verdict come from the validator and can quote the value that broke a rule, for example an invalid date or IBAN, so a validate row can hold short fragments of your invoice. The KoSIT report's HTML rendering of your invoice is stripped before parsing.
• What the Apify platform stores. Apify keeps every run's input as the INPUT record of that run's key-value store. If you send invoices as xml or base64, that record holds them. Your dataset, key-value store and run input follow your Apify account's data retention. If that matters for your data, pass url instead of the document itself, or delete the run when you are done.

Why now

When	Where	What
since 1 January 2025	Germany	every business must be able to receive an e-invoice; a plain PDF no longer counts as one (BMF FAQ)
1 January 2027	Germany	issuing e-invoices becomes mandatory above EUR 800,000 turnover
1 January 2028	Germany	issuing becomes mandatory for every business

Running the Java reference validators yourself means a JVM, a rule set to keep current twice a year, and a scenario configuration to load. This actor does that part and tells you which version answered.

FAQ

Is this the official KoSIT validator? Yes. It runs the KoSIT Validator 1.6.3 with the official XRechnung 3.0.2 configuration released 2026-08-31, unmodified, and every row echoes those versions.

Can it validate a ZUGFeRD PDF? Yes, when the embedded XML declares the EN 16931 (COMFORT) or XRechnung 3.0 profile. MINIMUM, BASIC WL and BASIC documents answer no_matching_scenario and are not charged.

What does valid: false with an empty errors list mean? The XRechnung configuration rejected the document over a rule it classifies as a warning. The rule is in warnings.

Am I charged for an invoice that fails? Yes, if it was evaluated: the failing rules are the result. Errors and documents that matched no rule set are free.

Does it send my invoice to the buyer or to Peppol? No. It validates, generates and extracts. Transmission needs a Peppol Access Point or, in France, a registered PDP.

How do I keep invoices out of Apify storage? Pass a url instead of xml or base64, and delete the run when you are done. validate rows never contain the whole document, but a rule message can quote the value that broke a rule.

How do I cap what a run costs? Set a maximum cost per run. The actor checks it before each document and stops cleanly when the next one would not fit.

Does it support Peppol BIS Billing 3.0? Not in this version. It is planned as a second scenario set.

How often are the rules updated? XRechnung publishes in January and July. Each update ships as a new build, and every row names the configuration that produced it.

Licences

The bundled validators are open source and unmodified: the KoSIT Validator, its XRechnung configuration and Mustang under Apache 2.0, and the EN 16931 Schematron under EUPL 1.2.

Changelog

• 0.1.10 (2026-10-09) a url download now stops at 32 MB as it arrives instead of being read whole first, and has to finish within 120 seconds. A document's own pdfProfile is used by generate-pdf, and a field the actor does not know is named in the log instead of being ignored silently. The README now says that a rule message can quote the value that broke the rule.
• 0.1.6 (2026-10-08) documentation and listing. Document downloads now identify the actor and its Store page in the User-Agent.
• 0.1.5 (2026-10-08) billing and error handling. The run respects its maximum cost and reports the real charged counts in an OUTPUT record. Validations that never reached a rule set are not charged, and every row says whether it was charged. A failed download is fetch_failed with the HTTP status, text that is not XML is invalid_document, one malformed entry no longer stops the run, and generated files with the same name no longer overwrite each other.
• 0.1.2 (2026-09-06) five third-party Factur-X and ZUGFeRD PDFs added to the test set. A document whose specification matches no scenario answers no_matching_scenario, and rows carry specificationId.
• 0.1.0 (2026-09-06) first version: validate, generate, generate-pdf and extract for XRechnung 3.0.2 and EN 16931 core, in UBL and CII, plus Factur-X PDF/A-3.