E-Invoice Finder
Menu
CountriesCompare softwareDeadlinesGuidesCheckerCheck obligation
ENFRDEPLNL
France · e-reporting launch controls

How to triage and recover French e-reporting at launch

Triage France e-reporting errors, separate transaction and payment data, recover failed batches safely and reconcile PA outcomes from September 2026.

Quick verdict:
  • Operating rule: keep fiscal classification, source completeness and transport state as three separate decisions.
  • Replay hazard: an ambiguous receipt can become two accepted records when the earlier attempt is presumed lost.
  • Opening move: snapshot control totals and lock the extraction window before anyone regenerates a file.
Get a France e-reporting readiness reportOfficial sources
Last checked: 21 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 launch-day scope, owners and control boundary

From 1 September 2026, large enterprises and ETIs that are sellers or service providers enter the French e-reporting timetable; they also begin issuing electronic invoices, while businesses of every size must be able to receive e-invoices. That date should trigger a dedicated e-reporting control workflow rather than a generic invoice helpdesk queue. Name one accountable business owner, a tax decision owner, an ERP or data owner, a cash and payment owner, an operations lead, and a PA liaison. Record deputies, coverage hours and the person authorised to approve a recovery submission. Build a legal-entity and population matrix before opening production. For each SIREN or relevant reporting perimeter, describe the seller role, establishment facts, VAT regime, source systems, customer population, transaction lane, possible payment lane, PA route and responsible team. The matrix should distinguish retail POS activity, e-commerce, international B2B, domestic B2C, services, deposits, adjustments and excluded or exempt operations. It should also identify entities using OSS or affected by non-established-business questions without assuming that either fact determines the French result. Treat the legal start date and scope rules as official requirements. Ownership, severity levels, dashboards and internal response targets are recommended operating controls, not statutory rules or a guaranteed automatic protection. A temporary technical incident does not remove the business's duty to control affected data. Continue unaffected activity, preserve source records and evidence, and separate correct records that failed in transmission from records that were never correctly produced. Do not infer scope merely from a foreign address, an invoice channel or the label attached by an ERP. Validate the French VAT facts, current DGFiP guidance and, where necessary, qualified tax advice. The first launch checkpoint is therefore a signed matrix showing which entity and population belongs in which lane, who decides ambiguous cases and which sources are authoritative.

Guide

2. Put every population through a classification gate

Use a classification gate before troubleshooting format or transport. First ask whether the operation belongs to mandatory domestic B2B e-invoicing. If it does, route it to the e-invoice process rather than treating it as an e-reporting transaction simply because the invoice was produced outside the normal channel. If it does not, assess whether it is a relevant B2C or international operation covered by transaction e-reporting. Then test exclusions, exemptions and fact-specific French VAT treatment. Keep unresolved items in a controlled exception population; do not force them into the nearest technical category to clear a dashboard. A useful decision record contains the seller entity and establishment position, customer status, place and nature of supply, VAT treatment, invoice or receipt evidence, reporting route, payment relevance and reviewer. Edge cases need explicit questions. Does a debit option change whether collection data is expected? Is the buyer liable under reverse charge? Does OSS affect the analysis? Is a foreign business non-established in France, and what does the DGFiP guidance say for that fact pattern? Is an exempt operation outside the dataset, or does another reporting obligation remain? Country and invoice channel are evidence, never conclusions on their own. For example, a French shop sale to a consumer may enter a B2C aggregate, while a service supplied to an overseas business may require international transaction reporting after its VAT facts are confirmed. A domestic sale between VAT-established businesses may instead follow e-invoicing. A marketplace, mixed-use customer record or missing VAT identifier should trigger investigation rather than an automatic B2C label. This gate is also a control against duplicate reporting: each source event should have one documented route for the relevant obligation. Recommended controls include rule versioning, sampled tax review and a dated decision log. They do not replace official rules. Recheck the current DGFiP material whenever the underlying VAT facts, entity structure or official guidance changes, and obtain qualified advice for material uncertainty.

