Mandatory e-invoicing: adapting ERPs, e-commerce and back offices

Mandatory e-invoicing came into force on 1 September 2026: all companies subject to VAT in France must now be able to receive their invoices via an approved platform, and large companies and mid-sized companies (ETI) must already issue them. Here is what it changes in your ERPs, e-commerce sites, back offices and CRMs, and how to prepare for 2027.

The state of the reform

The timeline

According to DGFiP sheet 1, an ETI employs between 250 and 5,000 people with turnover below €1.5 billion or a balance sheet total below €2 billion; above that, it is a large company. Businesses under the VAT exemption scheme (franchise en base), notably auto-entrepreneurs, are also affected. If in doubt, confirm your category with your accountant.

A start-up tolerance, not a postponement

In July 2026, the DGFiP published a practical start-up guide. Three messages matter for technical teams:

• No penalty during the start-up phase for companies that run into difficulties but are “committed to a serious path towards compliance”. The administration specifies that this is “neither a postponement nor a suspension of the obligation”.
• An invoice received as a PDF, by email or on paper remains payable and deductible if it corresponds to a real transaction and carries the necessary details.
• Evidence matters: support tickets, error messages, tests, a remediation plan, internal instructions. A “mere declaration of intent is not enough”.

Your system must therefore keep a trace: this is a design requirement.

Who does what: approved platforms, PPF and directory

Approved platforms (PA)

Invoices now travel from the issuer’s PA to the recipient’s. A PA is a private provider registered by the administration after interoperability tests (official list). It issues, receives and converts invoices, and transmits tax and payment data to the administration.

The public invoicing portal (PPF)

Since the abandonment, announced in October 2024, of a free public exchange platform, the PPF no longer carries invoices between companies. It plays two roles: it maintains the directory of recipients (which indicates which PA receives which SIREN’s invoices) and acts as a hub for the data transmitted to the administration. You do not use it directly: your PA talks to it.

Formats and standards

A compliant e-invoice uses one of the core formats: UBL, CII or a hybrid format combining a structured data file and a PDF image, that is, Factur-X. All are based on the European standard EN 16931, supplemented by French rules. The DGFiP external specifications are at version 3.2 (30 April 2026). Three experimental AFNOR standards complete them: XP Z12-012 (formats and profiles of invoices and statuses), XP Z12-013 (API between companies’ information systems and PAs) and XP Z12-014 (B2B use cases).

Lifecycle statuses

According to DGFiP sheet 6, four statuses must be offered by PAs, among about ten optional ones: submitted, rejected (technical error or non-compliance, the invoice is not transmitted), refused (commercial reason, by the customer) and payment received (indicated by the supplier). Your information system (IS) must receive them, store them and trigger the right processing.

The data that changes

Four new mandatory details

Article 242 nonies A of Annex II to the French General Tax Code (CGI) adds details that must exist as structured data in your systems, not just on a PDF.

E-reporting

E-reporting covers what does not go through a domestic B2B e-invoice: sales to individuals, transactions with foreign customers or suppliers, and payment data for services where VAT is due on receipt of payment. The data is transmitted by your PA. The filing calendar published by the DGFiP depends on the VAT regime:

For a B2C e-commerce business of an ETI on the monthly normal regime: three aggregations a month, reliable and replayable.

Technical impacts by information system component

ERP and management software

• Third-party master data: SIREN mandatory and validated for customers subject to VAT, a clear distinction between French business customers, foreign ones and individuals (it decides the route: e-invoice or e-reporting).
• Items: a “goods” or “service” category on each item, including ancillary charges (shipping, installation, subscription).
• Invoices and credit notes: production in a core format, credit notes linked to the original invoice, continuous numbering maintained.
• Receipt: import of structured supplier invoices with matching against order and receipt, and handling of reasoned refusal.
• Payments: “payment received” status and payment data if VAT is due on receipt of payment.

On maintained packaged software, the vendor delivers most of it; what remains is data quality and custom development.

E-commerce site

• B2C: no e-invoice to the individual, but transaction data to aggregate for e-reporting (amounts excluding VAT, VAT by rate, date, category).
• B2B: as soon as a French business customer buys, the invoice must go through a PA (2026 for large-company and ETI sellers, 2027 for the others). You therefore need to capture and verify the SIREN at order time, including on guest checkout.
• Invoicing modules (WooCommerce, PrestaShop, SaaS): check whether they produce a core format and talk to a PA, otherwise pass the data to the ERP.

