E-Invoice Finder
Menu
CountriesCompare softwareDeadlinesGuidesCheckerCheck obligation
ENFRDEPLNL
France · rejection, refusal and exception control

Handle rejected and refused e-invoices in France

Distinguish rejected and refused French e-invoices, preserve status evidence, correct safely and prevent duplicate resubmissions.

Quick verdict:
  • Clue: the event emitter and reason reveal whether to investigate transport or a buyer decision.
  • Risk: an unverified retry can turn one unresolved case into multiple competing records.
  • First action: lock further release and preserve the complete PA evidence chain.
Get your France readiness reportOfficial sources
Last checked: 13 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. Diagnose rejection versus refusal before changing the invoice

**Official fact:** In the DGFiP v3.2 lifecycle-status annex for Flux 6, the invoice-object statuses include 200 Déposée, 210 Refusée, 212 Encaissée and 213 Rejetée. A rejection or refusal may include a reason code and a reason label. These labels must not be treated as interchangeable: a technical, schema or routing failure and a commercial buyer dispute are different operational events, although the precise meaning depends on the originating PA message and current specifications. **Recommended control:** First identify who emitted the status, at what time, against which invoice and with what reason. Treat Rejetée as a technical investigation clue and Refusée as a buyer-decision clue, not as a universal legal conclusion. Misclassification can lead to an unnecessary correction, an unresolved receivable, a duplicate transmission or a response that weakens the audit trail. Do not assume either status automatically cancels the debt or the original invoice.

Guide

2. Preserve evidence and correlate identifiers before acting

**Official fact:** Flux 6 provides lifecycle-status information, and rejection or refusal can carry coded and free-text reason information. **Recommended control:** Store the original payload, PA acknowledgement, complete status message, code and label, emitter, timestamps, channel, invoice number, party identifiers, routing endpoint, PA message ID, ERP document ID and any PPF or directory reference returned. Correlate the event to one business invoice before an operator edits, retries or credits anything. A reviewer should be able to move from the ERP invoice to the exact payload and every status without searching email. Record gaps explicitly: “reason label absent” is evidence; a guessed explanation is not.

Guide

3. Use a reason-led decision tree

**Official fact:** DGFiP identifies AFNOR XP Z12-012 for invoice and lifecycle-status formats, XP Z12-013 for APIs, and XP Z12-014 for B2B use cases; the applicable external specifications v3.2 are dated 30 April 2026. **Recommended control:** Branch from verified evidence. For syntax or format faults, validate the Factur-X, UBL or CII instance and mapping against the applicable profile. For identity or routing faults, confirm supplier and buyer data, endpoint and current directory information before changing master data. For a duplicate indication, stop automation and search ERP, PA and receiving records using business and technical identifiers. For a commercial refusal, route the stated objection to AR and the contract owner; do not “repair” a valid invoice merely to clear a queue. For an unknown or contradictory reason, quarantine the case and ask the PA for interpretation. Record the chosen branch, owner, evidence and approval.

Guide

4. Control correction and resubmission without guessing the instrument

**Official fact:** The exact allowed status transition, correction instrument, accounting or tax treatment, and resubmission method must be checked against the PA message, current specifications, the contract and appropriate advisers. There is no safe universal instruction to resend or issue a credit note for every rejection or refusal. **Recommended control:** Require a disposition decision: correct technical data, amend business data, dispute the refusal, replace or adjust the document through the appropriate process, or take no invoice action pending clarification. Before release, compare the proposed payload with the original, explain every changed field and approve any change affecting amount, tax, parties, dates or invoice identity. Link a new transmission or document to the incident and original record while preserving both. A controlled release needs evidence that the original is not still progressing, the chosen instrument is permitted, and downstream AR, AP and ledger treatment is understood.

Guide

5. Prevent duplicates across ERP and PA workflows

**Recommended control:** Design idempotency around both the business invoice and each technical submission. The ERP should create one immutable invoice identity; the integration layer should assign a unique message identifier; the PA acknowledgement should be written back rather than inferred from a timeout. A retry must reuse or replace technical identifiers according to the PA's documented rules, never by operator habit. Block a second release when the same supplier, buyer, invoice number, date, currency and gross amount already has an active or completed transmission, then require reviewed override evidence for legitimate edge cases. Reconcile daily across ERP outbound records, integration logs, PA events and buyer-facing status. Measure duplicate blocks, manual overrides, uncorrelated statuses and invoices with more than one active submission. Network failure is not proof of failure: query the authoritative state before retrying.

Guide

6. Give AR clear ownership and escalation clocks

