Errores Frecuentes en Transmisión de Documentos Electrónicos a la DIAN

Los códigos de error que devuelve la DIAN al rechazar una transmisión son específicos y, una vez se conoce su catálogo, el diagnóstico baja de horas a minutos. Pero al inicio de una integración la respuesta "FAB14b" o "REGLA: 2A1" suele acompañar al desarrollador durante días hasta descifrar qué significa exactamente y cómo corregirlo — perdiendo tiempo que podría evitarse con una referencia clara desde el primer rechazo.

Esta guía recorre los códigos de error más frecuentes que la DIAN devuelve en producción, qué los causa, cómo diagnosticarlos sin recurrir al soporte del PT, y qué patrones de validación local conviene implementar para prevenirlos antes de transmitir.

Categorías de errores DIAN

Errores sintácticos (rechazo duro)

La DIAN valida primero la estructura del XML contra su XSD. Errores en este nivel — elementos faltantes, atributos mal formados, namespaces incorrectos — producen fault SOAP inmediato con detalle del elemento problemático. No hay ApplicationResponse en este caso: la transmisión se rechaza antes de entrar a validación de negocio. Diagnosticar es sencillo porque el error apunta al elemento exacto.

Errores de validación de negocio

Si el XML es estructuralmente válido, la DIAN ejecuta validación de negocio sobre el contenido: coherencia de totales, vigencia de claves, rangos de numeración, CUFE correcto. Estos errores se devuelven como ApplicationResponse con código específico (FAB14b, FAB16, etc.). Cada código apunta a una causa concreta documentada en el Anexo Técnico.

Códigos de error más frecuentes en producción

FAB14b — CUFE inválido

El CUFE enviado no coincide con el que la DIAN recalcula sobre los campos del XML. Causas más frecuentes: formato decimal incorrecto (ValTot=1190.0 en lugar de 1190.00), clave técnica del ambiente equivocado, campo concatenado fuera de orden, codificación del XML diferente entre el cálculo y el envío. Diagnóstico: reconstruir la cadena de entrada desde el XML transmitido y aplicar SHA-384 localmente; comparar con el CUFE que iba en el elemento UUID.

FAB16 — Número de factura duplicado

El número de factura enviado ya fue aprobado previamente para el mismo emisor. La DIAN identifica documentos por número único, no por CUFE — reenviar un número con payload distinto se rechaza. Causa más frecuente: reintento de transmisión donde la primera vez sí llegó y fue aprobada pero el sistema interno no recibió la ApplicationResponse y reintentó. Prevención: mantener índice de CUFEs ya aprobados y consultar GetStatus antes de reintentar.

REGLA: F22 — Totales incoherentes

La suma de las líneas de detalle no coincide con TaxInclusiveAmount o PayableAmount por décimas de centavo. La DIAN aplica tolerancia cero a estas diferencias. Causa habitual: aritmética de punto flotante en lugar de aritmética decimal precisa. Prevención: usar BigDecimal en Java, Decimal en Python o equivalentes en otros lenguajes; redondear los totales al final del cálculo, no en intermedios.

REGLA: A13 — NIT del adquiriente no válido

El NIT del adquiriente enviado no existe en el registro de la DIAN o no es válido por dígito de verificación. En sandbox, este error casi siempre indica que se está usando un NIT real en lugar del sintético. En producción, indica que el NIT del adquiriente está mal capturado en el sistema interno o que el dígito de verificación se calculó incorrectamente. Prevención: validar localmente el dígito de verificación contra el catálogo de NITs antes de transmitir.

REGLA: A15 — Rango de numeración vencido o agotado

El número de factura intentado está fuera del rango autorizado vigente. Causas: la resolución de autorización de numeración venció y no se renovó, el rango asignado se agotó por consumo, o el sistema interno quedó desincronizado del rango registrado en MUISCA. Prevención: monitorear el porcentaje de uso del rango y solicitar nuevo rango antes del 80% de consumo; verificar fecha de vigencia de la resolución con anticipación.

Diagnóstico paso a paso de un rechazo

Paso 1: capturar el código y descripción exactos

El primer paso siempre es loguear la ApplicationResponse completa que devuelve la DIAN, no solo el estado. La descripción del error suele incluir el campo problemático, el valor enviado, y el valor esperado por la DIAN. Sin ese detalle, el diagnóstico se vuelve adivinar; con ese detalle, suele bastar para corregir directamente.

Paso 2: reproducir localmente

Una vez identificado el código, intentar reproducir el escenario en sandbox con el mismo payload. Si reproduce, el problema es del XML construido y se aisla en el código de generación. Si no reproduce, el problema es de datos específicos del adquiriente o de la operación — conviene revisar la entrada del usuario o la fuente de datos.

Paso 3: validación local antes de retransmitir

Antes de retransmitir después de un rechazo, ejecutar las validaciones locales que la DIAN aplica del lado servidor: validar XML contra XSD, recalcular CUFE desde el XML construido, verificar suma de totales, validar dígito de verificación del NIT. Si alguna falla localmente, hay alta probabilidad de que el rechazo se repita. Si todas pasan, el reintento tiene sentido.

Patrones de validación local para prevenir rechazos

Validar XML contra XSD

Validar el XML contra el XSD oficial de la DIAN antes de transmitir captura el 30% de los errores. La validación con xmllint o equivalente toma milisegundos y se ejecuta como parte del pipeline de emisión. Cualquier error sintáctico aparece localmente, no en la respuesta DIAN.

Recalcular CUFE desde el XML

Después de construir el XML y antes de transmitir, recalcular el CUFE desde el XML construido (no desde los datos originales) y compararlo con el CUFE embebido. Si no coinciden, hay un bug entre la lógica de cálculo y la serialización del XML, y se detecta antes del rechazo en producción.

Verificar coherencia matemática de totales

La suma de los precios unitarios por cantidad debe igualar el subtotal. El subtotal más impuestos debe igualar el total a pagar. Las diferencias por aritmética de punto flotante deben corregirse con redondeo al final del cálculo. Validar esto antes de transmitir captura el error de "diferencia de centavos" que la DIAN rechaza sin tolerancia.

La documentación pública de Alanube mantiene un catálogo actualizado de códigos de error DIAN con su causa y la regla de validación local recomendada, lo cual sirve como referencia rápida cuando aparece un rechazo nuevo en producción.

Preguntas frecuentes