Colombia — DIAN, Factura Electrónica and RADIAN

Colombia has had a universal Factura Electrónica mandate since 2019, driven by the DIAN. The format is UBL 2.1 enriched with DIAN extensions, with a unique identifier CUFE (Código Único de Factura Electrónica) computed in SHA-384. The RADIAN platform manages invoices as negotiable credit instruments.

Regulatory timeline

• 23 December 1996 — Ley 383/1997. First Colombian framework on invoicing and digital, foundation for evolution.
• 5 November 2015 — Decreto 2242/2015. Sets the basis for electronic invoicing with DIAN prior validation (validación previa model).
• 26 June 2018 — Resolución 000010/2018. Launches the mandate schedule by sectoral group and turnover, phased go-live in 2018-2019.
• 1 November 2019 — Resolución 000020/2019 then 000030/2019. Universalisation of Factura Electrónica with the validación previa model for all VAT-taxable operations.
• 23 December 2020 — Resolución 042/2020. Consolidated overhaul of technical rules, UBL 2.1 annexes updated, schedule extended to Documentos Soporte (DSAD).
• 22 February 2021 — Decreto 196/2021 + Resolución 000015/2021. Creates RADIAN for the invoice as título valor (negotiable trade instrument).
• 22 December 2021 — Resolución 000013/2021. Nómina Electrónica (payroll reporting per employee via DIAN).
• 27 December 2023 — Resolución 165/2023. Major update of technical annexes (XSD, code lists, profiles), phased effect 2024-2025.

Technical schema

The format is UBL 2.1 + DIAN extensions via the standard UBLExtensions. Features:

• CustomizationID 10 — current Colombian profile version.
• ProfileID DIAN 2.1.
• ProfileExecutionID: 1 for sandbox (Habilitación), 2 for production.
• UUID schemeID=2: carries the CUFE SHA-384 hash, unique identifier of the invoice computed by the official DIAN formula.
• DianExtensions: DIAN-specific block carrying InvoiceControl (numbers authorised by the numbering resolution), QR Code, signature and fiscal statistics.
• InvoiceTypeCode: 01 (standard sale), 02 (export), 03 (DIAN contingency — invoice issued when the DIAN API is down), 04 (equivalent to a sale invoice).

Minimal example of a Factura Electrónica 01 (skeleton):

<?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>

Submission flow

The Colombian model is validación previa: the invoice must be validated by DIAN before delivery to the buyer. Typical workflow:

• The seller builds UBL 2.1 + DIAN extensions, computes the CUFE, signs XAdES-EPES.
• Submits the ZIP-compressed document via DIAN SOAP (SendBillSync).
• DIAN validates schema, code list, CUFE, signature and returns a synchronous ApplicationResponse (AR): acceptance, rejection or rejection with rules failed.
• The seller then delivers the validated invoice to the buyer (PDF + XML).
• The buyer can answer with an explicit ApplicationResponse (express acceptance, motivated rejection) or by tacit default after 3 working days.

┌─────────────┐    ┌──────────────────┐    ┌─────────────┐
│ CO supplier │───>│ DIAN — SOAP API  │───>│ CO customer │
│ (UBL 2.1)   │ ↓  │ Validación       │XML │ + AR/AD     │
│ + XAdES sig │ │  │ Previa           │ZIP │ (acceptance)│
│             │ │  └────────┬─────────┘    └─────────────┘
└─────────────┘ │           │
                │           ▼
                │  ┌──────────────────┐
                └──│ CUFE returned +   │  ← SHA-384 hash
                   │ ApplicationResp.  │     integrates invoice
                   └──────────────────┘

For circulation as a negotiable instrument, the seller can register the accepted invoice on RADIAN to assign it to a factor (factoring company) — RADIAN keeps the transfer registry and prevents double assignment.

Validation

• DIAN Factura Electrónica portal: dian.gov.co/impuestos/factura-electronica.
• Catálogo de Errores — official list of error codes (FAB01–FAR50), published in technical annex 1.9.
• Anexo Técnico — UBL 2.1 + DIAN extensions specification, official XSD and Schematron.
• RADIAN: radian.dian.gov.co — national registry of invoices as title-value instruments.

Common pitfalls

1. CUFE — 23-field computation formula. The CUFE is a SHA-384 hash over the concatenation of 23 fields (number, date, amounts per tax, NITs, etc.) following an official DIAN formula. A decimal comma instead of a period or a wrong date separator changes the hash and fails validation. It is the #1 source of rejections.
2. InvoiceAuthorization — numbering resolution. Each numbering souche (prefix + range) must be pre-authorised by a DIAN resolution. Issuing outside the authorised range or with an undeclared prefix triggers immediate rejection.
3. Habilitación vs Producción — ProfileExecutionID. Sandbox uses 1, production uses 2. A sandbox invoice issued in production with 1 is rejected; worse, a production invoice with 2 on the Habilitación environment pollutes the counter.
4. Document Soporte (DSAD) ≠ Factura. Purchases from non-DIAN-registered parties (foreign, individuals) must be documented by a DSAD (Documento Soporte en Adquisiciones), not an invoice. Many systems forget this flow and lose their deductible charges.
5. DIAN contingencia — code 03. If the DIAN API is down > 3h, the seller can issue in contingency mode (InvoiceTypeCode 03) and submit after the fact within 48h. Many vendors don't implement this fallback and block their clients on DIAN incidents.

Cross-links

• UBL — base OASIS standard.
• Mexico — CFDI / LatAm comparison.
• Peru — another Andean UBL profile (UBL-PE).
• Chile — DTE / South Pacific comparison.
• Official sources: dian.gov.co/factura-electronica, radian.dian.gov.co.