Cabinet Digital Cabinet Digital
Tous les logiciels Annuaire
Experts-Comptables Analyse de données 16 Audit 7 CRM 5 Coffre fort 4 Communication 9 Comptabilité expert-comptable 10 GED cabinet 9 Gestion interne 13 Hébergement 7 Mission juridique 17 Portail client 5 Production sociale 12 Ressources Humaines 7 Saisie automatisée (OCR) 11 Signature électronique 5
PME Achats & Dépenses 13 Comptabilité entreprise 13 ERP et Gestion 10 Gestion de projet 3 Gestion financière 6 Ventes & Facturation 15 Trésorerie 6

Choisir sa plateforme

Liste des PA Populaire Plateformes gratuites Trouver ma plateforme

Comprendre la réforme

Comprendre la réforme Guide formats et normes Simulateur d'échéances

Outils gratuits

Validateur de factures Générateur de factures Tous les outils
Intégrateurs Nouveau Actualités
Contact

Facture électronique

CDAR : le format des statuts de cycle de vie de la facture électronique

Le CDAR ne transporte pas de facture. Il transporte son statut : déposée, rejetée, refusée, encaissée, avec l'horodatage et le motif. C'est le message qui circule entre les plateformes agréées et le portail public de facturation, sous le nom de flux 6.

L'essentiel en 5 points

  • CDAR n'est pas un format de facture. Factur-X, UBL et CII portent la facture, le CDAR porte son statut.
  • Il est obligatoire sur le flux 6, celui qui remonte les statuts au portail public de facturation (PPF) et circule entre plateformes.
  • Vous n'en verrez probablement jamais. Ce que votre plateforme vous restitue est le flux 7, qui peut être dans n'importe quel format.
  • 4 statuts sur 14 partent à la DGFiP : déposée, refusée, encaissée, rejetée.
  • Délai : 24 heures entre l'horodatage d'un statut obligatoire et sa transmission au PPF par la plateforme.

Sommaire

  1. Ce qu'est le CDAR
  2. Flux 6 et flux 7 : qui manipule du CDAR
  3. Ce que contient un message
  4. Deux exemples réels
  5. Les 14 statuts d'une facture
  6. Les autres objets suivis
  7. Rejets, motifs et délais
  8. Ce qu'il faut vérifier auprès de sa plateforme
  9. Questions fréquentes
1

Ce qu'est le CDAR

Le CDAR est un message XML normalisé. Les spécifications externes de l'AIFE le désignent comme le message UN/CEFACT SCRDM CI Cross Domain Application Response, retenu par la France pour véhiculer le cycle de vie des objets échangés dans la réforme. Concrètement, un CDAR répond toujours à la même question : que devient l'objet que je t'ai transmis, et si quelque chose a échoué, pourquoi ?

La distinction à ne jamais perdre de vue : une facture électronique circule en Factur-X, UBL ou CII. Son statut circule en CDAR. Ce sont deux messages différents, dans deux flux différents. Déposer un CDAR dans un validateur de factures n'a aucun sens, et l'inverse non plus.

2

Flux 6 et flux 7 : qui manipule vraiment du CDAR

C'est le point que la plupart des articles passent sous silence, et il change tout pour une entreprise. Les spécifications prévoient deux flux de cycle de vie, pas un.

Flux Format Qui l'échange, et pour quoi
Flux 6 CDAR imposé Entre plateformes agréées, et des plateformes vers le PPF. Toute plateforme a l'obligation d'y transmettre les statuts obligatoires, que le PPF contrôle puis relaie à l'administration fiscale.
Flux 7 Format libre Entre une entreprise et sa plateforme (API, tableau de bord, export vers le logiciel comptable). Il doit véhiculer au moins les statuts obligatoires, mais n'est jamais transmis au PPF et n'a pas à être en CDAR.

Schéma sous licence CC BY 4.0 : · · Réutiliser ce schéma · SVG · PNG

Autrement dit : le CDAR est un sujet d'éditeur de logiciel, d'opérateur de dématérialisation et de plateforme agréée. Pour une PME, la bonne question n'est pas « sais-je lire un CDAR » mais « ma plateforme me remonte-t-elle ces statuts, et jusque dans ma comptabilité ».

3

Ce que contient un message CDAR

Le format sémantique est publié par l'AIFE (annexe 2 des spécifications, plus de 230 données). L'ossature utile tient en sept blocs.

