AIFE Finally Publishes a Schematron for Flux 10 (E-Reporting)

Summary

A long-awaited tool is here. The AIFE has released a first version of the Schematron dedicated to Flux 10 (e-reporting) to Approved Platforms (Plateformes Agréées). After months of requests from the market — and repeated refusals — this validation tool finally gives stakeholders an official reference to secure their developments. [aife.econo…ie.gouv.fr], [fnfe-mpe.org]
Why it matters. A Schematron automatically checks that an e-reporting message complies with the expected specifications — mandatory data, consistency, Flux 10 validation rules, and the syntactic/semantic constraints set by the AIFE. Without it, players had very limited visibility and no guarantee that their flows would be accepted by the administration. [generixgroup.com], [fnfe-mpe.org]
The final stretch before 1 September 2026. Coverage will not yet be complete for all in-scope companies at go-live, but the DGFiP has confirmed a pragmatic, supportive approach during the ramp-up: sanctions will not apply automatically, and business continuity takes priority over technical perfection. [bworkshop.fr], [comptaverse.fr]

A welcome surprise from the holidays

Returning from a break — and having missed the latest AIFE, DGFiP and FNFE-MPE progress meetings — many of us were genuinely surprised (pleasantly) to see the AIFE email announcing that a first version of the Schematron for Flux 10 (e-reporting) had been made available to Approved Platforms. For months, numerous stakeholders had asked for exactly this, and the AIFE had, somewhat inexplicably, kept saying no.

That refusal raised real questions: how were operators supposed to secure their developments and be confident that the e-reportings sent to the administration would actually be accepted? The e-reporting stream — Flux 10 — covers the transactions that fall outside domestic B2B e-invoicing: B2C sales, international transactions, and payment data, structured across sub-flows 10.1 to 10.4. [iopole.com], [comptaverse.fr]

What a Schematron actually does

For those less familiar with the plumbing of the reform, a Schematron is a rules-based validation tool that automatically checks whether an XML message respects the expected specifications — precisely the kind of complex, contextual business rules the reform relies on. In the e-reporting context it verifies, among other things: [generixgroup.com]

the presence of mandatory data;
the consistency of the information transmitted;
compliance with the Flux 10 validation rules;
the syntactic and semantic constraints defined by the AIFE.

This is the same logic already applied to the invoicing flows: the FNFE-MPE has been publishing Schematrons for the EN16931 and EXTENDED-CTC-FR profiles and the additional French BR-FR-CTC business rules (now at version 1.4.0, published 30 June 2026), with components made available to developers on GitHub. Extending that approach to Flux 10 closes an obvious and long-standing gap. [fnfe-mpe.org]

Why the gap was a problem

Without a Schematron for e-reporting, operators were effectively building in the dark — with(very) limited visibility and no genuine assurance that the flows sent to the State would be accepted. Given that the Portail Public de Facturation (PPF) was recentred in October 2024 to act as directory and e-reporting concentrator, the absence of an official validation reference for the very flows the PPF concentrates was a conspicuous weak point in the reform’s tooling. [comparatif…ronique.fr]

Why this publication matters

This release is an important milestone. It finally allows all stakeholders to:

rely on an official validation reference;
strengthen the reliability of developments and tests;
reduce technical rejections;
prepare the e-reporting rollout under far better conditions.

Late, but landing in a pragmatic environment

It arrives late, and it is clear that on 1 September 2026 e-reporting coverage will not yet be complete for every in-scope business. That said, the DGFiP has already signalled a pragmatic, accompanying stance for the start-up phase: this is not a postponement, but sanctions will not be applied automatically, technical difficulties and genuine compliance efforts will be taken into account, and business continuity prevails — companies can keep invoicing (PDF, email) during incidents and regularise via their Approved Platform afterwards. Conformance testing remains essential to secure projects before go-live. [bworkshop.fr], [comptaverse.fr]

For the record, the calendar is unchanged: reception of e-invoices becomes mandatory for all companies on 1 September 2026; emission and e-reporting obligations begin on the same date for large enterprises and ETIs, and on 1 September 2027 for SMEs and micro-enterprises. [entreprend…ic.gouv.fr], [comptaverse.fr]

