E-Invoice Finder
Menu
CountriesCompare softwareDeadlinesGuidesCheckerCheck obligation
ENFRDEPLNL
France · first e-reporting period

How to reconcile France e-reporting for the first period

Reconcile French e-reporting transaction and payment data from ERP to approved platform before the first period deadline, with controls and examples.

Quick verdict:
  • Segment assurance by reporting grain: consumer-day summaries, cross-border business records and receipts that trigger cash-basis VAT.
  • Match each entity's tax scheme to its statutory timetable; nominate a checker ahead of the filing window.
  • Withhold approval for any lane containing an untraceable platform result, regardless of apparently balanced headline figures.
Get an independent France e-reporting reviewOfficial sources
Last checked: 7 September 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. Immediate answer: identify the first live population and its owners

France's electronic invoicing reform took effect on 1 September 2026, according to the Service-Public update published on 2 September. From that date, all businesses affected by the reform must be able to receive electronic invoices. Large enterprises and entreprises de taille intermédiaire (ETIs) also began issuing electronic invoices and performing applicable e-reporting on 1 September 2026; SMEs and micro-enterprises follow for issuing and e-reporting on 1 September 2027. A group should assess the obligation legal entity by legal entity rather than infer it from a parent company's size or a software setting. Tax should confirm scope, finance should own the control totals, data or IT should evidence the interfaces, and an accountable period owner should decide whether the pack is ready for sign-off. E-reporting is not the same flow as domestic B2B e-invoicing. Domestic B2B invoices within the reform's scope travel through a registered plateforme agréée (PA) as electronic invoices. E-reporting covers required transaction data for transactions outside that domestic B2B e-invoice lane, notably relevant B2C and international B2B activity, plus payment data in the applicable VAT-on-receipt cases. The August 2026 DGFiP sheets describe different levels of aggregation and different payment treatment for those populations. Only a registered PA can transmit regulated invoice, transaction and payment data to the administration; an ERP or connector may prepare data, but it does not replace that regulated role. Nor does e-reporting replace ordinary bookkeeping, VAT controls, supporting documents or the VAT return process. It creates another governed output that must be traceable to sales, cash and accounting evidence. The practical first-period question is therefore not simply, 'Did the PA show green?' It is: did the frozen source population contain every applicable record and no excluded record; did transformation preserve the right period, category, VAT rate, amount and identity; did the PA receive the intended version; and is every final outcome or open exception evidenced? On 7 September 2026, the first normal-monthly transaction period, 1–10 September, is still open. Teams can map scope, test extracts, agree control keys and collect evidence now, but they should not describe that period as complete or sign a final submission today. A temporary transmission difficulty should not halt business activity: DGFiP's practical launch guide distinguishes data that exist but cannot be transmitted from data that are not produced correctly. Preserve business records and incident evidence, avoid knowingly sending manifestly wrong data, and route each issue to controlled correction or transmission. This operational guide is practical information, not legal, tax or accounting advice.

Guide

2. Choose the official calendar by VAT regime before setting an internal cut-off

