iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Validate a Factur-X or ZUGFeRD invoice in layers: check the PDF/A-3 container, validate the embedded or standalone CII XML against the exact profile XSD, then run the matching EN 16931, profile and—when required—national Schematron rules. Finally, review the invoice’s business meaning and test the recipient’s intake process. XSD alone proves that XML is structurally well formed; it does not prove that totals, VAT treatment, profile restrictions or routing requirements are acceptable.
This workflow applies because Factur-X and ZUGFeRD are two names for the same hybrid format: a human-readable PDF/A-3 file containing machine-readable XML. The profile identifier, release package and rule versions must travel together through validation and audit.
What are Factur-X and ZUGFeRD invoices?
Factur-X and ZUGFeRD are technically identical names for a hybrid electronic invoice maintained jointly by FeRD and FNFE-MPE. The PDF is the visual component, while an embedded UN/CEFACT Cross Industry Invoice (CII) XML file carries structured data for automated processing. A submission can therefore look correct to a person while still failing an XML or business-rule check.
The usual container is PDF/A-3, which permits the XML attachment to be embedded in the archival PDF. Some systems exchange CII XML without a PDF; that is a standalone XML input and does not require a PDF/A-3 check, although the same profile and business rules still apply. Treat the container and the XML as separate artefacts during diagnostics.
#1 Best Overall
Why is XSD validation not enough?
XSD and Schematron answer different questions. XSD validates the XML vocabulary and structure; Schematron evaluates assertions about relationships and business meaning. A PDF submission adds a third technical layer, and recipient platforms may impose operational controls that no standards validator can see.
| Layer | What it checks | Typical failures it finds | What it cannot establish |
|---|---|---|---|
| PDF/A-3 and container | Conformance of the visual file and embedded attachment; commonly checked against ISO 19005-3 level B. | Invalid PDF/A metadata, broken attachment relationships or a container that is not a conforming PDF/A-3 file. | Whether XML amounts and VAT calculations are correct. |
| Profile-specific XSD | Namespaces, element order, datatypes, required fields and cardinality in the selected CII profile. | Malformed dates, invalid decimals, missing mandatory nodes and elements in the wrong location. | Cross-field business rules, recipient routing or commercial truth. |
| EN 16931 Schematron | European core-invoice assertions and relationships between amounts, tax categories, dates and identifiers. | Inconsistent totals, missing data required by a calculation rule or an invalid tax relationship. | Whether the recipient’s directory or workflow will accept the file. |
| Profile FX-SCH rules | Restrictions and conditions specific to MINIMUM, BASIC WL, BASIC, EN 16931 or EXTENDED. | Fields forbidden, required or constrained by the declared profile. | Whether a different profile would better describe the transaction. |
| National or CIUS Schematron | Additional rules required by a country, sector or recipient, such as French BR-FR when applicable. | National code-list, tax or identifier violations. | Requirements that were never supplied to the validator. |
| Operational acceptance | Directory, endpoint, routing, authentication and lifecycle checks performed by the recipient platform. | Unknown supplier identifier, wrong endpoint, duplicate invoice or an out-of-sequence credit note. | Proof that the document is substantively accurate. |
A standards pass is therefore necessary but not universal acceptance. The person responsible for the invoice must still confirm that the totals, VAT category and rate, payment data, identifiers and profile reflect the underlying transaction.
Which profile and release should I use?
Start with the guideline or profile identifier in the CII XML, then select the matching FeRD/FNFE-MPE release package. Do not mix an XSD from one release with Schematron or code lists from another; keep the package version, profile, schemas, transformations, code lists and rule revisions as one controlled set.
| Profile | Purpose in the validation decision | Required artefacts |
|---|---|---|
| MINIMUM | Smallest supported data set for a basic electronic invoice. | The MINIMUM profile XSD and its corresponding FX-SCH rules. |
| BASIC WL | Basic profile with a limited set of line information. | The BASIC WL profile XSD and matching Schematron files. |
| BASIC | Broader basic invoice data than BASIC WL. | The BASIC profile XSD and matching Schematron files. |
| EN 16931 | Profile aligned to the European core invoice model. | The EN 16931 profile XSD, EN 16931 Schematron and profile rules. |
| EXTENDED | Additional data beyond the core profiles where the transaction and recipient support it. | The EXTENDED profile XSD and its FX-SCH rules, plus any applicable national rules. |
FeRD states that all five profiles have their own XSD and Schematron validation artefacts, updated in accordance with EN 16931. A national or reference profile may add another rule layer; apply it only when the transaction, jurisdiction and recipient require it.
The FeRD 2.5 information package, dated 10 June 2026, is based on UN/CEFACT CII D22B and is backward compatible with D16B. FeRD says version 2.5 should be used from 1 July 2026. The package contains separate schema and XSLT files, code lists and sample invoices, so record the exact package release rather than only writing “Factur-X” or “ZUGFeRD” in a log.
How do I validate a Factur-X or ZUGFeRD invoice step by step?
Run the checks in a fixed order and preserve every result. This separates a malformed document from a business-rule failure and makes a later dispute reproducible.
Rank #2
- FOR LANDLORDS and MORE: Adams Money/Rent Receipt books let you offer receipts for rent payments, in-home day care, craft fair sales and other cash transactions
- 200 TWO-PART CARBONLESS RECEIPTS: Get 4 perforated customer receipts per page; the yellow copy stays behind in your book
- SPIRAL-BOUND EFFICIENCY: A neat spiral keeps your duplicates in numerical order for a permanent record of transactions
- CONSECUTIVELY NUMBERED: Large 6-digit numbers in the upper right hand corner help you thumb through orders quickly, Consecutively numbered makes tracking easy
- 200 SETS PER BOOK: Stock up so you never run out; books provide 200 sequentially numbered carbonless sets
- Identify the artefact set. Read the guideline or profile identifier from the CII XML. Select the matching release package, including its CII version, profile XSD, FX-SCH rules, code lists and any required national CIUS rules. Store those files under version control with their hashes.
- Extract and inspect the container. For a hybrid invoice, extract the embedded XML from the PDF/A-3 attachment without editing its bytes. Validate the PDF/A-3 container separately. For standalone XML, begin at the XML layer and document that no PDF container was supplied.
- Run the profile-specific XSD. Apply the XSD that belongs to the declared profile and release. Record namespace, datatype, cardinality and structural errors separately. Fix the first structural errors before interpreting later messages, because one missing parent can produce many misleading child errors.
- Run EN 16931 Schematron. Apply the CEN EN 16931 rule set required by the profile. Schematron evaluates assertions that an XSD cannot express, such as consistency between taxable amounts, tax totals, line extensions and document totals.
- Run profile and national rules. Apply the profile’s FX-SCH files and, only when relevant, national or CIUS rules such as French BR-FR. Keep the rule-set revision in the report. A national rule file is not interchangeable with a core EN 16931 file.
- Review warnings and cross-layer consistency. FeRD warns that optional fields should be omitted rather than serialized empty. An empty element can trigger CII rule R74, which states that a document must not contain empty elements. Check that the XML shown in the PDF is the same XML that passed validation and that the visual totals agree with the machine-readable totals.
- Check business meaning and recipient acceptance. Confirm the profile choice, seller and buyer identifiers, invoice and payment data, totals, VAT categories and rates against the transaction. Then submit a controlled test to the intended recipient or platform; standards conformance does not guarantee routing, directory or lifecycle acceptance.
- Archive evidence. Retain the input hash, extracted XML, profile identifier, release artefact hashes, validator version, XSD and Schematron revisions, code-list versions and the complete SVRL or equivalent report. Include severity, rule ID and source location for every finding.
How should I read and triage validation results?
Classify each message by layer and severity before changing the invoice. A fatal XML error prevents meaningful downstream checks; a warning may still be important if a recipient treats it as a rejection condition.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors| Message pattern | Likely cause | Corrective action |
|---|---|---|
| Namespace, datatype or unexpected-element error | Wrong CII namespace, malformed value or an element placed outside the profile structure. | Use the profile XSD from the same release as the XML generator, then correct the first reported structural error. |
| Missing required element | The selected profile requires data that the generator omitted. | Populate the field when the transaction supplies it, or select a profile that genuinely permits its absence. |
| R74 or another empty-element finding | The serializer emitted an opening and closing tag with no value. | Change generation logic to omit optional empty nodes; do not send empty placeholders. |
| EN 16931 amount or VAT assertion | Line, taxable, tax or grand totals do not satisfy the rule relationship, or the tax category/rate is inconsistent. | Recalculate from source transaction data and inspect rounding, exemptions, reverse-charge treatment and sign conventions. |
| Code-list mismatch | A value is valid in one release, country or profile but not in the rule set being run. | Confirm the jurisdiction and release, then update the code list or the value; do not suppress the assertion without a documented rule decision. |
| All technical checks pass but recipient rejects | Directory, endpoint, authentication, duplicate, lifecycle or recipient-specific CIUS control. | Obtain the recipient’s intake specification and test the transport and business workflow separately from document conformance. |
| PDF fails while XML passes | The visual container or attachment metadata is not valid PDF/A-3. | Repair the PDF generation process and rerun the container validator; do not assume a valid XML makes the PDF acceptable. |
What tools and rule layers appear in a conformity implementation?
A published Factur-X API conformity report documents a layered implementation rather than a single “validator.” Its stack checks PDF/A-3 with veraPDF against ISO 19005-3 level B, XML structure with Mustangproject 2.26.0, the EN 16931 CEN Schematron 1.3.16, profile FX-SCH rules and French BR-FR rules where applicable. These versions describe that report’s reproducible setup; they are not permission to mix arbitrary versions in production.
The report records 10,210 assertions for veraPDF/ISO 19005-3 in 2026 and 17 files in the Factur-X API conformity corpus in 2026. Its published corpus covers French standard VAT, French VAT-franchise and intra-EU reverse-charge cases. It reports zero business-rule errors in that corpus, but also documents a French EXTENDED-CTC-FR code-list mismatch and an empty mandatory CII delivery-element warning. Those observations are useful diagnostic examples, not a guarantee that another validator, release or recipient will produce identical results.
How do I choose an implementation for PDF and XML inputs?
Choose the pipeline based on the artefact you receive and the rule scope your recipients require. The same business-rule stages apply to both forms, but only the hybrid form has a PDF/A-3 container to verify.
| Decision axis | PDF/A-3 with embedded CII | Standalone CII XML |
|---|---|---|
| Input handling | Extract the attachment, retain the original PDF and validate the container. | Validate the XML directly and record that no PDF was supplied. |
| Structural validation | Run the profile-specific CII XSD on the extracted XML. | Run the profile-specific CII XSD on the supplied file. |
| Business rules | Run EN 16931, profile FX-SCH and applicable national rules. | Run the same rule layers for the declared profile. |
| Visual consistency | Compare displayed totals, dates and identifiers with the XML values. | There is no visual representation to compare; rely on source-system controls or generate a controlled rendering. |
| Operational acceptance | Check attachment naming, recipient handling and PDF lifecycle controls in addition to transport. | Check the recipient’s XML endpoint, directory and lifecycle requirements. |
In either case, keep release pinning and diagnostics independent of the software vendor. A validator is defensible when another operator can rerun it with the same input hash, artefact hashes, versions and rule outputs.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How can a team make validation reproducible?
Put the profile and release decision in the invoice-generation contract, not in an operator’s memory. Build a small conformance manifest alongside each invoice containing the profile identifier, CII version, package release, code-list revision, validator versions and rule-set revisions.
- Fail the build on profile XSD errors and on Schematron violations classified as errors by the applicable rule set.
- Keep warnings visible; a recipient may promote a warning to a rejection even when the standards report does not.
- Store SVRL or equivalent output with source locations so a developer can find the exact XML node.
- Include representative cases for standard VAT, VAT exemption or franchise and intra-EU reverse charge when those transactions are in scope.
- Retest after changing the serializer, PDF generator, profile, code list or rule package; a visually unchanged invoice can produce different XML diagnostics.
What counts as a defensible validation pass?
A defensible pass has a valid PDF/A-3 container when one is supplied, a clean profile-specific XSD result, successful EN 16931 and applicable profile or national Schematron checks, and a documented review of business meaning. It also records the exact artefacts and versions used and has been exercised against the recipient’s actual intake path. Anything less may still be useful for development, but it is not evidence that the invoice will be accepted end to end.
Frequently Asked Questions
Can I validate an invoice generated under an older CII version with the current package?
Only after confirming the package’s compatibility statement and profile rules. FeRD’s 2.5 package is based on CII D22B and is backward compatible with D16B, but compatibility does not remove the need to run the profile’s own XSD, Schematron and code lists together.
When should a French BR-FR rule set be added?
Use it when the transaction and recipient fall under the French national or CIUS requirements that the rule set represents. Adding national rules to an unrelated transaction can create failures that are irrelevant, while omitting required national rules can leave a document unacceptable despite passing the European core rules.
Free tools Windows power users keep installed
One-click scans. No signup required.
What is the practical value of keeping an SVRL report?
SVRL preserves each Schematron assertion, severity and source location in a machine-readable form. Keeping it with the input and artefact hashes lets an auditor or developer reproduce why a particular invoice passed or failed without relying on a screenshot or a transient web validator.
Why can the PDF and XML appear to disagree after extraction?
The PDF is a presentation layer and the XML is the processing layer; they can diverge if a generator updates one without regenerating the other. Treat any mismatch as a production defect, regenerate both from the same transaction data and rerun container, XSD and Schematron checks.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
