Invoice Rejection vs. Refusal under France’s E‑Invoicing Reform

✅ Rejection – Platform‑level, regulatory failure

A Rejection occurs before the invoice reaches the buyer for business processing.

It is triggered when the invoice fails mandatory regulatory or technical checks performed by the Buyer’s platform (PA‑R).

Typical rejection cases include:

• Missing or invalid mandatory legal data (invoice number, VAT ID, dates, tax breakdown, etc.)
• Structural or semantic non‑compliance with EN 16931 / Factur‑X / UBL / CII
• Duplicate invoice detection
• Inactive or non‑existent e‑invoicing address for the buyer
• Any regulatory rule explicitly enforced by platforms

Key characteristics:

• Set by the platform, not by the buyer
• Invoice is never made available to the buyer
• Status “Rejected” is final
• Invoice must be cancelled in seller accounting
• Invoice is ignored for VAT pre‑filling

✅ Rejection = “This invoice is not legally/technically acceptable.”

✅ Refusal – Buyer‑level, business decision

A Refusal occurs after the invoice has passed all platform checks and has been delivered to the buyer.

It is a buyer decision, based on strictly regulated reasons.

Permitted refusal cases (closed list – XP Z12‑012):

• Regulatory non‑compliance not checked by platforms
  (e.g. missing mandatory purchase order number required by law or contract)
• Unknown transaction
  (buyer does not recognise the seller or the underlying transaction)
• Objective contractual blocking conditions, limited to:
  • references defined in EN 16931
  • information known to the seller at invoicing time

Explicitly NOT allowed:

• Price disputes
• Quantity disputes
• Commercial disagreements
• Quality or service issues

Key characteristics:

• Set by the buyer
• Must include a mandatory refusal reason
• Status “Refused” is final
• Invoice is excluded from VAT pre‑filling
• Seller must normally reverse the invoice internally

✅ Refusal = “This invoice cannot be processed by the buyer for regulated reasons.”

One‑line comparison

Key takeaway (very important)

Neither Rejection nor Refusal is a dispute‑management tool. Both are compliance mechanisms with direct accounting and VAT impact. All commercial disputes must be handled outside the invoice lifecycle.

The actions depend on whether the company is acting as SELLER or BUYER. The refusal workflow and consequences are explicitly described in XP Z12‑014.

1. Actions for the SELLER

When the SELLER receives the “Refused” lifecycle status (with a mandatory refusal reason):

✅ Mandatory actions (standard case)

• Cancel the accounting entry of the refused invoice
  The refusal status constitutes the accounting supporting document and justifies the reversal. [2025 12 20…U Customer | Word]
• Perform the cancellation typically via an internal credit note:
  • Not transmitted to the Buyer
  • Not transmitted to the PPF (no Flow 1)
• Ensure VAT alignment:
  • The refused invoice is excluded from VAT pre‑filling
  • The seller’s VAT return must therefore exclude the VAT of the refused invoice

This guarantees consistency between accounting, VAT return, and tax pre‑population.

⚠️ Optional but permitted action: contesting the refusal

XP Z12‑014 allows the SELLER to contest the refusal, but outside the invoice lifecycle:

• No internal credit note is issued
• The invoice remains posted in seller accounting
• The dispute is handled off‑platform (commercial/legal discussion)

⚠️ Consequence:

• VAT pre‑filling will still exclude the invoice
• A VAT mismatch arises between:
  • the seller’s VAT return
  • and the tax authority’s pre‑filled data

This situation is recognised by the standard and may be clarified in future versions

2. Actions for the BUYER

When the BUYER sets the “Refused” status:

✅ Mandatory actions

• Do not post the invoice in accounting, or
• Reverse the accounting entry if it was already posted
• Use the “Refused” status as the accounting justification
• Do not expect a credit note from the seller

The refusal itself is the supporting document for the accounting reversal.

⚠️ If the refusal is later withdrawn

If the BUYER ultimately accepts the invoice (after a dispute):

• The invoice may be posted and processed
• However:
  • VAT pre‑filling remains incorrect
  • A VAT discrepancy persists between Buyer and Seller VAT returns and the tax authority data

3. What must not be done

• ❌ Do not use “Refused” for price, quantity, or quality disputes
• ❌ Do not expect a corrective invoice or credit note to circulate via platforms
• ❌ Do not change or re‑open lifecycle statuses once “Refused” is set

“Refused” is final and irreversible in the PPF lifecycle.

4. One‑line summary

In case of refusal, the company must reverse or avoid accounting the invoice, align VAT with pre‑filling, and handle any dispute strictly outside the electronic invoice lifecycle.

If helpful, I can next:

• provide a Seller / Buyer internal checklist,
• draft a Refusal governance policy, or
• map this to ERP posting rules (SAP / Oracle) for AR and AP teams.

XP Z12‑014 – B2B Use Cases Applicable to the French Electronic Invoicing Reform

Focus on Invoice Rejection and Refusal: Roles, Accounting Treatment, and VAT Impacts

1. Regulatory context

The French B2B electronic invoicing reform is built on an ecosystem involving Partner Dematerialisation Platforms (PDPs / PA) and the Public Invoicing Portal (PPF), notably through its Data Concentrator (CdD).

Within this framework, AFNOR XP Z12‑014 defines the operational B2B use cases governing the invoice lifecycle, including exceptional situations such as Rejection and Refusal, which have material accounting, operational, and VAT consequences.

A strict distinction must be made between:

• Rejection, resulting from regulatory checks performed by platforms, and
• Refusal, which is a business decision taken by the BUYER after receiving the invoice.

2. Invoice Rejection upon receipt

2.1 Nature of a Rejection

