Eventos RADIAN en Colombia: qué son, cuáles son y cómo registrarlos por API

Por Ing. Carlos Méndez | 15 de octubre de 2026

Ing. Carlos Méndez es arquitecto de software con más de 10 años integrando sistemas fiscales en América Latina. Ha liderado implementaciones de facturación electrónica en Colombia, México y Centroamérica para ISVs de mediana y gran escala.

Los eventos RADIAN son los documentos electrónicos con los que la DIAN registra cada hecho relevante en la vida de una factura electrónica de venta una vez emitida: que el comprador la recibió, que recibió el bien o el servicio, que la aceptó, que la reclamó, que fue endosada o que fue pagada. Para un ISV, el problema no es entender el concepto sino modelarlo: cada evento tiene un código, un emisor autorizado, un orden de precedencia y, en los primeros pasos, un plazo legal que corre en días hábiles. Una integración que solo emite facturas y nunca procesa eventos deja a sus clientes sin la capacidad de usar esas facturas como instrumento de financiamiento.

Esta guía es el pilar de un cluster sobre eventos RADIAN. Al terminarla se tendrá el catálogo de eventos y su función, el ciclo de vida que lleva una factura hasta convertirse en título valor circulable, la estructura técnica de un evento, el reparto de responsabilidades entre emisor, adquirente y proveedor tecnológico, y un modelo de estados para implementar todo esto por API. Cada evento clave tiene su propia profundización enlazada más abajo.

Qué es RADIAN y por qué los eventos son el núcleo del registro

RADIAN es el Registro de Facturas Electrónicas de Venta como Título Valor, administrado por la DIAN. Su base legal combina la Ley 1231 de 2008 (que define la factura como título valor), la Ley 1676 de 2013, el Decreto 1154 de 2020 (que reglamenta la circulación de la factura electrónica como título valor y está incorporado al Decreto 1074 de 2015) y la Resolución 000015 de 2021 de la DIAN con su anexo técnico, que describe los eventos y los formatos de intercambio. Para un panorama general del sistema y del factoring electrónico, el artículo RADIAN en Colombia: el sistema de factoring electrónico de la DIAN cubre el contexto; aquí el foco es el modelo de eventos.

La razón por la que RADIAN se organiza en eventos y no en estados editables es la trazabilidad: una factura no cambia de estado por una actualización de campo, sino porque se registra un documento nuevo, firmado y con identificador propio, que referencia a la factura original por su CUFE. Eso permite reconstruir la historia completa de un título (quién lo aceptó, cuándo, quién lo adquirió por endoso) a partir de la secuencia de eventos, y es lo que un tercero, como un factor, consulta antes de comprar la factura.

Catálogo de eventos RADIAN y su función

El anexo técnico agrupa los eventos en dos bloques funcionales. El primero corresponde a la relación entre emisor y adquirente, es decir, a la aceptación de la factura. El segundo corresponde a la circulación del título: inscripción en RADIAN, endosos, limitaciones de circulación, mandatos y pago. La tabla resume los cinco eventos de aceptación, que son los que todo ISV debe soportar primero.

Código | Evento                              | Función principal                                          | Plazo
-------|-------------------------------------|------------------------------------------------------------|----------------------------------
030    | Acuse de recibo de la factura       | Constancia de que el adquirente recibió la factura          | Sin plazo propio; precede a 032
031    | Reclamo de la factura               | Rechazo o disputa de la factura por una causal legal        | 3 días hábiles tras recibir bien/servicio
032    | Recibo del bien o prestación del servicio | Constancia de recepción efectiva del bien o servicio  | Sin plazo propio; inicia el conteo
033    | Aceptación expresa                  | Aceptación activa e irrevocable por el adquirente           | Puede darse antes de vencer el plazo
034    | Aceptación tácita                   | Aceptación por vencimiento del plazo sin reclamo            | Tras los 3 días hábiles sin evento 031

Los eventos posteriores a la aceptación (endoso en propiedad, endoso en garantía, endoso en procuración, cancelación de endoso, limitación de circulación y su terminación, mandato y su terminación, y pago de la factura) forman el bloque de circulación. Sus códigos exactos y condiciones deben tomarse siempre de la versión vigente del anexo técnico de la DIAN, porque este es el bloque que más se ha ajustado entre versiones. Para el bloque de aceptación, los códigos 030 a 034 son estables y son los que sustentan el resto del cluster.

Ciclo de vida: de la emisión a título valor circulable

El flujo normal comienza cuando el emisor genera la factura electrónica de venta y la DIAN la valida, asignándole el CUFE. El adquirente la recibe y se genera el acuse de recibo (030). Cuando el adquirente efectivamente recibe la mercancía o el servicio se registra el evento 032. A partir de ahí corre el plazo de 3 días hábiles: si el adquirente reclama dentro del plazo, se registra el evento 031 con una causal; si acepta explícitamente, se registra el 033; y si el plazo vence sin reclamo, se configura la aceptación tácita (034).

Solo una factura que cuente con acuse de recibo y recibo del bien o servicio, y que no haya sido reclamada, puede quedar aceptada y circular como título valor. Esa es la razón por la que los eventos 030 y 032 no son un trámite administrativo menor: son los prerrequisitos que habilitan la aceptación. Una factura emitida correctamente pero sin estos dos eventos queda en un limbo en el que ni se acepta tácitamente ni puede inscribirse para negociarse.

Anatomía técnica de un evento: ApplicationResponse, CUDE y firma

