Why Validation Matters Before You Send
When you generate a Factur-X or ZUGFeRD invoice, the PDF looks perfectly normal. Your invoice number is there, the amounts add up, the client details are correct. But embedded inside that PDF is an XML file that your client's accounting software will try to process automatically. That XML has its own rules, and they have nothing to do with how the PDF looks on screen.
A Factur-X invoice that fails validation still opens fine in a PDF reader. It displays correctly. But when your client's ERP system or accounts payable software tries to import it, the automated processing fails silently. In France, Chorus Pro is the mandatory submission platform for public sector invoices, and it actively rejects files whose embedded XML does not meet the required standard. A rejection triggers a correction process that can take several days before you receive payment. In Germany, the obligation to receive structured e-invoices in EN 16931 format came into effect in January 2025, with the obligation to send them following in stages from 2027. Private clients who already process invoices automatically will not manually rescue a file their system could not parse either. As automated processing becomes the norm across Europe, sending an invalid invoice increasingly means sending one that does not get paid on time.
Running a validator before you send takes less than a minute and removes that risk entirely.
What a Validator Actually Checks
Validation works in three layers, each one more specific than the last.
The first is well-formedness. The XML must be technically valid in the most basic sense: all tags properly opened and closed, namespaces declared, encoding consistent. This level almost never fails when you use dedicated invoicing software, but it catches problems in manually edited files immediately.
The second layer is schema validation. Factur-X and ZUGFeRD use the Cross Industry Invoice (CII) format defined by UN/CEFACT. The CII schema specifies exactly which elements are permitted, which are mandatory, what data types each field accepts, and how elements nest within each other. Schema validation compares your XML against this specification and flags anything that does not fit: a missing required element, a date in the wrong format, a currency code that does not exist in the ISO 4217 list.
The third layer is business rule validation. The European standard EN 16931 defines around 70 business rules that go beyond what the schema alone can enforce. These rules carry identifiers like BR-1, which states that every invoice must have a specification identifier, and BR-CO-15, which requires that the total VAT amount equals the sum of all individual VAT category amounts. They are implemented using Schematron, a rule-based validation language that runs logical checks across the entire document rather than field by field.
On top of these, the Factur-X specification adds profile-level rules. If you declare your invoice as EN 16931 compliant but omit line items, you will fail profile validation even if the XML structure is technically correct.
Which Profile Should You Validate Against?
Before you run a validator, you need to know which Factur-X profile your invoice is claiming to follow. The profile is declared inside the XML itself, in the GuidelineSpecifiedDocumentContextParameter element. Whatever URI appears there is what the validator will test against — so a mismatch between the declared profile and the actual content of your XML is itself a failure.
For most businesses sending invoices to other businesses in France or Germany, the right profile is EN 16931. It satisfies the European standard, works with Chorus Pro, and covers the full set of fields that client accounting systems expect. If your invoicing software generates Factur-X and you are not sure which profile it uses, open the embedded XML and look for the guideline ID. If it contains en16931, you are on the right profile.
The MINIMUM and BASIC WL profiles are intentionally stripped down. MINIMUM contains no line items and no payment details. BASIC WL adds payment information but still has no individual line positions. These profiles exist for archival and simplified document exchange use cases, not for standard B2B invoicing. If you run an EN 16931 validator against a MINIMUM invoice, it will fail. Not because the invoice is wrong, but because the validator is applying the wrong set of expectations. Always validate against the profile your XML actually declares.
How to Extract the XML from a Factur-X PDF
To validate the embedded XML, you first need to access it. The XML lives inside the PDF as an attached file always named factur-x.xml. There are several ways to reach it.
In Adobe Acrobat Reader, go to View, then Show/Hide, then Navigation Panes, and select Attachments. The factur-x.xml file appears in the panel and you can save it directly to your desktop.
For a command-line approach, pdfcpu is a free open-source tool that extracts PDF attachments in a single command and works on Windows, macOS, and Linux. If you work with Python, the pypdf library can do the same programmatically with a short script.
Some validators accept the full Factur-X PDF and handle the extraction automatically. The Facturwise validator works this way. You upload the PDF and it reads the embedded XML without any manual extraction on your side.
Common Validation Errors and How to Fix Them
A handful of errors account for the vast majority of validation failures.
Wrong profile identifier. The profile URI in the XML must exactly match the profile you intend to use. For an EN 16931 compliant invoice, the correct value is urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:en16931. For MINIMUM it is urn:factur-x.eu:1p0:minimum, for BASIC WL urn:factur-x.eu:1p0:basicwl, for BASIC urn:factur-x.eu:1p0:basic. Any typo or use of an outdated URI causes the entire document to fail at the first check and can trigger a cascade of secondary errors. Always fix this one first.
Missing mandatory fields. At the EN 16931 profile level, both the seller and buyer must have an electronic address, typically an email address with scheme ID "EM." The seller must have at least one tax identifier, usually a VAT number. For invoices to French clients, the buyer's SIREN number is also required. For German B2B invoices, the buyer's VAT ID is expected. Missing any of these triggers specific business rule failures with clear error codes.
Incorrect VAT category codes. Each line item and each entry in the tax summary needs the right category code. Standard VAT is "S." Zero-rate is "Z." Exempt is "E." Reverse charge is "AE." Intra-community supply is "K." Using the wrong code for your situation fails the Schematron rules that cross-check the category code against the stated rate, the calculated amount, and the invoice type.
Arithmetic inconsistencies. EN 16931 business rules check that the numbers add up precisely. The sum of all line totals must equal the tax basis total. Tax basis plus tax must equal the grand total. Grand total minus prepayments must equal the amount due. A rounding difference of even one cent between any of these relationships will trigger rule BR-CO-15 or BR-CO-16. Most invoicing software handles rounding correctly, but invoices built in spreadsheets or assembled by hand often get this wrong.
PDF/A-3 non-compliance. The PDF that wraps the XML must conform to the PDF/A-3b archival standard. This means all fonts must be embedded, an ICC colour profile must be present, the file cannot be encrypted, and specific XMP metadata identifying it as PDF/A must be included. General-purpose PDF editors that modify the file after it is generated can silently strip these compliance flags. If you want to test the PDF layer independently of the XML, veraPDF is a free open-source PDF/A validator that checks only the PDF/A-3 conformance without touching the invoice data — useful when a file passes XML validation but still causes import problems.
Working Through Errors Systematically
When a validator returns multiple errors, start with the profile identifier. A wrong identifier does not just fail one rule. It can cause downstream failures across the entire document because the validator is applying the wrong set of expectations. Fixing the identifier first often clears a large number of apparent errors in one go.
After that, address schema errors before business rule failures. Schema errors mean the XML structure itself is broken, which makes business rule validation unreliable on top of it.
Good validators return error messages that include the rule code and the location in the document. BR-04 means the buyer name is missing. BR-S-02 means a line item using the standard VAT category is missing the tax rate percentage. The rule code is your starting point: look it up in the EN 16931 specification or the Factur-X documentation to understand exactly what the rule requires and what value is expected.
Validate Before Your Client Does
The best time to catch a validation problem is before the invoice leaves your system. A minute spent running a check can prevent a delayed payment, a Chorus Pro rejection, or a confusing correction request from a client's finance team.
The Facturwise validator accepts complete Factur-X PDFs and extracts the embedded XML automatically. It checks all three validation layers and returns clear error messages that identify the specific rule and field involved. No account needed.
If you would rather not think about validation at all, the most reliable approach is to use software that builds and validates the XML before generating the final PDF. Facturwise produces EN 16931 compliant Factur-X invoices with all mandatory fields mapped, tax codes applied correctly, and the PDF/A-3 wrapper built automatically. Every invoice it produces passes validation out of the box.
This article is for informational purposes only. E-invoicing requirements vary by country, client type, and applicable regulations. For advice specific to your situation, consult a qualified accountant or tax advisor.