E-invoice lifecycle statuses in France: mandatory and recommended statuses explained

Quick answer. An electronic invoice passes through four mandatory statuses: filed, rejected, refused, and collected. The approved platform (formerly "partner dematerialization platform", PDP) transmits these statuses in real time. A technical rejection requires resubmission; the obligation starts on September 1, 2026 for large enterprises and mid-sized companies, and September 1, 2027 for SMEs and micro-businesses.

The electronic invoicing reform that takes effect from September 1, 2026 is not limited to file exchange. It introduces granular tracking of each invoice's lifecycle through standardized statuses. This is a major operational change: for decades, a paper invoice or email simply disappeared into the client's inbox. Today, both sender and recipient know at all times the status of processing: has the invoice been properly received? Is it being validated? Why was it rejected? When will it be paid?

This traceability is mandated by the AFNOR XP Z12-012 standard ("Formats and Profiles for Invoice Messages and Lifecycle Statuses"), which describes all possible statuses and clearly distinguishes between mandatory, recommended, and free statuses.

The approved platform (formerly "partner dematerialization platform", PDP) where you register must obligatorily emit four statuses for each processed invoice: filed, rejected, refused, and collected. This is a non-negotiable minimum with any state-registered platform.

1. FILED (initial status)#

This is the first status. It means the invoice has been technically accepted by the platform and has entered the processing flow. This status is triggered once the platform has validated the format, XML syntax, and mandatory elements (supplier SIREN, delivery address, amount, etc.). An invoice may remain in "FILED" status for a few seconds to hours while the recipient formally receives it.

Concrete example: You issue a 5,000 € invoice to a client through your approved platform. Within a minute, the platform sends you the notification: FILED status. You know your file passed validation, that its structure complies with the standards.

2. REJECTED (technical rejection by the platform)#

This status flags a technical rejection by the approved platform, before transmission to the recipient: invalid file format, missing mandatory field, non-compliance with the AFNOR XP Z12-012 standard, or recipient not found in the official directory. The invoice never reaches the client: it is blocked at source.

The platform provides a specific reason (error code). You correct it, then resubmit the invoice, which returns to "FILED" status. A technical rejection is a standard correction, not a dispute.

Critical point: a technical rejection never automatically becomes a bad debt. At Hayot Expertise, we regularly see managers worry needlessly about a first rejection: it is normal, expected, and part of how the system works.

3. REFUSED (commercial refusal by the buyer)#

This status corresponds to a commercial refusal by the recipient: the invoice is technically compliant and was received, but the client disputes it on business grounds (wrong amount, contested quantity, service not performed, duplicate). Unlike a technical rejection, the dispute is about substance, not format.

The "REFUSED" status is recorded and traced: it proves the invoice was processed and then contested. You remain the creditor; depending on the reason, you issue a corrective invoice or a credit note, then resubmit the correct document. Electronic format takes nothing away from your collection rights.

4. COLLECTED (final status)#

This status confirms the invoice has been paid. Only the platform or the client can emit it, providing the payment date and amount collected. It is the only mandatory status that includes financial data (date, amount), and these data feed the pre-filling of your VAT return (CA3). Once in "COLLECTED" status, the invoice exits the active processing circuit.

Beyond the four mandatory statuses, the AFNOR XP Z12-012 standard offers platforms the option to emit recommended and free statuses to adapt tracking to different business needs by sector.

Examples of recommended statuses#

• MADE AVAILABLE: the invoice, technically validated, is available for the client to view. Very useful for tracking, this status is not part of the mandatory core but is among the most widely offered by platforms.
• RECEIVED: the invoice has been accepted by the client and integrated into their management system. This is an intermediate status between "MADE AVAILABLE" and "APPROVED".
• APPROVED: the client has validated the invoice without yet paying it. This means it is compliant and awaiting the contractual payment window.
• PROCESSING PAYMENT: the payment order has been initiated (direct debit, bank transfer), but the amount has not yet been debited from the account.

These statuses are not mandatory, but they help suppliers anticipate cash flow timelines and identify blockages. A quality PDP will offer them at no extra charge.

Free statuses#

Each PDP may define additional custom statuses for specific needs (business statuses, sector-specific, or related to internal processes). For example, a platform for restaurants might define a "RESTAURANT-ELIGIBLE VAT INVOICE" status to flag a particular tax rule. These free statuses apply to no one and are used only by businesses that choose to.

A rejection is not a problem; it is a correction. But you must anticipate and manage it methodically.