Técnicamente, cada evento RADIAN se transmite como un documento XML basado en el esquema ApplicationResponse de UBL 2.1, firmado con XAdES, que referencia a la factura afectada por su CUFE y lleva un identificador propio calculado como CUDE. El documento incluye la identificación del emisor del evento, el código del tipo de evento y, cuando aplica, datos adicionales como la causal de un reclamo. La DIAN responde a cada envío con un resultado de validación que puede ser aceptación, aceptación con notificaciones o rechazo.

Para quien implementa esto directamente contra los servicios de la DIAN, el trabajo recae en tres piezas: construir el XML conforme al anexo técnico, firmarlo con el certificado del participante y gestionar el ciclo de envío y consulta de resultado. La mayoría de ISVs delega esa capa en un proveedor tecnológico habilitado y se limita a invocar una API que recibe el tipo de evento y la referencia de la factura. En ambos casos, el modelo de datos propio del ISV debe guardar el CUFE de la factura, el CUDE de cada evento y la respuesta de la DIAN, porque son la evidencia ante cualquier controversia.

Quién genera cada evento y qué responsabilidad recae en el ISV

Los eventos 030, 031, 032 y 033 son acciones del adquirente: reflejan su recepción, su reclamo o su aceptación. El evento 034 no depende de una acción positiva, sino del vencimiento del plazo, y su registro lo asume la parte habilitada según el anexo técnico vigente. Los eventos de circulación los generan el tenedor legítimo del título, el factor o el mandatario, según el caso. El ISV puede ocupar cualquiera de esos lados: si construye un ERP para vendedores, procesa eventos como emisor; si construye un software de compras o de cuentas por pagar, genera eventos como adquirente.

Esta distinción cambia el diseño. Un ISV de emisión necesita consultar y reaccionar a los eventos que llegan sobre sus facturas (por ejemplo, notificar al cliente que su factura fue aceptada tácitamente y ya puede ofrecerse a un factor). Un ISV de adquirentes necesita automatizar la generación de 030 y 032 para no perder los plazos y evitar que facturas con las que está de acuerdo queden aceptadas tácitamente por omisión, o al revés.

Modelo de estados recomendado para una integración por API

Conviene modelar la factura como una máquina de estados derivada de eventos, nunca como un campo que se sobrescribe. Un conjunto mínimo de estados es: emitida, acuse registrado, bien o servicio recibido, reclamada, aceptada expresamente y aceptada tácitamente. Cada transición solo es válida si el evento anterior requerido ya existe, y cada evento se guarda con su CUDE y la respuesta de la DIAN. Los eventos son inmutables: un error se corrige con un evento posterior permitido por el anexo, no editando el anterior.

Tres decisiones de ingeniería evitan la mayoría de los incidentes: calcular el vencimiento del plazo con un calendario de festivos colombiano en lugar de sumar días corridos; hacer idempotente el envío de cada evento (reintentar tras un timeout no debe generar un segundo evento); y reconciliar periódicamente el estado local contra la consulta a la DIAN, porque un evento pudo registrarse por otro canal, por ejemplo directamente en el portal por el adquirente.

Profundizaciones del cluster y errores frecuentes

Los eventos con más casos límite tienen su propia guía: el acuse de recibo y el recibo del bien (eventos 030 y 032), la diferencia entre aceptación tácita y expresa (eventos 033 y 034), el reclamo de la factura (evento 031) y sus causales y el diagnóstico de errores comunes al registrar eventos.

Como referencia de implementación, la API de facturación electrónica de Alanube para Colombia expone el registro y la consulta de eventos RADIAN tanto por API REST como por un servidor MCP, lo que ilustra los dos patrones de integración posibles: flujos deterministas por REST y consultas asistidas por un agente de IA.

Preguntas frecuentes

¿Cuáles son los eventos RADIAN que debe soportar primero una integración?

Los cinco eventos de aceptación: 030 acuse de recibo, 031 reclamo, 032 recibo del bien o servicio, 033 aceptación expresa y 034 aceptación tácita. Son los que determinan si una factura queda aceptada y puede circular como título valor. Los eventos de circulación (endosos, limitaciones, mandatos y pago) se implementan después, y solo si los clientes del ISV usan sus facturas para factoring u otras formas de negociación.

¿Cómo puedo calcular el plazo de 3 días hábiles de los eventos RADIAN?

Contando días hábiles colombianos a partir de la fecha de recepción del bien o servicio, excluyendo sábados, domingos y festivos nacionales. Lo más seguro es mantener en el sistema un calendario de festivos actualizado y calcular el vencimiento al registrar el evento 032, almacenando la fecha límite para disparar alertas antes de que se configure la aceptación tácita.

¿Qué diferencia hay entre un evento RADIAN y un estado de la factura electrónica?

Un estado es un valor que se actualiza sobre un registro; un evento RADIAN es un documento nuevo, firmado, con CUDE propio, que referencia a la factura por su CUFE y que queda registrado ante la DIAN. El historial de la factura es la secuencia de eventos. Por eso un integrador debe guardar cada evento como un registro inmutable y derivar el estado a partir de ellos.

¿Es posible usar RADIAN sin implementar todos los eventos de circulación?

Sí. Un ISV puede soportar únicamente los eventos de aceptación (030 a 034) y dejar los de circulación para cuando exista demanda de factoring o endosos. Lo que no es opcional es respetar los prerrequisitos: sin acuse de recibo y recibo del bien o servicio, la factura no puede quedar aceptada ni inscribirse para circular como título valor.

Sobre el autor

Ing. Carlos Méndez es arquitecto de software con más de 10 años integrando sistemas fiscales en América Latina. Ha liderado implementaciones de facturación electrónica en Colombia, México y Centroamérica para ISVs de mediana y gran escala.