To verify a SIREN at checkout, the State’s Recherche d’entreprises API is free and needs no authentication:

curl -s "https://recherche-entreprises.api.gouv.fr/search?q=356000000&per_page=1" \
  | jq '.results[0] | {siren, nom_complet, etat_administratif, categorie_entreprise}'

The categorie_entreprise field (SME, ETI, large company) helps anticipate the behaviour of your suppliers and customers, but it remains indicative: it does not replace validating your own category.

Server-side format check, before any external call (Luhn checksum):

function isValidSiren(string $siren): bool
{
    if (!preg_match('/^\d{9}$/', $siren)) {
        return false;
    }
    $sum = 0;
    foreach (str_split(strrev($siren)) as $i => $digit) {
        $n = (int) $digit * (($i % 2) + 1);
        $sum += $n > 9 ? $n - 9 : $n;
    }
    return $sum % 10 === 0;
}

Business back offices and “in-house” invoicing

This is the riskiest case: a custom application (booking, subscriptions, extranet) that generates a PDF and sends it by email. Two options:

• Pass the data to the ERP or to a tool already connected to a PA, which issues the invoice.
• Produce a core format directly and call the PA’s API: more control, but you carry the compliance of the file and the statuses.

In both cases, the PDF is no longer the invoice, only a readable representation.

CRM

Add the SIREN to the customer account and, for groups, distinguish the invoiced entity from the delivery establishment (SIRET). Synchronise with the ERP in one direction only.

Customer data audit query

Before any development, measure the gap. Example on a relational database:

SELECT COUNT(*) AS clients_pro_sans_siren
FROM customers
WHERE country_code = 'FR'
  AND customer_type = 'B2B'
  AND (siren IS NULL OR siren !~ '^[0-9]{9}$');

Adapt the names to your schema: this figure often gives the true size of the project.

Integrating an approved platform via API

Each PA has its own APIs (the XP Z12-013 standard aims to harmonise them), but the architecture rules stay the same:

Our web development teams build this type of connector in PHP (Symfony, Laravel) or Node.js, tested against the PA’s test environment.

A six-step project plan

• Map the flows: everything that issues or receives invoices, including forgotten tools (subscriptions, re-invoicing).
• Choose the PA: formats, quality of the API and its documentation, test environment, statuses offered, reversibility, cost.
• Clean the data: SIREN, delivery addresses, item categories, VAT settings.
• Develop and connect: format generation, connector, status handling, e-reporting.
• Test flow by flow: the DGFiP guide encourages switching over the flows that are ready without waiting for the whole scope to be ready.
• Operate: monitoring of rejections, specification updates, module version upgrades. This is a subject for application maintenance (TMA) in its own right.

If you do not know where to start, an audit of your invoicing chain lets you quantify the gap and prioritise the flows.

Technical checklist

• [ ] A PA receives the invoices for each SIREN, and they reach accounting without re-keying.
• [ ] The SIREN is mandatory and validated on French business customer accounts.
• [ ] The delivery address is structured and carried on the invoice when it differs.
• [ ] Each item carries the goods or service category.
• [ ] The VAT-on-debits option is configured and carried over if it applies.
• [ ] Invoices are produced in UBL, CII or Factur-X and validated before sending.
• [ ] The call to the PA is asynchronous, idempotent and logged.
• [ ] The submitted, rejected, refused and payment received statuses are stored and used.
• [ ] E-reporting data is aggregated according to the periodicity of your VAT regime.
• [ ] Rejections, remediation and proof of compliance are tracked and kept.

Penalties and the right to make a mistake

The 2026 Finance Act (Act no. 2026-103 of 19 February 2026, Article 123) set the following amounts, according to service-public.fr:

They do not apply to a first offence remedied spontaneously or within 30 days of a request from the administration, and the start-up guide rules out any “immediate, automatic and blind” application where a difficulty is documented.

Frequently asked questions

Mandatory e-invoicing: above all, a data project

The reform is in force, with a tolerance reserved for companies able to show they are on track. Three technical priorities: clean data, a decoupled connector to your approved platform, monitoring of statuses and rejections. SMEs have a year to prepare for issuing: that is short if you invoice from custom applications.

iones supports IT directors, software vendors and web agencies: audit of flows, connectors, maintenance after the switchover, including on a white-label basis. Let’s talk about your invoicing chain: reply within 48 to 72 hours.