Donnée Ce qu'elle porte
Profil du message Le cadre auquel obéit le CDAR (e-invoicing, e-reporting, annuaire) et un indicateur de test.
Émetteur du message Le matricule de la plateforme ou du PPF, et le rôle de celui qui pose le statut (vendeur, acheteur, plateforme, affactureur).
Horodatage Date et heure à la seconde (AAAAMMJJHHMMSS). C'est lui qui fait courir le délai de 24 heures vers le PPF.
Objet de la réponse Le document visé : numéro de facture ou identifiant de flux, type d'objet, émetteur et destinataire, date de réception.
Code statut Le statut posé, dans la liste ci-dessous, avec son libellé.
Motif En cas d'irrecevabilité, de rejet ou de refus : code motif, libellé, code de la règle de gestion en cause, nom du fichier fautif.
Action attendue Ce que l'émetteur doit faire (demande d'avoir, facture rectificative), et le cas échéant la valeur attendue à la place de la valeur erronée.

Ce dernier bloc est la vraie valeur du format : un CDAR bien rempli ne dit pas seulement qu'une facture a échoué, il dit quelle balise corrige quoi.

4

À quoi ça ressemble : deux exemples réels

Voici deux messages CDAR complets, tirés des exemples officiels publiés par le FNFE-MPE en annexe de la norme XP Z12-012 (dépôt public fnfempe/France_RFE, licence Apache 2.0). Ils sont reproduits tels quels, aux commentaires de correspondance près, retirés pour la lisibilité.

Exemple 1 : statut « Déposée » (200) transmis au PPF

La plateforme d'émission atteste que la facture F202500003 est contrôlée et conforme. À regarder : l'élément racine s'appelle bien CrossDomainAcknowledgementAndResponse, et le message ne contient aucune donnée de facture. Pas une ligne, pas un montant, pas une adresse. 

<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossDomainAcknowledgementAndResponse
xmlns:qdt="urn:un:unece:uncefact:data:standard:QualifiedDataType:100"
xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100"
xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossDomainAcknowledgementAndResponse:100"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <rsm:ExchangedDocumentContext>
    <ram:GuidelineSpecifiedDocumentContextParameter>
      <ram:ID>urn.cpro.gouv.fr:1p0:CDV:einvoicingF2</ram:ID>
    </ram:GuidelineSpecifiedDocumentContextParameter>
  </rsm:ExchangedDocumentContext>
  <rsm:ExchangedDocument>
    <ram:ID>FFE0614A_CC0238_6095369382124026476</ram:ID>
    <ram:Name>UC1_F202500003_01-CDV-200_Deposee</ram:Name>
    <ram:IssueDateTime>
      <udt:DateTimeString format="204">20250701151500</udt:DateTimeString>
    </ram:IssueDateTime>
    <ram:SenderTradeParty>
      <ram:GlobalID schemeID="0238">0003</ram:GlobalID>
      <ram:Name>PA-E Vendeur</ram:Name>
      <ram:RoleCode>WK</ram:RoleCode>
    </ram:SenderTradeParty>
    <ram:IssuerTradeParty>
      <ram:GlobalID schemeID="0238">0003</ram:GlobalID>
      <ram:Name>PA-E Vendeur</ram:Name>
      <ram:RoleCode>WK</ram:RoleCode>
    </ram:IssuerTradeParty>
    <ram:RecipientTradeParty>
      <ram:GlobalID schemeID="0238">0000</ram:GlobalID>
      <ram:Name>PPF</ram:Name>
      <ram:RoleCode>DFH</ram:RoleCode>
    </ram:RecipientTradeParty>
  </rsm:ExchangedDocument>
  <rsm:AcknowledgementDocument>
    <ram:MultipleReferencesIndicator>
      <udt:Indicator>false</udt:Indicator>
    </ram:MultipleReferencesIndicator>
    <ram:TypeCode>305</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="204">20250701151000</udt:DateTimeString>
    </ram:IssueDateTime>
    <ram:ReferenceReferencedDocument>
      <ram:IssuerAssignedID>F202500003</ram:IssuerAssignedID>
      <ram:StatusCode>10</ram:StatusCode>
      <ram:TypeCode>380</ram:TypeCode>
      <ram:ReceiptDateTime>
        <udt:DateTimeString format="204">20250701151000</udt:DateTimeString>
      </ram:ReceiptDateTime>
      <ram:ReferenceTypeCode>urn.cpro.gouv.fr:1p0:CDV:einvoicingF2</ram:ReferenceTypeCode>
      <ram:FormattedIssueDateTime>
        <qdt:DateTimeString format="102">20250701</qdt:DateTimeString>
      </ram:FormattedIssueDateTime>
      <ram:ProcessConditionCode>200</ram:ProcessConditionCode>
      <ram:ProcessCondition>Déposée</ram:ProcessCondition>
      <ram:IssuerTradeParty>
        <ram:GlobalID schemeID="0002">100000009</ram:GlobalID>
      </ram:IssuerTradeParty>
    </ram:ReferenceReferencedDocument>
  </rsm:AcknowledgementDocument>