Guide

3. Control the transaction-data lane at its sources

The transaction-data lane covers operations outside domestic B2B e-invoicing where French e-reporting applies, notably relevant B2C and international operations, subject to exclusions and the precise VAT facts. For B2C, data is generally aggregated by day and VAT rate. That does not mean every business has a universal daily transmission cutoff: reporting frequency and deadlines depend on the applicable VAT regime, so operators should consult the current official frequency tables. It also does not justify sending customer details that are unnecessary for the obligation. Minimise personal data and keep operational diagnostics focused on transaction attributes. Anchor each aggregate in authoritative records. For retail, that may mean closed POS or cash-register totals, tax-rate breakdowns, cancellations and validated end-of-day adjustments. For e-commerce, reconcile order, fulfilment, refund and tax-engine states before extraction. For international records, retain the facts used to determine the reporting route, including customer status and relevant VAT treatment. The exact payload fields and correction mechanism must come from current official specifications and the contracted PA or software documentation; this guide does not invent them. Consider a store that records EUR 12,000 including VAT across two VAT rates, plus a properly authorised refund. The operational control is not simply to count receipts. It is to prove that the final daily totals by VAT rate agree to the closed source after the refund and that the same events were neither reported individually nor placed in another aggregate. A cross-border goods transaction from an ERP should separately retain its classification evidence and source value, not be blended into an unexplained international bucket. Recommended controls include immutable extraction snapshots, source-to-extract counts and values, mapping-version identifiers and a quarantine for missing tax classifications. Risks include stale VAT mappings, timezone boundaries, late POS closures, netting that obscures gross activity and replay of an already accepted day. Escalate classification questions to tax and data-quality failures to the system owner before transmission.

Guide

4. Run payment data as a separate operational lane

Payment or collection data is not a second copy of transaction data. It applies notably to services and deposits on goods where VAT is due on collection. The DGFiP guidance for foreign businesses also identifies exclusions where the supplier has opted for VAT on debits or the buyer accounts for VAT under reverse charge. Confirm those facts for each relevant population rather than applying a universal service rule. Relevant collection information includes the collection date, VAT-inclusive amount split by VAT rate and the invoice number where applicable, but implementation must follow current official and PA specifications. Feed this lane from cash application and receivables events, not only from invoice creation. A payment may arrive after the underlying transaction period, be applied partially, cover several invoices, be reallocated or be reversed. Define which system is authoritative for bank receipt, settlement and application, then document how combined payments are allocated without changing the underlying accounting truth. Unapplied cash belongs in an exception queue until the reporting consequence can be established; it should not be guessed into an invoice merely to meet an internal target. Example: a customer pays half of a taxable service invoice and the remainder later. Preserve both collection events and their dates, allocate the VAT-inclusive amounts consistently by VAT rate, and link the invoice where applicable. If one transfer settles three invoices, retain the allocation evidence and make sure the extracted collection total equals the applied amount. A deposit on goods requires a specific VAT-due-on-collection check. Conversely, a service under a valid debit option or a buyer reverse-charge situation needs documented classification before payment reporting is suppressed. Recommended controls include a payment eligibility matrix, cash-to-application ageing, separate duplicate checks and reconciliation by collection date and VAT rate. Do not promise a universal deadline, status or retry method. Check the entity's VAT regime against current official timing tables. Any automated rule that decides debit-option or reverse-charge treatment should expose its evidence and version for review.

Guide

5. Diagnose the failure before choosing a recovery action

