E-Invoice Finder
Menu
CountriesCompare softwareDeadlinesGuidesCheckerCheck obligation
ENFRDEPLNL
France · final launch sign-off

Final go/no-go evidence checklist for French e-invoicing

Make a defensible France e-invoicing go-live decision with entity-level receiving, issuing, e-reporting and PA evidence before 1 September 2026.

Quick verdict:
  • Decide at the intersection of taxpayer identity and operational flow, never at programme level.
  • The most dangerous false green is a successful platform demo that cannot be traced to the correct SIREN and ledger.
  • Begin by capturing one timestamped, correlated inbound path from directory lookup to accounting receipt.
Get an independent France readiness reportOfficial sources
Last checked: 22 August 2026Based on official sourcesClear summaryBusiness guidance, not legal advice
Official sources prioritized
Last-checked dates visible
Free checker, no signup required

What you need to know

Guide

1. Set the decision unit before judging readiness

Do not issue one verdict for a group, programme or ERP unless every relevant legal entity and flow has the same evidence. The practical decision unit is a legal entity identified by SIREN, then divided where necessary by invoice direction, operational perimeter and reporting lane. Record inbound purchasing, outbound sales, transaction e-reporting and payment-data reporting separately. Add establishments or SIRETs when they affect routing, permissions or operational ownership, but do not confuse an establishment-level test with proof for the legal entity as a whole. Start with a scope sheet containing the legal name, SIREN, relevant SIRETs, VAT position, size category, PA, source systems, AP and AR owners, receiving addresses, customer and supplier populations, and the flows expected at launch. The legal timetable must be explicit: on 1 September 2026 all affected businesses must be able to receive electronic invoices. Large enterprises and ETIs also start issuing electronic invoices and e-reporting on that date; SMEs and micro-enterprises start issuing and e-reporting on 1 September 2027. Confirm classification and tax scope against current official material or qualified advice where facts are unusual. A shared platform does not justify a shared verdict. One subsidiary may have valid directory routing and a successful inbound trace while another has an unresolved SIREN mapping. Likewise, an entity can be ready to receive yet not ready for an in-scope outbound or e-reporting lane. The decision sheet should therefore show one row per entity-and-flow combination, with a consolidated group view produced only after those rows are decided. A project percentage, a generic vendor assurance or a test completed for a sister company is insufficient because none identifies the accountable taxpayer, direction and lane actually being approved.

Guide

2. Apply three verdicts and distinguish hard stops from controlled exceptions

Use three verdicts. READY means the applicable legal obligations and essential operating controls have current, attributable evidence, with no unresolved defect capable of preventing regulated exchange, corrupting accounting or producing an unmonitored reporting gap. READY WITH CONTROLLED EXCEPTIONS means the core route works and the remaining issue is bounded, owned, time-limited, monitored and supported by a credible correction or contingency that does not pretend to replace a legal requirement. NO-GO means a hard stop exists or the evidence is too weak to determine whether the entity can operate compliantly. Hard stops commonly include no contracted and operational plateforme agréée for a required regulated role; an entity absent from, or incorrectly routed in, the relevant directory setup; no proven inbound path for the 2026 receiving obligation; failed authentication or unavailable production access; an outbound failure for a large enterprise or ETI that cannot create and transmit a compliant structured or hybrid invoice through its PA; and an unidentified or unreconciled e-reporting population. A compatible software solution that is not registered as a PA cannot directly perform the regulated PA role. Marketing claims about compatibility do not cure that gap. A controlled exception might be a low-volume supplier communication backlog where routing is already proven, a non-critical dashboard enhancement with compensating daily monitoring, or a small data-quality queue whose affected records are identified, isolated and assigned. Every exception needs impact, affected entities and flows, owner, deadline, monitoring trigger, correction route and escalation threshold. It becomes a hard stop if its population is unknown, it can silently lose invoices or reports, it lacks accountable ownership, or its workaround depends on untested manual heroics. Do not invent a grace period, safe harbour or penalty shield. The verdict answers whether evidence supports launch; it does not promise a tax authority outcome.

