RADIAN Colombia: integración técnica de eventos en factura negociable
Una factura electrónica en Colombia puede convertirse en un título valor negociable — puede endosarse, cederse o usarse como garantía financiera. Pero ninguna de esas operaciones tiene validez si los eventos no quedan registrados en RADIAN (Registro de Facturas Electrónicas de Venta como Título Valor). Si tu sistema permite que los clientes hagan operaciones de financiamiento sobre facturas electrónicas y no integra RADIAN, esos eventos son jurídicamente inexistentes para la DIAN y el sistema financiero colombiano.
Esta guía cubre la integración técnica de RADIAN: qué eventos existen, cómo construir el XML de evento, calcularlo con el CUFE de la factura original y enviarlo al servicio de la DIAN. Audiencia: desarrolladores integrando sistemas de financiamiento de cartera, factoring o confirmación de pago con el ecosistema de factura electrónica colombiano.
Prerrequisitos
- Factura electrónica de venta (FEV) previamente aceptada por la DIAN con CUFE válido
- Habilitación en el portal DIAN para el uso de RADIAN (diferente al proceso de factura electrónica)
- Certificado digital de firma para el actor que registra el evento (emisor, comprador, financiador)
- Software de facturación habilitado para RADIAN ante la DIAN
- Ambiente de pruebas DIAN para RADIAN: https://vpfe-hab.dian.gov.co/
¿Qué es RADIAN y para qué sirve?
RADIAN es el sistema de la DIAN que registra los eventos que ocurren sobre una factura electrónica de venta después de su emisión. Convierte la factura en un instrumento negociable con respaldo digital verificable. Los actores principales en el ciclo RADIAN son:
- Emisor (vendedor): Emite la factura y puede endosarla en propiedad
- Receptor (comprador): Acusa recibo y puede aceptar expresamente la factura
- Tenedor legítimo: Quien adquirió la factura por endoso o cesión
- Factor / entidad financiera: Puede adquirir la factura para anticipar el pago al vendedor
Tipos de eventos RADIAN
| Código | Nombre del evento | Actor que lo registra | Plazo máximo |
|---|---|---|---|
| 030 | Acuse de recibo de la FEV | Receptor (comprador) | 3 días hábiles |
| 031 | Recibo del bien o prestación del servicio | Receptor | Posterior al evento 030 |
| 032 | Aceptación expresa de la FEV | Receptor | Posterior al evento 031 |
| 033 | Aceptación tácita (transcurso de 3 días) | Sistema automático | Automático a los 3 días |
| 034 | Endoso en propiedad | Tenedor actual | Posterior al evento 032/033 |
| 036 | Endoso en garantía | Tenedor actual | Posterior al evento 032/033 |
| 043 | Pago de la FEV | Tenedor actual | Al momento del pago |
Estructura del XML de evento RADIAN
El XML de evento RADIAN usa el mismo namespace UBL 2.1 de la factura electrónica colombiana. A diferencia de la factura, el evento referencia el CUFE de la factura original y describe la operación realizada:
Nota: El XML de ejemplo completo está disponible en la documentación técnica de Alanube.
Flujo de registro del evento en la DIAN
Nota: El código funcional de envío SOAP está disponible en la documentación técnica de Alanube.
💡 Con Alanube: El endpoint POST /radian/events de Alanube Colombia acepta el payload JSON del evento, construye el XML ApplicationResponse, aplica la firma XAdES-BES y registra el evento en la DIAN — eliminando la integración directa con el servicio SOAP.
Dependencias entre eventos
Los eventos RADIAN tienen dependencias estrictas — no se puede registrar un endoso sin antes haber registrado el acuse de recibo y la aceptación. El flujo obligatorio para que una factura sea negociable es: 030 → 031 → 032 (o 033 tácito). Solo después de este ciclo se pueden registrar eventos de endoso (034, 036) o pago (043). La DIAN rechazará cualquier evento que llegue fuera de esta secuencia con error Regla: R-RADIAN-001.
Consulta del estado de eventos sobre una factura
Antes de registrar cualquier evento nuevo sobre una factura, el sistema debe consultar el historial de eventos ya registrados en RADIAN. Un evento puede haberse registrado por otro actor (por ejemplo, el comprador ya registró la aceptación tácita antes de que el vendedor lo verificara), y enviar un evento incompatible con el estado actual produce un rechazo.
El servicio de consulta de RADIAN permite obtener todos los eventos registrados sobre un CUFE específico. La respuesta incluye el código de cada evento, la fecha de registro, el actor que lo registró y el estado del evento (activo, anulado). Esta consulta debe ejecutarse antes de cualquier operación de endoso o financiamiento para verificar que la cadena de eventos cumple los requisitos.
Un patrón común en sistemas de factoring: el proveedor de financiamiento consulta el estado RADIAN de la factura como parte del proceso de due diligence antes de aprobar el anticipo. Si la factura no tiene el evento 032 (aceptación expresa) o 033 (tácita), no puede ser negociada y el anticipo es rechazado automáticamente por el sistema.
Casos de uso: factoring, confirming y supply chain finance
RADIAN es la infraestructura técnica detrás de varios productos financieros en Colombia. Los tres casos de uso más relevantes para desarrolladores son:
- Factoring (descuento de facturas): El vendedor endosa la factura en propiedad (código 034) a una entidad financiera. La entidad anticipa el valor de la factura al vendedor, descontando un porcentaje. Al vencimiento, el comprador paga directamente a la entidad financiera. El sistema del vendedor debe automatizar el registro del endoso en RADIAN inmediatamente después de que la entidad financiera apruebe la operación.
- Confirming (pago a proveedores): El comprador (empresa grande) garantiza a sus proveedores el pago de facturas en una fecha específica. La entidad financiera anticipa el pago al proveedor. El sistema del comprador debe registrar la aceptación expresa (código 032) oportunamente para que el proveedor pueda negociar la factura.
- Supply chain finance: Un administrador del programa coordina múltiples proveedores y una entidad financiera. El sistema debe manejar múltiples endosos (034) y eventos de pago (043) sobre distintas facturas en paralelo, respetando la secuencia de estados de cada una.
En los tres casos, la integración con RADIAN debe ser lo suficientemente robusta para manejar reintentos, consultar el estado antes de registrar eventos y alertar al equipo operativo cuando una factura queda en estado inconsistente (por ejemplo, un evento rechazado por la DIAN que bloquea el flujo de financiamiento).
Consideraciones para entornos de producción
La integración RADIAN en producción requiere atención especial a tres aspectos que no son evidentes en el ambiente de habilitación:
- Gestión de certificados por actor: Cada entidad que firma eventos RADIAN (vendedor, comprador, factor) debe tener su propio certificado digital activo. Si el vendedor delega el registro de eventos al software de facturación, el certificado del software debe estar autorizado para actuar en nombre del vendedor ante la DIAN. La cadena de autorización debe documentarse antes de salir a producción.
- Manejo de rechazos asincrónicos: La DIAN puede aceptar un evento de forma preliminar y rechazarlo en una validación posterior. El sistema debe consultar periódicamente el estado de los eventos registrados y manejar el caso en que un evento pase de “aceptado” a “rechazado” horas después — esto puede bloquear operaciones de financiamiento que se iniciaron con base en el estado anterior.
- Trazabilidad por CUFE: Cada operación RADIAN debe quedar trazada en la base de datos del sistema vinculando el CUFE de la factura, el código del evento, la fecha de registro y el actor. Esta trazabilidad es indispensable ante cualquier disputa legal sobre la titularidad o el estado de pago de una factura negociada.
Errores comunes en la integración RADIAN
Error: Regla: R-RADIAN-001 — Evento no corresponde al estado actual de la factura
Causa: Se intentó registrar un evento de endoso sin que exista el evento 032 (aceptación) previo en RADIAN.
Solución: Consultar los eventos existentes sobre el CUFE de la factura antes de registrar cualquier evento. Respetar la cadena: 030 → 031 → 032 o 033 → eventos de negociación.
Error: Regla: R-RADIAN-010 — CUFE de la factura referenciada no encontrado
Causa: El CUFE incluido en el DocumentReference del XML no corresponde a ninguna factura aceptada por la DIAN, o el ambiente es diferente (usar CUFE de producción en habilitación).
Solución: Verificar que el CUFE sea el de la factura aceptada en el mismo ambiente (hab o prod). Los ambientes son completamente independientes.
Error: Regla: R-RADIAN-025 — El actor no está autorizado para registrar este evento
Causa: El NIT del firmante del XML no coincide con el actor autorizado para ese tipo de evento. Por ejemplo, solo el receptor puede registrar el acuse de recibo (030), y solo el tenedor actual puede registrar el endoso (034).
Solución: Verificar que el certificado de firma corresponde al NIT del actor correcto para cada tipo de evento.
Error: Regla: R-RADIAN-040 — Factura ya pagada, no se permiten más eventos
Causa: Se intentó registrar un evento (endoso, garantía) sobre una factura que ya tiene el evento 043 (pago) registrado.
Solución: Una factura pagada está cerrada — no acepta más eventos RADIAN. Consultar el estado del CUFE antes de iniciar cualquier operación de financiamiento.
FAQ
¿Qué diferencia hay entre aceptación expresa (032) y aceptación tácita (033)?
La aceptación expresa (código 032) es el registro activo por parte del comprador confirmando que recibió los bienes o servicios. La aceptación tácita (código 033) opera automáticamente cuando transcurren 3 días hábiles desde el evento 031 sin que el comprador registre ningún rechazo. Ambas habilitan la negociabilidad de la factura, pero la expresa tiene mayor certeza jurídica para operaciones de factoring o financiamiento.
¿Cómo manejar el endoso de una factura a una entidad financiera?
El endoso en propiedad (código 034) transfiere la titularidad de la factura al endosatario (la entidad financiera). El XML del evento debe incluir los datos del nuevo tenedor en el nodo ReceiverParty, y debe estar firmado por el cedente actual. El nuevo tenedor pasa a ser quien registra el eventual evento de pago (043) cuando la factura se cancela.
¿Qué pasa si el comprador rechaza la factura en lugar de aceptarla?
El rechazo se registra con el código 031 en modo “Rechazo”, indicando la causa. Una vez registrado el rechazo en RADIAN, la factura no puede ser negociada y el emisor deberá emitir una nota crédito para anularla. El rechazo es definitivo — no puede revertirse una vez enviado a la DIAN, por lo que el comprador debe verificar los datos antes de registrar el evento.
¿La API de Alanube Colombia incluye integración con RADIAN?
Sí. El endpoint POST /radian/events de Alanube Colombia gestiona todos los tipos de eventos RADIAN, incluyendo la validación de dependencias entre eventos, la firma XAdES-BES y el envío SOAP a la DIAN. También expone un endpoint de consulta de estado para verificar los eventos registrados sobre cualquier factura. Más información en alanube.co.
¿Pueden coexistir un endoso en propiedad y un endoso en garantía sobre la misma factura?
No. Una factura solo puede tener un tenedor legítimo a la vez. El endoso en propiedad (034) transfiere completamente la titularidad. El endoso en garantía (036) no transfiere titularidad pero bloquea nuevas operaciones de endoso hasta que la garantía se cancele. Ambos eventos son mutuamente excluyentes en el estado activo de la factura — la DIAN rechazará el segundo endoso si el primero no ha sido reemplazado o cancelado.
Fuentes
- DIAN. (2021). Resolución 000042 de 2020 actualizada — Documentos electrónicos, RADIAN y eventos. Dirección de Impuestos y Aduanas Nacionales. https://www.dian.gov.co/impuestos/Paginas/Factura_Electronica.aspx
- DIAN. (2022). Anexo técnico RADIAN versión 1.0 — Registro de facturas electrónicas de venta como título valor. DIAN.
- Congreso de Colombia. (2020). Ley 2024 de 2020 — Circulación y negociación de facturas electrónicas. Diario Oficial.
