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.
Contenido de este artículo
1. Cómo funciona el ciclo de vida de un e-CF en la DGII
2. La diferencia entre estado interno y legalStatus
3. Códigos de rechazo más frecuentes
4. Cómo diagnosticar un rechazo desde un agente de IA
5. Cómo prevenir rechazos con validación previa
6. Preguntas frecuentes
Un rechazo de la DGII en la emisión de comprobantes fiscales electrónicos no es un error de sistema — es una respuesta con información precisa sobre qué falló en el documento. El problema no es el rechazo en sí; es que los códigos de error de la DGII requieren interpretar la documentación normativa para entender la causa y la acción correctiva. En una integración REST tradicional, ese proceso es manual. En un flujo con agente de IA, puede ser autónomo.
Este artículo explica cómo funciona el ciclo de vida de un e-CF, qué significan los estados, cuáles son los rechazos más frecuentes y cómo un agente de IA puede diagnosticarlos y corregirlos. Para la guía de integración paso a paso, ver Cómo conectar un agente de IA a la DGII.
Cómo funciona el ciclo de vida de un e-CF en la DGII
Desde que un e-CF se emite hasta que obtiene un resultado legal, el documento pasa por una secuencia de estados internos.
REGISTERED: el documento fue recibido y registrado. Aún no ha sido enviado a la DGII.
TO_SEND: el documento está en cola para transmisión.
WAITING_RESPONSE: transmitido a la DGII, esperando confirmación. El estado transitorio más largo en flujo asíncrono.
TO_NOTIFY: la DGII respondió, pendiente de notificar al sistema del emisor.
FINISHED: el ciclo concluyó. El legalStatus en este punto tiene el valor definitivo.
Un documento en WAITING_RESPONSE no es un rechazo. Es un estado normal del flujo asíncrono. Si el sistema reintenta la emisión en este punto, puede generar duplicados fiscales.
La diferencia entre estado interno y legalStatus
El estado interno describe en qué punto del flujo está el documento dentro del sistema del proveedor. El legalStatus describe el resultado que la DGII emitió. Son dos dimensiones independientes. La combinación FINISHED + REJECTED es el único estado que requiere acción correctiva del emisor.
Los tres valores posibles del legalStatus final son ACCEPTED (documento válido ante la DGII), ACCEPTED_WITH_OBSERVATIONS (válido con advertencias no bloqueantes) y REJECTED (requiere corrección y reemisión).
Códigos de rechazo más frecuentes
Los rechazos de la DGII incluyen un governmentResponseCode numérico y un governmentResponse con el mensaje de error.
Código 1 — Estructura inválida
Causa: el XML del e-CF no cumple con el esquema oficial de la DGII. Campo obligatorio ausente, tipo de dato incorrecto o valor fuera del dominio. Acción: validar el payload con validate_rd_request_payload antes de emitir.
Código 3 — RNC del receptor no encontrado
Causa: el RNC del receptor no existe o está inactivo en el padrón de contribuyentes de la DGII. El más común en Facturas de Crédito Fiscal (31). Acción: verificar el RNC. Si el receptor es consumidor final, evaluar emitir Factura de Consumo (32) en su lugar.
Código 4 — Secuencia de NCF incorrecta
Causa: el eNCF no sigue la secuencia correcta para el tipo de documento o ya fue utilizado. La DGII valida que los eNCF sean consecutivos y no repetidos por tipo. Acción: verificar el último eNCF y reiniciar desde el siguiente número válido.
Código 6 — Totales inconsistentes
Causa: los totales del documento no cuadran. La DGII aplica tolerancia cero. Las causas más comunes son redondeo inconsistente entre líneas y el total, o cálculo de ITBIS sobre montos que ya incluyen impuesto. Acción: recalcular con redondeo hacia arriba a dos decimales de forma consistente.
Código 9 — Emisor no habilitado para producción
Causa: la empresa emisora no completó el proceso de habilitación ante la DGII, o se están usando credenciales de sandbox en el endpoint de producción. Acción: verificar que el emisor está habilitado y que se usa el endpoint y token correctos.
Cómo diagnosticar un rechazo desde un agente de IA
Cuando un e-CF llega a FINISHED con legalStatus REJECTED, la respuesta incluye governmentResponseCode y governmentResponse. El siguiente paso es invocar la herramienta de diagnóstico:
En un flujo autónomo, el agente puede ejecutar la acción de forma inmediata: corregir el campo, revalidar con validate_rd_request_payload y reemitir sin intervención del developer.
Cómo prevenir rechazos con validación previa
La mayoría de los rechazos por estructura inválida y totales inconsistentes son detectables antes de transmitir a la DGII. La herramienta validate_rd_request_payload valida el payload contra el esquema del tipo de e-CF y devuelve todos los errores con la ruta del campo y la descripción del problema.
Activar validateFirst: true en el orquestador invoca esta validación automáticamente antes de transmitir. Si falla, el documento no llega a la DGII.
Activar validateFirst agrega latencia. Para flujos de alto volumen con payloads ya validados, puede desactivarse una vez que la tasa de rechazos sea consistentemente baja.
Preguntas frecuentes
¿Un documento rechazado puede reemitirse con el mismo eNCF?
No. La DGII trata cada eNCF como único por tipo de documento y emisor. Un documento rechazado debe reemitirse con un nuevo eNCF en la secuencia correcta.
¿Qué diferencia hay entre ACCEPTED y ACCEPTED_WITH_OBSERVATIONS?
Ambos son resultados válidos con efectos fiscales ante la DGII. ACCEPTED_WITH_OBSERVATIONS indica inconsistencias no bloqueantes. El documento es válido, pero el equipo debería revisar el campo señalado en futuras emisiones.
¿Cómo saber si el rechazo fue por payload o por conectividad con la DGII?
Un problema de conectividad no produce REJECTED — produce timeout o error de transmisión. Si el documento llegó a FINISHED con REJECTED, la DGII lo procesó y lo rechazó por su contenido. El governmentResponseCode identifica la causa específica.
¿Es posible que un documento quede atascado en WAITING_RESPONSE?
En situaciones de alta carga o mantenimiento de la DGII el tiempo de respuesta puede extenderse. El trackingReference permite consultar el estado en cualquier momento posterior sin necesidad de reemitir.
Para solicitar acceso al sandbox y probar los flujos de diagnóstico, el punto de partida es la página del MCP de Alanube para República Dominicana.
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.
Artículos Relacionados
Los 10 tipos de comprobantes fiscales electrónicos (e-CF) en República Dominicana: cuándo usar cada uno
Referencia práctica de los 10 tipos de comprobantes fiscales electrónicos en República Dominicana: código, caso de uso, flujo de emisión (síncrono o asíncrono) e implicaciones técnicas para developers e integradores.
Cuánto tiempo toma integrar la API de facturación electrónica de la DGII: benchmark por método
Desglose honesto del tiempo de integración de la API de facturación electrónica de la DGII por etapa: lectura de documentación, construcción de payloads, manejo de estados y diagnóstico de rechazos. Comparativa REST vs MCP con estimaciones transparentes.
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.