Guide

3. Build an evidence register that survives challenge

Create a controlled evidence register rather than a folder of screenshots. Each record should state the legal entity and SIREN, flow, control objective, evidence owner, originating system or source, capture timestamp, environment, test data reference, observed result, reviewer, validity or expiry condition, and link to the underlying artefact. An expiry condition is often more useful than an arbitrary date: evidence may cease to be reliable after a routing change, PA release, ERP mapping update, credential rotation or directory correction. Evidence should be reproducible and connected across systems. For an inbound test, retain the sender or PA transaction reference, directory lookup or routing confirmation, PA event trail, received invoice identifier, AP ingestion record, duplicate-control outcome and accounting disposition. For an outbound test, connect the source invoice to the generated Factur-X, UBL or CII object, PA acceptance and lifecycle outcome, then to the accounting entry. Redact personal or commercially sensitive test content where appropriate, but preserve identifiers needed to prove continuity. Grade each item as passed, failed, expired or not evidenced. Avoid “in progress” in the final verdict; it describes activity, not a result. A screenshot without a timestamp, a vendor email saying “configured”, a slide marked 95% complete, a successful login, or an invoice visible in one portal is not sufficient on its own. Nor is a production configuration export sufficient if no transaction demonstrates that the configuration works. The register should identify the source hierarchy. Official DGFiP and Service-Public material support the legal timetable and official framework. FNFE-MPE start-up checklists provide valuable professional operational guidance that complements official material, but they are not legislation. Record that distinction so a recommended control, such as a particular operational message treatment, is not inaccurately presented as a direct legal duty for every business.

Guide

4. Prove receiving from directory route to accounting control

Receiving proof begins with the PA relationship. Retain the executed contract or authoritative service confirmation, the legal entities covered, production activation status, authorised users and the regulated functions included. Then prove the receiving design: a reasoned address structure, routing rules tied to the correct SIREN or relevant address data, and synchronization with the annuaire. FNFE-MPE guidance favours purposeful receiving addresses and warns against unnecessary multiplication, because excessive routes increase maintenance and misdirection risk. The evidence pack should show who owns address changes and how PA directory updates are checked. Run an end-to-end invoice through the intended route. The test should establish that a sender can address the correct entity, the PA can receive and deliver it, AP can ingest or retrieve it, mandatory business processing can occur, and the accounting team can trace the result. A PDF emailed to AP, a portal upload outside the regulated route or a PA demo using its own sample tenant is not proof of the company's receiving readiness. A test for one SIREN also does not cover another. Test duplicate handling with controlled reuse of a business identifier or other scenario agreed with the PA and software provider. The desired evidence is not simply “the second file disappeared”; it is a visible, explainable outcome that prevents double processing while preserving an audit trail and escalation route for false positives. Also demonstrate governance for lifecycle statuses, especially Refusée. Access to that outcome should be tightly controlled, reasons reviewed and business teams trained not to use refusal as a convenient substitute for dispute handling. Where CDAR lifecycle messages or AFNOR XP Z12-012-related implementation features are used, document what the PA and software support, what the company consumes, and how exceptions are monitored. Treat these as implementation evidence in context, not as a claim that every technical feature is independently mandatory for every taxpayer.

Guide

5. Prove issuing for large enterprises and ETIs

