Validate an XRechnung or ZUGFeRD invoice and read what is inside
Drop the XML or the PDF. The file is checked against the KoSIT validator's rule set in memory on a server in the EU, the findings come back by rule id, and the invoice is rendered as something a person can read. It is not stored.
Drop an XRechnung XML (UBL or CII) or a ZUGFeRD or Factur-X PDF with the XML embedded.
This tool runs in your browser and needs JavaScript.
Observations, not verdicts. What you enter is processed for this result and written to a usage journal described in the privacy policy; nothing else is stored.
How the validation runs
-
Upload the invoice
An .xml file is taken as the invoice itself. A .pdf is opened as a PDF/A-3 container and the embedded factur-x.xml, zugferd-invoice.xml or xrechnung.xml attachment is pulled out. A PDF with no attachment stops here, and the result says so.
-
Syntax and profile are detected
The root element decides between UBL and UN/CEFACT CII; the customisation or guideline id names the profile, for example the XRechnung 3.0 URN or the Factur-X EN 16931 profile. Both are shown before any rule runs.
-
The KoSIT rule set runs
Schema check first, then the Schematron rules of the XRechnung validator configuration published by KoSIT: the EN 16931 business rules (BR-xx, BR-CO-xx, BR-S-xx) and the German extension (BR-DE-xx).
-
Read the findings and the rendering
Each finding carries the rule id, its severity and the rule's own text, so you can look it up in the specification. Below it the invoice is rendered as a readable document: parties, line items, totals, payment terms, Leitweg-ID.
What is checked, and what is not
Since 1 January 2025 every business in Germany has to be able to receive electronic invoices in the EN 16931 format, and public-sector buyers have required XRechnung since November 2020. In practice that means two families of file arrive in an inbox: an XRechnung, which is pure XML in either UBL or CII syntax, and a ZUGFeRD or Factur-X invoice, which is a PDF/A-3 with the same kind of XML embedded. Both are validated with the same rules, which is why this tool accepts both.
What the validator computes
The rule set is the one published by KoSIT, the Koordinierungsstelle für IT-Standards, as the validation configuration for XRechnung. It is the reference implementation the federal and state invoice portals use for their own acceptance checks. The tool runs it in three layers: the XML schema of the syntax, the EN 16931 Schematron rules, and the XRechnung-specific German rules. A ZUGFeRD or Factur-X invoice in the MINIMUM or BASIC WL profile carries less data by design and is not a full EN 16931 invoice; for those files the declared profile is the first thing to read, because findings against the EN 16931 rules are expected rather than surprising.
Every finding is reported with the rule id from the specification. BR-DE-15, the missing buyer reference that carries the Leitweg-ID, and BR-DE-2, the missing seller contact, are the two most common reasons an otherwise correct invoice is rejected by a public buyer, and both are the kind of thing a person cannot see in a PDF rendering.
What it does not judge
The tool tells you whether the file satisfies the published rules. It does not tell you whether the invoice is correct: the VAT rate, the arithmetic behind a line, whether the Leitweg-ID belongs to the buyer you meant, and whether a particular recipient accepts the profile you chose are outside the rule set. A file that passes here can still be rejected by a receiving portal that adds its own checks, and a PDF that yields valid XML is not thereby certified as a conforming PDF/A-3 container.
Where the file goes
The upload is processed in memory on a server in the EU and discarded when the response has been sent. It is not written to disk, not queued, not used to improve anything. What remains is a usage journal entry with a timestamp and the file size, described in the privacy policy. If your invoices should not leave your own infrastructure at all, the same rule set is available from KoSIT as open source, and the agent that automates a supplier portal can run it inside your own pipeline before an upload.
Formats and profiles the tool recognises
| XRechnung | XML in UBL 2.1 (Invoice, CreditNote) or UN/CEFACT CII D16B; versions 2.x and 3.x by customisation id |
|---|---|
| ZUGFeRD 2.x / Factur-X 1.x | PDF/A-3 with an embedded XML; profiles MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED and XRECHNUNG |
| Rule set | KoSIT validator configuration for XRechnung: syntax schema, EN 16931 Schematron, German BR-DE rules KoSIT |
| Severity levels | error (the rule is mandatory), warning (the rule is advisory), information (context the validator reports) |
| File handling | Processed in memory on EU hardware, not stored; a usage journal keeps a timestamp and the size |
As of 2026-09-08
Questions about e-invoice validation
How do I make an XRechnung readable?
Upload the XML here. The rendering below the findings shows seller, buyer, line items, totals and payment terms as a normal document. The XML itself is the invoice; the rendering is a view of it, not a replacement.
How do I check whether a PDF invoice is a valid ZUGFeRD file?
Drop the PDF. If it is a PDF/A-3 with an embedded XML, the tool extracts it, shows the declared profile and runs the rules for that profile. A plain PDF without the attachment is reported as such, which is itself the answer.
Is this the same validator the invoice portals use?
It runs the validator configuration KoSIT publishes for XRechnung, which is what the federal and most state portals build their acceptance checks on. A portal may add checks of its own, so passing here is necessary, not sufficient.
Does a green result mean the invoice is legally correct?
No. The rules check structure and business rules of the standard. Tax content, amounts and whether the recipient is the right one are your accountant's questions, not the validator's.
Is the invoice stored anywhere?
No. It is validated in memory on a server in the EU and dropped once the response is sent. Only a usage journal entry with timestamp and size remains.
Can I validate invoices automatically before uploading them to a portal?
Yes. The KoSIT validator is open source and runs on your own machines; a Browserberg workflow that uploads invoices to a supplier portal can run it as a step before the upload block.
Note · In memory, in the EU, not kept
The uploaded file is held in memory on a server in the EU for the duration of one request. Nothing is written to disk or kept for training or debugging; only the usage journal described in the privacy policy records that a validation took place.
Related tools and guides
- Supplier portal invoices Upload validated invoices into Coupa, Ariba and the rest without a person clicking
- JSON Schema generator Build the schema for extracting invoice data from a portal page
- Audit log verifier Check the signed action log of a run that uploaded an invoice
- EU data residency Where sessions, files and model calls are processed
- All tools The eighteen tools in one place
Automate the upload that follows the validation
Five browser hours, no card. Validate here, then let a workflow carry the invoice into the portal that wants it.