The invoice between two French businesses is now a data file.
For most of its life, an invoice between two French businesses was a document. It arrived as a PDF in an email or a sheet of paper in the post, someone read it, keyed the numbers into the ledger, matched it, and paid it. The tax office saw it only if it asked. On 1 September 2026 that arrangement changed. France began its business-to-business e-invoicing and e-reporting reform on the date set by the loi de finances pour 2024, and the invoice became structured data that travels a defined route.
The first obligation is the one every finance team should read first, because it reaches everyone immediately. From that date, every business established in France must be able to receive an electronic invoice, and reception happens through an approved platform, a plateforme agréée the State has registered. Article 289 bis of the Code général des impôts puts it plainly: the emission, transmission, and reception of electronic invoices are carried out through an approved platform. Issuance is phased. Large and mid-sized enterprises must issue every domestic invoice electronically from 1 September 2026, and smaller businesses follow on 1 September 2027. Reception waits for no one.
The part worth dwelling on is the quiet upside. The same approved platform that carries an invoice also transmits its data to the tax administration, and that data goes on to pre-fill the VAT return. A structured invoice, meanwhile, is not a picture to read but fields to post, so a received invoice can flow into the ledger without anyone retyping it. Put those two together and a compliance requirement and a cleaner accounts payable process stop being separate projects. They are the same piece of plumbing, built once.
The reform is careful about continuity. It changes how invoices move between businesses, not the substantive rules on whether an operation happened, what is owed, when it is paid, how it is booked, or the right to deduct VAT. An invoice that still arrives the old way during the startup period is not to be thrown out for that reason alone when it reflects a real operation. Read as a systems problem rather than a filing chore, all of this is a record a finance team can own: where each entity receives, what it can read, what it must report, and one query that shows whether it is ready.
What the mandate asks, and when it asks it.
The reform is really five obligations, arriving on two dates for two groups. It helps to read them not as a single switch but as distinct duties, each with its own data behind it, because that is how the work actually divides. The table below sets out what each one asks, who it falls on and when, and what it needs from the data a finance team holds.
| The obligation | What it asks | Who it falls on and when | What it needs from your data |
|---|---|---|---|
| Receive electronic invoices | Be able to accept a structured invoice delivered through an approved platform, and keep processing and paying without interruption | Every business established in France, from 1 September 2026 | A designated reception platform, a reception address published in the directory, and accounts payable able to read a Factur-X, UBL, or CII invoice. |
| Issue electronic invoices | Send every domestic business-to-business invoice as structured data through an approved platform rather than as a PDF or on paper | Large and mid-sized enterprises from 1 September 2026, smaller businesses from 1 September 2027 | Complete invoice data, including the four new mandatory mentions, and the partner SIREN and reception route resolved from the directory. |
| E-report transaction data | Report the sales the invoice flow does not carry, meaning sales to consumers and cross-border operations | The same sizes and dates as the issuance obligation | Transaction totals by VAT rate for consumer and cross-border sales, transmitted through the platform rather than filed by hand. |
| E-report payment data | Report the date cash is collected, for the operations where VAT falls due on collection | Mainly services, on the same sizes and dates | A payment status tied to each service invoice, except where VAT is paid on the debits or the reverse charge applies. |
| Return lifecycle statuses | Send back the status of an invoice as it moves, so both sides and the administration stay in step | Both parties, each through their own platform | Statuses such as received, refused, and cashed raised from the systems that actually handle the invoice. |
Two things are worth pulling out of that table. The first is that reception is universal and immediate, while issuance is phased, so the near-term job for most teams is simply to be able to receive cleanly, even if their own issuance obligation does not start until 2027. The second is that e-reporting is not a separate world. Transaction e-reporting picks up the sales the invoice flow does not carry, meaning sales to consumers and cross-border operations, and payment e-reporting picks up the collection date for services, where VAT falls due when the cash is received rather than when the invoice is raised. Both draw on data the ledger already holds.
The reform also adds four new mandatory mentions to a French invoice, and they are worth naming because they land squarely in master data. They are the client SIREN, the delivery address of the goods where it differs from the billing address, the information that the operation is exclusively goods, exclusively services, or a mix of the two, and the option for payment of VAT on the debits where a business holds it. None of these is a decision made afresh each time. Held on the partner and item records, they are simply present on every invoice, which is the difference between a control that works by construction and one that relies on somebody remembering.
The reception and reporting record, read as one governed control.
A worked example makes it concrete. Take one French entity, a mid-sized company that both buys and sells at home. It has chosen an approved platform and published its reception address in the directory, so suppliers can route to it. It accepts the base formats. When it issues, it carries the four new mandatory mentions because they live on its partner and item records. It reports its consumer and cross-border sales, and the collection date on its service invoices, from the same data it already keeps. Recorded that way, the entity can answer for itself: a reviewer can see it is ready without opening a single invoice.
Here is that logic expressed as a record. The entity carries its size class and its two dates, which decide when it must issue. A platform block records the approved platform, the directory reception address, and the formats it accepts. A partner block resolves the counterparty and its own platform from the directory. A mentions block holds the four new required fields as master data. An e-reporting block derives the transaction and payment data from the ledger. And an exception query at the end names the gaps that would make any of it untrustworthy, starting with an invoice that arrived off-platform when it should not have.
A reception, issuance, and e-reporting record for the France mandate
# Reception, issuance, and e-reporting record for the France mandate
# SIREN, names, and dates are placeholders for shape, not real values.
entity:
legal_name: "Our French operating company"
siren: "000000000"
vat_number: "FR00000000000"
size_class: ETI # GE, ETI, or PME/TPE, which sets the issuance date
reception_obligation_from: 2026-09-01
issuance_obligation_from: 2026-09-01 # 2027-09-01 for a smaller business
platform:
approved_platform: "Registered PA, three-year State registration"
reception_address: "the routing address listed in the directory"
directory_entry: current # the annuaire points suppliers to this platform
accepted_formats: [factur-x, ubl, cii] # the base formats, aligned to EN 16931
trading_partner:
name: "A domestic supplier"
siren: "111111111"
reception_platform: "the partner's own PA, which need not match ours"
in_directory: true
invoice_mentions: # the four new mandatory mentions the reform adds
client_siren: required
delivery_address: "state it when it differs from the billing address"
operation_category: goods | services | mixed
vat_on_debits_option: "add the mention when the option is held"
e_reporting:
transaction_data: [b2c_sales, exports, intra_community] # not carried by the invoice flow
payment_data: "collection date for services, unless VAT on debits or reverse charge"
purpose: "the same data pre-fills the VAT return"
exception_query: # the readiness control, run before each period
- a partner invoice arriving off-platform that should have come through one
- a received invoice with no lifecycle status returned
- a service invoice with no payment status where VAT falls due on collection
- a B2C or cross-border sale with no transaction report
- our own entry missing a current reception address in the directoryThe exception query is what keeps it honest. An invoice that arrived by mail when the supplier should have sent it through a platform is a gap to regularise, not a document to hide. A received invoice with no status returned is a silence a supplier will eventually chase. A service invoice with no payment status is a VAT timing question waiting to happen. A consumer or cross-border sale with no transaction report is a missing line in a return the administration will pre-fill from your data anyway. And a stale directory entry is the reason an invoice you expected never arrived. None of this is exotic. It is ordinary readiness, measured against the mandate, so a gap is a query result you clear on a Tuesday rather than a finding you explain later.
An implementation checklist.
- 1.Choose an approved platform and register how you receive, before anything else. Reception is the first obligation and it falls on every French business from day one. Pick an approved platform, directly or through the software, accountant, or bank you already use, publish your reception address in the directory so suppliers can route to you, and keep the trail that shows the step is done. A business that cannot yet receive should not stop paying or refuse invoices, it should get the reception route in place quickly and keep the record of doing so.
- 2.Teach accounts payable to read a structured invoice, not just look at it. The base formats are Factur-X, a PDF that carries structured data inside it, and the pure XML formats UBL and CII, all aligned to the European standard EN 16931. A Factur-X invoice still shows a human a familiar page, but the value is the data behind it, which posts to the ledger without rekeying. Map the fields once and the invoice becomes a clean feed rather than a document someone retypes.
- 3.Put the four new mandatory mentions into the data you send. The reform adds four required mentions to a French invoice: the client SIREN, the delivery address of the goods where it differs from the billing address, whether the operation is goods, services, or both, and the option for payment of VAT on the debits where you hold it. These are master-data and transaction fields, so set them at the partner and item level rather than remembering them per invoice.
- 4.Resolve the partner and the route from the directory, not from an email. The directory is the central register that says which approved platform manages a given business and what its reception address is. Use it to confirm a partner is reachable and to route an invoice to the right platform, and treat a missing or stale directory entry, yours or a partner’s, as a data problem to fix rather than a reason to fall back to paper.
- 5.Wire e-reporting for what the invoice flow does not carry. Transaction e-reporting covers sales to consumers and cross-border operations, and payment e-reporting covers the collection date for services where VAT is due on collection. Both run through the approved platform. Build them from the same sales and cash data you already hold, so the report is a by-product of the ledger rather than a separate return assembled by hand.
- 6.Return and consume the lifecycle statuses. An electronic invoice moves through statuses as it is received, refused, or cashed, and returning them keeps both sides and the administration in step. Raise the statuses from the systems that actually handle the invoice, and consume the ones your suppliers send, so a refused or delayed invoice is a visible event rather than a silence someone chases by phone.
- 7.Run one exception query before each period closes. Any partner invoice that arrived off-platform when it should have come through one, any received invoice with no status returned, any service invoice with no payment status where VAT falls due on collection, any consumer or cross-border sale with no transaction report, and your own entry missing a current reception address are the gaps. While that list has entries, the estate is not ready, and the list is far cheaper to clear at the desk than to explain to an auditor later.
Failure modes, framed so you can plan around them.
- Waiting for the issuance date and forgetting reception is already here. A smaller business may not have to issue electronically until 2027, but every French business has to be able to receive from 1 September 2026. A team that reads the headline as a 2027 problem can miss that a supplier is already sending through a platform today, and an invoice it cannot receive cleanly is one it will end up handling by hand.
- Rejecting an invoice that arrived the old way. During the startup phase an invoice that reaches you by mail, PDF, or paper is not to be set aside on that ground alone when it corresponds to a real operation, and the right to deduct VAT is judged on the substance, not the channel. Refusing to process or pay such an invoice does not advance compliance, it just breaks a supplier relationship and a payment that both had every right to proceed.
- Treating Factur-X as a nicer PDF. The point of a structured invoice is the data, not the picture. A team that opens the human-readable page and keys the numbers in by hand has taken on the format and left the benefit on the table. The value arrives only when the structured content posts to the ledger without rekeying, which is a mapping done once, not a habit repeated per invoice.
- Leaving the four mandatory mentions to be typed each time. The client SIREN, the delivery address where it differs, the operation category, and the VAT-on-debits option are stable facts about a partner or an item, not decisions made afresh on every invoice. Held as master data they are correct by default. Left to memory they are the fields that go missing on the invoice that matters.
- Building e-reporting as a separate return. Transaction and payment e-reporting draw on the same sales and cash data the ledger already holds. Assembled by hand as a fresh submission each period, they become a second month-end task that drifts from the books. Built as a by-product of the same data, they stay consistent with the return they help pre-fill.
- Ignoring the lifecycle statuses until something is late. A status is not paperwork, it is the signal that an invoice was received, refused, or cashed. A team that never returns or reads statuses loses the earliest warning that an invoice is stuck, and finds out at the reminder call what a status would have shown days earlier.
- Assuming both parties must share one platform. A supplier and a buyer each choose their own approved platform, and the two are designed to interoperate through the directory. A team that waits for a partner to be on the same platform, or tries to force one, has invented a blocker the reform removed. What matters is that each side has a registered platform and a current directory entry.
- Reading the startup grace as a delay. The administration has said it will not apply automatic sanctions to a business that meets documented difficulties while engaged in a serious compliance trajectory, and it has said in the same breath that this is neither a postponement nor a suspension. A team that hears only the first half can coast, when the message is to keep moving and keep the record that shows it.
What this asks of the data model.
- The entity carries its own size class and dates. Whether a French entity is a large, mid-sized, or smaller business sets when it must issue, so the size class and the reception and issuance dates are fields on the entity, not facts held in someone’s head, and a group with several entities can see each one’s obligation at a glance.
- The approved platform and reception address are recorded, not assumed. The platform each entity uses, the reception address published in the directory, and the formats it accepts are stored values, so a supplier can be routed correctly and a missing or stale entry is a query result rather than a surprise at the moment an invoice fails to arrive.
- The partner record resolves from the directory. A trading partner carries its SIREN, its own reception platform, and whether it is present in the directory, so the route to it is data the system resolves rather than a detail chased in an email thread.
- The four new mentions live as master data. The client SIREN, the delivery address where it differs, the operation category, and the VAT-on-debits option are held at the partner and item level, so the invoice carries them by construction and completeness is checked once rather than per document.
- The invoice is structured content, not an image. The record treats a received invoice as data aligned to EN 16931, so the fields post to the ledger and drive the match and the accrual, rather than sitting in a PDF a person has to read and retype.
- E-reporting is derived from the same data. Transaction data for consumer and cross-border sales and payment data for services are computed from the ledger and cash records the entity already holds, so the report is a view over existing data rather than a separately maintained return.
- Lifecycle statuses are events on the invoice. Received, refused, and cashed are recorded against the invoice as it moves, so the status history is queryable and a stalled invoice is a visible event rather than an absence someone notices late.
- Completeness reduces to one exception query. Off-platform arrivals, missing statuses, service invoices without a payment status, unreported consumer or cross-border sales, and a stale directory entry are the exception list, and it can run before each period rather than surfacing when a return is questioned.
The evidence to keep.
- The reception setup, showing the approved platform each French entity uses, the reception address published in the directory, and the formats it accepts, so readiness to receive is documented rather than asserted.
- The structured invoices received and issued, aligned to EN 16931, so the data that drove posting, matching, and payment is the evidence itself rather than a scan of a document.
- The mandatory-mentions record, showing that the client SIREN, the delivery address where it differs, the operation category, and the VAT-on-debits option are carried on the invoices issued, so the new requirements are met by the data and not by recollection.
- The e-reporting trail, showing the transaction data for consumer and cross-border sales and the payment data for services transmitted through the platform, tied to the same ledger and cash records they derive from, so the report and the books agree.
- The lifecycle status history per invoice, showing received, refused, and cashed as they occurred, so the state of an invoice at any point is evidenced rather than reconstructed.
- The directory alignment, showing each entity’s current reception entry and the partners resolved through the directory, so routing is a documented fact and a stale entry is visible.
- The startup-phase trail, showing the difficulties met, the trajectory engaged, and the corrective steps taken, which is exactly what the administration says it will look for while it holds back automatic sanctions.
- The exception query output, ideally empty, listing off-platform arrivals, missing statuses, unmatched payment data, unreported sales, and stale directory entries, so the gaps were checked before any period was relied on.
Questions worth asking in your own review.
- Can every French entity we run already receive a structured invoice through an approved platform today, with a reception address published in the directory?
- Does accounts payable read a Factur-X, UBL, or CII invoice as data that posts to the ledger, or does someone still open the page and key it in?
- Are the four new mandatory mentions, the client SIREN, the delivery address where it differs, the operation category, and the VAT-on-debits option, held as master data rather than typed per invoice?
- Do we resolve a partner and its reception route from the directory, or do we still fall back to email and paper when an entry looks unclear?
- Is our e-reporting for consumer and cross-border sales and for service payments built from the same data as the ledger, or assembled by hand as a separate return?
- Do we return and consume the lifecycle statuses, so a refused or stuck invoice is a visible event rather than something we learn at the reminder call?
- If an invoice still arrives by mail or PDF during the startup phase, do we process and pay it on its substance, or do we wrongly set it aside?
- Could we show an auditor, in one query, that no invoice arrived off-platform, no status is missing, and no sale went unreported for the period?
What this adds up to.
France has turned the invoice between two businesses into structured data on a defined route, and the first duty, live since 1 September 2026, is that every French entity can receive one through an approved platform. Issuance and e-reporting follow the same path, phased by size, with the base formats aligned to a European standard and the four new mandatory mentions added to the invoice itself. Read as a chore, it is a lot of moving parts. Read as an opportunity, it is a cleaner feed and a pre-filled return arriving together.
The build that makes it real is a record and a few deliberate choices. Choose an approved platform and publish how you receive, teach accounts payable to read a structured invoice as data rather than as a page, hold the four new mentions as master data, resolve partners through the directory, derive e-reporting from the ledger you already keep, and return and consume the lifecycle statuses so a stuck invoice is a visible event. Keep the startup-phase trail while the administration holds back automatic sanctions for teams making genuine progress.
If there is one place to start, run the exception query against your own French entities before you trust them ready: every invoice that arrived off-platform, every received invoice with no status, every service invoice with no payment status, every consumer or cross-border sale with no report, and every entity missing a current reception address. For a tidy estate that list is short and the rest is scheduled. For a sprawling one it is the work, and it is far better found now, at the desk, than in the first audit that reads the same data the administration already has.
Sources.
- Direction générale des Finances publiques (DGFiP), Facturation électronique : guide pratique de démarrage au 1er septembre 2026, downloaded and read directly. Source for the three startup principles: that from 1 September 2026 the businesses in scope must have the capacity to receive electronic invoices and those subject to the issuance obligation must issue through an approved platform (plateforme agréée), with article 289 bis of the Code général des impôts (CGI) providing that the emission, transmission, and reception of electronic invoices are carried out through an approved platform; that the reform changes how invoices are transmitted between businesses but not the substantive rules on the operation, the commercial debt, payment, accounting, or the right to deduct VAT, so an invoice received through another usual channel such as mail, PDF, or paper is not to be set aside on that ground alone when it corresponds to a real operation; and that electronic invoices issued under article 289 bis are transmitted to the administration by the approved platform chosen by the taxable person (article 289 E of the CGI). Source too for the right to deduct VAT resting on article 271 of the CGI, for the mandatory invoice mentions set out notably at article 242 nonies A of annexe II to the CGI, for the e-reporting transmission obligation applying from 1 September 2026 to large enterprises and mid-sized enterprises, and for the startup phase carrying no automatic sanctions for a business that meets documented difficulties while engaged in a serious compliance trajectory, which the guide is careful to say is neither a postponement nor a suspension of the obligation.
- impots.gouv.fr, Je découvre la facturation électronique. Source for the scope split that e-invoicing (facturation électronique) covers the purchase and sale of goods and services between businesses established in France, and that e-reporting has two parts, transaction e-reporting for sales to persons who are not taxable such as consumers and for cross-border operations, and payment e-reporting for the collected-cash data where VAT is due on collection rather than on the invoice. Source for an approved platform being a private company registered by the State, and for the two platforms in an exchange being independent so a supplier and a buyer need not use the same one.
- economie.gouv.fr, Tout savoir sur la facturation électronique pour les entreprises. Source for the reform entering into force on 1 September 2026 on the calendar fixed by the loi de finances pour 2024, for the four new mandatory mentions the reform adds to a French invoice, the client SIREN number, the delivery address of the goods where it differs from the billing address, the information that the operation consists exclusively of deliveries of goods or of provisions of services or of both, and the option for payment of VAT on the debits where it is held, and for the mandatory invoice data being transmitted to the administration to pre-fill the VAT return.
- economie.gouv.fr, Qu’est-ce que l’annuaire de la facturation électronique ? Source for the directory (annuaire) as the central register that lists the businesses subject to the obligation to issue and receive electronic invoices, records the approved platform managing each one, and holds the electronic invoicing addresses that route an invoice to the right reception platform.
- impots.gouv.fr, Facturation électronique et plateformes agréées. Source for an approved platform being registered by the DGFiP for a three-year renewable period, for its role converting invoices to the required format, guaranteeing the integrity and authenticity of the data, and carrying the mandatory reporting to the State, and for only an approved platform being authorised to provide the reform functionalities for e-invoicing and e-reporting.
- impots.gouv.fr, actualité, Facturation électronique : publication de la liste des plateformes agréées. Source for the DGFiP having published the list of registered approved platforms that passed the regulatory requirements and the technical and inter-platform interoperability tests, which a business can consult when choosing where to receive and issue its invoices.
- impots.gouv.fr, L’e-reporting pour les entreprises étrangères sans établissement stable en France. Source for e-reporting reaching activity that the domestic invoice flow does not carry, including sales to final consumers and cross-border operations, and for the transmission running through an approved platform rather than a manual filing.
The dates, the split between reception, issuance, and e-reporting, the three startup principles, the role of the approved platform and the directory, the four new mandatory mentions, and the governing articles of the Code général des impôts were read from the DGFiP startup guide, which was downloaded and read directly, and from the impots.gouv.fr and economie.gouv.fr guidance. No embedded posts from X appear here, because no public post on this topic could be verified as current, relevant, and authentic at the time of writing, and an unverified embed is worse than none. Nothing here is tax, legal, or accounting advice for a specific business. The SIREN numbers, names, and dates in the worked example and the record are placeholders for shape rather than real values, and how a given entity meets the mandate depends on its own platform, systems, size, and activity.