Reclamo de la factura en RADIAN (evento 031): causales, plazo y cómo implementarlo

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.

El reclamo de la factura (evento 031) es el registro formal con el que el adquirente rechaza o disputa una factura electrónica de venta dentro de RADIAN, y es el único evento que impide que se configure la aceptación tácita, siempre que se registre dentro de los 3 días hábiles siguientes a la recepción del bien o servicio. Un correo al proveedor o una llamada no reemplazan ese registro: si el evento no consta ante la DIAN, la factura se acepta tal cual por el solo paso del tiempo.

Esta guía explica las causales de reclamo, cómo se cuenta el plazo, qué ocurre con la factura después y cómo diseñar el flujo en un sistema de cuentas por pagar y en uno de emisión. Es parte del cluster de eventos RADIAN, cuyo catálogo completo está en la guía técnica de eventos RADIAN.

Qué es el reclamo y qué efecto tiene sobre la factura

El reclamo tiene su base en el régimen de la factura como título valor (Ley 1231 de 2008, Ley 1676 de 2013, Decreto 1154 de 2020 y el Código de Comercio), que permite al adquirente reclamar en contra del contenido de la factura dentro de un plazo corto y por motivos específicos. Su efecto es doble: impide la aceptación tácita y deja constancia ante la DIAN de que la factura está en disputa, de modo que ningún tercero debería adquirirla como si fuera un título limpio.

Un reclamo válido no anula la factura ni extingue la obligación por sí solo. Lo que hace es congelar su avance en el ciclo de aceptación hasta que el conflicto se resuelva, normalmente corrigiendo el documento mediante una nota crédito o débito, o emitiendo una nueva factura.

Causales de reclamo y cómo reflejarlas en el sistema

El anexo técnico exige que el evento 031 incluya una causal de una lista cerrada. En términos funcionales, las causales cubren cuatro situaciones: el documento presenta inconsistencias en su contenido, la mercancía no fue entregada totalmente, la mercancía no fue entregada parcialmente, o el servicio no fue prestado. La redacción y los códigos exactos deben tomarse de la versión vigente del anexo, porque una causal inválida provoca el rechazo del evento.

Situación                             | Causal funcional             | Acción posterior típica
--------------------------------------|------------------------------|------------------------------------------
Datos de la factura incorrectos       | Inconsistencias en documento | Nota crédito/débito o refacturación
Mercancía no llegó                     | No entregada totalmente      | Entrega pendiente o anulación con nota crédito
Llegó solo una parte                   | No entregada parcialmente    | Ajuste de valor con nota crédito
Servicio no ejecutado                 | Servicio no prestado         | Anulación con nota crédito o prestación

En el modelo de datos, la causal debe ser un campo estructurado (un enumerado) y no un texto libre, de modo que el sistema pueda enrutar cada caso al equipo adecuado: inconsistencias al área de facturación del proveedor, entregas incompletas a logística, servicios no prestados al responsable del contrato.

Plazo: cuándo se debe registrar el reclamo

El reclamo debe registrarse dentro de los 3 días hábiles siguientes a la recepción del bien o servicio, es decir, a partir de la fecha del evento 032. Una vez vencido ese plazo sin reclamo, se configura la aceptación tácita (evento 034) y el reclamo deja de ser posible por esta vía. Por eso el sistema debe tratar la fecha límite como una restricción dura: no basta con que un analista detecte el problema el cuarto día.

El cálculo debe usar días hábiles colombianos con calendario de festivos y debe tomar como referencia la respuesta de la DIAN al evento 032, no el reloj local. Un reclamo enviado el último día hábil cerca del cierre es un caso de riesgo: conviene que el flujo de revisión tenga alertas anteriores y que el envío del 031 sea prioritario sobre cualquier cola de procesamiento por lotes.

Flujo recomendado en cuentas por pagar

Un flujo robusto empieza al registrar el recibo del bien (evento 032, descrito en la guía de acuse de recibo y recibo del bien): en ese momento se calcula la fecha límite, se crea una tarea de revisión para el responsable de la compra y se programan recordatorios. El revisor tiene dos salidas explícitas, aceptar (que genera el evento 033) o reclamar con una causal (que genera el 031). Si no decide, el sistema debe escalar, no esperar en silencio a que venza el plazo.

Dos controles reducen errores. El primero es exigir evidencia al reclamar (acta de entrega con faltantes, correo con el error de la factura), almacenada junto al CUDE del evento. El segundo es impedir el reclamo duplicado: antes de enviar, el sistema consulta si ya existe un 031 o un 033 para esa factura, porque aceptar y reclamar la misma factura son acciones incompatibles.

Qué hace el emisor cuando recibe un reclamo

Para un ISV de emisión, el reclamo es una notificación que debe llegar al cliente de inmediato, porque su factura deja de avanzar hacia la aceptación. El sistema debe mostrar la causal, bloquear la factura para ofrecerla en factoring y abrir un flujo de resolución: validar si el reclamo es procedente, corregir el documento mediante nota crédito o débito, o emitir una factura nueva.

Si el emisor considera que el reclamo es improcedente, la discusión sale del flujo electrónico y pasa a la vía comercial o jurídica. El papel del software es dejar la trazabilidad completa: fecha del reclamo, causal, documentos de soporte y comunicaciones, para que el cliente tenga evidencia ordenada. Una vez resuelto el conflicto, el ciclo de aceptación se retoma según lo descrito en la guía de aceptación tácita y expresa.

Errores de implementación más comunes

El primer error es reclamar fuera de plazo y recibir un rechazo o, peor, un registro que no impide la aceptación tácita. El segundo es enviar una causal que no corresponde a la lista del anexo vigente. El tercero es tratar el reclamo como un estado editable: una vez registrado, el evento es inmutable, y si el adquirente se equivocó debe gestionarse con los mecanismos que el anexo permita y no sobrescribiendo datos locales. Los mensajes de rechazo más habituales y su diagnóstico están en la guía de errores comunes al registrar eventos RADIAN.

Preguntas frecuentes

¿Cuál es el plazo para reclamar una factura electrónica en RADIAN?

Tres días hábiles contados desde la recepción del bien o la prestación del servicio (evento 032). Pasado ese plazo sin reclamo, se configura la aceptación tácita y la factura queda aceptada de forma irrevocable. El conteo excluye sábados, domingos y festivos colombianos.

¿Cómo puedo registrar un reclamo (evento 031) desde mi sistema?

Enviando el evento con el CUFE de la factura y una causal válida del anexo técnico vigente, ya sea construyendo el XML y firmándolo directamente o invocando la API de un proveedor tecnológico habilitado. Antes de enviarlo conviene verificar que el plazo no ha vencido y que no existe ya un evento de aceptación sobre esa factura.

¿Qué diferencia hay entre un reclamo en RADIAN y una nota crédito?

El reclamo es un evento del adquirente que disputa la factura e impide su aceptación; la nota crédito es un documento del emisor que corrige o anula total o parcialmente la factura. Suelen ir en secuencia: el adquirente reclama y el emisor responde con una nota crédito o una refacturación, pero son documentos distintos con emisores distintos.

¿Es posible reclamar una factura después de que venció el plazo de 3 días hábiles?

No por la vía del evento 031: vencido el plazo, la aceptación tácita es irrevocable. Si la factura tiene un error real, la salida es solicitar al emisor una nota crédito o débito, o discutir la obligación por la vía comercial o jurídica. Por eso el control de plazos en el sistema es la defensa principal.

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.