</rsm:CrossDomainAcknowledgementAndResponse>
Exemple 2 : statut « En litige » (207) avec motif et valeur attendue

Le plus instructif des deux : l'acheteur conteste un taux de TVA. Le bloc SpecifiedDocumentStatus porte le motif codifié TX_TVA_ERR, l'action attendue NIN (créer une facture rectificative), le champ visé (BT-152) avec son chemin XPath dans la facture d'origine, la valeur trouvée (10,00 %) et la valeur attendue (20,00 %). Voilà ce qui permet à un logiciel de dire quoi corriger, et pas seulement que quelque chose a échoué. 

<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossDomainAcknowledgementAndResponse
xmlns:qdt="urn:un:unece:uncefact:data:standard:QualifiedDataType:100"
xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100"
xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossDomainAcknowledgementAndResponse:100"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <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>
  <rsm:ExchangedDocument>
    <ram:ID>F202500006_207_20250701161000#380_20250701</ram:ID>
    <ram:Name>UC4_F202500006_04-CDV-207_En_litige</ram:Name>
    <ram:IssueDateTime>
      <udt:DateTimeString format="204">20250701181500</udt:DateTimeString>
    </ram:IssueDateTime>
    <ram:SenderTradeParty>
      <ram:RoleCode>WK</ram:RoleCode>
    </ram:SenderTradeParty>
    <ram:IssuerTradeParty>
      <ram:GlobalID schemeID="0002">200000008</ram:GlobalID>
      <ram:Name>ACHETEUR</ram:Name>
      <ram:RoleCode>BY</ram:RoleCode>
    </ram:IssuerTradeParty>
    <ram:RecipientTradeParty>
      <ram:GlobalID schemeID="0002">100000009</ram:GlobalID>
      <ram:Name>VENDEUR</ram:Name>
      <ram:RoleCode>SE</ram:RoleCode>
      <ram:URIUniversalCommunication>
        <ram:URIID schemeID="0225">100000009_STATUTS</ram:URIID>
      </ram:URIUniversalCommunication>
    </ram:RecipientTradeParty>
  </rsm:ExchangedDocument>
  <rsm:AcknowledgementDocument>
    <ram:MultipleReferencesIndicator>
      <udt:Indicator>false</udt:Indicator>
    </ram:MultipleReferencesIndicator>
    <ram:TypeCode>23</ram:TypeCode>
    <ram:IssueDateTime>
      <udt:DateTimeString format="204">20250701180000</udt:DateTimeString>
    </ram:IssueDateTime>
    <ram:ReferenceReferencedDocument>
      <ram:IssuerAssignedID>F202500006</ram:IssuerAssignedID>
      <ram:StatusCode>46</ram:StatusCode>
      <ram:TypeCode>380</ram:TypeCode>
      <ram:ReceiptDateTime>
        <udt:DateTimeString format="204">20250701161000</udt:DateTimeString>
      </ram:ReceiptDateTime>
      <ram:FormattedIssueDateTime>
        <qdt:DateTimeString format="102">20250701</qdt:DateTimeString>
      </ram:FormattedIssueDateTime>
      <ram:ProcessConditionCode>207</ram:ProcessConditionCode>
      <ram:ProcessCondition>En_litige</ram:ProcessCondition>
      <ram:IssuerTradeParty>
        <ram:GlobalID schemeID="0002">100000009</ram:GlobalID>
      </ram:IssuerTradeParty>
      <ram:SpecifiedDocumentStatus>
        <ram:ReasonCode>TX_TVA_ERR</ram:ReasonCode>
        <ram:Reason> Taux de TVA erroné</ram:Reason>
        <ram:RequestedActionCode>NIN</ram:RequestedActionCode>
        <ram:RequestedAction>Créer une Facture Rectificative</ram:RequestedAction>
        <ram:SequenceNumeric>1</ram:SequenceNumeric>
        <ram:SpecifiedDocumentCharacteristic>
          <ram:ID>BT-152</ram:ID>
          <ram:TypeCode>DIV</ram:TypeCode>
          <ram:ValueChangedIndicator>
            <udt:IndicatorString>true</udt:IndicatorString>
          </ram:ValueChangedIndicator>
          <ram:Name>Taux TVA</ram:Name>
          <ram:Location>/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax/ram:RateApplicablePercent</ram:Location>
          <ram:ValuePercent>10.00</ram:ValuePercent>
        </ram:SpecifiedDocumentCharacteristic>
        <ram:SpecifiedDocumentCharacteristic>
          <ram:ID>BT-152</ram:ID>
          <ram:TypeCode>DVA</ram:TypeCode>
          <ram:ValueChangedIndicator>
            <udt:IndicatorString>true</udt:IndicatorString>
          </ram:ValueChangedIndicator>
          <ram:Name>Taux TVA</ram:Name>
          <ram:Location>/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:IncludedSupplyChainTradeLineItem/ram:SpecifiedLineTradeSettlement/ram:ApplicableTradeTax/ram:RateApplicablePercent</ram:Location>
          <ram:ValuePercent>20.00</ram:ValuePercent>
        </ram:SpecifiedDocumentCharacteristic>
      </ram:SpecifiedDocumentStatus>
    </ram:ReferenceReferencedDocument>
  </rsm:AcknowledgementDocument>
