France E-Invoicing vs E-Reporting in 2026: Which Transactions Go Where?
Published August 2026 by Solarc Labs
E-invoicing and e-reporting are separate flows inside the same reform
DGFiP separates the reform into distinct obligations rather than one universal electronic-invoice pipe. Domestic B2B operations between businesses established in France and subject to French VAT sit inside the electronic-invoicing scope. Other transaction classes can instead create transaction e-reporting or payment e-reporting obligations, with required data sent to the administration through the approved-platform path. For an ERP team, classification therefore comes before file generation: determine which source transactions belong to the invoice-exchange path and which belong to an e-reporting path before mapping every sale to the same output.
Domestic French B2B is the core e-invoicing path
DGFiP describes electronic invoicing as covering purchases and sales of goods or services between businesses established in France and subject to French VAT when the French invoicing rules apply. The invoice is exchanged through a Plateforme Agréée, and the platform handles the regulatory transmission associated with that flow. That makes customer establishment, VAT status and transaction scope operational routing data. If those attributes are unreliable in the source system, a technically valid invoice file can still enter the wrong process.
B2C and cross-border cases can move into transaction e-reporting
DGFiP identifies sales to non-taxable persons such as consumers and transactions involving operators established abroad among the operations covered by transaction e-reporting rather than the standard domestic B2B exchange. A billing estate serving B2B, B2C and international customers therefore needs more than a format switch. Build an explicit classification table from real transaction types, customer establishment data and tax treatment, then test the exceptions. The goal is not to turn InvoiceBatch into a tax decision engine; it is to stop uncertain classifications being hidden inside a generic export job.
Payment e-reporting is a separate conditional data path
The reform also includes transmission of payment data in relevant cases. Treat that as a source-event and tax-treatment problem rather than a universal paid/unpaid flag. Finance and integration teams should identify which source events are authoritative, how partial or corrected payments are represented, and which fields the selected Plateforme Agréée expects from the upstream system. Record those assumptions in the cutover evidence pack so a payment-data problem is not misdiagnosed as an invoice-format defect.
Keep regulated routing separate from corpus preflight
InvoiceBatch FR is not a Plateforme Agréée. It does not perform e-reporting, recipient routing, regulated invoice transmission or fiscal-data submission. Its useful upstream job is narrower: inspect representative structured invoice corpora, surface recurring data and mapping defects, and preserve evidence for remediation before the regulated platform carries live traffic. For mixed-flow ERP estates, keep the classification and PA design evidence beside the corpus-preflight evidence, but do not treat one as proof of the other.
Primary sources
Sources used for this article
Continue the job