E-Invoice Finder
Menu
Countries Compare software Deadlines Guides Checker Check obligation
ENFRDEPLNL
Independent 2026 software acceptance-test plan

How to test France e-reporting software before go-live

Use ten evidence-led acceptance tests to assess France e-reporting software for B2C, cross-border and payment data before the 2026/2027 reform deadlines.

Quick verdict:
  • Demand replayable evidence from your own test data, not a scripted product tour.
  • Treat unexplained black-box hand-offs as an immediate procurement stop signal.
  • Make reconciliation and exportability release gates, not post-launch enhancements.
View readiness reportOfficial sources
Last checked: 24 July 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. Separate demo promises from compliance evidence

France's reform covers three related but distinct flows. Domestic B2B e-invoicing concerns invoices exchanged within scope; transaction e-reporting covers relevant sales or services to non-taxable persons such as consumers and transactions involving operators established abroad; payment or collection e-reporting concerns operations for which VAT becomes due on collection, typically services where VAT-on-debits has not been elected and reverse charge does not apply. A credible demo must classify and route each flow rather than label everything e-reporting. The timetable also affects acceptance. Every business must be able to receive e-invoices from 1 September 2026. Large and mid-sized businesses must issue e-invoices and e-report from that date, while small and micro businesses have until 1 September 2027 for issuance and e-reporting. Your project plan should use the deadline applicable to each legal entity and role, not one group-wide assumption. Regulated exchange and transmission require a platform approved by the French tax administration, now commonly called a PA; older material and vendor interfaces may still use PDP terminology. An ERP, billing application, POS or cash register, accounting system, API gateway, or solution compatible with the reform may prepare data, but it cannot perform regulated transmissions by itself unless it is approved or connected to a PA. Ordinary PDFs sent by email are not compliant electronic invoices; accepted structured approaches in the reform context include UBL, CII and mixed Factur-X. • Ask the vendor to identify the system of record, the PA, every connector and the party contractually responsible for each hand-off. • Require a transmission identifier, acknowledgement, status history and payload evidence for every demonstrated regulated flow. • Confirm whether Factur-X, UBL and CII are created, validated, transformed or merely displayed, and where the original and transformed files are retained. • Treat statements such as ready, compatible or automated as unproven until the same result can be reproduced with your controlled test pack.

Guide

2. Prepare the pre-demo test pack and acceptance rules

Before the meeting, map representative source fields from the ERP, billing software, POS, accounting system and any payment application. Include legal entity, establishment status, customer type, SIREN or foreign identifier, invoice or receipt reference, transaction date, currency, taxable amount, VAT rate, VAT amount, tax treatment, payment date, amount collected and correction links. Mask real personal information; DGFiP indicates that B2C reporting generally uses daily aggregates by VAT rate and does not expect personal customer data. Give the vendor the test pack in advance but keep several expected results undisclosed so the session tests behaviour rather than presentation. Define a named owner for tax interpretation, source data, integration, PA configuration, security and acceptance. Record the software version, configuration, PA environment and test date because a result from a generic sandbox is not evidence for your intended production design. Use binary acceptance criteria wherever possible. A scenario passes only when the classification, required fields, regulated route, acknowledgement, correction behaviour, reconciliation result and retained evidence all match the agreed expected outcome. Record a fail for manual intervention that was not declared, a field silently defaulted, an unexplained transformation, or a result that cannot be exported and replayed. • Prepare at least one legal entity for each relevant VAT regime, system landscape and implementation wave. • Build expected-result sheets approved by finance or tax and the implementation owner before the demo. • Use synthetic customers covering domestic business, domestic consumer, EU business and non-EU business cases. • Include multiple VAT rates, zero or exempt treatment where relevant, foreign currency, collection-based VAT and exception statuses. • Specify evidence formats in advance: source extract, mapped payload, PA acknowledgement, status log, reconciliation report and audit export. • Set severity rules: a wrong scope or tax route is a release blocker; an evidence or usability gap needs an owner and dated remediation plan.