</rsm:CrossDomainAcknowledgementAndResponse>

Noter au passage que cet exemple officiel place un désaccord sur le taux de TVA en « En litige », pas en « Refusée » : c'est exactement la règle que rappelle notre assistant rejeter ou refuser.

5

Les 14 statuts d'une facture

Quatre statuts sont obligatoires et remontent à l'administration fiscale. Les dix autres sont facultatifs : ils servent la relation commerciale et ne sont pas transmis à la DGFiP.

Code Statut Posé par À la DGFiP
200 Déposée Plateforme d'émission Obligatoire
201 Émise par la plateforme Plateforme d'émission Facultatif
202 Reçue par la plateforme Plateforme de réception Facultatif
203 Mise à disposition Plateforme de réception Facultatif
204 Prise en charge Destinataire Facultatif
205 Approuvée Destinataire Facultatif
206 Approuvée partiellement Destinataire Facultatif
207 En litige Destinataire Facultatif
208 Suspendue Destinataire Facultatif
209 Complétée Fournisseur Facultatif
210 Refusée Destinataire Obligatoire
211 Paiement transmis Destinataire ou fournisseur Facultatif
212 Encaissée Fournisseur Obligatoire
213 Rejetée Plateforme d'émission ou de réception Obligatoire

Le statut « Encaissée » n'est dû que dans les conditions de l'article 290 A du CGI, en pratique pour les opérations dont la TVA est exigible à l'encaissement. Et « Refusée » n'est pas le fourre-tout des factures erronées : un désaccord sur le contenu relève du statut « En litige ». Notre assistant rejeter ou refuser une facture tranche les 12 cas courants.

6

Les autres objets suivis en CDAR

Le cycle de vie ne concerne pas que les factures. Le même format sert à accuser réception, ou à rejeter, tout ce qui circule dans la chaîne.