The reporting calendar depends on the business's VAT regime, not on a convenient monthly close convention. The table below reproduces the timing in DGFiP's official frequency sheet marked 'MAJ août 2026'. Confirm the entity's current regime and option with the tax owner, verify the latest official sheet before each cycle, and check how a date falling on a non-business day is treated. The sheet states the dates below; this guide does not invent a weekend or public-holiday adjustment. | VAT regime | Transaction-data period | Official transaction deadline | Official payment-data deadline, where applicable | |---|---|---|---| | Normal monthly VAT regime | Days 1–10 | 20th of the same month | Monthly, **before the 10th of the following month** | | Normal monthly VAT regime | Days 11–20 | 30th of the same month, except February | Monthly, **before the 10th of the following month** | | Normal monthly VAT regime | Days 21–month-end | 10th of the following month | Monthly, **before the 10th of the following month** | | Normal VAT regime with the quarterly option because annual VAT paid is under €4,000 | Monthly | Before the 10th of the following month | Before the 10th of the following month | | Simplified VAT regime | Monthly | No later than a date between the 25th and 30th of the following month | No later than a date between the 25th and 30th of the following month | | Franchise en base / VAT exemption | Two-month calendar periods | No later than a date between the 25th and 30th of the month following period end | No later than a date between the 25th and 30th of the month following period end | For a business on the normal monthly VAT regime, 1–10 September 2026 is the first transaction-data period and the sheet gives 20 September 2026 as its deadline. That is a concrete planning anchor, not permission to close the population before 10 September ends. As of 7 September, later sales, credits, cancellations and corrections can still enter the period. Payment reporting for a normal-monthly entity is monthly and uses the separate 'before the 10th of the following month' timing; do not force a monthly payment population into the ten-day transaction cadence. Turn the statutory calendar into a documented internal operating calendar. For each SIREN and lane, name the VAT-regime owner, extraction owner, PA operations owner, reviewer and final approver. Set a recommended internal freeze and review cut-off early enough to investigate exceptions, but label it as a company control rather than a DGFiP deadline. For example, a company might plan a provisional completeness check after the period closes, a PA-outcome review on a later date, and escalation before the official date. Those dates must reflect actual processing time and risk; there is no universal official freeze time, tolerance, materiality threshold or sign-off rule. Keep a dated screenshot or master-data extract showing the regime used for calendar selection, the current DGFiP frequency sheet, the internal timetable and approvals. If the regime changes, version the calendar and show which period the change affects. A calendar control fails if the data are correct but assigned to the wrong cadence, or if a payment population is signed with the transaction population simply because both are visible in one dashboard.

Guide

3. Freeze a reproducible scope by entity, period, lane and source

Create a scope manifest before comparing totals. One row should identify the legal entity and SIREN, VAT regime, reporting period start and end, lane, source system, extraction timestamp, query or report version, transformation version, PA destination and accountable owner. Give the frozen run a unique internal control ID. If a rerun is needed, preserve the prior manifest and assign a new version rather than overwriting the evidence. A reviewer should be able to reconstruct what was considered in scope, what was excluded, and why. Separate at least four populations. **Domestic B2B e-invoicing** is controlled as an invoice flow through the PA and must not be silently blended into e-reporting transaction totals; applicable receipt-based payment information for a deposited domestic B2B e-invoice may be handled through enrichment of the 'Encaissée' status. **B2C transactions** are reported as daily aggregates: the August 2026 transaction sheet expects controls by listed transaction category and VAT rate, including daily taxable base excluding VAT and corresponding VAT. **International B2B transactions** are substantially invoice-level and can include applicable identifiers, countries, goods/services category, issue date, unique invoice number, taxable amount and VAT by rate, totals and currency. Some detailed line, discount and charge fields phase in on 1 September 2027, so do not apply a universal field checklist to every 2026 case. **Payment data** require a separate eligibility decision and source, usually involving bank or treasury evidence only where VAT is chargeable on actual receipt. Document exclusions positively. Examples may include out-of-period records, test documents, cancelled records that never became transactions, domestic B2B invoices controlled in the e-invoice lane, reverse-charge operations excluded from payment e-reporting, and operations under the option to pay VAT on debits. An exclusion is not valid merely because the connector omitted it. Tax should own the fiscal classification; systems teams should implement and evidence the rule. Keep unknown cases in an exception population until resolved rather than forcing them into included or excluded totals. Source selection must match the business event. Billing or ERP may be authoritative for international B2B invoice identity, issue date and amounts. POS or cash-register output may be the operational source for B2C daily/category/rate aggregates. Bank or treasury data may establish the actual receipt date and cash amount for applicable payment reporting, while billing provides invoice and VAT-rate context. The general ledger and VAT control account are important control totals, but they may differ in timing, aggregation or posting status. Explain those boundaries; do not declare one universal system of record for every field. Version all late changes. Record credits, reversals, backdated postings, reopened till days, cash reallocations and master-data corrections after the first freeze. A change log should show original value, corrected value, reason, approver, affected reporting period, extraction version and PA outcome. This prevents a clean final total from erasing evidence that an earlier version was incomplete and enables a correction to be distinguished from a duplicate replay.

Guide

4. Build a source-to-PA evidence chain and reconcile every boundary