Start triage with six branches. One: the expected record was not produced, which points to scope, source-event, mapping or extraction failure. Two: it was produced incorrectly, requiring correction governance rather than blind retransmission. Three: a correct file or message was blocked before the PA, indicating an internal integration, authentication or routing problem. Four: the PA rejected the submission, in which case preserve the returned reason and use only the PA's documented resolution path. Five: no acknowledgement is visible, so the outcome is unknown and resending may create duplicates. Six: a duplicate or conflicting outcome exists, requiring quarantine and evidence-led investigation. For each incident, capture the entity, lane, reporting period, population, source boundary, extraction identifier, submission reference if available, timestamps, PA response, owner and next authorised action. Keep production diagnosis separate from transmission diagnosis. A source total missing because a store never closed is not a PA outage; a correct extract that never left middleware is not a tax-mapping defect; a PA rejection is not proof that every record in a batch is wrong. Suppose a B2C daily aggregate is absent from the PA dashboard. Confirm first that the source day closed and the extract contains the expected VAT-rate totals. Then inspect the internal hand-off and PA submission evidence. If the PA accepted it but an internal dashboard failed to update, creating a replacement batch would be the wrong response. If there is no reliable outcome, hold the record in an unknown-state queue and ask the PA to establish status through its supported process. Severity should reflect exposure, deadline proximity, affected values, duration and whether unaffected populations can continue. Internal severity and response objectives are recommended controls only; they are not official SLAs. Never invent a status code or infer acceptance from silence. Preserve logs and acknowledgements, avoid uncontrolled retries, and involve tax when the defect changes classification or reported values.

Guide

6. Recover the backlog once, with a controlled boundary

Begin recovery by freezing the affected extraction population and recording a reproducible snapshot. Establish the last accepted boundary using PA evidence rather than the last internal send attempt. Split the backlog into four groups: correct and demonstrably not transmitted, incorrect and needing approved correction, rejected with a known reason, and unknown outcome. Quarantine the last group. This prevents a transport incident from becoming a duplicate-reporting incident. Continue unaffected business flows where safe, but do not let live processing silently overtake or merge with an unbounded backlog. Before release, reconcile the frozen source window to the proposed recovery set. Remove records already evidenced as accepted, resolve overlaps at period and event level, and approve any correction according to the PA-supported method. Idempotency keys, replay protection, canary batches and quarantine are recommended technical controls whose availability and behaviour depend on the PA and software. They are not official guarantees. Ask the provider how it identifies repeat submissions, exposes accepted boundaries and handles a previous attempt with no confirmed outcome. Use a small controlled or canary batch only if the provider supports it and doing so remains consistent with official timing and the approved recovery plan. Verify the full path from submission to an unambiguous accepted or rejected outcome before increasing volume. Keep batch manifests, hashes or equivalent integrity evidence where supported, operator approvals and the mapping version. Do not transform data during transport recovery unless the underlying defect was a governed data error. For example, if 18 retail days are queued after middleware failure but two days were accepted directly by the PA during testing, the recovery manifest should exclude those accepted days and explain the evidence. If one day contains a VAT-rate mapping error, isolate it for correction rather than holding or rewriting all correct days. Promptly transmit or correct once the path is controlled, then reconcile the recovered population. No grace period, guaranteed penalty protection or universal retry rule should be assumed.

Guide

7. Prove completeness with four-way reconciliation

Reconcile four layers: the authoritative source population, the extraction population, the PA submission population and the final accepted or rejected outcome. Use both counts and values because either measure alone can conceal a defect. For B2C aggregates, compare covered days, VAT-rate buckets and monetary totals. For record-level international populations, compare the expected classified records and relevant values. Keep rejected, pending and unknown outcomes visible; do not net them into an apparently balanced accepted total. A practical reconciliation table can be described as one row per entity, lane, reporting period and population. Columns show source count and value, extracted count and value, submitted count and value, accepted count and value, rejected count and value, unknown count and value, variance, owner and evidence link. Add the source close time, extraction version and PA references needed to reproduce the position. Where aggregation changes counts, document the bridge—for example, thousands of POS receipts becoming daily VAT-rate totals—rather than expecting source and PA row counts to match directly. Payment controls must remain separate. Reconcile eligible collection events from the cash or receivables source to extracted, submitted and accepted payment data by collection date and VAT rate, with invoice linkage where applicable. Track partial settlements, combined-payment allocations, reversals and unapplied cash explicitly. A transaction reconciliation can be green while late payment data remains missing. Investigate every variance through classification, timing, mapping, filtering, aggregation, correction and transmission hypotheses. Require an evidence-backed disposition: accepted, legitimately excluded, corrected, awaiting supported resolution or escalated for tax review. Recommended tolerances may help prioritise investigation, but they should not silently write off a statutory population. Closure requires zero unexplained records and values for the defined boundary, or a documented open exception with accountable ownership. This four-way approach is an internal control design, not an official prescribed reconciliation format.