A Rejection occurs when an invoice fails mandatory regulatory compliance checks carried out upon receipt by the Buyer’s platform (PA‑R).
These checks are automated and relate to legal and technical conformity (mandatory data, structure, duplicates, etc.).

When a rejection occurs:

• the status “Rejected” is set by the PA‑R,
• this status is transmitted to:
  • the PPF Data Concentrator (CdD), and
  • the Seller’s platform (PA‑E).

The invoice is never made available to the BUYER for business processing.

2.2 Seller obligations in case of Rejection

Upon receiving the “Rejected” lifecycle status, the SELLER must:

• reverse the accounting entry of the rejected invoice,
• use the “Rejected” status as the accounting supporting document,
• typically perform this reversal through the creation of an internal credit note, which:
  • is not transmitted to the PA‑E,
  • except, where applicable, for archiving purposes only.

This ensures consistency between:

• the SELLER’s accounting records, and
• the VAT pre‑filled return, as rejected invoices are excluded from tax pre‑population.

2.3 Optional functionality of the Seller’s platform (PA‑E)

XP Z12‑014 allows an optional safeguard mechanism:

If the SELLER transmits to its PA‑E a credit note referencing a rejected invoice (via BG‑3 – reference to a previous invoice), the PA‑E:

• does not forward the credit note to the BUYER, and
• does not transmit any Flow 1 data related to this credit note to the PPF Data Concentrator.

3. Invoice Refusal by the Buyer

3.1 Definition and consequences of a Refusal

A Refusal is a business decision taken by the BUYER after the invoice has:

• passed platform compliance checks,
• been received and made available by the PA‑R.

When a refusal occurs:

• the Flow 1 data previously transmitted is ignored by the tax authorities,
• the invoice is excluded from VAT pre‑filling, both for collected VAT (SELLER) and deductible VAT (BUYER).

The “Refused” status is final and blocking: once set, no further lifecycle status may follow for that invoice.

3.2 Permitted refusal reasons

The standard explicitly prohibits using the “Refused” status to manage commercial disputes or invoice content disagreements.

A refusal must:

• always include a reason, and
• the reason must be selected from a closed list, defined in Annex A of XP Z12‑012.

Permitted reasons correspond strictly to:

• a regulatory non‑compliance not checked by the PA‑R (e.g. missing purchase order number required prior to invoicing),
• an unknown transaction, where the BUYER does not recognise the SELLER or the underlying business transaction,
• a failure to meet objective contractual conditions, limited to additional references:
  • defined in EN 16931,
  • known to the SELLER at the time of invoicing.

4. Refusal use case lifecycle (XP Z12‑014)

4.1 Key processing steps

1. Invoice creation by the SELLER and transmission to its PA‑E
2. Regulatory checks by the PA‑E and transmission:
   • of Flow 1 to the PPF Data Concentrator,
   • of the invoice to the BUYER’s PA‑R,
   • of the “Submitted” status
3. Receipt and availability of the invoice on the PA‑R
4. Refusal decision by the BUYER, including a valid refusal reason
5. Transmission of the “Refused” status by the PA‑R to:
   • the PPF Data Concentrator,
   • the SELLER’s PA‑E
6. Notification of the SELLER via its PA‑E

5. Obligations and actions following a Refusal

5.1 Platform obligations

• PA‑R must transmit the “Refused” status and its reason to both the CdD PPF and the PA‑E.
• PA‑E must make the status and reason available to the SELLER.

5.2 Seller actions

As a standard rule, based on the “Refused” status, the SELLER must:

• reverse the accounting entry of the refused invoice,
• create an internal credit note not transmitted to the PA‑E,
• thereby align its VAT reporting with the VAT pre‑filled return.

However, XP Z12‑014 recognises a specific scenario:

• the SELLER may contest the refusal,
• no credit note is issued,
• the dispute is handled outside the lifecycle status exchanges.

In this case:

• the SELLER’s VAT return continues to include the invoice VAT,
• a mismatch arises with VAT pre‑filling, since the tax authority has excluded the refused invoice.

5.3 Buyer actions

When refusing an invoice, the BUYER must:

• not post the invoice in its accounts, or reverse it if already posted,
• use the “Refused” status as the accounting supporting document,
• not expect any credit note from the SELLER.

If the refusal is later withdrawn and the invoice is accepted:

• accounting may proceed,
• but a VAT discrepancy remains between the VAT return and the pre‑filled data.

6. Key points of attention

• “Rejected” and “Refused” statuses are irreversible within the PPF lifecycle.
• Misuse or erroneous application may lead to:
  • commercial disputes,
  • VAT reconciliation issues,
  • loss of alignment with tax pre‑filling.
• Formal dispute management mechanisms are currently outside the standardised lifecycle, but may be addressed in future versions of the framework.

7. Conclusion

XP Z12‑014 provides a clear and rigorous framework for managing exceptions in the French B2B electronic invoicing system.
Rejection and Refusal are not merely technical statuses; they are accounting and tax‑relevant events with immediate consequences on VAT pre‑filling.

For organisations, the challenge is twofold:

• ensuring robust internal governance around invoice lifecycle statuses,
• preventing improper use of Refusal or Rejection that could undermine tax compliance and operational efficiency.

French E-Invoicing Mandate: A Comprehensive Briefing – VATupdate

• See also
  • E-Invoicing/Real Time Reporting – What can you find on VATupdate.com
  • Worldwide Upcoming E-Invoicing mandates, implementations and changes – Chronological
  • Collection of E-Invoicing Guides – Worldwide – VATupdate
• • Briefing / Comprehensive Guides (incl. podcasts)

• Join the Linkedin Group on Global E-Invoicing/E-Reporting/SAF-T Developments, click HERE