E-Invoicing and E-Reporting in France: How They Reshape a Retailer's POS, Middleware and ERP Architecture

France's e-invoicing and e-reporting rules don't just define new tax data - they test whether a retailer's tills, store servers, ERP and fiscal middleware can reliably capture, sequence and forward every transaction on time, whatever architecture sits behind them.

France's e-invoicing and e-reporting reform, in a strict legal sense, only splits a retailer's revenue into two flows: domestic B2B invoices go through e-invoicing, while B2C sales, cross-border transactions and certain payments go through e-reporting. In practice, it touches almost the entire retail estate, because one legal entity processes goods sales, services, refunds and cross-border online orders through the same stores, the same tills and often the same integration layer.

This reform lands on top of an architecture that is rarely uniform, even within a single retail group. Some chains run a store server, or store controller, that aggregates every till in a location before forwarding one feed to headquarters. Others run cloud-native tills that report each transaction directly to a central platform with no local aggregation point at all. A third, common pattern is a till that keeps working offline and batches its transactions upward once connectivity returns. A large, multi-brand, multi-country retailer typically runs more than one of these patterns at once, often inherited from acquisitions or from country-by-country technology choices made independently of each other.

Whichever pattern is in place, the tax authority's requirement is the same: the France-established legal entity has to classify every transaction as domestic B2B, B2C, cross-border or a payment event, decide whether VAT is due on delivery or on collection, and route it either to a Certified Platform for e-invoicing or, for B2C and cross-border flows, into a periodic e-reporting flux.

In practice, retailers implement this layer in one of three ways. The first is to build it into the ERP or a corporate integration platform the retailer already owns: it gives full control and no external dependency, but the retailer's own team has to keep pace with country-specific logic - VAT-on-debits versus VAT-on-collection, cancellation reasons, cross-border scope - for every country and legal entity in the group, and retest it whenever French rules, or any other country's rules, change. The second is a patchwork of country- or vendor-specific point solutions bolted onto individual store systems: faster to deploy locally, but a multi-country retailer ends up with as many implementations, audit trails and update cycles as it has countries, which is hard to govern centrally and easy to leave inconsistent. The third is a dedicated fiscal middleware sitting between every sales channel - POS, store server, e-commerce - and the tax authority's platform: it receives raw transaction data regardless of which architecture pattern produced it, applies classification and aggregation centrally, and handles the certified transmission itself. The trade-off is that the retailer now depends on that middleware's certification and uptime, and still has to guarantee that every till and channel actually delivers its transactions to it - a middleware cannot report data it never received.

This last point is where e-reporting becomes harder than e-invoicing. An invoice is either issued correctly or it is not; a periodic e-reporting flux for B2C sales aggregates every transaction from a ten-day period per cash register, and that period cannot close on time if one of that register's transactions is still in transit. Handling this well typically means working in stages: an empty report is opened for each register for a given business day only after a configurable delay, commonly three to seven days, to give transactions time to arrive. It is then filled once transactions exist and appear in sequence, while a period with no transactions is flagged as a zero report and one still missing transactions is flagged as missing transaction rather than silently left incomplete. Before anything is sent, the system checks whether new transactions have arrived since a report was filled, or whether transactions exist outside the sequence range already captured - either case reopens or resets the report rather than sending incomplete or duplicate data. Completed reports are then transmitted to the Certified Platform inside the window the rules allow, roughly seven to ten days after the business day in question, with automatic retries and a manual resend option if a submission fails. Running this cycle on a fixed schedule, rather than once at month-end, is what keeps a large retailer's e-reporting deadlines achievable even when store connectivity, batch jobs or public holidays delay a subset of transactions.

What should retailers take into consideration when assessing their e-reporting setup?

Retailers should map which of the store-server, cloud-till or offline-batch patterns above is actually running in each of their French stores and brands, and check whether their current process - in-house, point solution or middleware - can absorb transactions that arrive late or out of sequence without silently under-reporting a ten-day period. It is also worth confirming that whichever setup is chosen treats French e-reporting as a recurring, retry-capable process tied to an audit trail, rather than a manual export performed once a deadline approaches, since the same reconciliation has to run reliably for every register and every ten-day period, not only when a submission date is close.

From our perspective, the architecture question matters more than any single country's rule. A retailer that has already centralised its fiscal reporting, through whichever store-server or middleware layout, tends to absorb a new French e-reporting requirement as a configuration change. One with several disconnected implementations has to repeat the same analysis, and the same risk of missed periods, in every system that touches a French till.

These obligations, and the deadlines referenced above, are set out in the French e-invoicing and e-reporting framework administered by the French Tax Administration (DGFiP), including its published external specifications for B2B e-invoicing flows and for B2C and cross-border e-reporting, available through the official e-invoicing portal on impots.gouv.fr. 

The source for this text above is DGFiP - Facturation électronique (impots.gouv.fr) Source.

Tamara Tegeltija, Business Analyst at Fiscal Solutions

Linkedin profile