Modo Contingencia DIAN: Facturación Offline Colombia

Cuando los servidores de la DIAN dejan de responder en producción, la facturación de una empresa no puede simplemente detenerse — la operación comercial continúa, los clientes siguen llegando a las cajas, y los documentos se siguen emitiendo. El modo de contingencia es la respuesta normativa-técnica a ese escenario, y entender exactamente cómo activarlo, cómo se diferencia un documento de contingencia y cómo retransmitir cuando se restaura el servicio es lo que distingue una integración preparada de una que entra en crisis cuando ocurre la primera caída.

Esta guía explica cuándo se activa el modo de contingencia DIAN, qué prefijo y CUFE distintos se aplican en este modo, cómo se retransmiten los documentos al servidor cuando se restaura el servicio, los plazos legales aplicables y los errores frecuentes en la retransmisión que pueden dejar documentos en limbo legal.

Cuándo activar el modo de contingencia

Indisponibilidad del servidor DIAN

El escenario típico es caída total del endpoint de validación DIAN: ninguna transmisión obtiene respuesta dentro del timeout esperado y los reintentos siguen fallando con timeout o 5xx. Cuando esto se sostiene más allá de unos minutos y la operación comercial no puede esperar, el modo de contingencia se activa para que la facturación continúe offline con un mecanismo de retransmisión posterior.

Indisponibilidad del propio sistema emisor

También procede contingencia cuando el problema es del lado del emisor: certificado vencido sin renovación inmediata, pérdida temporal del PFX, error grave de configuración del software. En estos casos la lógica es la misma — emitir documentos de contingencia para no detener la operación — pero la responsabilidad de resolver el problema y retransmitir queda enteramente del lado del emisor sin externalidad de la DIAN.

Diferencias técnicas del documento de contingencia

Prefijo y rango independientes

Los documentos de contingencia llevan un prefijo distinto al rango normal de producción. La DIAN autoriza explícitamente un prefijo de contingencia al habilitarse el emisor; sin ese prefijo configurado, no se puede operar contingencia. El rango asignado al prefijo de contingencia también es independiente y suele ser más pequeño que el de producción, dimensionado para cubrir las ventanas razonables de caída.

CUFE específico de contingencia

El CUFE de contingencia se calcula con la misma fórmula SHA-384 que el normal pero con valores específicos: el campo TipoAmb mantiene el valor normal (1 para producción) y se añaden indicadores en el XML que identifican el documento como contingencia. La verificación local del CUFE debe usar la misma lógica para ambos modos; lo que cambia es qué marca del XML se incluye.

Validez legal inmediata

Un documento de contingencia es legalmente válido desde el momento de su emisión, sin necesidad de aprobación previa por la DIAN. Esa es la razón de existir del mecanismo: permitir que la operación continúe cuando la validación previa no es posible. La validez se ratifica posteriormente con la retransmisión exitosa al servidor, pero no depende de ella para los efectos inmediatos de la operación.

Retransmisión al servidor cuando se restaura el servicio

Plazo máximo legal

La normativa DIAN establece plazo máximo para retransmitir documentos emitidos en contingencia: típicamente 48 horas desde que se restaura el servicio. Pasado ese plazo, los documentos no transmitidos pasan a calificarse como omitidos y exponen al emisor a sanción. El monitoreo debe incluir alertas automáticas sobre documentos de contingencia pendientes de retransmisión para evitar exceder el plazo.

Estructura del lote de retransmisión

La retransmisión se hace documento por documento al endpoint normal de la DIAN, marcados con el indicador de contingencia. La DIAN los procesa con un flujo de validación levemente diferente al normal: verifica que efectivamente hubo contingencia (fechas, secuencia), valida el contenido del documento, y registra el resultado en el repositorio. Si todo coincide, la ApplicationResponse confirma la retransmisión exitosa.

Orden cronológico de la retransmisión

Conviene retransmitir los documentos en el orden cronológico en que se emitieron originalmente. La DIAN no exige estrictamente ese orden pero su violación complica la trazabilidad y, en casos límite, dispara alertas en el motor de validación. La práctica recomendada es procesar la cola de retransmisión en FIFO.

Errores frecuentes en retransmisión

