E-Invoice Finder
Menu
CountriesCompare softwareDeadlinesGuidesCheckerCheck obligation
ENFRDEPLNL
France · PA-to-ERP close control

How to reconcile French e-invoices at month-end

Reconcile French PA, ERP, AP/AR and payment records with control totals, lifecycle-status exceptions, evidence and close ownership.

Quick verdict:
  • Control lens — Certify each legal entity and transmission stream independently.
  • Exposure — Offsetting errors can make aggregate values look trustworthy.
  • Start — Preserve synchronized source snapshots before investigating variances.
Get your France readiness reportOfficial sources
Last checked: 18 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. Define the close scope and each system of record

Start by writing a scope statement for the reporting period rather than pulling one company-wide total. Define the legal entity, relevant SIREN and operational SIRET identifiers, inbound and outbound directions, invoice and credit-note populations, currencies, business routes and the plateforme agréée (PA) connections included. Record whether branches share an ERP tenant, whether several PAs or technical routes are used, and whether AP, AR, treasury or tax reporting sits outside the core ERP. The control unit should be narrow enough that a difference can be assigned to an owner: for example, one legal entity, one direction, one currency and one cut-off period. Assign a system of record to each fact. The PA is the source for platform receipt, transmission and lifecycle-status events exposed by that PA. The ERP or accounting ledger is the source for accounting document numbers, posting periods, journal status and ledger balances. AP and AR workflow tools may own approval or dispute states. Bank and treasury records evidence settlement movements, while the reporting solution owns the e-reporting or payment-data submission state where relevant. Document integrations between them so a copied status is not mistaken for independent evidence. A PA does not replace the general ledger. Equally, an ERP posting does not prove that an electronic invoice was transmitted or received successfully. Keep invoice lifecycle, accounting posting, business approval, settlement and regulatory reporting as separate state families. The French reform requires affected companies to use approved platforms to transmit and receive electronic invoices and send transaction or payment data from 1 September 2026, but the monthly reconciliation described here is a recommended internal control, not a DGFiP-prescribed close frequency or deadline. Confirm scope and tax treatment with qualified advisers for the organisation’s circumstances.

Guide

2. Freeze comparable extracts at a controlled cut-off

Take PA, ERP, AP/AR and treasury extracts against one documented cut-off timestamp and timezone. Preserve the raw exports before cleansing or joining them, note when each query actually completed, and identify late-arriving records. If systems cannot produce a historical point-in-time view, record that limitation and retain the query parameters, API pagination details and row counts. A short movement log between the nominal cut-off and extraction time helps explain in-flight invoices without silently changing the population. Recommended reconciliation fields are: legal entity and SIREN/SIRET context; inbound or outbound direction; supplier invoice identifier; PA or platform identifier; ERP document identifier; buyer and seller identifiers; issue date; accounting date and period; document type; original-invoice reference for a credit note; net, tax and gross amounts; currency; route or format such as Factur-X, UBL or CII; current lifecycle label; every available status timestamp; posting state; approval state; payment state; reporting state; and a hash, checksum or immutable reference where available. These are practical matching fields, not a claim that every field is legally mandatory in every case. Normalise formats only in a derived working copy. Preserve leading zeros, original currencies, signs, source timezone and source text. Do not overwrite a French lifecycle label during translation or map several source states into one generic value before exceptions are reviewed. Mark cancellations, reversals, test documents and manually entered invoices explicitly. Access to extracts should be controlled because they contain commercially sensitive transaction data. The freeze is complete when another reviewer can identify the population, reproduce the filters and distinguish source evidence from analyst transformations.

Guide

3. Build layered control totals before matching rows

Calculate counts and monetary totals before attempting record-level joins. At minimum, split inbound from outbound, invoices from credit notes, legal entities, currencies and transmission routes. Add net, tax and gross totals where those measures are comparable, and keep document counts separate from lifecycle-message counts because one invoice can have several messages. Never add different currencies into an unexplained grand total. Where conversion is genuinely required for management reporting, retain the original-currency controls and document the rate source separately. Consider a fictional example for an outbound EUR population. At the cut-off, PA export A contains 1,204 invoice documents with gross value of EUR 2,486,000 and 36 credit notes with gross value of negative EUR 74,000. The ERP AR extract contains 1,203 invoices totalling EUR 2,481,500 and the same 36 credit notes. The EUR 4,500 invoice-count and value gap is not an official tolerance: it is a specific exception to locate. Investigation finds invoice FR-EXAMPLE-884 in the PA with no ERP document ID because an interface queue stopped after platform submission. The team links the evidence, corrects the controlled interface and verifies one accounting posting without retransmitting the invoice. Use a control matrix that shows source total, target total, difference, explained in-flight amount, unresolved amount, owner and disposition. Decide materiality and escalation rules internally based on financial-reporting risk, tax risk, duplicate-payment exposure and operational impact; do not present them as DGFiP thresholds. Counts can reveal zero-value or offsetting errors that monetary totals hide, while monetary controls reveal amount corruption that matched counts miss. A successful high-level tie is therefore necessary but insufficient: proceed to identity, status and settlement testing.