A defensible reconciliation follows the population across ERP, billing or POS; bank or treasury where payment reporting applies; extraction and transformation; PA intake; and the acknowledgement or result available from the PA. Do not rely on a single dashboard total. Export evidence from both sides of each hand-off and use stable control keys: legal entity/SIREN, reporting period, lane, source record or aggregate key, document number where applicable, extraction version and PA trace or correlation identifier. Product-specific status labels can be recorded, but there is no universal technical status or acknowledgement name that every PA must expose. Use a matrix like this and adapt it to the entity's actual architecture. The columns are recommended internal controls, not a DGFiP-prescribed reconciliation method. | Evidence boundary | Control key | Count control | Value control | Proof to retain | |---|---|---:|---|---| | ERP/billing/POS source | SIREN + period + lane + source ID, or B2C date/category/rate | Eligible invoices, credits or daily aggregate rows | Taxable base and VAT by rate | Dated source export, selection logic and exclusion list | | Bank/treasury plus billing, where applicable | Actual receipt ID/date + invoice or allocation key + VAT rate | Eligible receipt events or aggregate rows | Amount received in euros by VAT rate | Bank/treasury evidence, allocation record and fiscal classification | | Extraction/transformation | Frozen run ID + record key + version | Input, output, excluded, quarantined and error counts | Input/output bases, VAT and payment values | Query, mapping/version report, exception file and run timestamp | | PA intake | Run ID + PA trace/correlation ID | Records or aggregates received, rejected or not visible | Values accepted at the PA boundary | PA intake export or dated machine-readable report | | PA result/acknowledgement | Original key + trace ID + result timestamp | Final, rejected, pending and unknown outcomes | Values tied to each evidenced outcome | Exportable acknowledgement/result history and rejection detail | | ERP/general-ledger control | Entity + posting period + account/tax code | Posted documents and explainable reconciling items | Revenue/base, VAT control and cash controls | Ledger extract, VAT control account and signed reconciliation | Apply two-way completeness at every boundary. Starting from source, prove that each eligible item reaches extraction and the PA exactly once or has a documented exception. Starting from PA results, prove that every reported item maps back to an authorised source record and extraction version. The reverse direction catches injected tests, stale replays, cross-entity contamination and duplicates that a source-to-PA check alone can miss. Compare counts as well as value: two missing €1,000 records can be hidden by two extra €1,000 records. Define proof boundaries precisely. 'Sent' may mean the ERP created a file, the connector made an API call, the PA accepted intake, or the PA returned a downstream outcome. Record which boundary a timestamp proves and which party owns the next evidence. If an acknowledgement is missing, classify the result as unknown until supported; do not relabel it as accepted or rejected to make the pack balance. Preserve raw exports, readable summaries and data dictionaries under the company's applicable retention policy. This guide does not invent a statutory retention period or software SLA.

Guide

5. Reconcile transaction data without letting grand totals hide errors

For B2C, start from closed POS or billing days and rebuild the expected aggregate keys. The August 2026 DGFiP transaction-data sheet states that transactions with non-taxable persons are aggregated by day. For each applicable listed transaction category and VAT rate, control the daily taxable base excluding VAT and the corresponding VAT. Compare the source day/category/rate population to the extraction and then to the PA result. A ten-day period total is not enough: a missing 5 September standard-rate row and an extra 6 September row of the same value can leave the grand total unchanged while the dates and business evidence are wrong. For international B2B, use invoice-level and credit-level controls because the official data are substantially invoice-level. Match applicable identifiers and countries, goods/services category, issue date, unique invoice number, taxable amount and VAT by rate, totals and currency. Field applicability depends on the transaction; the goal is not to dump every possible DGFiP field into one checklist. Record which required rule applies to the case and which source proves it. Treat the fields that phase in on 1 September 2027 as a roadmap item rather than inventing a 2026 rejection rule. Run completeness in both directions. The source-to-extract test finds omitted invoices, credits and daily aggregates. The extract-to-source test finds duplicates, stale files, wrong-SIREN records and rows manufactured by a faulty join. Then compare extract to PA intake and PA result using versioned trace IDs. Separate count differences from value differences, and split taxable base and VAT by rate rather than relying on gross value. Reconcile the general ledger and VAT control account with documented timing and classification items; a ledger posting date may not automatically determine the reporting period. Credits, cancellations and corrected invoices need explicit identity and period treatment. Preserve the original document, correction relationship, reason and final authorised version. Do not net an unexplained credit against unrelated sales merely to clear a value difference. For currency transactions, retain source currency, stated totals and the euro control used in the reporting process where applicable. Finance and tax should approve the conversion and rounding approach supported by current rules and company accounting policy; this page does not prescribe a universal exchange-rate method or tolerance. Investigate rounding at the lowest useful control level. A small period difference may be the accumulation of permitted calculation granularity, a mapping defect, a wrong VAT rate or an omitted negative line. Set any investigation threshold as a visible internal rule, never as a DGFiP materiality safe harbour. Require tax-classification review for unexpected zero-rate, exempt, reverse-charge, goods/services or country combinations. Equal grand totals do not prove completeness: count, date, category, rate, identity, currency, direction and PA outcome all have to support the same population.

