Cómo funciona la validación previa en la DIAN: flujo técnico completo
La validación previa es el proceso por el cual la DIAN verifica cada documento electrónico antes de darle validez legal. El flujo tiene 9 pasos definidos.
Entre el momento en que un equipo envía un documento al ambiente de producción de la DIAN y el momento en que ese documento queda legalmente válido, ocurren entre 8 y 9 intercambios técnicos asincrónicos — y cada uno tiene un punto de falla específico. Cuando una transmisión falla en producción, el tiempo de diagnóstico depende de qué paso del flujo se rompió: una autenticación rechazada por certificado vencido no se diagnostica con las mismas herramientas que una ApplicationResponse rechazada por contenido inválido.
Esta guía describe en detalle los 9 pasos del flujo de validación previa de la DIAN, qué actor interviene en cada uno, qué payload se intercambia, qué estados puede devolver el validador y cómo aislar el punto exacto de falla cuando algo deja de funcionar en producción. Al final encontrará las respuestas posibles del validador y las verificaciones recomendadas antes de transmitir.
¿Qué es la validación previa y por qué existe?
Del modelo de validación posterior al modelo previo
Antes de 2019, la DIAN operaba bajo un modelo de validación posterior: el contribuyente emitía el documento, lo entregaba al adquiriente, y solo después lo transmitía a la DIAN para registro. Ese modelo tenía dos problemas: documentos inválidos circulaban antes de ser detectados, y el factoring electrónico no era viable porque el documento no tenía respaldo verificable de la autoridad. El modelo de validación previa cambió la secuencia: la DIAN valida primero, y solo después de su aprobación el documento se puede entregar al adquiriente con validez legal.
Marco normativo del modelo actual
El modelo de validación previa quedó establecido en la Resolución DIAN 0030 de 2019, ratificado por la Resolución 0042 de 2020 y mantiene vigencia bajo el régimen actual. Su Anexo Técnico define los pasos del flujo, los formatos de XML que se intercambian (UBL 2.1 base más extensiones DIAN), los algoritmos criptográficos (firma XAdES-BES, hash SHA-384 para el CUFE), y los códigos de respuesta del validador.
Los 9 pasos del flujo de validación
Paso 1 — Autenticación y obtención del token
El emisor se autentica contra el endpoint de habilitación o producción de la DIAN usando su certificado digital del software. La respuesta es un token de sesión válido por tiempo limitado que se usará en los siguientes pasos. Si el certificado está vencido o el equipo no está habilitado en el ambiente que se está usando, el flujo se rompe aquí con código de error específico de autenticación.
Paso 2 — Construcción del XML
El emisor construye el documento en formato UBL 2.1 base con extensiones DIAN, incluyendo todos los elementos obligatorios: identificación del obligado, identificación del adquiriente, líneas de detalle, totales, impuestos discriminados, CUFE calculado, y los datos del software emisor (clave técnica, código de software, versión).
Paso 3 — Firma digital del XML
Se aplica firma XAdES-BES sobre el documento usando el certificado digital del emisor. La firma se incluye dentro del XML en el bloque ext:UBLExtensions y debe respetar la canonicalización C14N exclusiva. Una firma mal construida — algoritmo de digest incorrecto, canonicalización inclusiva en lugar de exclusiva, o referencias mal armadas — genera rechazo automático en el paso 5.
Paso 4 — Transmisión al endpoint SOAP
El XML firmado se envía al endpoint SOAP de la DIAN: SendBillSync para envío con respuesta inmediata, SendBillAsync para asincrónico. El payload se encapsula en un mensaje SOAP con el método correspondiente y el token de sesión en el header.
Paso 5 — Validación sintáctica
La DIAN ejecuta primero validación sintáctica: estructura del XML contra el XSD, presencia de campos obligatorios, formato de identificadores. Si falla en este punto, devuelve un fault SOAP con detalle del error de estructura. Aquí no hay aprobación parcial posible: es un rechazo duro.
Paso 6 — Validación de negocio
Si pasa el sintáctico, ejecuta validación de negocio: NIT del emisor habilitado, coherencia entre impuestos y totales (LineExtensionAmount, TaxExclusiveAmount, TaxInclusiveAmount, PayableAmount), correspondencia entre el CUFE recalculado y el enviado, vigencia de la clave técnica para el ambiente, numeración dentro del rango autorizado por resolución. Cualquier falla devuelve ApplicationResponse con código de rechazo específico.
Paso 7 — Generación de la ApplicationResponse
La DIAN genera un documento ApplicationResponse — también en UBL — que representa la decisión: Aprobado, Rechazo, o Aprobado con observaciones. La respuesta se firma con el certificado de la DIAN y queda disponible para descarga por el emisor mediante el método GetStatus.
Paso 8 — Notificación al adquiriente
Si la ApplicationResponse es Aprobado, el emisor entrega el documento al adquiriente — acompañado de la ApplicationResponse firmada por la DIAN. Esta entrega es responsabilidad del emisor, no de la DIAN, y puede ocurrir por correo, portal o intercambio EDI. El documento solo tiene validez legal una vez que el adquiriente lo recibe junto con la ApplicationResponse.
Paso 9 — Registro en el repositorio público
La DIAN registra el documento aprobado en el repositorio público de consulta (catalogo-vpfe.dian.gov.co). Desde ese momento, cualquier tercero puede verificar el documento por su CUFE sin requerir autenticación.
Estados posibles de la ApplicationResponse
Estados positivos
Aprobado significa que el documento pasó todas las validaciones y tiene plena validez legal. Aprobado con observaciones significa que el documento es legalmente válido pero la DIAN detectó inconsistencias menores (por ejemplo, formato de descripción de producto fuera del estándar) que el emisor debería corregir en envíos futuros pero no invalidan el actual.
Estados negativos
Rechazo es la decisión cuando el documento falló validación de negocio crítica. El emisor debe corregir el documento, recalcular CUFE y reenviar con un número distinto — no puede reutilizar el número rechazado. Falla técnica del sistema DIAN es un código específico que aplica cuando los servidores de validación están caídos; en ese caso, el emisor debe activar modo de contingencia, no reenviar inmediatamente.
Diagnóstico de fallas por paso
Cuando falla la autenticación (paso 1)
La primera verificación es la vigencia del certificado digital del software emisor (no el certificado de firma de documentos, que es distinto). La segunda es que el equipo esté correctamente habilitado en el ambiente que se está usando. La tercera es la sincronización del reloj del servidor — si está desfasado más de unos minutos respecto al servidor DIAN, las firmas se rechazan.
Cuando falla la validación sintáctica (paso 5)
Indicio claro de problema de construcción del XML. El error normalmente apunta al elemento faltante o malformado. La verificación rápida es validar el XML contra el XSD oficial de la DIAN localmente, antes de transmitir — herramientas como xmllint o el editor IntelliJ con plugin de XSD permiten validar offline en milisegundos.
Cuando falla la validación de negocio (paso 6)
El error más común es la suma de líneas que no cuadra con TaxInclusiveAmount o PayableAmount por décimas de centavo. La DIAN aplica tolerancia cero a estas diferencias. La segunda causa es CUFE mal calculado. La tercera es número de factura fuera del rango autorizado por resolución — indicio de que el rango configurado en el sistema está desactualizado respecto a la última resolución de habilitación.
Verificaciones antes de transmitir a producción
Verificación pre-transmisión recomendada
Antes de hacer un envío real a producción, las verificaciones mínimas son: hash SHA-384 del XML coincide con el CUFE embebido, firma XAdES-BES verifica correctamente con OpenSSL o xmlsec1, totales matemáticamente coherentes (suma de líneas igual a base imponible, impuestos igual a base por tarifa, total igual a base más impuestos), reloj NTP sincronizado dentro del minuto, certificado digital vigente al menos 30 días en el futuro.
Pruebas mínimas en sandbox antes de pasar a producción
El sandbox DIAN ofrece volumen suficiente para probar todos los flujos. Los escenarios mínimos que conviene cubrir son: factura aprobada sin observaciones, factura aprobada con observaciones, factura rechazada por error de cálculo, factura rechazada por sintaxis, escenario de servidor caído (debe activar contingencia local), retransmisión correcta tras contingencia, consulta de estado por CUFE.
Preguntas frecuentes
¿Cuál es la diferencia entre validación previa y validación posterior? En validación posterior — el modelo previo a 2019 — el contribuyente emitía el documento, lo entregaba al adquiriente y solo después lo transmitía a la DIAN para registro. El documento tenía validez antes del registro y los errores se detectaban después. En validación previa, modelo actual, la DIAN valida el documento antes de su entrega al adquiriente, y solo aprueba aquellos que pasan todas las validaciones. El cambio cierra la ventana donde documentos inválidos podían circular y habilita modelos como el factoring electrónico, porque el respaldo de la DIAN es verificable desde el momento de la emisión.
¿Cómo puedo identificar en qué paso del flujo está fallando una transmisión? Loguear cada paso individualmente y verificar dónde se detiene la cadena. Si falla en autenticación, el error es 401 o fault de seguridad. Si falla en transmisión, es timeout o error 5xx del endpoint SOAP. Si falla en validación, llega una ApplicationResponse con código específico que indica si fue sintáctica (rechazo duro) o de negocio (con detalle de campo). Si pasa la transmisión pero no llega ApplicationResponse, el flujo está en estado pendiente y conviene consultar GetStatus por CUFE.
¿Qué diferencia hay entre SendBillSync y SendBillAsync? SendBillSync envía el documento y bloquea la conexión hasta que la DIAN responde con su ApplicationResponse. Útil para volúmenes bajos donde la latencia no es problema y simplifica el código del emisor. SendBillAsync envía y devuelve inmediatamente un identificador de petición; el emisor debe consultar después mediante GetStatus para obtener la ApplicationResponse. Recomendado para volúmenes altos o cuando la integración no puede mantener conexiones abiertas. Ambos métodos son funcionalmente equivalentes — el documento resultante es el mismo — pero el patrón de integración es distinto.
¿Es posible reintentar una transmisión fallida sin generar duplicados en la DIAN? Sí, pero con cuidado. La DIAN identifica documentos por su número de factura único — no por CUFE — y rechaza con FAB16 si ese número ya fue aprobado previamente. Por lo tanto, reintentar un envío rechazado con el mismo número genera nuevo intento de validación sobre el mismo documento. Si la primera transmisión fue rechazada, conviene corregir y reenviar con un nuevo número. Si la primera transmisión simplemente no llegó por timeout, GetStatus por CUFE confirma si la DIAN lo recibió o no antes de reintentar.
Artículos Relacionados
Errores de rechazo de la DGII en e-CF: cómo diagnosticarlos y corregirlos desde un agente de IA
Los rechazos de la DGII en e-CF tienen causas precisas y acciones correctivas definidas. Esta guía explica el ciclo de vida del documento, los códigos de error más frecuentes y cómo un agente de IA puede diagnosticar y corregir rechazos de forma autónoma.
Cómo conectar un agente de IA a la DGII en República Dominicana: guía paso a paso con el MCP de Alanube
Guía completa para conectar un agente de IA a la DGII de República Dominicana usando el único servidor MCP de infraestructura fiscal disponible actualmente: configuración del cliente, primer e-CF en lenguaje natural y emisión programática con TypeScript.
Las 30 herramientas del MCP de infraestructura fiscal de República Dominicana: referencia completa
Referencia consolidada en español de las 30 herramientas del único servidor MCP de infraestructura fiscal conectado a la DGII en República Dominicana: organización por capas, casos de uso y cuándo usar el orquestador vs. emisión directa.