Objet Codes
Le flux lui-même (l'enveloppe déposée) 500 recevable, 501 irrecevable
Données réglementaires de facture (flux 1) 250 déposée, 251 rejetée
Statuts obligatoires eux-mêmes 601 rejeté
Données de transaction et de paiement (e-reporting, flux 10) 300 déposée, 301 rejetée
Actualisation de l'annuaire 400 acceptée, 401 rejetée

Un CDAR peut donc rejeter un autre CDAR (code 601). Ce n'est pas une curiosité : c'est ce qui garantit qu'un statut mal formé ne disparaît pas en silence.

7

Rejets, motifs et délais

Un rejet n'est jamais muet : le CDAR porte un ou plusieurs codes motif. Côté données réglementaires de facture, les motifs sont le contrôle du format sémantique (REJ_SEMAN), le contrôle d'unicité (REJ_UNI, l'unicité se juge sur le numéro de facture, le SIREN du fournisseur et l'année) et le contrôle de cohérence (REJ_COH). Côté statuts, les motifs portent sur la cohérence, la conformité, les règles de gestion, les habilitations et les encaissements.

Deux délais structurent la chaîne, tous deux à la charge des plateformes : 24 heures pour transmettre au PPF les données réglementaires d'une facture à compter du cycle de vie « Déposée », et 24 heures pour lui transmettre un statut obligatoire à compter de son horodatage.

Conséquence comptable, souvent ignorée : après un statut « Rejetée » ou « Refusée », le fournisseur procède à une annulation comptable par avoir interne. Cette annulation ne doit pas générer de nouveau flux de données réglementaires vers le PPF pour la facture concernée. La facture corrigée repart, elle, comme une facture neuve.

8

Ce qu'il faut vérifier auprès de sa plateforme

  • Les statuts remontent-ils dans le logiciel comptable, ou seulement dans le tableau de bord de la plateforme ? C'est la différence entre un suivi exploitable et un suivi à consulter à la main.
  • Le motif de rejet est-il restitué en clair, avec la règle en cause, ou réduit à un « échec de contrôle » ?
  • Les statuts facultatifs (prise en charge, approuvée, en litige) sont-ils supportés ? Ce sont eux qui font le suivi client, pas les quatre obligatoires.
  • Le statut « Encaissée » est-il alimenté automatiquement depuis le rapprochement bancaire, ou faut-il le poser à la main facture par facture ?
  • Existe-t-il un environnement de test pour rejouer un rejet avant septembre 2026 ?

Ces questions rejoignent les 8 critères de choix d'une Plateforme Agréée. En amont, la meilleure façon d'éviter un rejet reste de contrôler ses factures avant envoi : le validateur Factur-X applique les mêmes règles EN 16931 et CTC-FR que celles qui déclenchent un statut « Rejetée ».

Sources

  • Dossier de spécifications externes de la facturation électronique, AIFE / DGFiP, version 3.2 du 30 avril 2026 (dossier général et annexe 2 « Format sémantique FE CDV, flux 6 »), publié sur impots.gouv.fr.
  • Normes AFNOR XP Z12-012 (formats et profils des messages factures et statuts de cycle de vie) et XP Z12-014 (cas d'usage B2B).

Page à jour au 29 juillet 2026. Les codes et délais cités sont ceux de la version 3.2 des spécifications : ils peuvent évoluer à chaque publication de l'AIFE.

Rester informé

Réforme de la facture électronique : nouvelles plateformes agréées, échéances et outils, un email seulement quand il y a du neuf. Pas de spam : un email uniquement en cas d'évolution de la liste DGFiP ou du calendrier. Désinscription en un clic à tout moment, votre adresse n'est jamais partagée.

Questions fréquentes

Le CDAR est-il un format de facture comme Factur-X ou UBL ?
Non, et c'est la confusion la plus fréquente. Factur-X, UBL et CII transportent la facture elle-même. Le CDAR ne transporte aucune facture : il transporte les statuts d'un objet déjà échangé (déposée, rejetée, refusée, encaissée) et, en cas d'anomalie, le motif du rejet. Une facture ne se convertit pas en CDAR et un CDAR ne se lit pas dans un validateur Factur-X.

Mon entreprise va-t-elle recevoir des fichiers CDAR ?
Probablement jamais. Le format CDAR est imposé sur le flux 6, celui qui circule entre les plateformes agréées et le portail public de facturation. Ce que votre plateforme vous remonte à vous, dans son interface ou vers votre logiciel comptable, relève du flux 7 : les spécifications autorisent explicitement un autre format syntaxique, à condition de véhiculer au moins les statuts obligatoires. Le CDAR concerne donc surtout les éditeurs, les opérateurs de dématérialisation et les plateformes.

Quels statuts sont réellement transmis à l'administration fiscale ?
Quatre seulement, sur les quatorze prévus pour une facture : Déposée (200), Refusée (210), Encaissée (212) et Rejetée (213). Les dix autres sont facultatifs, utiles entre les acteurs de la chaîne mais non transmis à la DGFiP. Une plateforme agréée dispose de 24 heures à compter de l'horodatage du statut pour l'adresser au portail public de facturation.

Que contient un CDAR quand une facture est rejetée ?
L'identifiant de l'objet concerné (numéro de facture, identifiant de flux), le code du statut, son horodatage, un ou plusieurs codes motif avec leur libellé, le code de la règle de gestion en cause, le nom du fichier fautif et, le cas échéant, l'action attendue (demande d'avoir, facture rectificative). C'est ce qui permet à un logiciel de vous dire quoi corriger, et pas seulement que quelque chose a échoué.

Le CDAR sert-il uniquement au cycle de vie des factures ?
Non. Le même format porte le cycle de vie de plusieurs objets : les flux eux-mêmes (recevable 500, irrecevable 501), les données réglementaires de facture (déposée 250, rejetée 251), les statuts obligatoires eux-mêmes (rejeté 601), les données de transaction et de paiement de l'e-reporting (300 et 301) et l'actualisation de l'annuaire (400 et 401).

Une facture rejetée ou refusée doit-elle être renvoyée telle quelle ?
Non. Les spécifications prévoient que le fournisseur procède à une annulation comptable (avoir interne), sans générer de nouveau flux de données réglementaires vers le portail public de facturation pour la facture annulée. Attention aussi à ne pas confondre refus et litige : un désaccord sur le contenu relève du statut « En litige » (207), pas du refus.

Pour aller plus loin : le cycle de vie côté métier, le guide des formats et normes et le guide complet de la réforme.