Logo FactPulse
✓ Valider un PDF Factur-X ⚡ Convertir en Factur-X

Messages CDAR : Guide Complet du Cycle de Vie des Factures Électroniques 2026

Résumé : Avec la réforme de la facturation électronique (septembre 2026), les messages CDAR deviennent incontournables pour suivre le cycle de vie des factures. Cet article décrypte la norme AFNOR XP Z12-012, les règles de validation Schematron BR-FR-CDV, et montre comment implémenter les 31 codes statut via API.

Introduction

La réforme de la facturation électronique en France, régie par les articles 289bis, 290 et 290A du Code Général des Impôts, introduit une obligation de traçabilité complète des factures B2B et B2G. Au cœur de cette traçabilité : les messages CDAR (Cross Domain Acknowledgement and Response).

Ces messages, standardisés par l'UN/CEFACT et adaptés au contexte français par la Commission AFNOR, permettent aux Plateformes Agréées (PA), au Portail Public de Facturation (PPF) et aux entreprises de communiquer les statuts des factures tout au long de leur cycle de vie.

Note terminologique : Depuis juillet 2025, l'administration utilise officiellement le terme « Plateforme Agréée » (PA) plutôt que « Plateforme de Dématérialisation Partenaire » (PDP). Ce changement met l'accent sur l'agrément délivré par la DGFiP. Le terme PDP reste couramment utilisé dans l'écosystème mais est désormais obsolète dans les documents officiels.

Qu'est-ce qu'un Message CDAR ?

Un message CDAR est un document XML qui transporte une information de statut concernant une facture. Il répond à des questions comme :

  • La facture a-t-elle été reçue ?
  • A-t-elle été approuvée ou rejetée ?
  • A-t-elle été payée ?
  • Y a-t-il un litige ?

Structure d'un Message CDAR

<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossDomainAcknowledgementAndResponse
    xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossDomainAcknowledgementAndResponse:100"
    xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100">

    <!-- Contexte du document -->
    <rsm:ExchangedDocumentContext>
        <ram:BusinessProcessSpecifiedDocumentContextParameter>
            <ram:ID>REGULATED</ram:ID>
        </ram:BusinessProcessSpecifiedDocumentContextParameter>
        <ram:GuidelineSpecifiedDocumentContextParameter>
            <ram:ID>urn.cpro.gouv.fr:1p0:CDV:invoice</ram:ID>
        </ram:GuidelineSpecifiedDocumentContextParameter>
    </rsm:ExchangedDocumentContext>

    <!-- Identification du message -->
    <rsm:ExchangedDocument>
        <ram:ID>CDV-2025-001</ram:ID>
        <ram:IssueDateTime>...</ram:IssueDateTime>
        <ram:SenderTradeParty>...</ram:SenderTradeParty>
        <ram:RecipientTradeParty>...</ram:RecipientTradeParty>
    </rsm:ExchangedDocument>

    <!-- Statut de la facture référencée -->
    <rsm:AcknowledgementDocument>
        <ram:TypeCode>23</ram:TypeCode>
        <ram:ReferenceReferencedDocument>
            <ram:IssuerAssignedID>FAC-2025-001</ram:IssuerAssignedID>
            <ram:ProcessConditionCode>205</ram:ProcessConditionCode>
            <!-- 205 = APPROUVÉE -->
        </ram:ReferenceReferencedDocument>
    </rsm:AcknowledgementDocument>
</rsm:CrossDomainAcknowledgementAndResponse>

La Norme AFNOR XP Z12-012 vs. les Règles Schematron BR-FR-CDV

Deux Niveaux Complémentaires

La conformité des messages CDAR repose sur deux piliers :

Aspect Norme AFNOR XP Z12-012 Schematron BR-FR-CDV
Nature Document normatif (PDF) Fichier de validation (XML/XSLT)
Rôle Définit le cadre conceptuel Implémente les règles de validation
Public Architectes, décideurs Développeurs, systèmes
Contenu Principes, acteurs, flux Assertions techniques

Ce que dit la Norme AFNOR

