Colombie — DIAN, Factura Electrónica et RADIAN

La Colombie a un mandat universel de Factura Electrónica depuis 2019, piloté par la DIAN. Le format est UBL 2.1 enrichi d'extensions DIAN, avec un identifiant unique CUFE (Código Único de Factura Electrónica) calculé en SHA384. La plateforme RADIAN gère la circulation des factures comme titre de crédit négociable.

Timeline réglementaire

• 23 décembre 1996 — Ley 383/1997. Premier cadre colombien sur la facturation et le digital, base d'évolution.
• 5 novembre 2015 — Decreto 2242/2015. Pose les bases de la facturation électronique avec validation préalable DIAN (modèle validación previa).
• 26 juin 2018 — Resolución 000010/2018. Lance le calendrier d'obligation par groupes sectoriels et CA, mise en service étalée 2018-2019.
• 1^er novembre 2019 — Resolución 000020/2019 puis 000030/2019. Universalisation de la Factura Electrónica avec modèle de validación previa pour toutes les opérations gravées de TVA.
• 23 décembre 2020 — Resolución 042/2020. Refonte consolidée des règles techniques, anexos UBL 2.1 mis à jour, calendrier étendu aux Documentos Soporte (DSAD).
• 22 février 2021 — Decreto 196/2021 + Resolución 000015/2021. Création de RADIAN pour la circulation de la facture comme título valor (effet de commerce négociable).
• 22 décembre 2021 — Resolución 000013/2021. Nómina Electrónica (déclaration sociale par employé via DIAN).
• 27 décembre 2023 — Resolución 165/2023. Mise à jour majeure des annexes techniques (XSD, code lists, profils), entrée en vigueur progressive 2024-2025.

Schéma technique

Le format est UBL 2.1 + extensions DIAN via les UBLExtensions standards. Caractéristiques :