Guide

8. Operate to the correct calendar and close with evidence

Maintain an operating calendar by legal entity, VAT regime, transaction lane and payment lane. Before each reporting cycle, verify the current DGFiP frequency and deadline tables; e-reporting is not universally continuous or subject to one daily cutoff. Record the official source and date checked. Add internal preparation, review and contingency milestones, but label them as company controls rather than legal deadlines. The calendar should expose holidays, period closes, POS late closes, cash-application timing and the owner who approves each release. Handover between shifts or teams should cover the accepted boundary, frozen populations, unresolved classifications, rejected submissions, unknown outcomes, quarantined records and the next safe action. Use one decision log so that operations, tax, ERP, cash teams and the PA liaison do not run competing recoveries. An evidence pack should include the scope matrix, source snapshots, extraction and mapping versions, recovery manifests, submission references, acknowledgements or rejection evidence, reconciliations, approvals and material communications. Apply the organisation's validated retention policy and applicable legal requirements; do not assume a retention duration from this guide. Escalate immediately when the accepted boundary cannot be established, the official deadline is at risk, a material population is misclassified, values change without authorised correction, repeated submissions may exist or the PA cannot provide a determinable outcome. Escalation should state facts, impact, decision needed and owner—not merely mark the issue urgent. The tax team decides scope and VAT treatment; data and ERP owners resolve production; integration teams resolve internal transport; the PA explains its supported submission and outcome process. Close an incident only when the affected boundary is defined, correct data has reached a confirmed outcome through the supported route, rejected or corrected items have documented dispositions, four-way reconciliation has no unexplained variance, monitoring is restored and lessons have owners. These are recommended closure criteria. They do not create automatic protection, waive official obligations or guarantee protection from penalties.

Guide

9. Fictional launch scenario: three faults, one governed recovery

A fictional French ETI operates retail stores, sells consulting services to overseas businesses and collects late payments on domestic service invoices. On 2 September, its dashboard shows no outcome for one retail B2C aggregate, two cross-border service records are rejected, and a prior-period customer payment has not entered the payment dataset. The incident lead creates three work items rather than calling the whole event a PA failure. The decision log records each entity, lane, source window, known outcome and authorised owner. Retail control confirms the POS day closed and the VAT-rate totals match the frozen extract. Middleware shows a send attempt, but no dependable PA acknowledgement. The team quarantines that aggregate and asks the PA to establish status; it does not resend on silence. For the cross-border services, tax reviews customer status, place-of-supply and reverse-charge facts. One source mapping is wrong, while the other record was correctly produced but rejected for a provider-documented reason. They follow the supported correction and resolution routes separately. Cash operations finds that a partial settlement was applied after the extraction cutoff. It confirms whether collection reporting applies, preserves the collection date and VAT-inclusive allocation by rate, and adds the eligible event to the next controlled population in line with the current official timing. Early mistakes are logged: treating every foreign customer as one category, assuming a service always needs payment data, reading missing acknowledgement as rejection and comparing only batch counts. The team corrects the procedures rather than hiding those errors. Its vendor criteria now include population-level traceability, separate transaction and payment observability, clear accepted and rejected outcomes, support for uncertain submissions, duplicate protection, auditable corrections, exportable reconciliation data and evidence of PA status where direct transmission is claimed. A merely compatible non-registered solution cannot transmit e-reporting directly to the administration; the route requires a PA. The incident closes after confirmed outcomes and four-way reconciliation show no unexplained counts or values. The decision log identifies permanent mapping, cash-cutoff and monitoring actions. The next action is a formal France e-reporting readiness assessment that converts these gaps into requirements, followed by a software shortlist based on demonstrated controls and integration fit—not a named-vendor ranking. This scenario is practical information, not legal, tax or accounting advice.

