France: run invoice exchange, transaction reporting and payment reporting
A French invoice project needs an owner for the invoice, an owner for transactions reported outside that invoice flow, and an owner for relevant cash receipts. Connecting billing to a platform covers only part of the work. A successful process also finds missing consumer transactions, allocates partial payments and explains differences between reported data and the VAT return.
Diagram: Route French transactions and payment events by scope. Conceptual routing. Determine applicable invoice, transaction-data and payment-data duties separately for each population.
This guide takes a finance team from transaction classification to a reconciled reporting cycle. Use the France routing and payment worksheet to record decisions and test results. The controls below are an operating design; the cited authority material establishes the regulatory distinctions.
Establish the company's position as of October 2026
The reception milestone has already passed. DGFiP states that all relevant businesses must be able to receive electronic invoices from 1 September 2026. Large and intermediate-sized businesses enter mandatory issuance in September 2026; SMEs and microenterprises enter issuance and the associated transaction/payment reporting phase from 1 September 2027. Determine the business's actual classification and activities rather than deriving its phase from one turnover number. DGFiP: phase timetable.
Have the tax lead approve a one-page scope record containing the legal entity, French establishments, VAT position, size classification, invoice populations and relevant dates. Identify exempt activities and public-sector customers for separate treatment. A VAT-exempt transaction and an entity using a small-business VAT exemption do not automatically answer the same scope question.
Do not postpone incoming-invoice readiness because outbound issuance starts later. AP needs a working receiving address, access for authorized users, a route into accounting and an exception process now. Test reception from an actual supplier platform, including attachments and a disputed document, rather than relying on a successful vendor demonstration.
Assign each transaction to a route
Start with sales and purchase populations from billing, tills, expense systems and the ledger. Record customer/supplier establishment, taxable-person status, transaction nature and French VAT treatment. A postal address or the presence of a French VAT number should not be the entire classification rule.
DGFiP distinguishes domestic B2B electronic invoicing from transaction reporting for relevant international and non-taxable-person transactions. Certain exempt, invoice-exempt operations fall outside the reform. Public-sector invoicing has its own Chorus Pro context. These categories need individual assessment, not a default "send every document twice" rule. DGFiP: scope explanations, DGFiP: specifications and public-sector interface.
For each population, write one complete instruction: which system supplies the data, which platform receives it, which process sends it onward, and how acceptance is returned. Keep an explicit excluded population with a reason and reviewer. That makes omissions visible without flooding a reporting flow with documents that do not belong there.
For consumer sales, decide how daily detail reaches the reporting process and how cancelled or refunded sales are represented. For international business transactions, retain the foreign counterparty identifier used in the approved mapping. When the same sale appears in a commerce system and an ERP journal, designate one authoritative reporting source.
Confirm the platform and receiving identity
Use the current term plateforme agréée, or PA. The authority's platform list separates operators satisfying all conditions, including interoperability tests, from operators still awaiting definitive registration. Save the selected provider's actual status and the date checked; a historic logo or application acknowledgement is insufficient evidence. DGFiP: current platform lists.
The finance owner should approve the entity's receiving identity and routing instructions. The integration owner should verify that changes to organizational units, addresses or provider relationships are reflected in the receiving arrangement. Use separate permissions for administrators, operators and reviewers.
Agree which services the provider performs for invoice exchange, transaction reporting and payment reporting. Ask for a sample response and export for each. A contract that only describes document delivery leaves the finance team unable to prove the completeness of the other flows.
Pin the implemented message and API versions in the worksheet. DGFiP's current technical page identifies external specifications version 3.2 dated 30 April 2026, while the company/platform common foundation is described through AFNOR XP Z12-012, XP Z12-013 and XP Z12-014. Confirm the provider's supported editions instead of implementing a historic external-specification bundle as if it defined every current interface. DGFiP: applicable technical documents.
Build payment reporting from tax treatment and real receipts
Payment reporting is not a copy of every bank transaction. DGFiP's August 2026 payment factsheet limits this flow to operations whose VAT is due on collection, excluding reverse-charged operations and the option for VAT on debits. The required receipt facts include the effective collection date and amount in euros by VAT rate. Where applicable, an electronic invoice is enriched through its *encaissée* status; other scenarios use the relevant reporting flow. DGFiP: payment data to transmit.
Put the approved cash-VAT treatment on the transaction, with an effective date and supporting decision. Treasury should identify the receipt; AR should allocate it; tax should approve the VAT-rate split; the reporting operator should send and verify the resulting event. One person may perform several tasks, but the responsibilities must remain visible.
For mixed-rate invoices, allocate using the actual approved composition. Do not divide the entire receipt by one standard rate. For a remittance covering multiple invoices, preserve the individual allocations and any unapplied balance. An amount placed in suspense is not evidence that a particular invoice has been collected.
Keep separate fields for receipt date, bank import date, allocation date, transmission date and acceptance date. This allows a late match to be corrected without pretending cash arrived later. Handle cheques, net settlement, factoring and other special receipt methods using their specific tax rules and platform use cases before extending the simple bank-transfer process below.
Schedule reporting independently from invoice delivery
DGFiP's August 2026 timetable distinguishes transaction reporting from payment reporting. For the monthly normal VAT regime, transaction reporting uses three periods within the month, while payment data is monthly and due before the tenth of the following month. The sheet gives different arrangements for other VAT regimes. Load the approved regime-specific calendar rather than adopting a universal ten-day rule. DGFiP: transmission frequency and deadlines.
Create an internal cutoff earlier than the applicable deadline. The reporting owner should see four queues: ready, rejected, awaiting information and accepted. Each unresolved item needs an accountable person and an escalation time. Document what happens when a provider response arrives after the operator has finished the daily review.
Work through an invoice and two receipts
The following is a synthetic control example, not a classification of a real company. Assume Atelier Exemple is already in the issuance/reporting phase, uses the monthly normal regime, and supplies a domestic French business service at an illustrative 20% VAT. Its tax adviser confirms VAT on collection, with no debits option or reverse charge. There are no discounts, other tax rates or foreign-currency amounts.
On 5 October, the business issues invoice FR-100 for EUR 10,000 net plus EUR 2,000 VAT, total EUR 12,000. AR checks the customer and service classification, sends the invoice through the PA and stores the transmitted document and responses against FR-100. Successful delivery updates the exchange record, but does not mark the invoice paid.
The customer pays EUR 4,800 on 20 October and EUR 7,200 on 5 November. AR allocates both receipts to FR-100. In this simple single-rate example, October's receipt contains EUR 4,000 net and EUR 800 VAT; November's contains EUR 6,000 net and EUR 1,200 VAT. The totals reconcile to the original EUR 10,000 net and EUR 2,000 VAT.
The payment operator prepares the applicable October event using the actual 20 October receipt date and EUR 4,800 collected, with the approved rate allocation and invoice reference. November's event follows the second receipt. The worksheet records the statutory calendar from the approved regime and an earlier internal submission cutoff. This example does not use invoice date as a substitute for cash date.
Alongside FR-100, assume the business has an eligible consumer-service sale of EUR 120 gross and a separate international transaction. Their routing records determine their transaction-reporting treatment. They do not become extra copies of FR-100. The consumer receipt may also belong in the applicable aggregated payment population; the tax decision and source detail must explain that inclusion.
Recover exceptions without changing history
Suppose the October receipt was imported promptly but remained unmatched until 3 November. Treasury's evidence still shows 20 October. AR allocates the receipt with that evidence, and the reporting operator reviews the affected October reporting population before submission. If it has already been submitted, follow the provider's verified correction process and retain both outcomes.
If the invoice is technically rejected, distinguish that result from commercial rejection after successful delivery. Correct data through the approved lifecycle and preserve the relationship to the original attempt. Do not create a second sale solely to clear an integration queue. A commercial credit note, a replaced technical submission and a bank refund are different events requiring different decisions.
If no cash has been collected, the operator should not invent a payment event to close an aged receivable. If a credit note follows partial payment, tax and AR must agree how it changes the debt, any refund and the applicable reporting. Use the current platform use case for the selected scenario and test it with evidence before operating it at volume.
Close the cycle and assign approval
The finance controller should reconcile the whole population first: issued documents, receipts, eligible transaction records, payment events and accepted responses. Then compare net, VAT and gross amounts by relevant period and rate. Record timing and scope differences explicitly rather than forcing invoice totals to equal collection-based VAT.
Treasury owns receipt evidence; AR/AP own allocation and invoice lifecycle; tax owns scope, treatment and calendars; integration owns transport and response capture; the controller approves the reconciliation. The PA's work belongs in this chain, with named contacts and an escalation route.
For the worked invoice, approval requires one original EUR 12,000 sale, two allocated receipts totalling EUR 12,000, payment evidence totalling EUR 800 plus EUR 1,200 illustrative VAT, and an explained reporting outcome for each period. A green transport dashboard alone does not satisfy that control.
Ready checklist
- ☐ Tax has approved entity phase, transaction populations and exclusions.
- ☐ Incoming invoices reach AP and can be retrieved with their structured content and responses.
- ☐ The PA's current status and the business's routing identity are verified.
- ☐ Invoice, transaction and payment services each have a named owner and tested response path.
- ☐ Cash-VAT, debits-option and reverse-charge decisions control payment eligibility.
- ☐ Partial receipts, mixed rates, unmatched cash and corrections have passed representative tests.
- ☐ The reporting calendar uses the business's approved VAT regime.
- ☐ The controller can reconcile the source population to accepted reporting and explain differences.
Use How to map tax and reporting obligations for the wider output inventory and localization acceptance tests for supplier evidence. Complete the linked worksheet with the provider and finance owners before accepting the operating process.
Worksheet: France routing and payment control worksheet
Copy this worksheet for each case. It records decisions and evidence; it does not determine the tax or legal treatment.
Show the worksheet
Use with the France operating guide. Duplicate the population and event blocks as needed. Blank fields are intended inputs. Keep sensitive bank/person data in the approved system and link evidence by controlled reference.
Approval and configuration
- Entity and SIREN:
- Establishment/VAT position and source:
- Size classification, phase and approval date:
- VAT reporting regime and approved calendar source:
- PA legal name, definitive-status evidence and check date:
- Receiving/routing identity and date tested:
- Message/API editions and provider release:
- Tax owner / treasury owner / AR/AP owner / integration owner / controller:
Transaction population
- Name and authoritative source system:
- Business or consumer; counterparty establishment and evidence:
- Goods/services, VAT treatment and scope decision:
- Electronic invoice / transaction reporting / public-sector route / excluded:
- Exclusion reason and reviewer, where relevant:
- Source identifiers and duplicate-prevention control:
- Applicable calendar, internal cutoff and reporting operator:
- Submission evidence and acceptance/export location:
Receipt and payment event
- Receipt evidence reference and effective collection date:
- Bank import date / allocation date:
- Invoice(s), applied amounts and unapplied balance:
- Cash-VAT eligibility decision and effective date:
- Debits option or reverse charge present, with tax approval:
- Gross euros collected, split by applicable rate:
- Reporting route: invoice status / invoice-level flow / daily aggregate:
- Original event ID / submission ID / response / acceptance date:
- Correction relationship and unresolved exception owner:
Reconciliation and tests
- Issued invoice population/count and net/VAT/gross totals:
- Transaction-report population/count and explained exclusions:
- Eligible receipt population and payment-report totals by period/rate:
- Ready / rejected / unresolved / accepted counts:
- Unmatched receipts and late allocations:
- Mixed-rate allocation test and expected result:
- Partial-payment test and expected result:
- Credit/refund/correction test and expected result:
- Technical rejection and recovery evidence:
- Differences, reviewer, resolution and approval date:
Worked control expectation
For the guide's synthetic FR-100: EUR 12,000 gross = EUR 10,000 net + EUR 2,000 VAT. October receipt EUR 4,800 contains EUR 800 VAT; November receipt EUR 7,200 contains EUR 1,200 VAT, assuming one 20% rate. Store actual receipt dates independently of allocation dates. This arithmetic is a test expectation, not a tax classification for the user's business.
Sources checked: 17 October 2026. The worked amounts and internal controls are illustrative. Entity classification, special collection methods and correction scenarios require the current applicable tax treatment and deployed PA documentation.
Related on this site
- Country pages: key facts with sources
- E-invoicing matrix: country × ERP support
- All guides
Vendor documentation is cited only as an example of the level of evidence to ask for; it is not a recommendation or a ranking. This guide is general information, not tax or legal advice. Checked 2026-10-17.
Related: Glossary – abbreviations and terms used in these guides (SAF-T, Peppol, CTC, EN 16931, IFRS and more).
Page last updated: · Markdown version