**Recommended control:** AR should own commercial impact, while integration support owns technical diagnosis and the account or contract owner handles buyer disputes. Publish internal response clocks as management controls, not statutory or PA SLAs—for example, triage high-value or period-end cases within two business hours, assign an owner the same day and escalate unanswered buyer or PA questions after a defined interval. Severity should combine value, due-date exposure, customer criticality, close proximity and repeat frequency. The case record should show next action, accountable person, target time and evidence of contact. AR must keep collection activity aligned with the verified status and contract rather than assuming “refused” settles the matter. Track median time to diagnosis, time to accepted disposition, aged value in exception and recurrence by root cause. Escalate patterns, not just loud customers.

Guide

7. Make buyer refusals defensible in AP

**Recommended control:** AP should refuse only through an authorised workflow with a specific, reviewable reason tied to the invoice, purchase order, receipt, contract or legal-entity data. Separate a genuine commercial objection—wrong quantity, price, entity or unsupported charge—from a file-validation problem that belongs in technical handling. Require the reviewer to identify the disputed field or obligation, attach supporting evidence and state whether the whole invoice or a defined element is contested, without implying a legal effect the workflow cannot establish. Restrict refusal permissions, log the decision maker and prevent generic labels such as “incorrect” when a precise explanation is available. Monitor refusal rates by buyer team, supplier and reason category. A buyer-side control is defensible when the supplier can understand the issue, the organisation can reproduce the decision, and later settlement or correction remains linked to the original evidence.

Guide

8. Worked incident: from alert to evidenced closure

**Recommended-control example:** A PA event reports 213 Rejetée for invoice FR-1048 with an identity-related label. The monitor opens one incident and freezes automatic retry. Support captures the original UBL payload, PA message ID, emitter, timestamp and reason, then matches them to the ERP record. Master-data review finds that the transmitted buyer identifier differs from the approved customer record; AR confirms that price, tax and contractual details are not disputed. The owner asks the PA which resubmission treatment and identifiers apply, documents the answer, corrects the governed mapping and obtains approval. A single controlled transmission is released and correlated to the incident. The team verifies the subsequent PA evidence and confirms that no parallel copy exists in ERP or the PA portal. Closure records the root cause, mapping change, approver, before-and-after values, reconciliation result and a regression test. This example is a control pattern, not a universal status sequence.

Guide

9. Operate the dashboard, runbook and seven-day implementation plan

**Official fact:** Affected businesses must use a plateforme agréée (PA)—formerly called a PDP—to transmit and receive e-invoices and transmit transaction and payment data from 1 September 2026. **Recommended control:** Dashboard open cases by Rejetée, Refusée, unknown and duplicate risk; show value, age, owner, severity, reason completeness, recurrence and reconciliation gaps. The runbook should define evidence fields, decision branches, approval points, PA escalation, release locks and closure criteria. Test malformed syntax, invalid identity, ambiguous reason, timeout after submission, duplicate attempt and buyer refusal in a safe environment. Seven-day plan: Day 1 map events and owners; Day 2 define evidence and severity; Day 3 implement correlation and retry locks; Day 4 configure queues and clocks; Day 5 run six scenarios; Day 6 reconcile ERP, PA and AP/AR records; Day 7 approve the runbook and dashboard. Common mistakes are treating every alert alike, editing before preserving evidence, trusting a timeout, using vague refusal reasons and closing a case without end-to-end reconciliation.

Guide

Practical question summary

For France e-invoice rejected versus refused status workflow: French SMEs usually need to know when the deadline applies, whether a PDF is still enough, which platform path to use, how Factur-X relates to UBL and CII, what data must be cleaned, and how the accountant will work with the new flow. This guide answers those questions from an SME workflow perspective.

Guide

Decision framework for SMEs

For France e-invoice rejected versus refused status workflow: A good decision compares legal deadline, receiving readiness, issuing workflow, software integration, accountant access, archive/search and support. If two tools look similar, choose the one that can demonstrate your real invoice scenario end to end before the deadline.

Guide

How to use this guide

Use this guide to decide whether France e-invoice rejected versus refused status workflow affects your France workflow and which evidence is still missing. Start with approved platform path, Factur-X, UBL or CII data, SIREN/SIRET and VAT fields, then test receive a structured supplier invoice and issue a Factur-X or UBL/CII invoice before comparing software.

Guide

Data and terms to prepare

For France e-invoice rejected versus refused status workflow, the important terms are France e-invoice rejected versus refused status workflow, France, approved platform path, Factur-X, UBL or CII data, SIREN/SIRET and VAT fields, e-reporting cases, accountant handoff. Clean these fields in customer, supplier, tax and accounting records before rollout; otherwise validation and support issues appear during daily invoicing.

