FREE TOOLS
Quote Generator Factur-X Generator SEO Analyzer Dependency Security Checker PDF Comparator PDF / XML ComparatorFREE TOOLS
Quote Generator Factur-X Generator SEO Analyzer Dependency Security Checker PDF Comparator PDF / XML ComparatorTechnical note on Factur-X EN16931 compliance, PDF/A-3, XSD and Schematron, and the most common errors in e-invoicing solutions.
The e-invoicing reform sets strict deadlines. Many solutions claim to be Factur-X compliant. Few actually are.
Factur-X compliance is not just about embedding an XML file inside a PDF.
It relies on three distinct, independent, and all mandatory levels.
The technical process behind producing a compliant Factur-X document is explained in Factur-X Integration .
A Factur-X invoice is considered compliant only if it simultaneously satisfies these three requirements:
Most solutions only validate one or two of these levels. PDF/A-3 is consistently the most problematic part.
Generating a PDF and embedding an XML file into it does not produce a compliant PDF/A-3 document.
PDF/A-3 enforces strict constraints on the document itself: fully embedded fonts, declared color spaces, ICC OutputIntent present, compliant XMP metadata.
Most HTML-to-PDF generation libraries do not produce valid PDF/A by default. Without explicit configuration — declared color space and associated ICC OutputIntent — the resulting document remains a standard PDF and is invalid under the archival standard, even if the embedded XML is fully structured.
The Factur-X validator detects this immediately. The invoice is rejected.
The reference Factur-X validator performs three distinct passes:
A solution that passes XSD and Schematron but fails on PDF/A-3 is not Factur-X compliant. It produces a correct XML inside a non-archivable PDF.
French Schematron rules require fields and information beyond the basic EN16931 XML structure. Several points regularly appear in rejected invoices.
These items are not independent fields that can simply be filled in separately. They must be present, correctly structured and consistent with one another. Missing, incorrect or contextually incompatible information may cause validation to fail, even when the XML structure itself is correct.
The invoicing engine must therefore determine the applicable treatment from the seller, buyer and transaction data, then derive the legal wording, VAT categories, rates, amounts and corresponding XML data. This logic must remain consistent across the source data, the PDF shown to the customer and the transmitted Factur-X file.
The nature of a transaction is a good example of business data that may appear simple at first but becomes more complex in structured data. It must not be treated as a simple display choice between goods, services or a mixed transaction.
The code transmitted in the XML depends on the invoicing context, including the actual nature of the transaction, the possible existence of a previously paid advance payment, as well as national rules and the invoice profile used. As code lists and validation rules may evolve, they should not be hard-coded into the engine or exposed as a fixed choice in a user interface.
The system must retain the source business data, determine the appropriate code when the invoice is generated and allow this mapping to be updated following a regulatory change. The same transaction may therefore require different structured data depending on its invoicing context.
This information should not be confused with the tax mentions displayed on the invoice either. The nature of the transaction and its coding within the structured data follow a business logic that is distinct from VAT-related legal mentions such as reverse charge, VAT exemption or export-related mentions.
Early payment discounts and late payment penalties follow the same logic: they are rarely hard-coded in existing generators because they are not part of traditional accounting requirements. However, EN16931 expects them by default, whether or not they apply to the actual invoice scenario.
The VAT-related legal mention follows the same missing-default logic: many generators only display it when the VAT rate is zero, while overlooking that a different legal statement (reverse charge, exemption, or export) remains mandatory as soon as a specific tax regime applies, even when VAT is non-zero.
A tax mention displayed on an invoice may appear to be a simple value to select. In reality, it is often the result of several pieces of business information that must be evaluated together by the system.
To determine the applicable VAT treatment, the engine must notably know the seller's VAT regime, the seller's country, the customer's country, whether the customer is located in France, within the European Union or outside the EU, the nature of the transaction and, depending on the context, the B2B status and the customer's VAT information.
Only after this context has been determined can the system apply the appropriate VAT treatment, produce the relevant legal mention, select the correct VAT category and maintain consistency between the PDF and the structured data.
An invoice may include both goods and services when they are subject to the same VAT treatment, for example in a French transaction subject to French VAT, or for an EU customer without a VAT identification number where French VAT applies.
However, in an intra-EU B2B transaction or a transaction outside the European Union, goods and services may be subject to different VAT categories and legal wording. An intra-EU supply of services may, for example, be subject to reverse charge, while a supply of goods may be VAT-exempt.
A generator that can apply only one overall VAT treatment to an invoice must therefore not accept a mixed transaction in these situations. The transactions must be split into separate invoices, one for each type of transaction, unless the engine can identify each line, assign its own VAT treatment and generate the corresponding XML data consistently.
This is an essential characteristic of an invoicing engine: information does not exist independently from the rest of the invoice. A value entered in one place can modify several elements calculated or generated elsewhere.
The customer's country can change the VAT treatment and the applicable legal mentions. The nature of the transaction can influence both the tax treatment and the structured data. The existence of a previous advance payment can modify the amounts, the remaining amount due and certain codes associated with the invoicing process. A discount can, in turn, modify taxable bases, VAT amounts and totals.
The difficulty is therefore not to present the user with a succession of dropdown lists corresponding to the expected fields. It is to automatically determine the values that can be derived from the actual business context, then correctly propagate their consequences throughout the entire document.
In other words, an electronic invoice is not a collection of mandatory fields completed independently. It is a set of interdependent business rules that must remain consistent across source data, calculations, tax mentions, the PDF and the XML.
To better understand the structure of a Factur-X invoice, you can also explore the topic in two different ways, through an interactive experience or an animated visualization, to see how business data, the PDF, and the XML contribute to building a single electronic invoice.
A Factur-X invoice contains two representations of the same business reality: the human-readable PDF and the structured XML used by information systems.
Having a valid PDF and an XML file that passes its own validation checks is not enough if both representations do not carry exactly the same financial results.
Invoice lines, discounts, taxable amounts, VAT amounts, advance payments, total excluding VAT, total including VAT and the amount due must be calculated according to a single logic and then represented consistently in both formats.
An error at a single step can propagate throughout the entire invoice. An incorrectly applied discount changes the taxable amount, which changes the VAT amount, which changes the total including VAT and potentially the remaining amount due.
This is why the PDF and XML should not be calculated independently. They should both be generated from the same business result, preventing differences in calculation logic, rounding or processing from creating two different representations of the same invoice.
Rounding is one of the most subtle difficulties in electronic invoice generation. Fractions of a cent can be enough to produce different totals depending on the order in which calculations are performed.
The issue appears in particular with quantities or unit prices containing several decimal places, discounts, multiple invoice lines or multiple VAT categories.
Obtaining a visually correct final result is therefore not enough. The engine must define precisely when each value is rounded and apply the same strategy throughout all calculations that depend on it.
For example, rounding each VAT amount at line level and then adding the results may produce a different value from adding the taxable amounts first and then calculating VAT on the total.
A one-cent difference can then propagate through the taxable amount, VAT amount, total including VAT and remaining amount due. If the PDF uses one method and the XML another, both representations may contain different values even though they originated from the same source data.
The rounding strategy is therefore an integral part of the business logic. It must be deterministic, applied at the appropriate level and shared across all representations of the invoice.
Contrary to a common misconception, generating a compliant Factur-X document once does not guarantee that the generator will remain compliant over time. The EN16931 specifications, the French Schematron rules and the associated Business Terms evolve regularly.
New validation checks may be introduced as validators are updated. Information that was previously tolerated, such as certain Business Terms or the nature of the transaction, can progressively become mandatory during XML validation.
Compliance is therefore not simply about generating a valid XML file once, but about keeping the generator aligned with evolving European and French specifications.
These changes are part of the broader Electronic Invoicing Reform , which gradually introduces new technical and regulatory requirements for electronic invoices.
PDF/A-3 compliance requires a PDF generation library capable of natively producing an archivable document.
mPDF generates clean PDF/A-1b output, with an integrated ICC OutputIntent, embedded fonts and compliant XMP metadata. The Python factur-x library then injects the EN16931 XML and converts the document to PDF/A-3.
The result passes all three validation levels: XSD, Schematron, PDF/A-3.
This remains true only if the business data embedded in the XML also complies with the latest French validation rules.
Once the invoice has been generated and validated, another layer of business logic comes into play: determining how it should be transmitted.
Not every invoice necessarily follows the same path. The system must notably take into account the customer's status, whether an Accredited Platform is configured and the transmission channel chosen by the company.
In an automated architecture, this decision can be made directly by the engine based on the business context already available.
Invoice generation therefore remains independent from the transmission provider. The engine first produces a compliant invoice based on its own business rules, then determines the appropriate output channel according to the context.
This separation avoids building the invoicing system around a specific platform. Business data, calculations, the PDF, the XML and traceability remain managed by the internal system.
The Accredited Platform then acts as the regulatory exchange channel. When an API is available, the engine can automatically transmit the invoice to the platform as part of the sending process. When the company prefers a manual workflow, the same Factur-X invoice can be retrieved and uploaded directly to the platform.
The architecture therefore remains adaptable: changing Accredited Platforms does not require rebuilding the entire invoicing engine, but mainly adapting the integration layer used for transmission.
An existing invoicing solution can be made Factur-X compliant without a full rewrite.
The XML engine adapts to the existing data structure. The PDF/A-3 injection is added at the output of the current PDF generator.
This integration is also simplified when business data is already exchanged through API Integration or other structured interfaces.
The existing business system does not need to be redesigned. However, the Factur-X generator must evolve alongside new validation rules to ensure long-term compliance.
What changes: the produced document is now valid, archivable, and interoperable with e-invoicing platforms.
The September 2026 deadline for B2B e-invoice reception leaves no room for partial solutions.
This approach is implemented through the Factur-X Integration service, which adds compliant Factur-X generation to existing invoicing solutions without requiring a complete system redesign.
To place electronic invoicing in a broader context, Palks Studio also publishes an investigation into the links between electronic invoicing, transaction data, the Digital Product Passport, digital identity and payments.