🇨🇴ColombiaGuía Técnica

Acuse de recibo y recibo del bien en RADIAN: eventos 030 y 032 explicados para desarrolladores

Qué son los eventos 030 y 032 de RADIAN, por qué son prerrequisito de la aceptación y cómo automatizarlos desde un software de compras o cuentas por pagar.

Ing. Carlos Méndez
Arquitecto de Software · Integraciones Fiscales LATAM
7 min lectura15 de octubre de 2026

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.

Resumen: el evento 030 (acuse de recibo) confirma que el adquirente recibió la factura y el 032 (recibo del bien o servicio) confirma que recibió lo facturado. Sin ambos, la factura no puede quedar aceptada ni circular como título valor en RADIAN.

El acuse de recibo (evento 030) es la constancia electrónica de que el adquirente recibió la factura electrónica de venta, y el recibo del bien o prestación del servicio (evento 032) es la constancia de que recibió efectivamente lo facturado; ambos son prerrequisito para que la factura pueda aceptarse y circular como título valor. El error típico de un ISV es tratarlos como notificaciones de cortesía: se emiten tarde, de forma manual o nunca, y la factura queda sin poder avanzar en el ciclo.

Esta guía profundiza en esos dos eventos dentro del cluster de eventos RADIAN. Explica qué representa cada uno, cómo se relacionan con el plazo de 3 días hábiles, qué debe guardar el sistema y cómo automatizar su generación desde un módulo de compras. Para el catálogo completo de eventos, el punto de partida es la guía técnica de eventos RADIAN.

Qué representa cada evento y en qué se diferencian

El evento 030 prueba la recepción del documento: el adquirente, o el proveedor tecnológico que actúa por él, certifica que la factura electrónica llegó a su buzón. No dice nada sobre si la mercancía llegó, ni sobre si el adquirente está de acuerdo con la factura. El evento 032, en cambio, prueba la recepción del bien o la prestación del servicio: es un hecho operativo del mundo real (la mercancía ingresó a bodega, el servicio se ejecutó) que se refleja en el registro.

Esta separación existe porque la factura y la entrega son momentos distintos: una factura puede llegar el lunes y la mercancía el jueves. El plazo para reclamar y la aceptación tácita se cuentan desde la recepción del bien o servicio, no desde la recepción de la factura, y por eso el 032 es el evento que realmente inicia el reloj legal.

text
Aspecto                     | Evento 030 (acuse de recibo)        | Evento 032 (recibo del bien/servicio)
----------------------------|-------------------------------------|----------------------------------------
Qué certifica               | Recepción del documento electrónico | Recepción física del bien o del servicio
Quién lo genera             | Adquirente (o su proveedor)         | Adquirente (o su proveedor)
Dispara el plazo de 3 días  | No                                  | Sí, según el criterio de recepción
Orden típico                | Primero                             | Después del 030
Requisito para aceptación   | Sí                                  | Sí
Evidencia a guardar         | CUDE del evento, respuesta DIAN     | CUDE del evento, fecha real de entrega

Por qué son prerrequisitos de la aceptación y del título valor

El marco legal de la factura como título valor (Ley 1231 de 2008, modificada por la Ley 1676 de 2013, y el Decreto 1154 de 2020) exige constancia de recibo de la factura y de recibo de la mercancía o del servicio para que el título pueda circular. En el modelo de RADIAN esa exigencia se traduce en eventos: sin 030 y 032 registrados, el sistema no tiene la base para configurar una aceptación y la factura no es negociable.

Para el vendedor, esto tiene una consecuencia práctica: aunque emita todas sus facturas correctamente, no podrá ofrecerlas a un factor mientras el adquirente no haya registrado esos eventos. Un ISV que atiende a vendedores debe, por tanto, monitorear el estado de acuse y recibo de cada factura y alertar al cliente cuando una factura lleva días sin avanzar, porque ese es el cuello de botella real del financiamiento.

Cómo automatizar 030 y 032 desde un software de compras

Para un ISV que construye módulos de compras o cuentas por pagar, el acuse (030) se puede generar de forma automática en cuanto la factura entra al sistema y pasa las validaciones básicas, porque su sentido es probar la recepción del documento. El recibo del bien (032) no debe automatizarse a ciegas: tiene que dispararse desde un hecho real, como el cierre de la orden de recepción en bodega o la firma de conformidad del servicio. Automatizarlo antes de que el bien llegue crea un registro falso y adelanta el reloj del plazo para reclamar.