Documento duplicado

Si la cola de retransmisión no maneja correctamente el estado de cada documento, puede ocurrir que un documento se retransmita dos veces — una vez en contingencia, otra vez como retransmisión — y la DIAN rechace la segunda con FAB16. Prevención: marcar cada documento con su estado (pendiente, transmitido, confirmado) en la base de datos local y consultar antes de retransmitir.

Plazo de retransmisión vencido

Cuando un documento de contingencia no se retransmite dentro del plazo legal, la DIAN lo califica como omitido. La retransmisión posterior es técnicamente posible pero ya implica sanción por extemporaneidad. Si una caída larga genera muchos documentos pendientes, conviene priorizar la retransmisión por valor (los más importantes primero) para minimizar el impacto si no se logra completar todo dentro del plazo.

Rechazo del contenido al retransmitir

Es posible que la DIAN rechace el contenido de un documento de contingencia al retransmitirlo — típicamente por totales mal calculados, NIT del adquiriente inválido o algunos errores que en validación previa habrían impedido la emisión. Como el documento ya tuvo validez legal desde su emisión, el rechazo posterior abre un escenario donde hay que emitir nota crédito anuladora y nuevo documento corregido. Vale la pena hacer las validaciones locales completas antes de emitir contingencia para minimizar este caso.

La documentación pública de Alanube describe el flujo de validaciones locales completas que se aplican antes de emitir contingencia (CUFE, totales, dvNIT, rango activo), lo cual hace que un documento de contingencia raramente sea rechazado al retransmitirse — manteniendo la integridad legal de la operación durante la ventana de caída.

Preguntas frecuentes

¿Cuál es la diferencia entre modo de contingencia y reintento por timeout? No son lo mismo. Un reintento por timeout asume que la DIAN está respondiendo lenta o intermitentemente: se transmite, se espera, si no responde se reintenta con backoff. El modo de contingencia es una decisión más gruesa: cuando la DIAN no responde sostenidamente y la operación no puede esperar, se cambia a emisión offline con prefijo de contingencia. El reintento es técnico y automático; la contingencia es declarativa y queda registrada en el sistema emisor. La práctica habitual es agotar reintentos antes de pasar a contingencia, normalmente tras unos minutos sostenidos de falla.

¿Cómo puedo automatizar la detección del momento en que activar contingencia? Monitoreo del endpoint DIAN con health check cada N segundos más contador de fallos consecutivos. Cuando el contador supera un umbral (típicamente 3-5 fallos consecutivos en ventana de 1-2 minutos), el sistema marca el endpoint como caído y conmuta a emisión en contingencia. Cuando el health check vuelve a pasar, el sistema marca el endpoint como restaurado y dispara el job de retransmisión de la cola acumulada. La automatización debe incluir una bandera que el operador pueda forzar manualmente cuando se sabe de una caída planificada de la DIAN.

¿Qué diferencia hay entre contingencia por caída DIAN y contingencia por problema interno del emisor? Normativamente ambos califican como modo de contingencia y el documento emitido es idénticamente válido. La diferencia es operativa: cuando la causa es la DIAN, la duración de la caída no depende del emisor y la retransmisión inicia tan pronto la DIAN vuelve. Cuando la causa es interna, la duración depende del equipo (renovar certificado, restaurar PFX, etc.) y el plazo de retransmisión empieza a correr desde que se resuelve internamente, no desde la disponibilidad del servidor. En auditorías DIAN posteriores, la contingencia por causa interna recibe escrutinio adicional para verificar que efectivamente no hubo negligencia.

¿Es posible emitir notas crédito o débito en modo contingencia? Sí. Las notas crédito y débito pueden emitirse en contingencia con la misma lógica que las facturas: prefijo de contingencia específico, CUDE calculado según la fórmula correspondiente al tipo de documento, validez legal inmediata, y retransmisión posterior dentro del plazo. La complicación adicional es que las notas deben referenciar la factura original; si la factura original también está en contingencia pendiente de retransmisión, el orden de retransmisión importa — primero la factura, luego las notas — para que la DIAN pueda validar la referencia.

Modo de Contingencia DIAN: Facturación Offline y Retransmisión Correcta