Guide

4. Reconcile identity and prove population completeness

Match records through a hierarchy rather than one fragile key. The strongest practical match usually combines supplier invoice ID, seller identifier, buyer identifier, direction and document type. Add the PA/platform ID and ERP document ID once their relationship has been established. Use gross amount, currency, issue date and original-invoice reference as corroborating attributes, not as the sole identity test. A source hash or immutable document reference can strengthen evidence where available, provided the team understands whether it represents the original payload, a converted format or an envelope. Run both directions. First, start from every PA invoice and locate exactly one expected ERP or AP/AR record. Then start from every in-scope ERP invoice and locate the corresponding PA record or a documented reason why the transaction belongs outside the electronic-invoice population. This bidirectional test catches both interface omissions and manual ERP entries. Maintain separate outcomes for exact match, valid one-to-many relationship, valid many-to-one relationship, in-flight, excluded with reason and unresolved. Credit notes must reference and net against the correct commercial event; do not simply allow them to conceal an unmatched invoice. Buyer and seller SIREN/SIRET context is especially useful when invoice numbers repeat across suppliers, branches or years. Normalise punctuation and case only after preserving originals, and never strip meaningful prefixes without testing collision risk. If one platform document produces several ERP postings, document the expected accounting design and prove the sum, currency and tax components. If several documents settle one ERP balance, keep each electronic invoice traceable. Completeness is evidenced by reproducible source populations, bidirectional matching and explained exclusions—not by a dashboard showing a reassuring percentage alone.

Guide

5. Reconcile lifecycle events separately from accounting states

Create parallel columns for PA lifecycle, ERP posting, workflow approval, payment or collection, and reporting submission. Do not force them into one universal status. A lifecycle event describes the progress of an invoice or associated message through a platform-supported process; a posted ERP document describes an accounting event; approval describes an internal business decision; settlement describes cash movement; and a reporting acknowledgement describes a different exchange. They can legitimately move at different times and in different orders. Use French labels only in their proper context. For example, Déposée may indicate a deposited/submitted stage in the relevant lifecycle, while Rejetée, Refusée and Encaissée communicate different events that require the underlying specification, profile and PA implementation to be checked. Do not assume that every business must use every optional lifecycle status, and do not invent status codes. DGFiP’s external specifications page identifies version 3.2 dated 30 April 2026 as covering invoice data, transaction data, payment data and lifecycle-status messages. AFNOR XP Z12-012 addresses invoice and lifecycle-status message formats and profiles, XP Z12-013 addresses APIs, and XP Z12-014 addresses B2B use cases. Define expected state combinations and timing windows as internal control rules. A newly received PA invoice may be unposted while validation runs; a posted invoice may await an asynchronous platform update; an approved invoice may remain unpaid; and a paid ledger item may await payment-data processing. Age these in-flight combinations from the relevant event timestamp, not merely the invoice date. Investigate when a pair remains inconsistent beyond the organisation’s documented threshold. Preserve event history rather than only the latest label, because sequence, timestamp and source response often explain whether a mismatch is normal latency, an integration failure or an unauthorised manual override.

Guide

6. Work exception buckets without blind retries

Route every unmatched or inconsistent item into a defined bucket. Missing in PA means an in-scope ERP/AP/AR document has no expected platform trace; check scope, route, identifier mapping, queue and acknowledgements before deciding whether transmission is required. Missing in ERP means a PA document lacks the expected accounting or workflow record; quarantine it from duplicate ingestion, inspect interface errors and post only through an approved recovery path. A duplicate requires comparison of document identity, amounts, payload references and prior actions before any deletion, reversal or payment release. For an amount mismatch, compare source payload, any PA format conversion, tax and rounding components, currency and ERP transformations. A stale or inconsistent status needs event-history and API/message evidence, not a manual cosmetic update. For Rejetée, establish where validation failed and correct the cause under the applicable process. For Refusée, preserve the business response and determine the appropriate commercial correction rather than treating it as a technical retry. Keep rejected and refused cases distinct. For a correction or credit note, verify the link to the original invoice and its separate accounting effect. Put unclassifiable records into an unknown-state bucket with an incident owner rather than forcing a misleading match. No-blind-retry controls are critical. Before retransmission or re-import, query by immutable ID, check acknowledgements and idempotency behaviour, confirm whether the prior attempt may have succeeded, and require maker-checker approval for high-risk recovery. Block payment when duplicate exposure is plausible, but avoid indiscriminate holds that create overdue liabilities. Record root cause, immediate containment, final disposition and preventive action. Useful decision criteria include financial value, tax impact, due date, counterparty consequence, data exposure, recurrence and whether the exception compromises population completeness. Escalate systemic mapping or queue failures even when each individual invoice is small.