Guide

6. Reconcile only applicable payment data, using actual receipt evidence

Payment e-reporting is narrower than a bank reconciliation. The August 2026 DGFiP payment-data sheet limits it to operations for which VAT is chargeable on receipt—for example, certain services and deposits on goods. Reverse-charge operations and transactions under the option to pay VAT on debits are excluded from this payment reporting. Tax must decide eligibility from the operation and VAT treatment; a connector must not classify every incoming bank movement as reportable merely because it has a customer reference. For eligible operations, the core controls include the actual receipt date and amount received in euros by VAT rate. Build the source population from bank or treasury receipt evidence joined to billing and tax data. Keep the raw cash event, allocation version, related invoice or invoices, VAT-rate allocation, currency conversion where relevant and eligibility decision. Reconcile receipt-event counts and values separately from invoice balances. A full invoice may generate several partial receipts, and one receipt may settle several invoices; neither relationship justifies waiting for full settlement or multiplying the cash amount through an uncontrolled one-to-many join. Handle common exceptions deliberately. **Partial payments** should retain each actual receipt date and amount rather than inherit the invoice issue date or final settlement date. **One payment across several invoices** needs a controlled allocation whose parts add back to the single bank receipt. **Refunds, chargebacks and unapplied cash** should enter an exception review: determine the proper fiscal and business treatment before inclusion, exclusion or correction. A suspense posting is not automatically a reportable receipt. Separate differences caused by timing or matching from differences caused by fiscal classification. The official sheet also describes different transmission patterns. Where payment relates to a domestic B2B electronic invoice deposited with a PA, the information passes through enrichment of the 'Encaissée' status. For an international B2B operation without an electronic invoice deposited, payment data are transmitted invoice by invoice in a global flow. B2C payment data are aggregated by day of receipt. Control each route at its stated grain; do not demand an invoice-level B2C payment export if the official model is daily aggregation, and do not reduce international B2B evidence to one monthly cash total. Keep fiscal judgement and technical matching in separate columns. Tax or a qualified adviser decides whether VAT is chargeable on receipt, whether an exclusion applies and how a difficult case should be treated. Data and finance teams prove that the approved decision was implemented once, for the correct actual receipt date, amount in euros, VAT rate, entity, period and route. Unknown eligibility remains an open tax decision; unmatched cash remains a technical or operational exception. Neither should be auto-reported to empty the queue.

Guide

7. Triage missing, rejected, wrong, duplicate and unknown outcomes