Guide

3. Acceptance tests 1–3: B2C aggregation and foreign-customer data

Run these transaction tests from the real source interface wherever possible, not from fields typed directly into a vendor portal. The objective is to prove that operational data can be classified, aggregated and traced without sending unnecessary customer information. For each test, retain the input extract, mapping or transformation record, outbound e-reporting payload, PA acknowledgement, processing status and reconciliation result. If the platform aggregates records, require a drill-back from the aggregate to the contributing source totals without exposing personal B2C data. • Test 1 — Domestic B2C daily aggregation across VAT rates. Input: same-day French consumer sales of €1,000 net at 20% VAT and €400 net at 10% VAT, including distinct POS transaction references. Expected output: the correct daily period and separate aggregates by VAT rate, with totals matching the source and no consumer name, email or address. Evidence to retain: POS close report, mapping, outbound aggregate, PA acknowledgement, rate-level reconciliation and drill-back list. • Test 2 — B2C without an invoice or individual document. Input: cash-register or POS totals for small consumer sales where no customer invoice was issued, plus one voided line and one end-of-day adjustment. Expected output: reportable totals are produced from the permitted source summary, the void is excluded or reversed according to the configured lifecycle, and no fictitious invoice or customer identity is created. Evidence to retain: till close, adjustment log, aggregation calculation, transmitted payload, acceptance status and exception report. • Test 3 — Foreign B2B customer with foreign identifier and currency. Input: a sale to an operator established abroad using an applicable foreign VAT or business identifier instead of SIREN, invoiced in GBP or USD with documented accounting currency values. Expected output: the customer is not forced into a domestic SIREN rule, the transaction follows the appropriate e-reporting route, identifier type and currency fields remain traceable, and conversion logic is explicit rather than silently guessed. Evidence to retain: customer master extract, invoice, exchange-rate source and timestamp, mapped payload, PA response and currency reconciliation.

Guide

4. Acceptance tests 4–6: cross-border routing and collection events

Cross-border status and VAT due on collection are common fault lines because the necessary facts may sit in customer master data, tax determination, invoicing and cash allocation systems. Test the end-to-end chain and make the vendor show which field controls each decision. DGFiP lists collection date and amount collected split by VAT rate for payment reporting. For an electronic invoice, payment information may complement the invoice through an encaissée, or paid, status. Exact mappings and cadence depend on the VAT regime, transaction type, current specifications and PA setup, so validate the configured result against current DGFiP documentation and your adviser or PA. • Test 4 — Export and intra-EU classification. Input: one qualifying intra-EU B2B supply and one non-EU export with distinct destination, establishment, identifier and tax-treatment data. Expected output: each is distinguished from domestic B2B e-invoicing and from consumer activity, receives the configured cross-border transaction classification, and preserves the evidence supporting that classification. Evidence to retain: customer and ship-to masters, tax code decision, source documents, payloads, acknowledgements and a report comparing source tax treatment with transmitted categories. • Test 5 — Domestic service invoice with VAT due on collection. Input: a French service invoice for €1,200 net plus €240 VAT at 20%, with no VAT-on-debits election and no reverse charge, followed by full collection. Expected output: invoice handling and the later payment event remain linked; the collection date and €1,440 amount are represented with the appropriate VAT-rate split, and any paid status supplements rather than overwrites the invoice history. Evidence to retain: invoice, tax configuration, bank or allocation event, payment payload, PA acknowledgement, status timeline and ledger reconciliation. • Test 6 — Partial payments on different dates. Input: the same €1,440 receivable settled by €600 on 10 October and €840 on 28 October, with both cash entries allocated to the invoice. Expected output: two separate, correctly dated collection events or the current specification's equivalent representation, no premature full-payment status after the first receipt, correct cumulative amounts by VAT rate and a final settled balance of zero. Evidence to retain: remittance data, allocation records, both outbound events, acknowledgements, status changes and cumulative reconciliation.