Step 1: decode the rejection reason#

Each rejection is accompanied by an error code and message. The most common reasons:

• Code 001: Invalid SIREN or not registered with the PDP
• Code 015: Incorrectly formatted VAT (periods instead of commas, for example)
• Code 089: Delivery address missing or incomplete
• Code 103: Total amount < gross amount (mathematical error)
• Code 250: Duplicate detected (identical invoice submitted twice within 24 hours)

Consult your PDP for the exhaustive list of error codes.

Step 2: correct upstream before resubmission#

Never resubmit the same invoice twice without correction. The platform will detect the duplicate and block it. You must:

1. Correct the field that triggered rejection in your invoicing software
2. Generate a new XML/Factur-X file
3. Resubmit the file via the PDP (which assigns a new unique identifier)

Step 3: track bounces#

A good electronic invoicing dashboard should display:

• Number of rejected invoices per week
• First-attempt success rate (> 95% is a good benchmark)
• Most frequent rejection reasons (to improve your generation process)

At Hayot Expertise, we recommend a weekly review of rejections for the first three months of rollout. It is often during this "honeymoon" phase that subtle errors (poor accounting integration → bad data output) reveal themselves.

A frequent question: "What is the legal deadline for receiving status notifications?"

Regulations do not impose a maximum transmission delay for each status. However, approved PDPs commit, in their service terms, to transmit statuses within commercially reasonable timeframes:

Practical tip: verify with your PDP that it offers webhooks or a polling API to automatically retrieve statuses. Email-only notifications are obsolete and unreliable for real-time tracking.

The REJECTED status vs. bad debt trap#

A technical or application rejection never transforms an invoice into an uncollectable debt. It is simply a correction. You retain ownership of the receivable; you just need to resubmit the correct invoice. A receivable becomes uncollectable only if, after repeated legal actions, the client refuses definitively.

Refusal to collect: legal distinction#

A client who rejects an electronic invoice remains a client who refuses payment. Legal recovery procedures (formal notice, payment order, etc.) apply exactly as they do with a paper invoice. Electronic format does not diminish creditor rights.

SMEs with deadline until September 2027#

If you are an SME or micro-enterprise, the obligation to emit electronic invoices only takes effect September 1, 2027. However, the obligation to receive them begins September 1, 2026. This means:

• From Sept 1, 2026, you must receive electronic invoices from your suppliers (large enterprises)
• You are not required to emit e-invoices until Sept 1, 2027

Anticipate this transition: set up a PDP capable of receiving now, even if you do not yet have to emit.

1. Do not underestimate the data dimension#

Statuses are plain text. But each status comes with metadata (timestamps, error codes, trace references). Your invoicing software (Pennylane, Tiime, etc.) must automatically parse and archive this metadata. An invoice without a trace of its statuses is an invoice without legal justification in case of audit.

2. The importance of PDP choice#

Not all PDPs offer the same recommended statuses. A "budget" PDP may offer only the four mandatory statuses. A "premium" PDP will offer 10-15, giving you fine-grained visibility into each processing step. Verify this before signing, especially if you process high volumes (> 1,000 invoices/month).

3. Anticipate API integrations#

If you decide to use a PDP in API mode (instead of manual XML file uploads), ensure your invoicing software supports the chosen PDP's APIs. Otherwise, you will need to manage integration via a third-party technical partner, adding cost and delay.

Recently, a CEO of an international SME asked us to implement electronic invoicing. She feared a complicated journey: new interfaces, new procedures, new errors. What we observed: after three weeks of proper rollout, with a quality PDP and basic team training, rejection rates dropped from 15% to < 2%. The statuses that seemed complex became a source of peace of mind. Instead of wondering "did my invoice arrive?" the CEO could read on her dashboard: "847 invoices filed, 819 collected, 28 awaiting client validation."

The real difficulty is not technical; it is change management. Accountants must change reconciliation habits. Sales teams must accept that clients have greater visibility into invoice processing. IT teams must configure the right APIs. But once this transition succeeds, electronic invoicing becomes a competitive advantage: you collect faster, you identify operational blockages immediately, and you have irrefutable proof of each invoice's processing.

Hayot Expertise advice. Do not leave e-invoice statuses to chance. Invest 15 days of work (internal or assisted) to choose the right PDP, configure alerts, and train your teams to read statuses. It is during this "honeymoon" phase that you prevent 80% of future friction. After September 2026, it will be too late to correct bad choices.