DGFiP's practical launch guide says a temporary e-reporting difficulty should not stop business activity. Use that guidance carefully: preserve data and incident evidence, distinguish data that exist but cannot be transmitted from data that are not produced correctly, correct or transmit as appropriate, avoid sending manifestly wrong data, and reconcile regularised data with invoices, receipts and accounting entries. It does not create a promised grace period, penalty protection or legal safe harbour. Use a bounded decision tree for each control key: 1. **Does the source event exist and is its eligibility supported?** If no, resolve production or fiscal classification before transmission. If yes, freeze the evidence and continue. 2. **Did the expected extraction version contain it exactly once?** If absent, correct the query or mapping and create a new controlled version. If duplicated, stop replay, identify every copy and preserve the correction trace. 3. **Can PA intake be proved with a trace ID or equivalent evidence?** If no, classify it as missing at that boundary; do not assume the administration received it. 4. **Is the PA outcome final, rejected, pending or genuinely unknown?** Use the PA's documented meaning. For an unknown or missing acknowledgement, ask for event evidence before deciding to replay. 5. **Is the data wrong?** Identify the exact SIREN, period, operations, customers where relevant, amounts, VAT and payment data. Distinguish absent records from wrong records and use the supported correction method. 6. **Would a resend create a duplicate?** Check the original trace, business key, version and PA duplicate controls. Replay only the bounded failed population and verify the post-correction result. Rejected items should be grouped by rule-level reason, source cause and owner—not simply by a red dashboard state. A data rejection may need master-data or tax-mapping correction; a transport failure may need connector recovery; an unknown result may need PA investigation before any resend. Preserve original payload evidence where policy permits, rejection detail, correction approval, new version, new trace and final reconciliation. Do not invent a universal correction file format, status sequence or response deadline. Common first-period mistakes are uncontrolled bulk resubmission, changing data and replaying it under the same undocumented version, deleting rejected rows from the denominator, treating a missing acknowledgement as a rejection, assuming a connector retry is harmless, and netting corrections into later totals without a period link. Another mistake is declaring success because ledger and PA values match while counts or identities do not. Close an exception only when the corrected business record, extraction, PA evidence and relevant ledger or receipt evidence agree, or when an authorised exclusion is documented. Keep open unknowns visible in the sign-off pack.

Guide

8. Test software and PA controls, then assemble the sign-off pack

A first-period demonstration should use anonymised examples that reproduce the buyer's real lanes, periods and exception patterns. Ask the ERP, connector and PA providers to show exports, not only screen navigation. At minimum, require clear answers to these concrete questions: 1. Can we export the complete eligible population by SIREN, reporting period and transaction or payment lane, including exclusions and their reasons? 2. Can we lock or snapshot a period without preventing later authorised corrections, and can we compare every version? 3. Does each run retain the extraction query, mapping version, timestamp, operator and source counts and values? 4. Can one source key be followed through connector events to a stable PA trace or correlation ID without manual guesswork? 5. Can we export rule-level rejection detail, affected fields, timestamps and the party that owns correction? 6. How does the workflow distinguish an absent record, a wrong accepted record, a rejected record, a pending result and a genuinely unknown acknowledgement? 7. Can a correction preserve the relationship to the original period and record while creating an auditable new version? 8. What duplicate protection is applied before and during controlled replay, and can we test it without creating a second actionable record? 9. Can we export PA intake and acknowledgement/result histories in a reusable format with a data dictionary? 10. Can the product reconcile counts, taxable bases, VAT by rate and payment values back to ERP, POS, bank/treasury and general-ledger controls without hiding reconciling items? 11. Can role access separate preparer, tax reviewer, replay operator and approver, and does the change log identify who did what? 12. Who owns evidence at every boundary, how is an unresolved cross-provider hand-off escalated, and what can the buyer retrieve without paid manual intervention? Score the answers by demonstrated evidence, applicability and exportability, not by feature labels. A product can calculate attractive totals and still fail the completeness test if it cannot reveal exclusions, preserve versions or tie acknowledgements to source records. Conversely, a rejected record is manageable when the rule, owner, correction path, duplicate control and final outcome are fully visible. Do not rank named vendors from a scripted demo; apply the same dataset and decision criteria to each candidate. The sign-off pack should contain the scope manifest; official calendar and internal cut-off; source, extraction, PA-intake and PA-outcome control totals; B2C and international B2B detail at the appropriate grain; applicable payment reconciliation; ledger and VAT-control-account bridges; exclusion register; unresolved and corrected exception log; version and trace history; and named preparer, reviewer and approver. Record whether each lane is signed, signed with an expressly authorised reconciling item, or held. Any tolerance, freeze time or approval rule is an internal control and should be labelled as such. If current systems cannot answer these questions, an independent France readiness report can reproduce the evidence gaps, separate mandatory facts from internal control choices and turn the findings into requirements for a provider shortlist or remediation plan. The useful outcome is not a generic badge: it is a decision record showing which ERP, connector and PA combination can prove complete, correct and non-duplicated reporting for the buyer's real population.

Guide

9. Fictional multi-entity walkthrough: mismatches, corrections and final decisions