La norme XP Z12-012 (publiée en novembre 2025) définit :

  1. Le cadre réglementaire : Articles du CGI, Directive ViDA 2025/516 (entrée en vigueur le 14 avril 2025)
  2. Les acteurs : PA (Plateforme Agréée), PPF, OD (Opérateur de Dématérialisation)
  3. Les processus métier : REGULATED, B2C, B2BINT, OUTOFSCOPE
  4. La structure des messages : Basée sur UN/CEFACT CDAR
  5. Les codes et leurs significations : Statuts, motifs, actions

Ce que valide BR-FR-CDV-CL-06

La règle BR-FR-CDV-CL-06 est l'implémentation technique qui :

  • Définit la liste fermée des 31 codes statut valides
  • S'applique aux champs MDT-105 (statut principal) et MDT-115 (statut secondaire)
  • Génère une erreur si un code non autorisé est utilisé
<!-- Extrait du Schematron BR-FR-CDV V1.2.0 -->
<pattern id="BR-FR-CDV-CL-06">
  <title>BR-FR-CDV-CL-06 — Liste fermée de codes statuts de facture</title>

  <rule context="rsm:AcknowledgementDocument/ram:ReferenceReferencedDocument/ram:ProcessConditionCode">
    <assert test="custom:is-valid-invoice-status-code(.)"
      flag="warning"
      id="BR-FR-CDV-CL-06_MDT-105">
      BR-FR-CDV-CL-06/MDT-105 : Le code de statut de facture (MDT-105)
      doit être dans la liste des codes autorisés.
      Valeur actuelle : "<value-of select='.'/>".
    </assert>
  </rule>
</pattern>

4 Statuts Obligatoires vs. 31 Codes Valides

Une distinction fondamentale à comprendre :

Concept Statuts Obligatoires (PPF) Codes Valides (BR-FR-CDV-CL-06)
Nombre 4 statuts 31 codes
Destination Concentrateur de Données du PPF Échanges inter-plateformes (PA/PDP)
Obligation DOIVENT être transmis PEUVENT être utilisés
Contexte Reporting fiscal Interopérabilité technique

Les 4 Statuts Obligatoires pour le PPF

