France E-Invoicing for PME: Connecting Your Own Billing System Before 1 September 2027

Since 1 September 2026, every company in France covered by the reform has had to be able to receive electronic invoices through a plateforme agréée, an approved platform. Large companies and ETI have also had to issue invoices that way and file e-reporting. The French tax site now describes the reform as "effective depuis le 1er septembre 2026".

The second wave lands on 1 September 2027. From that date PME, TPE and micro-entreprises must issue their B2B invoices electronically through an approved platform and start e-reporting: sending the administration data on sales to consumers, on international transactions and, for services, on payments received.

If your invoices come out of a mainstream package such as Sage, Cegid or Pennylane, the connection to an approved platform comes from your vendor, which either is one or works with one. Your part is choosing the platform and cleaning customer data.

This article is for the other case: invoices produced by your own billing software, a customised ERP, or your platform's own code. There, the connection has to be built. Eleven months is enough if you start now.

The Calendar, and Which Wave You Are In

The DGFiP's practical guide to the start of e-invoicing sets out the dates:

• 1 September 2026: every company in scope must be able to receive e-invoices; large companies (grandes entreprises) and ETI must also issue them and file e-reporting.
• 1 September 2027: PME, TPE and micro-entreprises must issue and file e-reporting.

Size is judged per legal entity (per SIREN) as of 1 January 2025, using the last financial year closed before that date. According to the official FAQ, a PME has fewer than 250 staff and either turnover up to €50 million or a balance sheet up to €43 million. Above that line, your date was 2026.

One trap. The external specifications (version 3.2, 30 April 2026) put entities that belong to a VAT group (assujetti unique) in the 2026 wave, whatever their size. If yours is one, you are already late.

The guide also settles two questions in your favour. You may start issuing electronically before your deadline, on a voluntary basis. And a customer cannot use the reform to force you to send e-invoices before 1 September 2027, although your contracts can still set how you exchange invoices.

What an Approved Platform Does

A plateforme agréée is a private operator registered (immatriculée) by the State. To appear on the official list, it has to demonstrate tax compliance, the security of its infrastructure and data, and technical interoperability.

The specifications call the architecture the "Y" model. Your system sends the invoice to your platform. Your platform looks up the buyer in the central directory (the annuaire) run by the public invoicing portal (PPF), and delivers the invoice to the buyer's platform. Separately, your platform extracts the regulatory data from the invoice and sends it to the PPF, which passes it to the tax administration.

Three consequences for whoever builds the integration:

• You never talk to the State directly. Only approved platforms can deliver invoices to recipients and send data to the PPF. Your billing system is what the specifications call a solution compatible: it talks to a platform, and the platform does the rest.
• You probably already have a platform. You needed one for receiving from 1 September 2026. Ask it first what it offers for issuing. You are free to use a different one, but one contract and one integration is simpler.
• The interface is standardised. AFNOR standard XP Z12-013 defines the APIs between company systems and approved platforms; XP Z12-012 covers the invoice and status formats. Platforms also offer EDI and portal channels, and Peppol links platforms to each other. Ask which yours supports before designing anything.

Public buyers stay on Chorus Pro, and existing Chorus Pro connections can be kept.

What Your System Has to Produce

A platform can transport and convert an invoice. It cannot invent data your system never held.

A format from the common base

Every approved platform must support three formats, all built on the European standard EN 16931: UBL (version 2.1), CII (version D22B) and Factur-X, a PDF with the structured data embedded. Platforms may accept others; only these three are guaranteed.

Choose based on what your system can produce cleanly, not on what each customer prefers. A supplier cannot impose a format on a buyer, and the buyer's platform can convert to the buyer's preferred format. Factur-X suits companies whose customers still want a readable PDF; UBL or CII suits pure system-to-system flows.

The data, field by field

The administration publishes a table of the invoice data it receives, mapped to EN 16931 business terms. Four mentions are new for most French invoices:

• the customer's SIREN (BT-47);
• the category of operation: goods, services, or both (BT-23);
• the option to pay VAT on debits, where you have opted for it (BT-8);
• the full delivery address, if different from the customer's billing address (BT-75 to BT-80).

The rest of the mandatory set is familiar but has to be structured: your SIREN, both countries, an invoice number from a chronological and continuous sequence, the issue date, the totals before VAT and of VAT, the currency, and a VAT breakdown giving the taxable base, the tax and the rate for every rate used (BT-116, BT-117, BT-119). Conditional fields include VAT numbers, the exemption reason (as a VATEX code), reverse charge, self-billing, a delivery date that differs from the invoice date, and the original invoice's reference on a corrective one.

Several fields in that table are expected only from 1 September 2027: line detail (item name, quantity, unit price), document-level discounts and charges, the delivery address, the date of the corrected invoice, the early-payment discount note and the eco-participation amount. The 2027 deadline is also the day the data model gets deeper for everyone.

Where custom systems usually fall over:

• The customer record has no SIREN, or holds a SIRET in the SIREN field.
• Category of operation is not stored per product or service, so a mixed invoice cannot be classified.
• VAT is computed and rounded per line, so the per-rate breakdown does not reconcile with the totals.
• Credit notes are free-floating documents with no reference to the invoice they correct.
• Invoice numbers have gaps, or get reused after a cancellation.

