Cycle de vie d'une facture

Le mandat français impose un suivi normalisé en 10 statuts, échangé entre PDPs et remonté au PPF concentrateur. Cette traçabilité homogène est ce qui transforme une facture en objet vivant et auditable.

Pourquoi 10 statuts ?

Sans suivi normalisé, le client se demande où en est sa facture, le fournisseur ne sait pas si elle est lue ni payée, et la DGFiP ne sait pas quand la TVA devient exigible. Les statuts répondent à ces trois besoins simultanément :

• Visibilité métier — le fournisseur voit instantanément si sa facture a été déposée, validée, approuvée, payée. Réduit les relances et accélère le recouvrement.
• Coordination inter-PDP — chaque PDP doit notifier les autres des événements qu'elle observe (réception, validation, refus). Le standard garantit l'interopérabilité entre 80+ PDPs concurrentes.
• Pilotage fiscal — la DGFiP suit en temps quasi-réel l'encaissement, qui déclenche la TVA pour les régimes encaissement (prestations de services article 269-2 du CGI).

Table des 10 statuts

Machine à états et transitions

Les transitions entre statuts sont strictement encadrées : toute transition non autorisée est rejetée par la PDP réceptrice avec le code d'erreur INVALID_STATUS_TRANSITION. Le diagramme ci-dessous montre les transitions autorisées.

┌────────────┐
                                  │ DÉPOSÉE    │  (PDP émetteur)
                                  └────┬───────┘
                                       │
                       ┌───────────────┼──────────────────┐
                       ▼               ▼                  ▼
            ┌──────────────────┐  ┌───────────┐  ┌────────────────┐
            │ REJETÉE PPF/PDP  │  │ APPROUVÉE │  │  REFUSÉE       │
            │ (PPF ou PDP-dest)│  │ (acheteur)│  │  (acheteur)    │
            └──────────────────┘  └─────┬─────┘  └───────┬────────┘
                  ▲                     │                │
                  │                     ├──>┌──────────┐ │
                  │                     │   │ LITIGÉE  │<┤
                  │                     │   └──────────┘ │
                  │                     │                ▼
                  │                     │       ┌────────────────┐
                  │                     │       │ SUSPENDUE      │
                  │                     │       │ (escalade)     │
                  │                     │       └────────────────┘
                  │                     ▼
                  │              ┌──────────────────┐
                  │              │ PAYÉE PARTIELLE  │ ──> ┌──────────────────┐
                  │              └──────────────────┘     │ PAYÉE TOTALEMENT │
                  │                                       │ + ENCAISSÉE      │
                  │                                       └────────┬─────────┘
                  │                                                ▼
                  │                                       ┌────────────────┐
                  └──── (échec validation) ─────────────> │ ARCHIVÉE 10 ans│
                                                          └────────────────┘

Quelques règles métier issues des Spécifications Externes AIFE chapitre 6 :

• Une facture REJETEE_PPF_PDP ne peut plus changer d'état (terminale avant ARCHIVEE).
• Une facture REFUSEE peut être ré-émise en nouveau cycle (nouvelle DEPOSEE) après correction, dans un délai de 90 jours.
• Une facture APPROUVEE ne peut pas devenir REFUSEE ; en cas de contestation tardive, l'acheteur doit demander un avoir.
• Une facture peut être à la fois APPROUVEE et SUSPENDUE pour blocage technique (par exemple : RIB du fournisseur en cours de vérification).
• PAYEE_PARTIELLEMENT peut être émis plusieurs fois (chaque paiement partiel) jusqu'à PAYEE_TOTALEMENT.

Format de transmission entre PDPs

Les événements de cycle de vie sont transmis en JSON signé via l'API REST PPF endpoint POST /api/v1/lifecycle/events, ou directement entre PDPs en AS4 PEPPOL pour les flux interop sans passer par le PPF.

{
  "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=...>"
}

Le champ signature_ds est un XML Digital Signature encapsulé dans le JSON, calculé sur le bloc evenement. La PDP réceptrice vérifie la signature contre le certificat de la PDP émettrice publié dans l'annuaire AIFE.

Impact comptable

• DEPOSEE — pas d'impact comptable côté acheteur. Côté émetteur : enregistrement en pré-facturation.
• APPROUVEE — engagement de paiement côté acheteur (compte 401 Fournisseurs). Côté émetteur : compte 411 Clients.
• ENCAISSEE / PAYEE_TOTALEMENT — solde des comptes 411/401, mouvement bancaire (compte 512). Pour les prestations de services, déclenche l'exigibilité de la TVA (art. 269-2 du CGI).
• REJETEE_PPF_PDP / REFUSEE — annulation de l'écriture comptable si déjà passée, ou attente avant comptabilisation.
• ARCHIVEE — pas d'impact, mais l'archive est opposable à l'administration fiscale en cas de contrôle.

Cas particuliers

• Avoir. Un avoir suit son propre cycle de vie en 10 statuts. L'événement AVOIR_EMIS (statut optionnel) lie l'avoir à la facture originelle via id_facture_liee.
• Acompte. Un acompte est une facture à part entière avec son propre cycle. Le solde final référence les acomptes via une mention textuelle EN 16931 (BT-22 NoteContent).
• Compensation. En cas de compensation entre dettes et créances réciproques (art. 1347 du Code civil), chaque facture porte un statut PAYEE_TOTALEMENT avec mode_paiement: COMPENSATION et la référence croisée.
• Affacturage. Si la facture est cédée à un factor, l'événement ENCAISSEE est émis lors du règlement par le factor au fournisseur. Le solde par l'acheteur va vers le factor (changement de beneficiaire_paiement).

Liens transverses

• Hub France — mandat e-invoicing complet
• PPF — architecture et API
• Liste des PDPs immatriculées
• E-reporting : flux et périodicité
• Calendrier 2026-2027
• AS4 — protocole de transport eDelivery
• AIFE — Spécifications Externes (téléchargement)
• BOFiP — Réforme e-invoicing