Évolution du rôle du PPF : Initialement prévu comme plateforme centrale d'émission et de réception, le PPF a été recentré sur deux missions : (1) la gestion de l'annuaire central des entreprises et de leurs PA, et (2) le rôle de concentrateur de données fiscales pour l'administration. L'émission et la réception des factures sont désormais exclusivement gérées par les plus de 100 Plateformes Agréées immatriculées (dont plus de 80 connectées à l'annuaire et plus de 200 000 adresses actives).

La norme XP Z12-012 (section 5) précise que seuls 4 statuts doivent obligatoirement être transmis au Portail Public de Facturation :

Code Libellé Quand le transmettre au PPF
200 DÉPOSÉE Dès réception de la facture par la PA émettrice
210 REFUSÉE Quand le destinataire refuse la facture
212 ENCAISSÉE Quand le paiement est effectué
213 REJETÉE Quand la PA rejette la facture (erreur technique/métier)

Ces 4 statuts permettent à l'Administration fiscale de suivre le cycle de vie minimal des factures pour le contrôle TVA.

Les 31 Codes pour l'Interopérabilité

Les 27 autres codes (205, 207, 208, 209, 210, 211, 214, 220-228, 250-251, 300-301, 400-401, 500-501, 601) sont destinés aux échanges entre plateformes et avec les utilisateurs finaux :

  • Ils offrent une granularité fine du suivi (litige, données réglementaires, annuaire...)
  • Ils ne sont pas transmis au PPF
  • Ils restent valides techniquement (acceptés par le Schematron)

En résumé : Le PPF ne voit que 4 jalons clés (dépôt, rejet, refus, encaissement). Les plateformes peuvent utiliser les 31 codes pour un suivi détaillé entre elles.

Implications pour l'Intégration Multi-Plateforme

Les spécifications externes (v3.1) précisent que les statuts facultatifs ne sont pas garantis d'être supportés par toutes les plateformes agréées. Chaque PA peut choisir d'implémenter ou non les statuts optionnels.

Conséquence pratique : Si votre système doit interagir avec plusieurs PA différentes, il est recommandé de :

  1. Se baser uniquement sur les 4 statuts obligatoires pour les flux critiques (comptabilité, TVA)
  2. Traiter les statuts facultatifs comme "bonus" : les accepter s'ils arrivent, mais ne pas en dépendre
  3. Prévoir des fallbacks : si un statut attendu (ex: 205 Approuvée) n'arrive jamais, implémenter une logique de timeout ou de relance
✅ FIABLE (toutes PA) ⚠️ VARIABLE (selon PA)
200 Déposée 201 Émise par plateforme
210 Refusée 202 Reçue par plateforme
212 Encaissée 203 Mise à disposition
213 Rejetée 204 Prise en charge
205 Approuvée
206-209, 211, etc.

Conseil : Pour une intégration robuste, concevez votre système autour des 4 statuts obligatoires, puis enrichissez l'expérience utilisateur avec les statuts facultatifs quand ils sont disponibles.

Les 31 Codes Statut du Cycle de Vie

La règle BR-FR-CDV-CL-06 autorise exactement 31 codes, répartis en 7 catégories fonctionnelles :

1. Dépôt et Prise en Charge (200-204)

Code Libellé Caractère Description
200 DÉPOSÉE Obligatoire PPF La facture a été déposée sur la PA émettrice
201 ÉMISE PAR PLATEFORME Facultatif La PA a transmis à la PA réceptrice
202 REÇUE PAR PLATEFORME Facultatif La PA réceptrice confirme réception
203 MISE À DISPOSITION Facultatif Disponible pour le destinataire
204 PRISE EN CHARGE Facultatif Le destinataire accuse réception

2. Traitement Métier (205-214)

Code Libellé (Specs Externes v3.1) Caractère Notes
205 APPROUVÉE Facultatif
206 APPROUVÉE PARTIELLEMENT Facultatif Motif obligatoire
207 EN LITIGE Facultatif Motif obligatoire
208 SUSPENDUE Facultatif Motif obligatoire
209 COMPLÉTÉE Facultatif
210 REFUSÉE Obligatoire PPF Motif obligatoire
211 PAIEMENT TRANSMIS Facultatif
212 ENCAISSÉE Obligatoire PPF Montant MEN requis
213 REJETÉE Obligatoire PPF Motif obligatoire
214 INCONNU (FACTURE) Facultatif

Note : Les libellés peuvent varier légèrement selon les documents (Schematron, XP Z12-012, Specs Externes). Les codes numériques sont la référence stable pour l'implémentation.

3. Codes Réservés Facture (220-228)

Code Libellé
220 INCONNU (FACTURE)
221 INCONNU (FACTURE)
224 INCONNU (FACTURE)
225 INCONNU (FACTURE)
226 INCONNU (FACTURE)
227 INCONNU (FACTURE)
228 INCONNU (FACTURE)

4. Données Réglementaires (250-251)

Code Libellé
250 DÉPOSÉE (DONNÉES RÉGLEMENTAIRES)
251 REJETÉE (DONNÉES RÉGLEMENTAIRES)

5. Transaction/Paiement (300-301)

Code Libellé
300 DÉPOSÉE (TRANSACTION/PAIEMENT)
301 REJETÉE (TRANSACTION/PAIEMENT)

6. Ligne d'Annuaire (400-401)

Code Libellé
400 ACCEPTÉE (LIGNE D'ANNUAIRE)
401 REJETÉE (LIGNE D'ANNUAIRE)

7. Flux et Cycle de Vie (500-601)

Code Libellé
500 RECEVABLE (FLUX)
501 IRRECEVABLE (FLUX)
601 REJETÉ (CYCLE DE VIE)

Les Règles Métier Incontournables

BR-FR-CDV-14 : Le Cas du Statut 212 (ENCAISSÉE)

Quand une facture passe au statut 212 (ENCAISSÉE), il est obligatoire d'indiquer le montant encaissé :

<ram:SpecifiedDocumentStatus>
  <ram:SpecifiedDocumentCharacteristic>
    <ram:TypeCode>MEN</ram:TypeCode>
    <ram:ValueAmount currencyID="EUR">1500.00</ram:ValueAmount>
  </ram:SpecifiedDocumentCharacteristic>
</ram:SpecifiedDocumentStatus>

Sans cette information, le message sera rejeté.

BR-FR-CDV-15 : Statuts Nécessitant un Motif

Six statuts exigent un code motif explicatif :

Statut Motifs autorisés (exemples)
206 (Approuvée partiellement) AUTRE, CMD_ERR, QTE_ERR, PU_ERR, LIVR_INCOMP
207 (En litige) DOUBLON, TX_TVA_ERR, CALCUL_ERR, NON_CONFORME
208 (Demande d'infos) JUSTIF_ABS, COORD_BANC_ERR, REF_CT_ABSENT
210 (Refusée) ⭐ TX_TVA_ERR, EMMET_INC, CONTRAT_TERM, DOUBLE_FACT
213 (Rejetée) ⭐ REJ_SEMAN, REJ_UNI, REJ_COH, REJ_ADR
501 (Irrecevable) IRR_VIDE_F, IRR_SYNTAX, IRR_ANTIVIRUS

⭐ = Statut obligatoire pour le PPF

BR-FR-CDV-CL-09 : Les 45 Codes Motif

Le Schematron définit 45 codes motif répartis en catégories :

Erreurs de données :

  • TX_TVA_ERR - Taux de TVA erroné
  • MONTANTTOTAL_ERR - Montant total erroné
  • CALCUL_ERR - Erreur de calcul
  • PU_ERR - Prix unitaire erroné
  • QTE_ERR - Quantité erronée

Problèmes d'identification :

  • SIRET_ERR - SIRET erroné
  • DEST_INC - Destinataire inconnu
  • DEST_ERR - Destinataire erroné
  • EMMET_INC - Émetteur inconnu

Problèmes de fichier :

  • IRR_VIDE_F - Fichier vide
  • IRR_TYPE_F - Type de fichier invalide
  • IRR_SYNTAX - Erreur de syntaxe
  • IRR_ANTIVIRUS - Échec antivirus

Recevoir les CDAR : Le Retour d'Information

Le Vocabulaire de la Norme : FlowType

Avant d'aller plus loin, clarifions le vocabulaire technique de la norme XP Z12-013. Chaque flux échangé via l'API est qualifié par un FlowType :

FlowType Signification Vous êtes...
CustomerInvoice Facture de vente Vendeur (vous émettez)
SupplierInvoice Facture d'achat Acheteur (vous recevez)
CustomerInvoiceLC Cycle de vie d'une facture de vente Vendeur (vous recevez les statuts)
SupplierInvoiceLC Cycle de vie d'une facture d'achat Acheteur (vous émettez les statuts)

LC = Life Cycle (Cycle de vie). C'est le suffixe qui indique qu'il s'agit d'un message CDAR, pas d'une facture.

Pourquoi Recevoir des CDAR ?

Si vous émettez des factures, vous n'êtes pas seulement émetteur de factures — vous êtes aussi récepteur de statuts. Quand votre client (ou sa plateforme) traite votre facture, il génère des messages CDAR que vous devez recevoir :

Ce que vous faites FlowType Direction
Émettre une facture CustomerInvoice Out (sortant)
Recevoir le statut de cette facture CustomerInvoiceLC In (entrant)

Concrètement, après avoir envoyé une facture, vous pouvez recevoir :

  • 200 (Déposée) : votre PA confirme le dépôt
  • 210 (Refusée) : le client refuse la facture
  • 212 (Encaissée) : le client a payé
  • 213 (Rejetée) : erreur technique détectée

L'API AFNOR pour Rechercher les CDAR Entrants

La norme XP Z12-013 définit comment récupérer les statuts de cycle de vie entrants via l'API standardisée :

# Rechercher les CDAR entrants sur vos factures de vente
POST /flows/search
{
  "flowType": ["CustomerInvoiceLC"],
  "flowDirection": ["In"],
  "dateFrom": "2025-01-01T00:00:00Z"
}

Traduction : "Donne-moi tous les messages de cycle de vie (CustomerInvoiceLC) que j'ai reçus (In) depuis le 1er janvier 2025."

Le Webhook : Être Notifié en Temps Réel

La norme XP Z12-013 (section 5.6) introduit un mécanisme de webhook (recommandé, pas obligatoire) permettant d'être notifié de l'arrivée de nouveaux flux.

Note importante : Le webhook est un mécanisme générique pour tous les types de flux (factures, CDAR, e-reporting...). La norme ne fait pas de lien explicite entre webhook et CDAR — c'est une possibilité de configuration via le paramètre FlowType.

flowchart LR
    PA["🏢 Votre PA"]
    WH["POST /votre-endpoint"]
    SYS["💻 Votre Système"]

    PA -->|"Notification JSON"| WH --> SYS

    style PA fill:#4FC3F7,stroke:#0288D1,color:#000
    style SYS fill:#66BB6A,stroke:#2E7D32,color:#FFF

Exemple de notification JSON :

{
    "flowType": "CustomerInvoiceLC",
    "flowId": "abc-123",
    "flowDirection": "In",
    "timestamp": "2025-01-15T10:30:00Z"
}

Avantages du webhook :

  • Notification immédiate (pas de polling)
  • Économie de ressources (pas d'appels périodiques)
  • Réactivité métier (traitement temps réel)

Configuration possible (selon XP Z12-013 §5.6.2) :

  • Filtrage par FlowType (ex: uniquement CustomerInvoiceLC)
  • Filtrage par FlowDirection (In/Out)
  • Filtrage par FlowAckStatus (Ok/Error)

Note : La sécurisation du webhook (signature, authentification) fera l'objet d'une publication AFNOR en janvier 2026 (section 5.6.4).

Intégration Complète : Émettre ET Recevoir

Pour une intégration complète du cycle de vie, votre système doit gérer les deux sens :

📤 ÉMISSION (vous → client)

Étape Action FlowType Direction
1 Émettre la facture CustomerInvoice Out
2 Recevoir confirmation dépôt CustomerInvoiceLC In (200)

📥 RÉCEPTION (client → vous)

Étape Action FlowType Direction
3 Client traite la facture — —
4 Recevoir statut métier CustomerInvoiceLC In (205/210/212)

⚡ VOTRE ACTION

Étape Action
5 Mettre à jour votre comptabilité/ERP
6 Si 210 (Refusée) : créer avoir interne, corriger, réémettre

Diagramme du Cycle de Vie

graph TD
    %% Définition des acteurs
    E["👤 <b>ÉMETTEUR</b><br/>Fournisseur"]
    C["👤 <b>DESTINATAIRE</b><br/>Client"]

    %% Sous-graphe : PA Émetteur
    subgraph PAE ["🏢 PA ÉMETTEUR"]
        direction TB
        200["<b>200 ★</b><br/>Déposée"] --> 201["<b>201</b><br/>Émise"]
        200 --> 213E["<b>213 ★</b><br/>Rejetée<br/><i>(émission)</i>"]
        201 --> TRANS["Transmission"]
    end

    %% Sous-graphe : PA Récepteur
    subgraph PAR ["🏢 PA RÉCEPTEUR"]
        direction TB
        202["<b>202</b><br/>Reçue"] --> 203["<b>203</b><br/>Mise à dispo"] --> 204["<b>204</b><br/>Prise en charge"]
        202 --> 213R["<b>213 ★</b><br/>Rejetée<br/><i>(réception)</i>"]
        204 --> DEST["Destinataire"]
    end

    %% Sous-graphe : Traitement Métier
    subgraph TM ["⚙️ TRAITEMENT MÉTIER (Acheteur)"]
        direction TB
        205["<b>205</b><br/>Approuvée"]
        210["<b>210 ★</b><br/>Refusée"]
        212["<b>212 ★</b><br/>Encaissée<br/><i>(MEN requis)</i>"]
        207["<b>207</b><br/>En litige"]

        205 --> 212
        207 -.-> 210
    end

    %% Connexions entre sous-graphes
    E --> 200
    TRANS --> 202
    DEST --> TM
    C --> TM

    %% Styles - Statuts OBLIGATOIRES PPF (fond jaune vif)
    classDef mandatory fill:#FFD700,stroke:#B8860B,stroke-width:3px,color:#000;
    class 200,210,212,213E,213R mandatory;

    %% Styles - Acteurs (fond bleu clair)
    classDef actor fill:#4FC3F7,stroke:#0288D1,stroke-width:2px,color:#000;
    class E,C,DEST actor;

    %% Styles - Succès (fond vert)
    classDef success fill:#66BB6A,stroke:#2E7D32,stroke-width:2px,color:#FFF;
    class 205 success;

    %% Styles - Intermédiaires (fond orange)
    classDef warning fill:#FFA726,stroke:#E65100,stroke-width:2px,color:#000;
    class 207 warning;

    %% Styles - Neutres (fond gris)
    classDef neutral fill:#B0BEC5,stroke:#546E7A,stroke-width:1px,color:#000;
    class 201,202,203,204,TRANS neutral;

Légende du diagramme :

  • 🟡 Jaune : 4 statuts OBLIGATOIRES pour le PPF (200, 210, 212, 213)
  • 🟢 Vert : Statuts de succès (Approuvée)
  • 🟠 Orange : Statuts intermédiaires (Litige)
  • 🔵 Bleu : Acteurs
  • ⚪ Gris : Statuts de transit

Note : Le rejet (213) peut intervenir à deux moments :

  • À l'émission : la PA de l'émetteur rejette la facture (erreur de format, SIRET invalide...)
  • En réception : la PA du récepteur rejette la facture (destinataire inconnu, doublon...)

Conclusion

Les messages CDAR sont la pierre angulaire de la traçabilité dans la facturation électronique française. Leur maîtrise implique de comprendre :

  1. La norme AFNOR XP Z12-012 qui définit le "quoi" et le "pourquoi"
  2. Les règles Schematron BR-FR-CDV qui implémentent le "comment valider"
  3. La norme XP Z12-013 qui standardise les API d'échange

Points clés à retenir :

  • 4 statuts obligatoires pour le PPF : 200 (Déposée), 210 (Refusée), 212 (Encaissée), 213 (Rejetée)
  • 31 codes valides dans BR-FR-CDV-CL-06 pour les échanges inter-plateformes
  • Statuts facultatifs : non garantis entre toutes les PA — privilégiez les 4 obligatoires
  • 45 codes motif pour expliquer les rejets et suspensions
  • Le statut 212 (ENCAISSÉE) requiert obligatoirement un montant MEN (BR-FR-CDV-14)
  • 6 statuts nécessitent un code motif explicatif (BR-FR-CDV-15)
  • Flux bidirectionnel : vous émettez des factures ET recevez leurs statuts (voir FlowType CustomerInvoiceLC)

Perspectives : Vers le Temps Réel

La norme XP Z12-013 introduit un mécanisme de webhook générique (§5.6) permettant d'être notifié de l'arrivée de nouveaux flux. Bien que ce dispositif ne soit pas spécifiquement conçu pour les CDAR, il peut être configuré pour notifier les FlowType de cycle de vie (CustomerInvoiceLC, SupplierInvoiceLC).

Applications potentielles :

  • Recevoir instantanément les statuts de vos factures
  • Automatiser les processus comptables (lettrage, relance)
  • Réagir immédiatement aux rejets et refus

La spécification de sécurisation du webhook (signature HTTP, RFC 9421) est attendue en janvier 2026 (§5.6.4), signe que l'écosystème continue d'évoluer.

Implémenter les CDAR avec l'API Factpulse

Endpoints Simplifiés pour les Statuts Obligatoires

Pour les deux statuts obligatoires que vous devez gérer côté acheteur, Factpulse propose des endpoints dédiés :

Refuser une facture (210)

curl -X POST https://factpulse.fr/api/v1/cdar/refusee \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "invoiceId": "FAC-2025-001",
    "invoiceIssueDate": "2025-01-15",
    "senderSiren": "123456789",
    "reasonCode": "TX_TVA_ERR"
  }'

Confirmer l'encaissement (212)

curl -X POST https://factpulse.fr/api/v1/cdar/encaissee \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "invoiceId": "FAC-2025-001",
    "invoiceIssueDate": "2025-01-15",
    "senderSiren": "123456789",
    "amount": 1500.00
  }'

4 champs, c'est tout. Le XML CDAR conforme est généré et transmis automatiquement à votre PA.

Endpoint Générique

Pour les autres statuts ou cas d'usage avancés :

curl -X POST https://factpulse.fr/api/v1/cdar/generate \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "invoiceId": "FAC-2025-001",
    "invoiceIssueDate": "2025-01-15",
    "senderSiren": "123456789",
    "status": "205"
  }'

Endpoints API Disponibles

Endpoint Méthode Description
/api/v1/cdar/refusee POST Refuse une facture (210) — motif requis
/api/v1/cdar/encaissee POST Confirme l'encaissement (212) — montant requis
/api/v1/cdar/generate POST Génère un XML CDAR pour tout statut
/api/v1/cdar/submit POST Génère et soumet à la PA en une opération
/api/v1/cdar/status-codes GET Liste les 31 codes statut
/api/v1/cdar/reason-codes GET Liste les 45 codes motif

Découverte des Codes

# Lister tous les codes statut
curl https://factpulse.fr/api/v1/cdar/status-codes

{
    "codes": [
        { "code": "200", "description": "Déposée" },
        { "code": "210", "description": "Refusée" },
        { "code": "212", "description": "Encaissée" },
        { "code": "213", "description": "Rejetée" }
    ],
    "count": 31,
    "source": "BR-FR-CDV-CL-06"
}

Questions Fréquentes (FAQ)

Qu'est-ce qu'un message CDAR ?

Un message CDAR (Cross Domain Acknowledgement and Response) est un document XML standardisé par l'UN/CEFACT qui transporte une information de statut concernant une facture électronique. Il permet aux plateformes agréées (PA), au PPF et aux entreprises de communiquer les statuts des factures (déposée, approuvée, refusée, encaissée, etc.) tout au long de leur cycle de vie.

Quels sont les 4 statuts obligatoires pour le PPF ?

Les 4 statuts obligatoires que les plateformes doivent transmettre au Portail Public de Facturation sont :

  • 200 (Déposée) : la facture a été déposée sur la PA émettrice
  • 210 (Refusée) : le destinataire refuse la facture (motif obligatoire)
  • 212 (Encaissée) : le paiement a été effectué (montant MEN requis)
  • 213 (Rejetée) : la PA rejette la facture pour erreur technique/métier

Quelle est la différence entre PDP et Plateforme Agréée (PA) ?

Depuis juillet 2025, l'administration utilise officiellement le terme « Plateforme Agréée » (PA) plutôt que « Plateforme de Dématérialisation Partenaire » (PDP). Ce changement met l'accent sur l'agrément délivré par la DGFiP. Le terme PDP reste utilisé dans l'écosystème mais est obsolète dans les documents officiels. À ce jour, plus de 100 Plateformes Agréées sont immatriculées.

Combien de codes statut existent dans la norme BR-FR-CDV ?

La règle BR-FR-CDV-CL-06 du Schematron définit exactement 31 codes statut valides pour les échanges inter-plateformes. Seuls 4 sont obligatoires pour le PPF, les 27 autres sont facultatifs et servent à un suivi plus détaillé entre plateformes.

Quand le statut 212 (ENCAISSÉE) nécessite-t-il un montant ?

La règle BR-FR-CDV-14 impose que le statut 212 (ENCAISSÉE) soit toujours accompagné du montant encaissé via le champ MEN (Montant ENcaissé). Sans cette information, le message CDAR sera rejeté par validation Schematron.

Comment recevoir les statuts de mes factures en temps réel ?

La norme XP Z12-013 introduit un mécanisme de webhook permettant d'être notifié de l'arrivée de nouveaux flux. Vous pouvez configurer votre système pour recevoir les notifications de type CustomerInvoiceLC (cycle de vie de vos factures de vente) ou SupplierInvoiceLC (cycle de vie de vos factures d'achat).

Références

Documents normatifs

Document Description
XP Z12-012 Formats et Profils des messages Factures et Statuts de cycle de vie (AFNOR, novembre 2025)
XP Z12-013 Interopérabilité des plateformes - API, incluant webhooks (AFNOR, novembre 2025)
XP Z12-014 Cas d'usage de la facturation électronique B2B/B2G
Schematron BR-FR-CDV V1.2.0 Règles de validation CDAR (14 novembre 2025)
UN/CEFACT CDAR Cross Domain Acknowledgement and Response - Standard international
Specs Externes v3.1 Spécifications du PPF (DGFiP)
Directive ViDA 2025/516 VAT in the Digital Age - Cadre européen (entrée en vigueur 14 avril 2025)

Sources complémentaires

Source Description
AFNOR - Facture électronique : des normes pour harmoniser les pratiques Présentation officielle des travaux de normalisation
FNFE-MPE - Réforme facture électronique cap 2026 Forum National de la Facture Électronique - ressources et actualités
Impots.gouv.fr - Facturation électronique et plateformes agréées Page officielle DGFiP sur les PA
Esker - Cycle de vie facturation électronique Explication des statuts obligatoires vs recommandés
Commission européenne - ViDA Page officielle sur VAT in the Digital Age
Ministère de l'Économie - Tout savoir sur la facturation électronique Guide gouvernemental complet

_Article publié par Factpulse