Guide

5. Acceptance tests 7–10: advances, corrections and control failures

The strongest demos deliberately create lifecycle problems. Advances, refunds, tax-treatment exclusions, rejected batches and duplicate submissions reveal whether the software controls state or merely generates a plausible file. Do not accept screenshots as the only proof. Retained evidence should connect the source event to each transformed payload and PA response, show who changed what and when, preserve failed attempts, and support an independent export for audit and reconciliation. • Test 7 — Deposit or advance. Input: a €300 advance against a later €1,500 service order, followed by the final document and settlement, using the tax treatment confirmed for the test case. Expected output: the advance is classified at the correct event point, linked to the final transaction, not double-counted when the balance is billed or collected, and reflected consistently in open balances and reporting. Evidence to retain: order, advance request or invoice, receipt, final document, event links, payloads, acknowledgements and net reconciliation. • Test 8 — Credit note, refund and cancellation. Input: an accepted original sale, a partial credit reducing one VAT-rate line, a cash refund and a same-day cancellation before transmission as separate variants. Expected output: each action follows its own configured correction route, references the original where required, carries the correct sign and period, and does not erase history or create an unmatched negative. Evidence to retain: original and corrective documents, reason codes, refund event, linked payload chain, PA statuses and before-and-after totals. • Test 9 — VAT-on-debits election or reverse-charge exclusion. Input: one service transaction under a valid VAT-on-debits configuration and one transaction subject to reverse charge, then apply a payment to each. Expected output: the system does not generate collection e-reporting merely because cash was received when that payment flow is outside the configured scope; it still routes any separate transaction or invoice obligation correctly and records the reason for exclusion. Evidence to retain: tax master configuration, decision trace, invoice records, payment inputs, suppressed-event log or control report and reviewer approval. • Test 10 — Rejection, correction, resubmission, duplicate and reconciliation. Input: a batch containing one deliberately invalid mandatory field, then a corrected version, followed by an intentional resend of the accepted batch. Expected output: the invalid item or batch is visibly rejected, ownership and reason are clear, correction preserves lineage, resubmission receives a traceable outcome, and idempotency prevents double reporting. Evidence to retain: original and corrected payloads, rejection detail, user action log, submission identifiers, duplicate response, final PA acknowledgement, complete audit-trail export and source-to-PA reconciliation.

Guide

6. Use a pass-fail decision matrix

Score the demonstrated configuration, not the vendor's roadmap. Mark each line Pass, Conditional or Fail, attach an evidence reference, name the person who verified it and record any dependency. Conditional should mean a specific, testable remediation with an owner and date, not a softer word for unknown. Weight scope, PA route, payment events, correction integrity and reconciliation more heavily than interface convenience because errors there can affect regulated outputs. Security, permissions and exportability are also release criteria: finance users need suitable operational access, but no user should be able to alter accepted history without traceability. A vendor can pass product capability while the overall implementation still fails because customer masters, tax codes, POS data or cash allocation are incomplete. Keep product, integration, data and operating-model scores separate so ownership is visible. • Scope classification — Pass if domestic B2B, B2C, cross-border transaction and collection-based payment flows are distinguished from source facts with an explainable decision trace; fail if users choose a generic route manually without control. • PA connection and data mapping — Pass if the production-intended PA, connector, field transformations and structured formats are identified and testable end to end; fail if the demo stops at an export file or relies on an unspecified compatible solution. • Payment events — Pass if collection date and amount by VAT rate can be derived, linked, partially settled and reconciled; fail if invoice issue date or bank receipt alone is silently substituted without validated allocation logic. • Corrections and rejection handling — Pass if rejects have reasons, queues, owners, service targets, correction lineage and controlled resubmission; fail if records are overwritten, dropped or fixed outside the audit trail. • Reconciliation and exportability — Pass if source totals, payloads, PA acknowledgements and final statuses reconcile and can be exported in usable detail; fail if proof depends on a dashboard that cannot be independently retained. • Permissions and security — Pass if role-based access, segregation of duties, authentication controls, logging, retention and relevant data handling can be evidenced for your design; fail if administrators can change mappings or statuses without review and trace. • Implementation ownership and support — Pass if vendor, integrator, PA and customer responsibilities, incident escalation, specification updates and support coverage are documented; fail if material gaps sit between contracts or depend on an unnamed future team.