El patrón recomendado es acoplar el evento 032 al documento interno de recepción del ERP: cuando la entrada de mercancía se confirma, el sistema invoca la API de eventos con el CUFE de la factura y la fecha de recepción. Así el registro ante la DIAN refleja exactamente lo que ocurrió en la operación, y el sistema puede calcular desde ese momento la fecha límite de los 3 días hábiles.

json
pseudocódigo ilustrativo
// PSEUDOCÓDIGO: no es el contrato de ninguna API real
onFacturaRecibida(factura) {
  validarLocalmente(factura)
  registrarEvento({ tipo: 30, cufe: factura.cufe })        // acuse
}
onRecepcionBodegaConfirmada(factura, fechaRecepcion) {
  registrarEvento({ tipo: 32, cufe: factura.cufe,
                    fecha: fechaRecepcion })               // recibo del bien
  fechaLimite = sumarDiasHabiles(fechaRecepcion, 3, festivosCO)
  programarAlerta(factura, fechaLimite)
}

Qué debe guardar el sistema y cómo evitar duplicados

Cada evento exitoso debe persistirse con el CUFE de la factura, el CUDE del evento, la fecha y hora de registro, el resultado de validación de la DIAN y el usuario o proceso que lo originó. Esos datos son la evidencia si más adelante hay una controversia sobre si el bien se recibió o cuándo. Para el 032, conviene guardar además la referencia al documento interno que lo sustenta, como la orden de recepción o el acta de conformidad.

El riesgo técnico más frecuente es el duplicado: un timeout en la llamada de registro hace que el cliente reintente y se intente enviar dos veces el mismo evento. La defensa es usar una clave de idempotencia derivada de la combinación CUFE más tipo de evento, consultar el estado antes de reintentar y tratar una respuesta de evento ya registrado como éxito, no como error.

Casos límite: entregas parciales, servicios continuos y facturas sin recibo

Las entregas parciales y los servicios continuos son donde el modelo se complica. Si una factura cubre una entrega que llega en varias remesas, el sistema debe decidir cuándo considera recibido el bien: lo prudente es registrar el 032 solo cuando la recepción esté completa, y usar el evento de reclamo con la causal correspondiente si hay faltantes, tema que se desarrolla en la guía del reclamo de la factura (evento 031). En servicios continuos, conviene facturar por períodos y tratar cada factura como una recepción independiente.

El otro caso frecuente es la factura que nunca recibe acuse ni recibo porque el adquirente no usa un sistema integrado. Aquí el ISV de emisión debe ofrecer una alternativa: un tablero que liste las facturas sin eventos y una forma de recordarle al adquirente que debe registrarlos. Una vez registrados, el siguiente paso del ciclo es la aceptación, cuyas modalidades se detallan en la guía de aceptación tácita y expresa.

Preguntas frecuentes

¿Cuál es la diferencia entre el acuse de recibo y el recibo del bien en RADIAN?

El acuse de recibo (evento 030) certifica que el adquirente recibió el documento electrónico de la factura. El recibo del bien o servicio (evento 032) certifica que recibió la mercancía o que el servicio fue prestado. Son hechos distintos y pueden ocurrir en fechas distintas; el plazo para reclamar se cuenta desde el segundo, no desde el primero.

¿Cómo puedo automatizar el evento 032 sin registrar recepciones falsas?

Acoplando el registro al documento interno que prueba la recepción, como la orden de entrada de mercancía o el acta de conformidad del servicio. El evento se dispara cuando ese documento se confirma, con la fecha real de recepción. Nunca debe dispararse al ingresar la factura al sistema, porque la factura puede llegar antes que el bien.

¿Qué diferencia hay entre no registrar el evento 032 y reclamar la factura?

No registrar el 032 deja la factura sin avanzar: no corre el plazo y no se configura la aceptación. Reclamar la factura (evento 031) es una acción formal con una causal legal que disputa su contenido o la entrega. Omitir el 032 no equivale a rechazar la factura y no protege al adquirente si luego se discute la deuda.

¿Es posible aceptar una factura en RADIAN sin haber registrado el acuse de recibo?

No de forma válida para circular como título valor: el acuse de recibo y el recibo del bien son prerrequisitos de la aceptación en el modelo de eventos de la DIAN. Un sistema bien diseñado debe impedir la transición a aceptada si esos eventos no están registrados, en lugar de dejar que el error aparezca como rechazo al enviar el evento.

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.