Guide

7. Reconcile Encaissée, payment data and bank settlement cautiously

Treat collection and payment-data reconciliation as its own layer. Where an Encaissée lifecycle label or payment-data flow is relevant, identify what event the source system is actually reporting, which invoice it references, the amount and currency, event date, submission timestamp, acknowledgement and subsequent correction history. Do not interpret a platform label as universal proof that cash is finally settled, correctly allocated, posted to the ledger or given the right tax treatment. Scope can depend on transaction and tax circumstances, so obtain professional advice rather than assuming every invoice follows the same payment-data process. Reconcile from invoice to cash and from cash to invoice. Compare PA or reporting records with AR allocation, customer account, bank statement and treasury data. Handle partial payments by retaining cumulative collected amount and remaining balance per invoice; never mark the full document settled merely because one payment event exists. For one payment covering multiple invoices, preserve an allocation schedule. For several payments covering one invoice, preserve each bank reference and allocation timestamp. Account for fees, net settlement, refunds, chargebacks, foreign exchange, payment-on-account and timing across the cut-off without hiding differences in a suspense total. Cash-accounting situations can make the timing and accuracy of collection information particularly important, but this guide does not determine whether cash accounting or a payment-data obligation applies. Define internal checks for over-collection, negative remaining balance, collection before invoice recognition, payment data without bank support, bank receipt without allocation, and corrected or reversed collection. Example: a EUR 12,000 invoice receives EUR 7,000 on day one and EUR 5,000 after month-end. The close should show the first supported allocation and a EUR 5,000 open balance at cut-off, not a fully collected status based on the later event.

Guide

8. Retain an evidence pack and govern unresolved items

Assemble one indexed evidence pack for each close control unit. Include the signed scope statement; cut-off and timezone; source-system names and query parameters; raw extract references and integrity checks; row and amount control totals; transformation and matching logic; exception register; sampled source documents and messages; lifecycle-event histories; payment or bank support where relevant; approvals; and the final reconciliation summary. Retain access logs or export metadata when available. The evidence should let an independent reviewer reproduce the conclusion without relying on screenshots alone. Age exceptions from the most relevant timestamp and disclose the basis: platform event, interface failure, accounting posting or payment event. Set internal ageing bands, materiality, due dates and escalation levels according to risk. No French official monthly tolerance, close deadline or retention period is asserted here. Align retention and accounting evidence policy with applicable law, professional advice and the organisation’s records schedule. Owners should be named by role: AP for inbound business validation, AR for outbound and allocation, accounting for posting and close, tax for tax analysis, treasury for settlement, IT/integration for queues and mapping, and the PA relationship owner for platform escalation. Require preparer and reviewer sign-off stating total population, unresolved count and value, risk assessment, compensating control and expected resolution date. A sign-off is not permission to bury differences. Material or systemic issues should follow the organisation’s incident and financial-reporting escalation process. If an item changes after sign-off, reopen it through a change log recording old state, new state, actor, timestamp, reason, evidence and approval. Re-run affected totals and clearly version the close conclusion. The control is accepted only when every difference is matched, formally explained as in-flight or out of scope, or carried as an owned and risk-assessed exception.

Guide

9. Operate a five-day close and test PA/software capability

A practical five-day timetable can make the control repeatable, but it remains an internal design. Day 1: confirm scope, freeze extracts, validate pagination and calculate initial totals. Day 2: complete bidirectional identity matching and separate true exceptions from expected timing differences. Day 3: investigate lifecycle, posting, approval and duplicate risks; reconcile collection and bank evidence where relevant. Day 4: resolve safe corrections, quantify unresolved exposure, complete root-cause notes and obtain owner responses. Day 5: refresh affected totals, assemble evidence, review, sign off and open tracked actions. Adjust this sequence to reporting needs rather than presenting it as an official French deadline. Ask prospective or current PA and software providers whether exports and APIs expose immutable invoice IDs, complete event histories and timestamps; whether historical point-in-time reporting is possible; how pagination, corrections, conversions and idempotency work; whether inbound/outbound, credits, entity, route and currency can be filtered; whether payment-data acknowledgements are traceable; and whether reports can map PA IDs to ERP IDs. Request evidence through a sandbox or controlled sample. A dashboard total without downloadable detail, stable identifiers or audit history is not enough for a robust PA ERP reconciliation. Common mistakes are comparing only gross value, counting status messages as invoices, merging lifecycle and ledger states, retrying before checking prior success, netting credit notes against unrelated invoices, treating Encaissée as universal bank proof, changing raw extracts, ignoring timezone, and closing unknown differences with an unsupported tolerance. Acceptance criteria should require reproducible populations, tied control totals, bidirectional identity coverage, explicit state-family reconciliation, controlled duplicate recovery, supported settlement treatment, owned exceptions and reviewer evidence. The next action is to run one dry close with representative Factur-X, UBL or CII documents and lifecycle events, document capability gaps, and feed the findings into the France readiness report with named remediation owners and target dates.