Checklist

Confirm each legal entity, SIREN, VAT regime, source system and accountable owner in the launch matrix.

Classify every population through domestic B2B e-invoicing, B2C, international, excluded or exempt routes.

Separate transaction datasets from payment or collection datasets and assign different source controls.

Validate B2C daily aggregates by VAT rate against closed POS or other authoritative records.

Document debit-option, reverse-charge, OSS and non-established-business decisions with current evidence.

Record the last PA-accepted boundary before preparing any backlog submission.

Quarantine unknown outcomes and prevent automatic resubmission until status is established.

Reconcile source, extraction, PA submission and accepted or rejected outcomes using counts and values.

Check current official frequency and deadline tables for each applicable VAT regime.

Close only after corrections, acknowledgements, evidence, monitoring and unexplained variances are resolved.

FAQ

Who enters French e-reporting on 1 September 2026?

Large enterprises and ETIs that are sellers or service providers enter e-reporting from 1 September 2026. They also begin issuing e-invoices, while all businesses must be able to receive electronic invoices. Scope still depends on the operation and French VAT facts, so entity and population classification is required.

How do transaction data and payment data differ?

Transaction data describes relevant operations outside domestic B2B e-invoicing, notably covered B2C and international activity. Payment data concerns collection where applicable, notably services and deposits on goods when VAT is due on collection. Debit-option and buyer reverse-charge situations require specific checks rather than a blanket rule.

Are B2C sales always reported one receipt at a time?

No. B2C data is generally aggregated by day and VAT rate. The source-to-aggregate bridge must remain auditable, and unnecessary personal data should not be transmitted. Reporting frequency and deadlines depend on the VAT regime, so consult the current official tables rather than assuming daily transmission.

Does every cross-border transaction belong in e-reporting?

Not automatically. Customer country alone is insufficient. Check customer status, seller establishment, place and nature of supply, VAT treatment, exemptions, reverse charge, OSS and any non-established-business guidance. Material uncertainty should be reviewed against current DGFiP sources and qualified advice.

What should we do when a PA rejects a batch?

Preserve the rejection evidence, identify whether the issue affects production, classification or transmission, and follow the PA's documented resolution or correction process. Do not assume every record is defective, invent a status meaning or resend the whole population without defining the accepted and rejected boundary.

Can we resend when no acknowledgement appears?

Do not treat silence as acceptance or rejection. Place the affected population in an unknown-outcome quarantine, retain the submission evidence and use the PA's supported process to establish status. Resend only when the boundary and duplicate risk are controlled under the provider's documented capabilities.

How do we prove that backlog recovery is complete?

Perform a four-way reconciliation from authoritative source to extraction, PA submission and final accepted or rejected outcome. Compare counts and values, document aggregation bridges, keep payment reconciliation separate and require an evidence-backed disposition for every variance, rejection and unknown item.

Which PA or software capabilities matter during launch remediation?

Look for traceability by entity and population, separate transaction and payment monitoring, explicit accepted and rejected outcomes, support for uncertain submissions, duplicate protection, governed corrections, exportable reconciliation evidence and responsive incident support. Confirm that direct administrative transmission is performed by a registered PA.

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-reporting launch triage and backlog recovery

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.