Each of those is a fix in the source system, not in the connector.

Routing data

The directory addresses a private company at SIREN level by default, but can also route by SIRET, routing code or suffix when a customer wants invoices per establishment or department. Store the right identifiers per customer. When a lookup fails, the guide's first instruction is to check the SIREN, the SIRET and the receiving establishment you used.

Lifecycle statuses, in both directions

An invoice now has a lifecycle, carried as status messages. Four statuses are mandatory and reach the tax administration:

Others, such as "received by the platform", "in dispute" or "payment sent", are optional.

Your system has to read statuses as well as send them. A rejection is technical: wrong format, missing or inconsistent data, bad routing. You fix it and resend. A refusal comes from the buyer, must give a reason, and may only use the reasons the standard allows (a regulatory defect the platform missed, a wrong addressee, contractual conditions not met), never a plain commercial dispute. If you reissue after a refusal, the new invoice needs a new number. The specifications say a refused or rejected invoice is cancelled in your books with an internal credit note; the guide adds that if you contest a refusal, you should not create one automatically.

Encaissée is the one custom systems forget. For services, where VAT falls due on payment, this status carries the invoice number, the payment date and the amount received per VAT rate: it is how payment data reaches the administration for domestic B2B. So your bank reconciliation or receivables module has to feed the invoicing integration, and those are often two systems that have never spoken.

E-Reporting: Everything That Is Not a Domestic B2B Invoice

E-invoicing covers sales between two VAT-registered businesses established in France. E-reporting covers the rest, also sent through your approved platform:

• Sales to non-taxable persons (B2C), in France or abroad: daily totals rather than individual invoices, split by category (taxable goods, taxable services, intra-EU distance sales, margin schemes), with the taxable base and the VAT for each rate.
• International B2B: sales to and purchases from businesses not established in France, invoice by invoice, with much the same fields as a domestic invoice. Purchases count: buying training from a German supplier is reported by you, the French buyer.
• Payment data, only for services, and not for reverse-charge operations or companies that opted for VAT on debits: the date and the amount received per VAT rate.

The rhythm depends on your VAT regime, per the published frequency table. Under the monthly régime réel normal, transaction data goes three times a month (1st to 10th, 11th to 20th, 21st to month end), each due ten days after its period, and payment data monthly before the 10th of the next month. Under the régime simplifié, both are monthly, due between the 25th and 30th of the following month. Under the franchise en base, both go every two calendar months.

Three filings a month is a scheduled job, not a spreadsheet. And if your B2C sales pass through a till, a web shop and an invoicing tool, the daily totals have to come from all three.

An 11-Month Plan

Counting back from 1 September 2027, and writing off August because it is August:

1. October 2026: scope. Confirm your size category and whether you belong to a VAT group. List every flow that produces an invoice or a sale: domestic B2B, B2C, international, credit notes, deposits, self-billing, public sector. Ask your receiving platform for its issuing offer: formats, API documentation, a test environment, the statuses it returns, e-reporting.
2. November and December 2026: data. Run the field table against your real data. Add and verify SIREN and SIRET on customer records, add category of operation to the catalogue, settle the VAT-on-debits flag, audit invoice numbering. Choose the format.
3. January to March 2027: build. The format generator; validation against EN 16931 and the French rules before sending; the platform API client; status handling with an invoice state machine; the Encaissée feed from receivables; the e-reporting aggregates.
4. April and May 2027: test, then go live voluntarily. The test environment first, then real invoices to a few customers who agree. The guide allows voluntary issuing before your deadline, and if it fails you may fall back to your usual method for those flows. Spring 2027 is the cheapest live testing you will get.
5. June and July 2027: widen. All domestic B2B through the platform, e-reporting running, the first month-end and VAT return reconciled against what the platform reported.
6. August 2027: freeze. No releases, a written procedure for rejections and refusals, named people covering the holidays.
7. 1 September 2027: obligation. Then your first e-reporting deadline, the real test of the reporting side.

If You Are Not Ready on the Day

The guide written for the September 2026 start sets a tolerant line: no penalties during the start-up phase for companies that hit difficulties but are on a "trajectoire sérieuse de mise en conformité", judged on concrete, dated evidence (platform contract, tests, support tickets). It also says this is "ni un report ni une suspension" of the obligation. It does not say whether the same line will apply in September 2027.

The penalties are in the FAQ: €50 per invoice not issued electronically, capped at €15,000 per calendar year, with the first offence not penalised. E-reporting failures fall under article 1788 D of the CGI.

Treat 1 September 2027 as fixed, and keep the evidence trail anyway: it is what the administration will ask for.

Where This Fits

Most French PME will get this from their software vendor, and should. Our work is for the others: we build the format generation, the platform connection, the status handling and the e-reporting feeds inside the system that already produces your invoices, and we fix the data underneath. There is more on our e-invoicing integration service, and on ERP modernisation when the billing system itself is the problem.

If you have a September 2027 date and an invoicing system nobody wants to touch, write to office@c9group.dev. We are engineers rather than tax advisers: scope and VAT treatment belong with your expert-comptable, and we build to their answer.