EU E-Invoice APISelf-host the KoSIT validator or use an API?
The official tools for validating e-invoices are open source. When running them yourself pays off, what it costs over time, and when a hosted API is the better choice – an honest comparison, even though it comes from an API provider.
As of 29 October 2026. Language: Deutsch
The building blocks
- KoSIT validator (Java, Apache 2.0) with the XRechnung validator configuration: validates XRechnung and EN 16931 in UBL and CII. The configuration is released several times a year and has to be updated each time.
- Mustang (Java, Apache 2.0) with the ZUGFeRD / Factur-X rules of FeRD and FNFE-MPE: reads and writes ZUGFeRD PDFs and validates their XML.
- veraPDF (GPL-3.0 or MPL-2.0): checks that the PDF really is PDF/A-3.
- For other countries: the Peppol BIS rules of OpenPeppol, the French rules BR-FR, CIUS-RO, HR-CIUS, the FatturaPA and KSeF schemas – each with its own release cycle.
This API uses exactly these tools and rule sets, unmodified. The difference is who runs them and keeps them current.
Comparison
| Self-hosted | EU E-Invoice API | |
|---|---|---|
| Cost | No licence fees; servers and working time | Free up to 100 documents a month, then from €29 a month |
| Setup | Java service, configuration and rule sets, operations | Get an API key, make an HTTP call |
| Rule updates | Watch, test and roll out new releases yourself | Watched and applied; the version is in every response, upcoming rules via /v1/preview/validate |
| Formats | One tool per format | One call for XRechnung, ZUGFeRD, Peppol, FatturaPA, KSeF, CIUS-RO, HR-CIUS and the French rules |
| Result | XML report (KoSIT) or each tool's own output | One JSON shape with rule id, severity, XPath and a link to the rule page |
| Parsing and generating | Write the mapping yourself | /v1/parse returns EN 16931 JSON, /v1/generate writes validated documents |
| Data | Never leaves your network | Processed in memory only on servers in Germany, never stored |
| Dependency | None | Availability of the service; no committed availability (SLA) |
When self-hosting pays off
- You process very large volumes and your team runs Java services anyway.
- Invoices must not leave your network, not even for validation.
- You need a single format, such as XRechnung, and can follow KoSIT's releases yourself.
When an API is the better choice
- Your software is not written in Java, or you don't want to run another service.
- You need several countries, or parsing and generating as well as validation.
- You don't want to watch and test rule updates yourself.
The two combine well: pin a version with ?ruleset=xrechnung@3.0.2 and compare results with your own installation.
More: guide to e-invoicing in Germany from 2027 · API documentation (Markdown) · rule index
Try the validation with your own file – free in the browser, without sign-up.