The following numbers are fictional and are a forward-looking control rehearsal, not completed results available on 7 September 2026. Groupe Atlas uses a recommended internal rule that every record and euro difference must be explained, every unknown PA outcome holds the affected lane, and the period owner reviews evidence two days before the official date. Those are Groupe Atlas controls, not DGFiP thresholds or deadlines. **Atlas Retail SAS (fictional SIREN ending 110), B2C transaction lane.** After 10 September closes, its POS estate freezes run `RET-0910-v1` covering 1–10 September. The source has 28 daily category/rate aggregate rows, taxable base **€184,200** and VAT **€36,840**. Extraction v1 has 27 rows, base €177,400 and VAT €35,480. Mismatch 1 is a missing 4 September standard-rate aggregate, base €6,800 and VAT €1,360, caused by one store reopening its till day after the first data pull. The team does not edit the file manually; it closes the store day, versions the source, reruns as v2 and obtains 28 rows and the source totals. At PA review, all values total correctly but one 6 September row has no exportable outcome. Mismatch 2 is therefore an unknown acknowledgement, not a value difference. The owner holds sign-off and does not mass-resubmit. The PA later supplies the trace under the existing run, proving the row was received once. Retail's final controls are source 28, extraction 28, PA evidenced 28, base €184,200 and VAT €36,840; the transaction lane can then be signed before the applicable 20 September date. **Atlas Export SAS (fictional SIREN ending 220), international B2B transaction lane.** Its 1–10 September invoice-level source contains 12 invoices and one credit, so **13 documents**, net taxable base **€118,000** and VAT **€4,800** under the company's approved case classifications. Extraction v1 contains 12 documents, base €120,000 and VAT €5,200. Mismatch 3 is the omitted credit note for base **–€2,000** and VAT **–€400**, caused by a query that selected only positive document types. The query is corrected and the credit remains linked to its original invoice. A separate USD invoice shows a €60 base difference between the reporting transform and the ledger bridge. Mismatch 4 is an inconsistent currency conversion configuration, not rounding: the connector used a stale mapping while finance used the approved period configuration. Tax and accounting review the applicable treatment, approve one supported euro value and require both controls to use that documented version. No universal exchange-rate rule is inferred from this example. Final source, extraction and PA evidence each show 13 documents, base €118,000 and VAT €4,800; the lane remains held until the conversion approval and PA evidence are attached, then is signed. **Atlas Services SAS (fictional SIREN ending 330), applicable payment lane.** The example looks ahead to the complete 1–30 September payment period and an 8 October internal review; it is not a population that can be finalised on 7 September. Tax has identified only service operations where VAT is chargeable on actual receipt and has excluded reverse-charge and option-for-debits cases. Treasury plus billing show nine eligible receipt events with final payment value **€54,000 in euros**, allocated by VAT rate. Extraction v1 contains eight events and €48,000. Mismatch 5 is a **€6,000 partial payment received on 27 September** that the billing rule withheld until full invoice settlement. The rule is corrected to preserve the actual receipt event. One €7,500 bank receipt allocated across two invoices is then duplicated by a one-to-many join, temporarily adding €7,500. Mismatch 6 is a technical duplicate; the team removes the extra transformed record, retains the single receipt and its controlled allocation, and tests replay protection. Finally, a €1,200 unapplied customer transfer appears in the candidate file. Mismatch 7 is over-broad bank matching. Tax does not classify it as reportable merely to clear suspense; it is excluded pending proper allocation and the decision is logged. Final eligible source, extraction and PA evidence each show nine receipt events and €54,000. Domestic B2B deposited-invoice receipts are evidenced through the relevant Encaissée enrichment, international B2B payments remain invoice-level in their global flow, and B2C receipt data are controlled as daily aggregates. Services is held until 30 September closes and every outcome is evidenced, then signed at the 8 October review if those controls still match. The consolidated sign-off sheet does not add unlike grains into a misleading 'record count'. It presents Retail: 28 B2C aggregate rows, base €184,200, VAT €36,840; Export: 13 invoice/credit records, base €118,000, VAT €4,800; and Services: nine eligible receipt events, payment value €54,000. It lists seven mismatches, causes, owners, correction versions and outcome evidence. Retail and Export may be signed only after their holds clear; Services cannot be signed before its monthly period ends. Equal grand totals at an intermediate step never override a missing key, duplicate, wrong date, fiscal uncertainty or unknown PA result.