Checklist

Define each legal entity, SIREN/SIRET context, direction, route, currency and reporting cut-off in scope.

Assign PA, ERP, AP/AR, treasury and reporting systems as records of specific facts rather than one universal truth.

Freeze reproducible source extracts with timestamp, timezone, filters, pagination evidence and raw totals.

Calculate separate counts and net, tax and gross controls for invoices and credit notes by meaningful population.

Match PA and ERP populations in both directions using stable identifiers and corroborating attributes.

Compare lifecycle, posting, approval, settlement and reporting states in separate fields with documented timing rules.

Bucket every missing, duplicate, mismatched, stale, rejected, refused, corrected or unknown item with an owner.

Check acknowledgements and idempotency before any retransmission, re-import, reversal or payment release.

Support Encaissée or payment-data records with allocations, partial-payment balances and bank evidence where relevant.

Retain the evidence pack, unresolved exposure, reviewer sign-off and post-close reopening log for auditability.

FAQ

How should finance reconcile a PA export with the ERP at month-end?

Freeze comparable, timestamped populations; calculate layered counts and monetary totals; then match every invoice in both directions using supplier invoice ID, buyer/seller identifiers, PA ID and ERP document ID. Investigate differences by category and keep lifecycle, ledger, approval, settlement and reporting states separate. The procedure and timing are internal controls, not a statutory monthly method prescribed by DGFiP.

Which French e-invoice statuses should be compared?

Compare the lifecycle events actually supported and applicable in the PA flow, preserving their original labels, timestamps and sequence. Déposée, Rejetée, Refusée and Encaissée may be relevant French lifecycle labels, but do not assume every business must use every optional status. Map them alongside—not on top of—ERP posting, workflow approval, payment and reporting states.

What should we do when an invoice exists in the PA but not in the ERP?

Quarantine duplicate-processing risk, inspect interface queues and mapping, check whether the document is still legitimately in flight, and search by immutable platform and invoice identifiers. Recover through an approved, idempotent process only after confirming that no prior ERP posting succeeded. Record the cause, evidence, owner and final document ID.

What if an ERP invoice has no matching PA record?

First verify entity, direction, date, route and whether the transaction belongs in the electronic-invoice population. Then inspect transmission queues, acknowledgements, rejected messages and identifier mapping. Do not retransmit blindly: confirm prior-attempt status and duplicate controls, escalate according to financial and compliance risk, and retain the documented disposition.

Does a plateforme agréée replace the accounting ledger?

No. A PA can issue, transmit and receive invoices, convert formats under applicable safeguards, extract invoice data and transmit transaction or payment data. It is not the general ledger, and its status does not automatically prove accounting posting, approval, payment, ledger classification or tax treatment. Reconciliation connects these different records without conflating them.

How can the close evidence invoice completeness for auditors?

Retain reproducible PA and ERP populations, source query parameters, cut-off details, raw counts and values, bidirectional matching results, transformation logic, event histories and a complete exception register. Add named ownership, risk assessment, supporting documents, preparer/reviewer sign-off and a controlled change log for anything reopened after close.

How should Encaissée and partial payments be reconciled?

Confirm what the source event means and link its amount, currency, date and acknowledgement to AR allocation and bank or treasury evidence where relevant. Track cumulative collection and remaining invoice balance, preserve one-to-many or many-to-one allocations, and account for refunds or reversals. Do not treat Encaissée as universal proof of final bank settlement or tax treatment.

What PA reporting capabilities matter for reconciliation?

Look for downloadable detail and APIs with stable invoice IDs, ERP-reference mapping, event history, timestamps, historical cut-offs, filters, pagination controls, correction traceability and payment-data acknowledgements. Test idempotency and format-conversion visibility with representative Factur-X, UBL or CII cases. A headline dashboard count alone cannot support a reproducible completeness control.

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-invoice month-end reconciliation between PA and ERP

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.