The Three Levels of Factur-X Document Compliance
XSD, Schematron and PDF/A-3
To validate a Factur-X document, three levels in particular must be verified:
- Valid XSD XML: the XML file structure complies with the expected schema
- Valid Schematron XML: the applicable business rules are respected, particularly regarding amounts, VAT and identifiers
- PDF/A-3 compliance: the document meets archival requirements and correctly contains the associated XML file
Passing these checks does not, however, mean that the entire invoicing system complies with the reform. The system must still correctly apply the business rules, the data requirements for each use case, the calculations, the invoice lifecycle, and the exchanges with Approved Platforms.
Why PDF/A-3 Remains a Critical Point
Generating a PDF and embedding an XML file inside it does not automatically produce a compliant PDF/A-3 document.
The Limitations of Standard PDF Generators
PDF/A-3 imposes specific requirements on the document itself: embedded fonts, color space management, an appropriate OutputIntent, and compliant XMP metadata.
HTML-to-PDF generation libraries do not necessarily produce a compliant PDF/A-3 document by default. Without the appropriate configuration, the document may remain a standard PDF, even if the embedded XML is perfectly structured.
An appropriate validator can then detect this non-compliance. But even when a file passes these checks, the work does not end there.
What a Factur-X Validator Actually Validates
A solution that produces valid XML but embeds it in a non-compliant PDF/A-3 does not produce a compliant Factur-X document. Conversely, a perfectly constructed PDF/A-3 does not compensate for invalid XML or incorrectly applied business rules.
Validating the Document Does Not Validate the Entire System
These checks validate the document and its structured data. On their own, they are not sufficient to validate the entire business logic and regulatory process in which the invoice will subsequently be used.
The Business Rules Most Often Overlooked
The EN16931 standard and the applicable French rules do not simply define an XML structure. They organize invoice data into Business Terms (BT) and Business Groups (BG), together with business rules, code lists, and constraints that depend on the profile and use case.
Several pieces of information therefore become interdependent:
- identification of the seller and buyer
- electronic identifiers and identification schemes when required
- nature of the transaction, goods, services, or a mixed transaction
- country of the seller and country of the customer
- seller's VAT regime, including VAT exemption schemes or VAT liability
- customer status and the possible presence of an intra-EU VAT number
- VAT category and rate applicable to lines, allowances, and charges
- associated tax statements, including reverse charge, exemption, or export
- presence of an advance payment, an overall allowance, or additional charges
- references to an invoice, contract, order, or previous invoice when required by the use case
- invoice, delivery, service, due, or payment dates depending on the context
These pieces of information are not independent fields that can simply be filled in separately. A BT may become mandatory, prohibited, or conditional depending on the value of another BT, the presence of a BG, the profile being used, or the use case being processed. Missing, incorrect, or contextually incompatible data can therefore trigger an error even when the XML structure itself is syntactically valid.
The invoicing engine must determine the applicable treatment from the seller, customer, and transaction data, then derive the required statements, VAT categories, rates, amounts, references, and corresponding XML data. This logic must remain consistent across the source data, the human-readable representation, and the structured data being transmitted.
The Nature of the Transaction Is Not Simply Goods or Services
The nature of the transaction is a good example of business data that appears simple on the surface but becomes more complex when translated into structured data. It should not be treated as a simple display choice between goods, services, or a mixed transaction.
The treatment depends on the actual invoicing context, the profile being used, the data contained in the invoice, and the applicable use case. As code lists and validation rules evolve with the specifications, these mappings should not be scattered throughout or hard-coded into the invoicing engine and user interface.
The system should retain the source business data, determine the appropriate structured values when generating the invoice, and allow these mappings to evolve when the specifications change. The same commercial transaction may therefore require different structured data depending on its invoicing context.
This information should not be confused with the tax statements displayed on the invoice. The nature of the transaction, the VAT category, the exemption reason, and the legal statements are governed by distinct rules, even when they describe the same commercial transaction.
One Business Rule Can Trigger Several Others
This is one of the main difficulties of a compliant invoicing engine: a change does not necessarily remain limited to the field that triggered it.
Adding an advance payment can modify references, amounts, VAT, the remaining balance, and the structured data of the final invoice. Adding an allowance can affect the taxable amount, VAT breakdowns, and several totals. Changing the tax regime or the customer's country can modify VAT categories, statements, and some of the required data.
The difficulty is therefore not simply knowing the BTs and BGs. It lies in maintaining all the dependencies between these data and ensuring that a regulatory or standards update does not create inconsistencies elsewhere in the invoice.
A VAT Statement Is the Result of Several Business Rules
A tax statement 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 the system must evaluate together.
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 customer's B2B status and VAT information.
- VAT exemption scheme: VAT not applicable, Article L. 223-3 of the French Code of Taxes on Goods and Services (CIBS)
- Domestic transaction subject to VAT: application of French VAT at the applicable rate
- Intra-EU B2B supply of services: reverse charge when the applicable conditions are met
- Intra-EU B2B supply of goods: VAT exemption when the applicable conditions are met
- Export of goods outside the European Union: VAT exemption when the applicable conditions are met
- Supply of services outside the European Union: treatment determined according to the applicable place-of-supply rules
- Transaction combining goods and services: common treatment only when the components can fall under the same qualification and tax treatment; otherwise, the goods and services must be distinguished and treated according to their respective rules
Only after determining this context can the system apply the corresponding VAT treatment, produce the appropriate statement, select the correct VAT category, and maintain consistency between the human-readable representation and the structured data.
A Mixed Transaction May Require Multiple Treatments
An invoice may contain both goods and services, but their presence on the same document does not necessarily mean that they are subject to the same tax treatment or require the same structured data.
In certain intra-EU B2B transactions or transactions outside the European Union, goods and services may be subject to different VAT categories, place-of-supply rules, and statements. An intra-EU supply of services may, for example, be subject to the reverse charge mechanism, while a supply of goods may qualify for VAT exemption when the corresponding conditions are met.
The engine must therefore be able to determine the treatment applicable to each relevant component, correctly break down the taxable amounts and VAT, and produce the corresponding structured data. If the software architecture can only apply a single tax treatment to the entire invoice, some mixed cases cannot be processed correctly without adapting the system.
An Advance Payment Is No Longer Just an Amount to Subtract
Advance payments are a particularly good illustration of how complex the business logic has become. It is no longer sufficient to record an amount received and subtract it from the total of the final invoice: an advance payment may give rise to its own invoice.
One Transaction, Multiple Invoices and Multiple Flows
A single commercial transaction may therefore generate several documents: an advance payment invoice when the corresponding advance payment is requested or received, followed by a final invoice that must correctly account for that advance payment.
This also means that multiple invoice flows may have to be processed. The advance payment invoice has its own structured data, amounts, VAT treatment, references, and transmission process when it falls within the scope of electronic invoicing. The final invoice then constitutes a new document, with its own data and its own flow.
Maintaining Consistency Between the Advance Invoice and the Final Invoice
The engine must therefore link the two documents without confusing them: retain the necessary references, correctly account for amounts already invoiced or paid, recalculate taxable amounts, VAT, and the remaining balance, then maintain consistency between the business data, the human-readable representation, and the structured data of each invoice.
Incorrect handling of an advance payment can therefore produce two documents that are individually valid but inconsistent with one another, cause amounts to be counted twice, produce an incorrect outstanding balance, or trigger incorrect processing during subsequent lifecycle stages.
The Impact on the Number of Flows and Their Cost
This also has an often-overlooked operational consequence: when an Approved Platform or service provider charges according to the number of invoices, flows, or transactions processed, a commercial transaction involving an advance payment may generate more exchanges than a transaction invoiced only once. The actual cost therefore depends on the platform's pricing model and on what it includes within the invoice lifecycle.
To better understand the structure of a Factur-X invoice, you can also explore the subject through an interactive experience or an animated visualization, to see how business data, the PDF, and the XML contribute to the construction of the same electronic invoice.
Consistency of Calculations Between the PDF and XML
A Factur-X invoice contains two representations of the same business reality: a human-readable representation and structured XML data that can be automatically processed by systems.
The fact that the PDF is valid and the XML passes its own checks is not sufficient if the two representations do not describe the same transaction and do not contain consistent financial results.
Invoice lines, allowances, charges, taxable amounts, VAT amounts, advance payments, totals, and the amount due must be calculated according to a single business logic, then correctly reflected in the corresponding structured data.
A Single Calculation Logic for the PDF and XML
- sum of invoice line net amounts
- allowances applied to invoice lines
- document-level allowances or reductions
- applicable charges or surcharges
- taxable amounts by VAT category and rate
- corresponding VAT amounts
- total amount excluding VAT
- total VAT amount
- total amount including VAT
- amounts already paid or credited
- amount due for payment
These values are not independent. In the structured data, several Business Terms specifically represent the different levels of invoice totals. An inconsistency between invoice lines, allowances, taxable amounts, VAT, and totals can therefore trigger a validation rule even when each value appears correct when considered individually.
An error at a single stage can therefore propagate throughout the invoice. An incorrectly applied allowance modifies the taxable amount, which modifies VAT, which modifies the total amount including VAT and potentially the amount due. An incorrectly allocated amount already paid can in turn produce an incorrect balance even though the original invoice amount is correct.
This is why the PDF and XML should not rely on two independent calculation engines. They must be produced from the same business result, in order to prevent differences in logic, rounding, or processing from creating two contradictory representations of the same invoice.
Rounding Alone Can Be Enough to Create a Discrepancy
Rounding is one of the most subtle difficulties in generating an electronic invoice. Fractions of a cent can be enough to produce different totals depending on the level and order in which calculations are performed.
This issue arises particularly with quantities or unit prices containing several decimal places, allowances, charges, multiple invoice lines, or multiple VAT categories and rates.
It is therefore not enough to obtain a final result that appears visually correct. The engine must precisely define at which level each value is calculated and rounded, then comply with the rules applicable to the different totals and breakdowns expected in the structured data.
For example, rounding a value at an intermediate stage and then reusing that value in several calculations can produce a different result from a calculation performed using unrounded values. These differences become visible when totals and subtotals are subsequently checked against one another.
A one-cent discrepancy can then propagate from an invoice line to a taxable amount, a VAT amount, the total including VAT, and the amount remaining due. If the human-readable representation uses one method and the structured data another, the two can diverge even though they originally came from the same business data.
The rounding strategy is therefore an integral part of the business logic. It must be deterministic, applied at the expected level, and shared across all representations and all dependent invoice calculations.
Compliance That Evolves Over Time
Producing a compliant Factur-X document today does not guarantee that the generator, or the system surrounding it, will remain compliant over time.
European and French specifications evolve, as do validation rules, Business Terms, Business Groups, code lists, profiles, lifecycle statuses, and supported use cases.
The French framework no longer relies solely on the invoice format itself. It notably includes the formats and profiles used for Invoice and Status messages, the APIs used to interface information systems with Approved Platforms, as well as B2B use cases.
Keeping the Engine Aligned With Evolving Specifications
The external specifications themselves have gone through several successive versions. An update may add or clarify a rule, modify a validation check, extend a use case, or change the data expected in certain exchanges.
Compliance is therefore not simply a matter of producing valid XML once. It requires maintaining the invoicing engine, its business rules, mappings, validations, and interfaces in line with the evolution of the framework.
These developments form part of the broader electronic invoicing reform , whose obligations extend far beyond the generation of a structured document.
A Technical Combination for Producing the Document
PDF/A-3 compliance requires a generation chain capable of producing the expected hybrid document while maintaining consistency with the embedded XML data.
Combining PDF Generation With Structured XML Data
In the architecture presented here, mPDF is used to generate the PDF document with the parameters required for archival, while the Python factur-x library is then used to associate the structured XML data with the document in order to produce the Factur-X file.
The resulting document can then be submitted to XSD, Schematron, and PDF/A-3 validation checks.
This chain addresses document compliance. However, on its own, it is not sufficient to make the entire electronic invoicing system compliant.
The Engine Does Not Stop at Factur-X Generation
Once the invoice has been generated and validated, another part of the business logic begins: determining which framework applies to the transaction, what data must be transmitted, through which intermediary, and which subsequent stages must be tracked.
Determining the Regulatory Path for Each Transaction
Not all transactions follow the same path. Depending on the customer, their place of establishment, the nature of the transaction, and its tax treatment, the system may fall within the scope of electronic invoicing, transaction e-reporting and, in certain cases, payment e-reporting.
- domestic B2B transaction within the scope of the reform: electronic invoice transmitted through an Approved Platform
- transaction with a private individual: document sent to the customer through the applicable channel, while transaction data falls within the scope of e-reporting
- transaction with a business established outside France: not necessarily subject to French e-invoicing, but the transaction may fall within the scope of transaction e-reporting
- transaction subject to payment e-reporting: transmission of payment collection data according to the applicable rules
A company can retain its own invoice generation engine and interface it with an Approved Platform. However, producing Factur-X locally does not eliminate either the platform or the regulatory exchanges when they are applicable.
Transmission Itself Becomes Business Logic
Integration with an Approved Platform does not necessarily consist of making a single API call to send a file.
The system must determine the recipient and their addressing information, transmit the expected data, interpret the platform's responses, handle errors, and maintain a consistent state between its own system and the exchanges performed.
The invoice lifecycle must also be taken into account. Standardized formats cover not only invoice messages, but also the status messages associated with their processing.
An action that appears local within a software application can therefore have consequences beyond its interface. A change in an invoice's status may require the system to determine whether information must be retained locally, transmitted to the platform, or used to produce additional regulatory data.
Payment Can Itself Produce Data That Must Be Transmitted
A software application's "paid" status should not be treated as simple display information. When a transaction is subject to payment e-reporting, the payment received becomes regulatory data, including a payment date and amount received, with a breakdown by VAT rate where applicable.
When a transaction has resulted in an electronic invoice, this information can supplement its lifecycle through the "payment received" status. In other applicable cases, payment data follows the dedicated e-reporting process.
The engine must therefore distinguish between the internal business status, the invoice status, the actual receipt of payment, and any obligation to transmit that information. A simple "paid" button can therefore trigger different logic depending on the type of transaction and its VAT regime.
An Approved Platform Does Not Eliminate the Software's Business Logic
The Approved Platform performs the regulatory functions assigned to it: issuing, transmitting, and receiving electronic invoices, extracting certain invoice data, and transmitting transaction and payment data to the tax administration.
However, it does not relieve the upstream software from producing and transmitting consistent business information. A calculation error, incorrect VAT treatment, an incorrect reference, an improperly allocated advance payment, or inconsistencies between the human-readable representation and the structured data remain issues that must be handled within the invoicing chain.
Compliance therefore becomes a responsibility distributed across the business engine, document generation, structured data, platform integration, and lifecycle management.
The Approved Platform Should Not Become the Core of the Business Engine
Separating the business engine from the transmission layer remains an important architectural principle. Source data, calculations, tax rules, document generation, and internal traceability should not depend on the specific operation of a particular platform.
However, the Approved Platform goes well beyond being a simple channel for uploading a file. It participates in regulatory exchanges, the transmission of invoices and required data, the processing of lifecycle statuses and, depending on the transactions concerned, exchanges related to transaction or payment e-reporting.
Decoupling the Business Engine From Platform Integration
When an API is used, the integration must therefore handle more than simply sending a Factur-X file. It must notably transmit the required data, interpret responses and statuses, handle errors, prevent duplicates, and maintain consistency between the state known by the software and the exchanges performed with the platform.
A decoupled architecture helps limit dependency on a particular Approved Platform. Changing platforms should not require rebuilding the calculation or tax engine, although the integration layer may still require adaptations depending on the APIs, services offered, and technical methods used by the new provider.
The Impact on Existing Software
Adapting existing software to Factur-X can sometimes be achieved without a complete rewrite. Adapting an invoicing system to the full range of obligations introduced by the reform is a much broader issue.
When business data is already properly structured, an XML generation layer and a PDF/A-3 production chain can be added to the existing system. However, this approach quickly reaches its limits when the software does not contain the data, statuses, or rules required for the new processes.
When Adding Factur-X Is No Longer Enough
The business system itself may then need to evolve: new data, new Business Terms and Business Groups, new references, advance payment invoice management, additional calculations, lifecycle statuses, payment collection data, routing rules, error handling, and synchronization with an Approved Platform.
A seemingly limited change can therefore propagate across several parts of the software. Adding an advance payment invoice is not simply a matter of creating a new document template: the system must determine its treatment, calculations, references, relationship with the final invoice, transmission process, and the states in which it should or should not be involved.
This adaptation is easier when the system's data and different functions are already separated and accessible through APIs or other exchange interfaces. However, this does not eliminate the need to evolve the business logic itself when the rules change.
Maintaining the Entire Compliance Chain Over Time
The issue is therefore no longer simply maintaining a Factur-X generator. The entire chain must be maintained over time: business data, calculations, tax rules, XML mappings, validations, use cases, statuses, platform integration, and regulatory exchanges.
An invoice that passes XSD, Schematron, and PDF/A-3 validation today may be perfectly compliant as a document without demonstrating that the software which produced it correctly covers the entire framework.
From September 1, 2026, all businesses established in France and subject to VAT must be able to receive electronic invoices. The electronic invoicing and e-reporting issuance obligations apply from the same date to large companies and mid-sized companies, then from September 1, 2027 to SMEs and micro-enterprises.
Before choosing an Approved Platform, it can therefore be useful to examine exactly what its offer covers: pricing, how invoices and flows are counted, API access, supported statuses, e-reporting management, integration requirements, technical limitations, and any additional costs. The service provider assessment can be used to review these elements and the answers provided by the platform before making a commitment.
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.