The final straight

We are now entering the final stretch of the first phase of this reform. Good luck to everyone contributing to its success — businesses, Approved Platforms, compatible solutions, administrations, experts and integrators alike. And for those lucky enough to be taking one: enjoy the break! 🏖️

External links

Mandatory Data Fields

The “mandatory data” checked by the new Flux 10 Schematron are the fields the AIFE requires in each e-reporting transmission. These vary by block (10.1 to 10.4) and by whether you are reporting a transaction or a payment. Here is the structured picture.

1. How Flux 10 is organised

Flux 10 is the regulatory format dedicated to e-reporting, structured into four blocks, each covering a distinct type of data: [iopole.com]

Block 10.1 — International B2B invoices → nominative logic (one occurrence = one invoice). [iopole.com]
Block 10.2 — International payment receipts → one occurrence = one receipt, mandatorily linked to an invoice in block 10.1, when VAT is due on collection. [iopole.com]
Block 10.3 — B2C transactions → aggregated logic (one occurrence = one day + one currency + one transaction type; individual receipts are not transmitted). [iopole.com]
Block 10.4 — B2C payment receipts → aggregated by day and payment type. [iopole.com]

A key structural rule the Schematron enforces: transaction ≠ payment. A sale recorded on 28 March but collected on 3 April generates two separate transmissions, potentially in different periods. [iopole.com]

2. Mandatory data — transaction data (B2B international, block 10.1)

For international B2B transactions, the reporting is at invoice level, and the FNFE-MPE confirms it requires the same mandatory data as a domestic invoice — but with an important difference between sales and purchases: [fnfe-mpe.org]

B2B international sales: invoice-level data, with invoice lines mandatory. [fnfe-mpe.org]
B2B international purchases: invoice-level data, with invoice lines not mandatory. [fnfe-mpe.org]

At field level, block 10.1 requires party identification, amounts excluding and including VAT, currency, and specific fiscal mentions such as reverse charge or exemption. More broadly, the data transmitted includes the amount HT, VAT due, country, and the partner’s tax identifier. [iopole.com] [comparatif…ronique.fr]

3. Mandatory data — transaction data (B2C, block 10.3)

For B2C, no individual receipt is sent. Instead, the mandatory content is aggregated daily revenue data per day, per currency and per transaction type, by SIREN. One notable simplification: the number of transactions per day is not mandatory (“e-reporting blanc” / nil returns are also not required). [fnfe-mpe.org], [iopole.com] [fnfe-mpe.org], [frenchinvoice.fr]

4. Mandatory data — payment data (blocks 10.2 and 10.4)

Payment reporting applies only where VAT is due on collection (services under the “TVA sur les encaissements” regime, or any advance payment/acompte regardless of regime). It is excluded for reverse-charge cases and for suppliers who have opted for VAT on debits. [fnfe-mpe.org], [cleartax.com]

Block 10.2 (international): payment declared at invoice level, each receipt linked to a block 10.1 invoice. [fnfe-mpe.org], [iopole.com]
Block 10.4 (B2C): aggregated payment declaration by day and payment type, including the amount and date of collection. [fnfe-mpe.org], [comparatif…ronique.fr]

5. What the Schematron actually validates

Beyond simply listing the fields, the Schematron enforces the four categories mentioned in the AIFE announcement against these blocks: the presence of mandatory data (e.g. amounts, VAT, party identifiers), the consistency of the information, the Flux 10 validation rules (block structure, nominative vs aggregated logic, mandatory linkage of 10.2 to 10.1), and the syntactic/semantic constraints of the AIFE’s proprietary XML format. [iopole.com], [fnfe-mpe.org]

⚠️ Important caveat: The precise, field-by-field mandatory list is defined in the AIFE External Specifications (flows 8, 9, 10.1–10.4) and their business rules — the authoritative reference that the Schematron implements. For your development/testing, the binding version is the one published on impots.gouv.fr, not third-party summaries. [impots.gouv.fr], [avocats.ey.com]