Invoice lifecycle

The French mandate enforces standardised tracking across 10 statuses, exchanged between PDPs and reported to the PPF concentrator. This homogeneous traceability is what turns an invoice into a living, auditable object.

Why 10 statuses?

Without standardised tracking, the client wonders where their invoice stands, the supplier does not know if it is read nor paid, and DGFiP does not know when VAT becomes due. Statuses address these three needs simultaneously:

Business visibility — the supplier instantly sees whether the invoice has been deposited, validated, approved, paid. Reduces follow-ups and accelerates collection.
Inter-PDP coordination — each PDP must notify the others of events it observes (reception, validation, refusal). The standard guarantees interoperability between 80+ competing PDPs.
Fiscal monitoring — DGFiP tracks cashing in near-real-time, which triggers VAT for cash-basis regimes (services under article 269-2 CGI).

The 10 statuses table

#	Status	Emitter	When	Minimum content
1	DEPOSEE (Deposited)	Sender PDP	Upon receipt of the invoice from the sender ERP, before PPF validation	id_facture_pdp, timestamp, sender/recipient SIRET
2	REJETEE_PPF_PDP (Rejected by PPF/PDP)	PPF or recipient PDP	EN 16931 + 24 French clauses validation failed, or recipient unknown in directory	error_code, error_message, faulty_document_id
3	REFUSEE (Refused)	Buyer (through their PDP)	Buyer contests the invoice (price, delivery, terms). Legal window: 90 days.	reason (free text), optional dispute_id
4	ENCAISSEE (Cashed)	Sender PDP or buyer	Payment received, total or partial. Triggers VAT for cash-basis regimes.	cash_date, cashed_amount, payment_reference
5	APPROUVEE (Approved)	Buyer	Buyer validates the invoice (internal workflow OK), payment commitment at maturity.	validator_id, approval_date
6	SUSPENDUE (Suspended)	Buyer	Internal workflow pending: hierarchical escalation, element verification, supporting-document request.	reason (free text), max_suspension_date (typical 30 days)
7	LITIGEE (Disputed)	Buyer or sender	Formal disagreement: derives from REFUSEE not resolved within 30 days.	dispute_id, dispute_type (PRICE, QUANTITY, QUALITY, DELIVERY, OTHER)
8	PAYEE_PARTIELLEMENT (Partially paid)	Sender PDP	Payment received but lower than the total amount due.	paid_amount, remaining_amount, payment_date
9	PAYEE_TOTALEMENT (Fully paid)	Sender PDP	Balance settled. Coexists with ENCAISSEE for cash-basis regimes.	settlement_date, payment_method, payment_reference
10	ARCHIVEE (Archived)	PDP (sender or recipient)	Invoice closed and placed in 10-year archive. Terminal status.	archive_date, legal_archive_id, final_invoice_hash

State machine and transitions

Transitions between statuses are strictly framed: any unauthorised transition is rejected by the receiving PDP with the INVALID_STATUS_TRANSITION error code. The diagram below shows authorised transitions.

text state-machine.txt

┌────────────┐
                                  │ DEPOSITED  │  (sender PDP)
                                  └────┬───────┘
                                       │
                       ┌───────────────┼──────────────────┐
                       ▼               ▼                  ▼
            ┌──────────────────┐  ┌───────────┐  ┌────────────────┐
            │ REJECTED PPF/PDP │  │ APPROVED  │  │ REFUSED        │
            │ (PPF or dest PDP)│  │ (buyer)   │  │ (buyer)        │
            └──────────────────┘  └─────┬─────┘  └───────┬────────┘
                  ▲                     │                │
                  │                     ├──>┌──────────┐ │
                  │                     │   │ DISPUTED │<┤
                  │                     │   └──────────┘ │
                  │                     │                ▼
                  │                     │       ┌────────────────┐
                  │                     │       │ SUSPENDED      │
                  │                     │       │ (escalation)   │
                  │                     │       └────────────────┘
                  │                     ▼
                  │              ┌──────────────────┐
                  │              │ PARTIALLY PAID   │ ──> ┌──────────────────┐
                  │              └──────────────────┘     │ FULLY PAID       │
                  │                                       │ + CASHED         │
                  │                                       └────────┬─────────┘
                  │                                                ▼
                  │                                       ┌────────────────┐
                  └──── (validation fail) ──────────────> │ ARCHIVED 10y   │
                                                          └────────────────┘

A few business rules from AIFE External Specifications chapter 6:

An invoice in REJETEE_PPF_PDP cannot change state any more (terminal before ARCHIVEE).
An invoice in REFUSEE can be re-emitted in a new cycle (new DEPOSEE) after correction, within 90 days.
An invoice in APPROUVEE cannot become REFUSEE; in case of late contestation, the buyer must request a credit note.
An invoice can be both APPROUVEE and SUSPENDUE for technical block (e.g. supplier IBAN being verified).
PAYEE_PARTIELLEMENT can be emitted multiple times (each partial payment) until PAYEE_TOTALEMENT.

Transmission format between PDPs

Lifecycle events are transmitted as signed JSON through the PPF REST API endpoint POST /api/v1/lifecycle/events, or directly between PDPs in AS4 PEPPOL for interop flows bypassing the PPF.

json lifecycle-event.json

{
  "version": "AIFE-LIFECYCLE-1.2",
  "id_facture_pdp": "INV-2026-04127-FR",
  "id_correlation_ppf": "PPF-2026-1052-9C1185",
  "evenement": {
    "code_statut": "PAYEE_TOTALEMENT",
    "horodatage": "2026-10-14T10:23:45Z",
    "emetteur_event": "PDP-DOCAPOSTE",
    "siret_emetteur_event": "37956002600014",
    "motif": null,
    "donnees_complementaires": {
      "mode_paiement": "VIREMENT_SEPA",
      "reference_paiement": "VIR-20261014-789456",
      "montant_paye": 2880.00
    }
  },
  "signature_ds": "<ds:Signature xmlns:ds=...>"
}

The signature_ds field is an XML Digital Signature encapsulated in the JSON, computed over the evenement block. The receiving PDP verifies the signature against the sender PDP certificate published in the AIFE directory.

Accounting impact

DEPOSEE — no buyer-side accounting impact. Seller side: pre-invoicing record.
APPROUVEE — payment commitment on buyer side (account 401 Suppliers). Seller side: account 411 Customers.
ENCAISSEE / PAYEE_TOTALEMENT — clearance of accounts 411/401, bank movement (account 512). For service provisions, triggers VAT chargeability (art. 269-2 CGI).
REJETEE_PPF_PDP / REFUSEE — reversal of the accounting entry if already recorded, or wait before accounting.
ARCHIVEE — no impact, but the archive is opposable to the tax authority in case of audit.

Special cases

Credit note. A credit note follows its own 10-status lifecycle. The AVOIR_EMIS event (optional status) ties the credit note to the original invoice via id_facture_liee.
Down payment. A down payment is a full invoice in its own right with its own lifecycle. The final balance references down payments through a textual EN 16931 mention (BT-22 NoteContent).
Set-off. In case of set-off between reciprocal debts and claims (art. 1347 of the Civil Code), each invoice carries a PAYEE_TOTALEMENT status with mode_paiement: COMPENSATION and the cross-reference.
Factoring. If the invoice is assigned to a factor, the ENCAISSEE event is emitted upon payment by the factor to the supplier. Settlement by the buyer goes to the factor (change of beneficiaire_paiement).

Foundations

Standards

Flagship messages

Tools