Guide

Software proof to request

For France e-invoice rejected versus refused status workflow, ask vendors to show show French platform routing, structured format handling, e-reporting, archive and accountant access using your examples. The demo should cover receive a structured supplier invoice, issue a Factur-X or UBL/CII invoice, simulate an e-reporting case, correct customer master data and explain who handles errors, corrections, archive access and accountant handoff for approved platform path, Factur-X, UBL or CII data, SIREN/SIRET and VAT fields.

Guide

Evidence before rollout

Keep official links, screenshots, test invoices and the decision reason for France e-invoice rejected versus refused status workflow. For France e-invoice rejected versus refused status workflow, the implementation file should prove how approved platform path, Factur-X, UBL or CII data, SIREN/SIRET and VAT fields, e-reporting cases were checked, not just that a tool was selected.

Guide

Decision checkpoint

Do not close France e-invoice rejected versus refused status workflow until someone can explain France e-invoice rejected versus refused status workflow in France, name the workflow owner, show one tested invoice scenario and describe how the team avoids choosing software for France before proving the real France e-invoice rejected versus refused status workflow workflow.

Checklist

Capture the complete PA status message before anyone edits the invoice.

Confirm the emitter, timestamp, invoice identity and technical message ID.

Keep reason codes, reason labels and missing fields exactly as received.

Classify technical, routing, duplicate, commercial or unknown cause from evidence.

Freeze automatic retries while the authoritative transmission state is uncertain.

Check current specifications, PA rules, contract and adviser input where relevant.

Approve changes to amount, tax, parties, dates or invoice identity explicitly.

Link every correction, dispute or transmission to the original incident record.

Reconcile ERP, integration, PA and AP or AR records before closure.

Track recurrence, exception value, diagnosis time and duplicate-prevention overrides.

FAQ

What is the operational difference between Rejetée and Refusée?

Rejetée points toward technical, schema, identity or routing investigation; Refusée points toward a buyer decision and its commercial basis. This is an operational distinction, not a universal legal definition, so verify the emitter, reason and permitted response.

Should I resend a rejected electronic invoice immediately?

No. Preserve the event, correlate the original transmission and check whether the PA processed another copy. Diagnose the reason and confirm the PA's documented resubmission method; blind retries can create duplicates or hide the cause.

Does a rejection or refusal cancel the invoice or the debt?

Do not assume so. A status alone does not establish every contractual, accounting or tax consequence. Review the event, specifications, contract and circumstances with the PA and appropriate advisers before deciding treatment.

What if the status has no useful reason code or label?

Record the gap, quarantine the case and request clarification from the PA or authorised buyer contact. Do not infer a cause from the status name; retain timestamps and identifiers for tracing.

Who should own a rejected or refused invoice status?

Technical support diagnoses transmission failures, AR manages receivable impact, AP governs buyer refusals, and contract owners handle disputes. One named incident owner should coordinate evidence, approvals, deadlines and closure.

How can we prevent a PA retry from creating a duplicate?

Use immutable invoice identities, controlled message IDs, PA acknowledgements written to the ERP and a block on parallel submissions. After a timeout, reconcile the authoritative state; silence does not prove failure.

Must every refused invoice be corrected with a credit note?

No. The correct correction, dispute or adjustment route depends on the reason, specifications, PA process, contract, accounting and tax facts. Obtain operational and professional confirmation before release.

How do AFNOR standards help investigate the incident?

DGFiP identifies XP Z12-012 for invoice and status formats, XP Z12-013 for APIs and XP Z12-014 for B2B use cases. Use them to validate exchanges while retaining the PA message and applicable v3.2 specifications as case evidence.

What do French SMEs usually search for first?

For France e-invoice rejected versus refused status workflow: They usually search for deadlines, whether PDFs are still valid, approved platforms, Factur-X, software choices and what their accountant needs.

What is the most practical risk?

For France e-invoice rejected versus refused status workflow: The practical risk is choosing software that cannot handle receiving, issuing, corrections, archive or accountant access in the real workflow.

What should I test first for France e-invoice rejected versus refused status workflow?

For France e-invoice rejected versus refused status workflow, start with receive a structured supplier invoice, issue a Factur-X or UBL/CII invoice, simulate an e-reporting case because those scenarios reveal whether the workflow is practical.

What is the main risk for France e-invoice rejected versus refused status workflow?

The main risk is choosing software for France before proving the real France e-invoice rejected versus refused status workflow workflow.

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 rejected versus refused status workflow

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.