For each large enterprise or ETI in scope on 1 September 2026, select representative source invoices and trace them from the ERP or billing system through the PA to a meaningful downstream outcome. The evidence must identify the seller SIREN, buyer route, invoice type, source record, transformation step, format, PA reference, validation result, lifecycle response and accounting entry. Include credits or other materially different document families where they use different mappings, but do not assert a universal minimum number of tests. Coverage should follow risk and system variation. Demonstrate that the solution produces an accepted core format appropriate to the design: Factur-X, UBL or CII. Validate more than file extension or visual appearance. Show the format and business data were accepted through the intended production-like chain, including routing or address information such as BT-34 where applicable to the implementation. A readable PDF alone is insufficient because it does not prove structured data, PA transmission, correct buyer routing or downstream acceptance. A schema validator alone is also insufficient because it does not prove the real exchange route. Record lifecycle outcomes and the operational response to them. The team should know which PA or software events mean accepted for further processing, which require correction, and who investigates a rejection, refusal or unresolved state. If CDAR messages are part of the chain, retain the correlated message and show it reaches the right queue or owner. Avoid inventing universal status codes, response times or payload fields; use the current PA specification and applicable standards for the actual implementation. Finally, reconcile the transmitted invoice to AR and the general ledger. Confirm that retries cannot create duplicate invoices, numbering remains controlled, tax and totals are unchanged across transformation, and corrections remain linked to their source. Evidence from one brand or billing engine does not approve another engine with different mapping logic.

Guide

6. Prove e-reporting population, lanes and reconciliation

For large enterprises and ETIs starting e-reporting in 2026, build a population matrix before testing files. Map transaction families by legal entity, customer type, geography, VAT treatment, channel, invoicing treatment and source system. Identify which activity belongs in electronic invoicing, transaction e-reporting, payment-data reporting where applicable, or an evidenced out-of-scope category. The purpose is to prove boundaries and completeness, not merely that the PA accepted one technically valid submission. SMEs and micro-enterprises should record their later 1 September 2027 issuing and e-reporting start while still meeting the 2026 receiving requirement. Test each materially distinct applicable lane through the selected PA and software route. Keep the source population query, transformation result, PA acknowledgement or rejection, correction history and final accepted boundary. “Accepted boundary” means the organisation has identified the point at which it can reliably demonstrate the submitted population was accepted by the relevant service in its implementation; it does not imply a universal legal status or invented platform SLA. Payment-related data should have its own ownership and timing analysis rather than being assumed to follow transaction reporting automatically. Reconciliation is the decisive control. Compare source-system totals and counts to extracted, submitted, rejected, corrected and accepted populations by entity and period. Explain legitimate differences and prevent silent exclusions caused by new products, stores, marketplaces, payment methods or VAT codes. The sign-off pack should include a zero-unexplained-difference result or a bounded exception with named records. Insufficient evidence includes a mapping workshop with no population output, a PA test receipt with no source reconciliation, or a spreadsheet whose filters and extraction time are unknown. FNFE-MPE guidance can help identify operational lanes, while tax scope and fact-specific classification should be checked against current official sources and qualified advice.

Guide

7. Prove people, continuity and operational control

A technically successful test does not prove the organisation can operate on launch day. Capture production access evidence for primary and backup users across finance, tax, AP, AR, IT support and the PA administration route. Verify role separation for sensitive actions, especially routing changes, master-data changes and use of Refusée. Confirm that credentials, certificates or integrations will remain valid through launch and that an absent employee does not hold the only knowledge or permission. Require a handover record for each operational queue. It should explain normal monitoring, failed transaction diagnosis, duplicate review, correction ownership, escalation to the PA or software provider, and the accounting treatment while an item is unresolved. Supplier and customer communications should be targeted: state the correct receiving route, effective date and support contact without creating unnecessary parallel addresses. Keep a log of high-risk counterparties and unresolved routing questions rather than treating a mass email as proof of readiness. Continuity evidence should cover detection, containment, recovery and reconciliation. Show how teams identify a stuck or missing flow, preserve source documents, prevent uncontrolled resubmission, restore service, and prove that the backlog was cleared exactly once. A generic disaster-recovery policy is insufficient if it does not address invoice identifiers, PA queues, e-reporting extracts and accounting reconciliation. Equally, an informal promise that “IT will watch it” is not an operating control. Define launch monitoring by entity and lane: inbound volumes, outbound accepted and failed items, duplicates, unresolved lifecycle outcomes, reporting differences, aged queues and access failures. Set internal thresholds based on the company's volumes and risks; do not present them as statutory SLAs. Name the person who can pause a defective flow, who can approve correction, and who communicates a material issue to leadership and qualified tax advisers.