Checklist

Confirm each legal entity's SIREN, size obligation, VAT regime and applicable reporting lanes.

Copy the current official reporting calendar into a versioned period schedule and verify non-business-day treatment.

Assign the period owner, source owners, reviewer, approver and a clearly labelled internal cut-off.

Freeze source populations separately for domestic B2B e-invoicing, B2C, international B2B and applicable payments.

Retain selection logic, exclusions, extraction and mapping versions, timestamps and source control totals.

Reconcile counts, taxable bases, VAT by rate and payment values in both directions at every system boundary.

Tie every PA intake and acknowledgement or result to a stable source key and trace identifier.

Classify missing, rejected, wrong, duplicate and unknown items before correcting or replaying anything.

Reconcile corrected versions to invoices, receipts, the general ledger and VAT control account, with differences explained.

Sign or hold each lane explicitly and preserve the complete evidence pack and open correction queue.

FAQ

What is the difference between French e-reporting and e-invoicing?

E-invoicing is the regulated exchange of in-scope domestic B2B electronic invoices through a registered plateforme agréée. E-reporting sends required transaction data for relevant activity outside that domestic B2B lane, including B2C and international B2B, plus applicable payment data. Neither replaces bookkeeping, VAT controls or VAT returns. Keep the populations separate and reconcile each at its official grain.

Who must act for the first period in September 2026?

Since 1 September 2026, all affected businesses must be able to receive electronic invoices. Large enterprises and ETIs also began issuing and applicable e-reporting then; SMEs and micro-enterprises follow for issuing and e-reporting on 1 September 2027. Confirm scope for each legal entity and SIREN rather than relying only on group size or a vendor setting.

When is the first September 2026 e-reporting deadline?

For a business under the normal monthly VAT regime, the first transaction-data period is 1–10 September and the official August 2026 frequency sheet gives 20 September as the deadline. On 7 September the period is not complete. Other VAT regimes use different monthly or bimonthly calendars, and payment data have their own cadence. Verify the current sheet and treatment of non-business-day dates.

Which totals and evidence should we reconcile?

Reconcile counts, taxable bases excluding VAT, VAT by rate and applicable payment values from source to extraction, PA intake, PA result and the relevant ledger or cash controls. Keep dated exports, selection and exclusion logic, versions, stable keys, trace IDs, rejection detail and correction history. Use two-way completeness so every reported item maps to an authorised source record as well as every eligible source item reaching the PA.

Is French B2C e-reporting daily or per individual sale?

The August 2026 DGFiP transaction sheet describes B2C or non-taxable-person transactions as aggregated by day. Control each applicable day, transaction category and VAT rate using taxable base excluding VAT and corresponding VAT. Preserve underlying POS or billing evidence, but do not turn the reporting population into invoice-level or sale-level output when the official route uses daily aggregates.

Which payments must be included in payment e-reporting?

Only operations for which VAT is chargeable on receipt are within this payment reporting, such as certain services and deposits on goods. Reverse-charge operations and the option to pay VAT on debits are excluded. Control actual receipt date and amount received in euros by VAT rate. Do not report every bank movement; tax owns eligibility and technical teams evidence matching and transmission.

What should we do when a record is missing, rejected or has an unknown PA result?

Preserve the source record, extraction version, PA traces and incident evidence. Identify whether data were not produced correctly or existed but could not be transmitted. Correct the bounded cause, distinguish absent from wrong records, and check duplicate risk before replay. Keep a missing acknowledgement as unknown until supported. Avoid uncontrolled bulk resubmission and do not assume a grace period or penalty protection.

Which ERP, connector and PA capabilities matter most?

Prioritise complete population exports by SIREN, period and lane; period snapshots and version comparisons; stable cross-system trace IDs; rule-level rejection detail; controlled corrections and duplicate-safe replay; acknowledgement exports; reconciliation to ERP, POS, treasury and ledger totals; role separation; immutable change evidence; and clear ownership at every boundary. Test these with your own anonymised cases instead of relying on generic feature claims.

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 first-period e-reporting reconciliation

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.