Guide

7. Work through one illustrative reconciliation

Consider a fictional retailer's daily French B2C sales: €1,000 net at 20% VAT, producing €200 VAT, and €400 net at 10% VAT, producing €40 VAT. The illustrative gross total is €1,640. The expected test result is two VAT-rate aggregates for the same reporting day whose net, VAT and gross totals reconcile to the POS close, without personal customer data. Now add a separate fictional domestic service invoice for €1,200 net and €240 VAT, subject for this test to VAT due on collection. A first receipt of €600 is allocated on 10 October and the remaining €840 on 28 October. The demo should show the two collection events, their link to the invoice, the split or mapping required by the current specification, and the transition from partly paid to paid without reporting €1,440 twice. These figures illustrate software behaviour only. They do not determine whether a real transaction is taxable, reportable, due on collection or assigned to a particular filing period. Confirm legal and tax treatment, cadence, rounding and field mappings for each entity with its adviser, PA and current DGFiP documentation. • Tie €1,640 of B2C gross activity to the till close, two VAT-rate aggregates and the accepted PA result. • Tie the €600 and €840 receipts to distinct cash-allocation records and one €1,440 receivable without an early paid status. • Force a one-cent source-versus-payload difference to prove where rounding tolerances and exception approval appear. • Export the complete evidence pack and ask a reviewer who did not attend the demo to reproduce the reconciliation.

Guide

8. Watch for common demo and implementation mistakes

A frequent mistake is to treat a successful invoice screen or PDF generation as proof of reform readiness. It says little about structured content, PA transmission, e-reporting scope, collection events, acknowledgements or operational recovery. Another is to test only happy-path domestic invoices while B2C aggregation, foreign customers and payment allocations remain unresolved. Risk also arises when teams freeze mappings too early. DGFiP specifications, platform configuration and applicable cadence must be checked at implementation and maintained thereafter. Avoid hard-coding an assumption from an old slide deck, including older PDP terminology, without confirming how the current PA service and documentation implement it. • Do not confuse a solution compatible label with approval to perform regulated transmission; verify the PA and connection. • Do not send personal B2C customer data simply because the source system holds it; prove data minimisation in the aggregate payload. • Do not infer VAT due on collection from customer type alone; test tax configuration, election and reverse-charge logic. • Do not allow rejected files, manual spreadsheet fixes or duplicate sends to sit outside monitored queues and reconciliation. • Do not accept proprietary dashboards as the sole audit trail; require durable, readable exports with identifiers and timestamps.

Guide

9. Convert the demo into a controlled implementation decision

Within two working days of the demo, issue a findings log that links every acceptance criterion to evidence, severity, owner and target date. Separate configuration fixes from missing source data, integration work, PA dependencies, policy decisions and user training. Retest blockers with the same input pack so the before-and-after result is comparable. Before production approval, rerun the suite in the intended environment with realistic volumes, role permissions and support procedures. Obtain sign-off from finance or tax, operations, IT security and the accountable implementation owner. Revalidate the design against current DGFiP material and the selected PA rather than assuming the demo remains current through go-live. • Send shortlisted vendors the same scenario pack and evidence rules to make results comparable without creating a generic feature ranking. • Assign one accountable owner for each failed control and one decision-maker for disputed tax or scope assumptions. • Schedule defect retests, volume and performance testing, access review, operational rehearsal and disaster-recovery evidence before go-live. • Agree who monitors PA rejections, unmatched payments, stale statuses and reconciliation differences each business day. • Keep the signed matrix, payload samples, acknowledgements, exports and current-source references as the baseline for change control.