Guide

8. Run the 48-hour go/no-go meeting as a decision, not a status call

Hold the final meeting approximately 48 hours before the planned operational start, late enough for evidence to be current but early enough to act on a hard stop. Invite the accountable finance executive, tax owner, AP and AR leads, IT or integration owner, security or access owner where relevant, and the operational contacts for the PA and software. The chair should review each legal entity and flow, not invite a general percentage-complete presentation. Freeze the evidence register at a named version and display only passed, failed, expired and not-evidenced controls. Review every exception for affected records, business impact, owner, correction deadline, monitoring method and escalation trigger. If the team cannot bound the population or demonstrate the workaround, classify the matter as a hard stop. Record dependencies between entities without allowing one successful subsidiary to mask another's failure. One failed entity need not automatically block the whole group, but shared defects in the PA tenant, ERP mapping, directory configuration or reporting extract may create a wider NO-GO. The signed decision should name the entity, SIREN, approved flows, verdict, exceptions, effective time, evidence-pack version and signatories. Finance or operations owns the business launch decision; tax confirms scope and reporting analysis; technology confirms system evidence; control owners accept their actions. Governance may differ by company, but signatures must reflect real authority rather than attendance. Retain the pack under the organisation's records policy and obtain qualified advice on fact-specific retention duties instead of assuming a universal period. After sign-off, allow only controlled changes. Any routing, mapping, credential or PA configuration change should trigger impact review and, where material, renewed evidence. Start first-week monitoring immediately, with daily entity-and-lane reconciliation, an exception log, named incident route and a scheduled leadership review.

Guide

9. Example: three entities, three defensible verdicts

Consider the fictional Groupe Marceau, which uses one PA but three legal entities. Marceau Industrie SA is a large enterprise with two billing engines. Its inbound tests show correct SIREN routing, annuaire synchronization, AP ingestion, duplicate detection and controlled Refusée handling. Both billing engines produce accepted Factur-X or UBL invoices through the PA, with BT-34 routing data where required by the chosen design, correlated lifecycle evidence and AR-to-ledger reconciliation. Its transaction and payment reporting populations reconcile with no unexplained differences. Access, backup ownership and first-week monitoring are evidenced. Verdict: READY. Marceau Services SAS is an ETI. Receiving, issuing and transaction e-reporting pass, but customer notifications for 14 low-volume accounts are incomplete. The customers are identifiable; valid PA routes are already confirmed; invoices can be monitored individually; a commercial owner has a two-day deadline; and any routing failure escalates before resubmission. The issue does not hide an untested legal flow. Verdict: READY WITH CONTROLLED EXCEPTIONS. A common mistake would be calling the entity fully ready because the platform works, or calling it NO-GO without assessing whether the bounded communication gap affects regulated exchange. Marceau Retail SARL is an SME, so its 2026 focus is receiving, not the 2027 issuing and e-reporting start. Its project dashboard says 98%, but the annuaire points to an obsolete route, the only test was a PDF emailed to AP, and nobody can show a PA transaction reaching its accounting queue. Verdict: NO-GO for receiving. The successful tests of the other entities cannot cure this entity's missing evidence. Immediate actions are to correct and verify the directory route, confirm production PA coverage, run a SIREN-specific end-to-end invoice, test duplicate treatment and document operational ownership. The group should not buy software from a named-vendor league table. It should score the PA and connected software against its failed or fragile evidence: entity coverage, directory synchronization, format support for Factur-X, UBL and CII, routing-data handling, lifecycle visibility, duplicate controls, e-reporting lane coverage, reconciliation exports, role-based access, diagnostic detail, migration effort, support escalation and total cost. A paid independent readiness assessment can validate the verdicts, expose unsupported assumptions and produce an evidence-based shortlist aligned to actual systems and flows.

Checklist

List every legal entity by SIREN and separate receiving, issuing, transaction e-reporting and payment-data reporting decisions.

