E-invoice
Validate XRechnung and ZUGFeRD
Upload your XRechnung or your ZUGFeRD/Factur-X PDF — we work out which format it is. If a PDF carries an embedded invoice, that is what gets checked, against the official KoSIT rule set.
Or paste XML
XML or PDF, up to 5 MB — or just drop a file here. No sign-up, no allowance to spend.
Your file is processed in memory and discarded immediately. We never store invoice content.
No invoice at hand?
One click checks the file right here — downloading is optional.
- ValidValid invoice (UBL)
Passes validation cleanly. A good starting point for your own mapping.
File ↓ - ValidValid invoice (CII)
The same invoice in the second permitted syntax, UN/CEFACT CII.
File ↓ - ValidValid invoice (ZUGFeRD PDF)
A hybrid of readable PDF and embedded CII invoice — produced by NormAPI generation, verified like every sample.
File ↓ - BR-DE-15Buyer reference missing
Without BT-10 — for public-sector invoices this holds the Leitweg-ID.
File ↓ - BR-DE-2Seller contact missing
The BG-6 contact group is absent entirely — the most common mapping gap.
File ↓ - BR-CO-16Amount due does not add up
The amount due contradicts the totals — the classic rounding bug.
File ↓ - BR-DE-18Skonto notation malformed
PROZENT=2 instead of PROZENT=2.00 — the notation started but not followed.
File ↓ - SchemaSchema error: invoice number missing
Fails at the XML schema. The business rules are never evaluated — an empty error list here does not mean "nothing wrong".
File ↓ - Not checkedA profile with no validation scenario (Factur-X MINIMUM)
Declares MINIMUM, which is not an EN 16931 invoice. No scenario matches, so no rule runs — the outcome is neither valid nor invalid but "not checked".
File ↓
What a finding looks like
The "Amount due does not add up" sample above, checked. Not a screenshot but the report itself — rule code, severity, the official rule text and the location:
Invoice is not valid
Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Paid amount (BT-113) +Rounding amount (BT-114).
Location: /Q{urn:oasis:names:specification:ubl:schema:xsd:Invoice-2}Invoice[1]/Q{urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2}LegalMonetaryTotal[1]
Rule set v2026-08-31Checked as EN16931 XRechnung (UBL Invoice)
The rule code leads to a page of its own. The location is the path within the document in Clark notation, not a line number — the same value the API returns.
What gets checked
Two layers, in that order. First the XML schema: whether the file is structurally an XRechnung at all. Only once it passes do the business rules run — which is why the report carries a field of its own for whether they did. Without it, "nothing found" and "not checked" would look identical from outside.
Then the business rules: some 300 checks from EN 16931 and its German extension, with codes like BR-DE-15, BR-CO-16 or BR-CL-23. Validation runs KoSIT's own tool against the official configuration — not a reimplementation, and against the same release the public sector's own checking services use.
What you can upload
XRechnung as plain XML in both syntaxes, UBL and UN/CEFACT CII, and ZUGFeRD or Factur-X PDFs — from a PDF the embedded invoice is extracted and that is what gets checked. Which format arrived is worked out from the file's content, not its extension.
Covered are XRechnung 3.0, plain EN 16931, and the Factur-X/ZUGFeRD profiles BASIC, EN 16931 and EXTENDED. MINIMUM and BASIC WL are not EN 16931 invoices: they deliberately carry fewer fields than the norm requires, so there is nothing to check them against. For a German B2B invoice they do not suffice anyway.
What the report tells you
Per finding: the rule code, the severity, where in the document it sits, and the official rule text. For the common rules the code leads to a page of its own that explains it in plain language: what it means, what usually causes it, how to fix it.
A warning does not make an invoice invalid, and the rule set emits advisories on perfectly clean invoices too. So the verdict is kept separate from the findings list: an invoice with three advisories and no errors is acceptable.
What happens to your file
The note above the form means it literally: the check happens in memory, and then the file is gone. What follows from that matters more for an intake process — the report is produced at your end and stays there. Anyone who has to keep it as evidence can, without a second copy sitting somewhere else.
What this check cannot see
Whether the tax rate is the right one, whether the description of the supply is accurate, whether the invoice was even addressed to the right recipient. The BMF letter of 15 October 2025 treats that as its own class of error, and no technical check detects it. An invoice can pass all 300 rules and still be substantively wrong.
Why not just any free checker?
Because they disagree with each other, and we measured that rather than asserting it: the same three files from the official KoSIT test suite, put through eleven freely accessible checking sites on one day. Three did not process an XRechnung in UBL at all; three more were working from a rule set predating 2 September 2026. A "valid" there does not mean the invoice is sound — it means that site found nothing.
Eleven online validators, the same invoice, one day →
Even two serious implementations of the same rule set do not agree everywhere: across 29 documents they agreed on 22 and disagreed on 7. Which is why this runs KoSIT’s own validation tool against the official configuration — the same release the public sector’s own checking services use.