Valid XML is not the same as an accepted invoice. Learn the three layers of e-invoice validation — schema, business rules and recipient checks — and how to test your file in under a minute.
An e-invoice can be perfectly well-formed XML, pass every schema check, and still come back rejected. That gap — between "technically correct" and "actually accepted" — is where most e-invoicing projects lose time, and it is almost always a business validation problem rather than a technical one.
Here is how the layers actually stack up, and how to check your own invoice in about a minute.
Is the file structurally a UBL Invoice or a UN/CEFACT Cross Industry Invoice? Are the elements in the right order, are the data types right? This layer catches broken files, and almost nothing else. Passing it tells you very little.
This is the layer that matters. The European standard EN 16931 defines several hundred rules — the BR-* and BR-CO-* families — that check whether the content of the invoice makes sense. On top of those sit national rules (BR-DE-* for XRechnung) and network rules (PEPPOL-EN16931-* for Peppol BIS Billing). A file can be flawless XML and break twenty business rules.
The layer no validator can test for you. Does the Leitweg-ID belong to the authority you are actually invoicing? Is the purchase order number the one the buyer's system expects? Does the VAT treatment match the transaction? Your invoice can pass every public validator and still be rejected by the recipient's accounts payable system.
Almost all real-world rejections cluster in a handful of areas:
BR-CO-10, BR-CO-13, BR-CO-15 and BR-CO-16 check the arithmetic chain. One rounding decision in your ERP breaks the chain.
In Germany, BR-DE-15 makes the buyer reference (BT-10) mandatory — this is where the Leitweg-ID goes. It is the single most common reason a B2G invoice bounces.
Every VAT breakdown line has to be consistent with the category codes used on the invoice lines, and exemptions need an exemption reason or code.
Missing IBAN, or a payment means code that does not match the payment information supplied.
Most validators grade findings as fatal errors, errors and warnings. It is tempting to ship anything that only produces warnings — but a warning means "this is unusual, and the recipient may not handle it". Public sector portals in particular are stricter than the minimum standard requires. Treat warnings as questions to answer, not noise to ignore.
Our E-Invoice Validator is free and runs in the browser. It covers:
Get instant access to our free E-Invoice Validator. Check XRechnung, Peppol BIS and ZUGFeRD for business rule errors before sending.
Free validation tool • No registration required • Instant results
This is where most people get a confusing result. Three quick rules:
Extract the XML attachment from the PDF/A-3 file first, then validate the XML — usually as ZUGFeRD 2.2 EN 16931.
Look at the invoice type code: 380 is an invoice, 381 is a credit note. UBL uses a different root element for each, so choosing the wrong variant produces errors that have nothing to do with your data.
Check the opening tag of the XML. urn:oasis:names:specification:ubl:schema:xsd:Invoice-2 means UBL; urn:un:unece:uncefact:standard:CrossIndustryInvoice:100 means CII.
For Peppol, use the Peppol Participant ID Checker to verify the recipient is reachable before sending.
Validation is cheap; rejection is not. A file that fails at your desk costs a minute. The same file failing three weeks later in a customer's accounts payable queue costs a payment cycle — and in mandate countries, it can cost a filing deadline.
Test the file before it leaves your system. Every time.
With Invoice Portal, you can validate XRechnung, Peppol BIS and ZUGFeRD invoices in one place, catch business-rule failures before transmission, and route compliant files straight to your customers.
Schema validation checks whether the XML file is structurally correct. Business-rule validation checks whether the invoice content makes sense, for example whether totals add up and mandatory buyer references are present.
The most common rejections are caused by totals that do not add up, missing buyer references such as the German Leitweg-ID, inconsistent VAT categories, and missing or incorrect payment details.
Warnings should not be ignored. A warning means the content is unusual and the recipient may not handle it. Public sector portals are often stricter than the minimum standard requires.
Check the opening tag of the XML. A UBL invoice starts with urn:oasis:names:specification:ubl:schema:xsd:Invoice-2, while a UN/CEFACT CII invoice starts with urn:un:unece:uncefact:standard:CrossIndustryInvoice:100.
https://invoice-portal.de/wp-content/uploads/2024/01/logo_invoice_portal_blue_white.png
283
283
Irina Oldenburger
https://invoice-portal.de/wp-content/uploads/2023/12/Invoice-Portal-logo.svg
Irina Oldenburger2024-11-26 10:52:392024-11-27 09:54:47News from the Federal Ministry of Finance
https://invoice-portal.de/wp-content/uploads/1730888436826.jpg
1535
2048
Irina Oldenburger
https://invoice-portal.de/wp-content/uploads/2023/12/Invoice-Portal-logo.svg
Irina Oldenburger2024-11-21 13:02:262024-11-21 16:58:12ViDA – VAT in the Digital Age
https://invoice-portal.de/wp-content/uploads/1730363603896.jpg
1066
800
Irina Oldenburger
https://invoice-portal.de/wp-content/uploads/2023/12/Invoice-Portal-logo.svg
Irina Oldenburger2024-11-21 12:59:142024-11-21 16:55:243rd Digitisation Day in Leinfelden-Echterdingen on 15.10.2024
https://invoice-portal.de/wp-content/uploads/346c2402-4871-4f52-a6c7-7e72596950cb.jpg
1600
1200
Irina Oldenburger
https://invoice-portal.de/wp-content/uploads/2023/12/Invoice-Portal-logo.svg
Irina Oldenburger2024-11-21 12:56:262024-11-21 16:55:52The Smart City Expo World Congress 05.11.-07.11.2024 in Barcelona
https://invoice-portal.de/wp-content/uploads/2024/01/Peppol_.png
200
365
Irina Oldenburger
https://invoice-portal.de/wp-content/uploads/2023/12/Invoice-Portal-logo.svg
Irina Oldenburger2024-11-21 12:46:512024-11-21 12:46:51
