EN 16931 Validator
Find out why your e-invoice gets rejected.
Drop in a Factur-X, ZUGFeRD, XRechnung, or Peppol invoice. You get back the exact rules it breaks, what each one means, and how to fix it. Free, no signup, nothing stored.
- Factur-X
- France, all conformance levels
- ZUGFeRD 2.x
- Germany, hybrid PDF
- XRechnung
- German public sector, CII and UBL
- Peppol BIS 3
- Cross-border UBL
Drop an invoice here
Factur-X or ZUGFeRD PDF, or a bare XRechnung, Peppol, or CII file.
Your invoice is checked and discarded. Nothing is stored.
01 What gets checked
Four stages, in order.
If a stage cannot run, the report says so and the result is never reported as a pass.
01
The PDF container
Whether the XML is embedded, referenced from the catalog, flagged with the right relationship, and declared in the metadata. Most rejected hybrid invoices fail here, not in their XML.
02
The profile
Which specification the invoice declares, such as Factur-X BASIC, XRechnung 3.0, or Peppol BIS 3. That decides which schema and which rule sets apply in the next two stages.
03
The XML schema
Structure and element order against the published CII D16B and UBL 2.1 schemas. Order matters in both, and an out-of-sequence element fails before any business rule is evaluated.
04
The business rules
The full published EN 16931 rule set, plus the official XRechnung rules (BR-DE-15 and so on) or Peppol BIS 3 rules when the invoice declares them. Factur-X MINIMUM and BASIC WL are not EN 16931 invoices, so they are checked against their own official profile rules instead, and the report says so. Failures come back as BR-01, BR-CO-15 and so on, with the business term and the exact element.
ZUGFeRD 1.0 is recognised, but it predates EN 16931 and uses a different data model, so the EN rules are not applied to it. The report tells you that rather than passing it silently.
02 Rule reference
Already have a rejection code? Look it up.
Every EN 16931 business rule has a page explaining what it means, why it fires, and how to fix it. If a platform has bounced an invoice back with a code, it is the fastest way to find out what it objects to.
- BR-01An Invoice shall have a Specification identifier (BT-24).
- BR-16An Invoice shall have at least one Invoice line (BG-25).
- BR-CO-10Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131).
- BR-CO-15Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).
- BR-S-08For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is "Standard rated", the VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall equal the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT-102, BT-95) is "Standard rated" and the VAT rate (BT-152, BT-103, BT-96) equals the VAT category rate (BT-119).
03 API
Run it on every invoice.
The same checks are available as an API, so you can validate before you send instead of finding out when a platform bounces it back. It works with your PDFPipe API key on every plan, including the free one, and does not count against your monthly render quota. Fair use is up to 2,000 validations per key per day.
Read the docscurl -X POST https://einvoice.pdfpipe.xyz/v1/einvoice/validate \
-H "Authorization: Bearer pp_live_..." \
-F "file=@invoice.pdf"The response is a JSON report: a verdict, the detected profile, every finding with its rule code and business term, and which stages ran.
Scope Limits
What this does not tell you.
Full PDF/A conformance is not checked. We report the PDF/A violations that are unambiguous from the document structure: encryption, a missing output intent, fonts that are not embedded, and a missing or incomplete association between the PDF and its XML. We do not check the rest of the standard, which covers colour spaces, transparency, and a long tail that only a dedicated engine gets right. A document can pass every check here and still fail a full PDF/A validator, so run one if that matters to you.
A pass is not a guarantee of acceptance. Tax authorities, Peppol Access Points, and individual buyers apply their own rules on top of EN 16931, including country extensions and registration checks that no file-level validator can see. This tool reports what the published rule set says about your document, and nothing more.
This is not legal, tax, or accounting advice. The results are provided as is, without warranty of any kind. Decide your compliance position with a qualified adviser, not with this page.
Rule text comes from the EN 16931 validation artefacts published by CEN/TC 434 and the European Commission, used unmodified under the European Union Public Licence v1.2. The artefacts are available from the upstream repository. XRechnung rules come from the KoSIT XRechnung Schematron (Apache License 2.0), Peppol BIS Billing 3 rules from OpenPeppol, and the Factur-X MINIMUM and BASIC WL profile rules from the Factur-X specification published by FNFE-MPE.
Factur-X, ZUGFeRD, XRechnung, and Peppol are trade marks of FNFE-MPE, FeRD, KoSIT, and OpenPeppol AISBL respectively, and are used here only to identify the invoice formats this tool reads. PDFPipe is not affiliated with, endorsed by, or certified by any of them, nor by CEN or the European Commission.