• CustomizationID 10 — version courante du profil colombien.
• ProfileID DIAN 2.1.
• ProfileExecutionID : 1 pour sandbox (Habilitación), 2 pour production.
• UUID schemeID=2 : porte le CUFE hash SHA-384, identifiant unique de la facture calculé par formule officielle DIAN.
• DianExtensions : bloc DIAN-spécifique portant InvoiceControl (numéros autorisés par la résolution de numération), QR Code, signature et statistiques fiscales.
• InvoiceTypeCode : 01 (vente standard), 02 (exportation), 03 (contingencia DIAN — facture émise quand l'API DIAN est en panne), 04 (équivalent à una factura de venta).

Exemple minimal d'une Factura Electrónica 01 (squelette) :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
         xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
         xmlns:sts="dian:gov:co:facturaelectronica:Structures-2-1">
  <ext:UBLExtensions>
    <ext:UBLExtension>
      <ext:ExtensionContent>
        <sts:DianExtensions>
          <sts:InvoiceControl>
            <sts:InvoiceAuthorization>18760000001</sts:InvoiceAuthorization>
            <sts:AuthorizationPeriod>
              <cbc:StartDate>2026-01-01</cbc:StartDate>
              <cbc:EndDate>2026-12-31</cbc:EndDate>
            </sts:AuthorizationPeriod>
            <sts:AuthorizedInvoices>
              <sts:Prefix>SETP</sts:Prefix>
              <sts:From>1</sts:From>
              <sts:To>5000000</sts:To>
            </sts:AuthorizedInvoices>
          </sts:InvoiceControl>
        </sts:DianExtensions>
      </ext:ExtensionContent>
    </ext:UBLExtension>
  </ext:UBLExtensions>
  <cbc:UBLVersionID>UBL 2.1</cbc:UBLVersionID>
  <cbc:CustomizationID>10</cbc:CustomizationID>
  <cbc:ProfileID>DIAN 2.1</cbc:ProfileID>
  <cbc:ProfileExecutionID>2</cbc:ProfileExecutionID>
  <cbc:ID>SETP142</cbc:ID>
  <cbc:UUID schemeID="2" schemeName="CUFE-SHA384">
    a4f2b8c1...384hexchars...
  </cbc:UUID>
  <cbc:IssueDate>2026-05-16</cbc:IssueDate>
  <cbc:IssueTime>10:30:00-05:00</cbc:IssueTime>
  <cbc:InvoiceTypeCode>01</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>COP</cbc:DocumentCurrencyCode>
</Invoice>

Flux de soumission

Le modèle colombien est validación previa : la facture doit être validée par la DIAN avant remise à l'acheteur. Workflow type :

• Le vendeur génère UBL 2.1 + extensions DIAN, calcule le CUFE, signe XAdES-EPES.
• Il soumet le document compressé en ZIP via SOAP DIAN (SendBillSync).
• DIAN valide schéma, code list, CUFE, signature et retourne un ApplicationResponse (AR) synchronique : acceptation, rejet ou rejet avec rules failed.
• Le vendeur livre alors la facture validée à l'acheteur (PDF + XML).
• L'acheteur peut répondre par un ApplicationResponse explicite (acceptation expresse, rejet motivé) ou par défaut tacite après 3 jours ouvrés.

┌─────────────┐    ┌──────────────────┐    ┌─────────────┐
│ Vendedor CO │───>│ DIAN — SOAP API  │───>│ Acheteur CO │
│ (UBL 2.1)   │ ↓  │ Validación       │XML │ + AR/AD     │
│ + Signature │ │  │ Previa           │ZIP │ (acceptance)│
│ XAdES       │ │  └────────┬─────────┘    └─────────────┘
└─────────────┘ │           │
                │           ▼
                │  ┌──────────────────┐
                └──│ CUFE retourné +   │  ← Sha384 hash
                   │ ApplicationResp.  │     intègre la facture
                   └──────────────────┘

Pour la circulation comme titre négociable, le vendeur peut enregistrer la facture acceptée sur RADIAN pour la céder à un factor (compagnie de factoring) — RADIAN tient le registre des transferts et empêche la double cession.

Validation

• Portail DIAN Factura Electrónica : dian.gov.co/impuestos/factura-electronica.
• Catálogo de Errores — liste officielle des codes erreur (FAB01–FAR50), publiée en annexe technique 1.9.
• Anexo Técnico — spécification UBL 2.1 + extensions DIAN, XSD et Schematron officiels.
• RADIAN : radian.dian.gov.co — registre national des factures comme titres valeurs.

Pièges courants

1. CUFE — formule de calcul à 23 champs. Le CUFE est un hash SHA-384 sur la concaténation de 23 champs (numéro, date, montants par taxe, NITs, etc.) selon une formule officielle DIAN. Une virgule décimale au lieu d'un point ou un séparateur de date erroné change le hash et fait échouer la validation. C'est la source #1 des rejets.
2. InvoiceAuthorization — résolution de numération. Chaque souche de numéros (prefix + range) doit être pré-autorisée par résolution DIAN. Émettre hors range autorisé ou avec un prefix non déclaré déclenche rejet immédiat.
3. Habilitación vs Producción — ProfileExecutionID. Sandbox utilise 1, production utilise 2. Une facture sandbox émise en production avec 1 est rejetée ; pire, une facture production avec 2 sur l'environnement Habilitación pollue le compteur.
4. Document Soporte (DSAD) ≠ Factura. Les achats à des non-redevables DIAN (étrangers, particuliers) doivent être documentés par un DSAD (Documento Soporte en Adquisiciones), pas une facture. Beaucoup de SSII oublient ce flux et n'ont pas leurs charges déductibles.
5. Contingencia DIAN — code 03. Si l'API DIAN est en panne > 3h, le vendeur peut émettre en mode contingence (InvoiceTypeCode 03) et soumettre a posteriori dans les 48h. Beaucoup d'éditeurs n'implémentent pas ce fallback et bloquent leurs clients en cas d'incident DIAN.

Liens transverses

• UBL — standard OASIS de base.
• Mexique — comparaison CFDI / Latam.
• Pérou — autre profil UBL andin (UBL-PE).
• Chili — comparaison DTE / Pacifique sud.
• Sources officielles : dian.gov.co/factura-electronica, radian.dian.gov.co.