Confirm the applicable 2026 or 2027 timetable, entity classification and fact-specific tax scope against current authoritative sources.

Verify contracted, production-ready PA coverage and distinguish it from software that is merely compatible.

Capture annuaire and routing evidence for each receiving entity, including accountable ownership of future changes.

Run a SIREN-specific inbound invoice through the PA to AP and accounting, with correlated references.

Demonstrate duplicate prevention and governed use of lifecycle outcomes, especially Refusée.

For each large enterprise or ETI, trace representative Factur-X, UBL or CII invoices from source through PA outcome to ledger.

Reconcile applicable transaction and payment e-reporting populations from source extraction to accepted or corrected results.

Test access, backup ownership, incident escalation, recovery and first-week entity-and-lane monitoring.

Sign a versioned verdict and exception register for every entity and flow, then reassess material post-sign-off changes.

FAQ

Who should sign the final France e-invoicing go/no-go decision?

The accountable finance or operations executive should own the business launch decision, supported by tax for scope, AP and AR for operating control, and technology for system evidence. Each signer should approve a named legal entity, SIREN, flow and evidence-pack version rather than merely confirm attendance at a programme meeting.

What proves that an entity is ready to receive electronic invoices?

Strong proof connects active PA coverage, correct annuaire or routing configuration, an end-to-end invoice addressed to the entity, PA events, AP receipt, duplicate treatment and an accounting trace. A vendor statement, portal screenshot or emailed PDF does not establish that the regulated route works for that SIREN.

Can one failed legal entity block the whole group?

Not automatically. Verdicts should be made per entity and flow, so an isolated routing defect may produce one NO-GO while other entities remain ready. However, a shared defect in the PA tenant, authentication, ERP transformation or reporting extraction can invalidate evidence across several entities and should be assessed for systemic impact.

What qualifies as a controlled exception?

It is a bounded issue that does not prevent the core applicable route from operating and has identified records, an owner, deadline, monitoring control, correction path and escalation threshold. If the affected population is unknown, the workaround is untested, or the issue can silently lose regulated data, it should not be treated as controlled.

Is a successful PDF invoice test enough?

No. A visually correct PDF does not by itself prove structured Factur-X, UBL or CII data, PA exchange, buyer routing, lifecycle handling, duplicate control or accounting integration. The test must follow the intended route and preserve correlated evidence from source or sender through the PA to the receiving and accounting systems.

How can a company prove PA routing and directory readiness?

Retain entity-specific PA activation evidence, the configured receiving address and routing rule, an annuaire verification with timestamp, and a successful transaction using that route. Also document who controls changes and how synchronization is monitored, because a correct screenshot can become obsolete after a directory or configuration update.

What must large enterprises and ETIs prove for 1 September 2026?

In addition to receiving readiness, they should evidence applicable issuing and e-reporting operation: valid source invoices transmitted through a PA in an appropriate core format, routing and lifecycle outcomes, accounting traceability, mapped transaction and payment-reporting lanes, and reconciled populations. Fact-specific scope should be checked against current official guidance or qualified advice.

What evidence should be retained after sign-off?

Keep the versioned decision, entity-and-flow scope, evidence register, underlying transaction traces, reconciliations, exception approvals, test results, access and continuity proof, and records of material changes. Apply the organisation's records policy and obtain qualified advice for specific legal retention questions rather than assuming one universal period for every artefact.

Key regulations, formats and terms

FranceFrench tax administrationDGFiPimpots.gouv.frapproved platformplateforme agrééePDPFactur-XUBLCIISIRENVATe-reportingSMEmicro-enterpriseaccounting softwareEuropean CommissioneInvoicingEN 16931Directive 2014/55/EUstructured electronic invoiceVAT automationcross-border tradeFrance e-invoicing final go/no-go evidence checklist

France — Country hub

France

Open country hub →

Use the country hub to see every related deadline, checklist, format guide and software comparison for this market.

Continue reading

Official sources

We prioritize official government and EU sources where available and keep last-checked dates visible for mandate-sensitive pages.