Checklist

Confirm the applicable 2026 or 2027 obligations and reception role for every legal entity in scope.

Document which ERP, billing software, POS, accounting system, API and PA handle each data field and hand-off.

Prepare synthetic domestic B2B, B2C, EU and non-EU customers with valid identifier patterns and no real personal data.

Approve expected classifications, VAT treatments, payment triggers and correction outcomes before the demo.

Run all ten scenarios from source input through the production-intended PA route or a representative connected test environment.

Retain source extracts, mappings, payloads, acknowledgements, status histories and reconciliation reports for every result.

Verify partial payments, advances, refunds, cancellations, rejects and duplicate submissions without overwritten history.

Test role-based permissions, segregation of duties, logging, data minimisation and evidence retention.

Record every fail or conditional result with severity, owner, remediation date and mandatory retest.

Obtain cross-functional sign-off and recheck current DGFiP and PA specifications before production approval.

FAQ

How do I test e-reporting software in France?

Use a controlled pack of representative source transactions and define the expected classification, mapped fields, PA route, acknowledgement, status and reconciliation before the demo. Run normal, correction and failure cases from the ERP, billing software, POS or accounting system rather than entering perfect data directly into a portal. A test passes only when the vendor can export evidence connecting the original event to the accepted or rejected outcome.

What payment data must software send for VAT due on collection?

DGFiP describes payment reporting using the collection date and amount collected split by VAT rate for operations where VAT is due on collection. For an e-invoice, payment information can complement the invoice through an encaissée, or paid, status. The exact payload, cadence and applicability depend on the transaction, VAT regime, current specifications and PA setup, so validate the configured mapping with current DGFiP documentation and appropriate advisers.

How should partial payments and refunds be tested?

Post at least two receipts on different dates, allocate them to one invoice and verify that the first does not create a premature full-payment status. Then test a partial credit, cash refund and cancellation as distinct events, checking signs, dates, VAT-rate allocation, links to the original and cumulative balance. Retain each outbound event, PA response, status transition and reconciliation so history cannot be silently rewritten.

Does my ERP need to connect to an approved platform?

If the ERP is not itself a platform approved by the French tax administration, it needs a connection to a PA for the regulated exchange or transmission it cannot perform directly. A billing or ERP product described as a solution compatible with the reform may prepare, validate or display data, but compatibility alone is not approval. Ask the supplier to name the PA, show the end-to-end route and define responsibility for acknowledgements, rejects and specification changes.

How do I test B2C daily aggregation across VAT rates?

Create one day's consumer sales at two or more VAT rates, including a void or adjustment, and reconcile the source net, VAT and gross totals to separate rate-level aggregates. Check that the reporting period is correct, voids are controlled and personal customer data is absent. Retain the POS close, aggregation calculation, payload, PA acknowledgement and drill-back to contributing totals.

What proof should a vendor demo provide?

Require the source record, field mapping, transformed payload, PA submission identifier, acknowledgement, status timeline, user action log and source-to-PA reconciliation. For failed and corrected cases, keep the rejected version, reason, correction lineage and resubmission result. Screenshots can supplement this pack but should not replace machine-readable or durable exports that an independent reviewer can inspect.

Are PDF invoices sent by email enough for the French reform?

No. An ordinary PDF sent by email is not a compliant electronic invoice for the regulated reform flow. The reform context accepts structured approaches including UBL, CII and mixed Factur-X, used through the required platform route. Test the actual structured data, validation, transformation and PA acknowledgement rather than judging compliance from the human-readable invoice image.

Can one filing cadence or data mapping be used for every entity?

Do not assume so. Exact cadence and mappings can vary with VAT regime, transaction type, current technical specifications and platform configuration. Build an entity-level scope and mapping register, identify who owns each assumption, and confirm it against current DGFiP material, the selected PA and the company's adviser before acceptance and again before go-live.

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 software demo and acceptance-test plan for 2026/2027

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.