Flujo de autorización del e-CF en la DGII: estados, tiempos y reintentos

Por Ing. Carlos Méndez | 18 de septiembre 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.

Sumario: El servicio de autorización de e-CF de la DGII devuelve cuatro estados: Aprobado, Aprobado Condicionalmente, Rechazado y En Proceso. Solo los primeros dos permiten entregar el comprobante al receptor. El tiempo de respuesta normal es de 300ms a 2 segundos; puede superar 30 segundos en cierres de mes.

El servicio de autorización de e-CF de la DGII no es una API REST moderna con códigos HTTP 200/400/500 y payloads JSON bien definidos. Es un servicio SOAP con respuestas XML que contienen códigos de estado propios, mensajes de error en español poco descriptivos, y comportamiento asincrónico en ciertos escenarios de carga. Sin conocer en detalle sus estados posibles y sus implicaciones de negocio, un ISV puede enviar el mismo comprobante dos veces, dejarlo en estado indeterminado, o entregar al cliente un e-CF que no tiene validez fiscal.

Este artículo documenta el flujo de autorización del e-CF en la DGII: los cuatro estados posibles y qué hacer con cada uno, los tiempos de respuesta observados en cada escenario, la estrategia correcta de reintentos, y cómo detectar y manejar los estados intermedios.

Los cuatro estados del e-CF y qué hacer con cada uno

Estado: Aprobado

El e-CF fue validado y autorizado por la DGII. La respuesta incluye el eNCF (número de comprobante electrónico) que identifica el documento de forma única. Con este estado, el ISV puede: entregar el e-CF al receptor, almacenarlo como autorizado, e incluirlo en el reporte mensual de comprobantes. Es el único estado en que el comprobante tiene plena validez fiscal.

Estado: Aprobado Condicionalmente

El e-CF fue autorizado pero la DGII detectó observaciones no bloqueantes: campos recomendados ausentes, datos del receptor incompletos en escenarios donde no son estrictamente obligatorios, o inconsistencias menores en los datos complementarios. El comprobante tiene validez fiscal y puede entregarse al receptor. Sin embargo, el ISV debe revisar las observaciones porque en futuras versiones de la norma pueden volverse errores bloqueantes. La respuesta incluye un bloque de observaciones con los códigos específicos.

Estado: Rechazado

El e-CF fue rechazado por uno o más errores de validación. La respuesta incluye códigos de error con descripciones. El comprobante NO tiene validez fiscal y NO debe entregarse al receptor. El ISV debe: (1) registrar el código de error, (2) corregir el XML, (3) usar el mismo número secuencial del rango o solicitar uno nuevo dependiendo del tipo de error, (4) reenviar. Un secuencial rechazado puede reutilizarse para un nuevo intento en la mayoría de los códigos de error; la excepción es cuando el rechazo fue por secuencial duplicado.

Estado: En Proceso

El estado más problemático para los ISVs. El e-CF fue recibido por la DGII pero la autorización está pendiente. Ocurre principalmente durante picos de carga. El ISV debe: (1) NO reenviar el mismo XML (podría crear un duplicado cuando el primero se procese), (2) almacenar el XML con estado pendiente, (3) consultar el estado del e-CF mediante el endpoint de consulta de la DGII cada 30 segundos, (4) esperar hasta 10 minutos antes de considerar el e-CF como no procesado. Si después de 10 minutos no hay respuesta definitiva, activar protocolo de contingencia.

Tiempos de respuesta observados por escenario

Los tiempos observados en integraciones con la DGII varían significativamente según el momento del mes. Escenario normal (días 1-20 del mes): 300ms a 1.5 segundos para la mayoría de e-CF tipo 31 y 32. Escenario de carga moderada (días 21-27): 1.5 a 5 segundos. Escenario de cierre fiscal (días 28-31): 5 a 30 segundos, con picos que superan los 60 segundos. Mantenimiento no anunciado: timeouts completos de hasta 4 horas. La DGII no publica métricas de disponibilidad ni SLA oficial. El timeout de 30 segundos es el estándar de la industria para integraciones con la DGII.

Estrategia de reintentos: qué reintentar y qué no

La estrategia de reintentos para el servicio DGII tiene reglas estrictas para evitar duplicados y desincronización:

Reintentar (safe to retry): Timeout de conexión (el XML nunca llegó a la DGII), error HTTP 5xx del servicio DGII (sin respuesta de autorización), e-CF rechazado con código de error corregible (errores de formato, firma, totales). En estos casos, se puede reenviar el mismo XML con el mismo secuencial.

NO reintentar sin verificar: Estado 'En Proceso' (el XML ya está en la cola de la DGII), timeout sin confirmación de recepción (puede haber llegado y estar en proceso), errores de autenticación HTTP (resolver credenciales antes de reintentar). En estos casos, consultar el estado del e-CF antes de decidir si reenviar.

Para reintentos automáticos seguros, implementar backoff exponencial: primer reintento a 2 segundos, segundo a 4, tercero a 8, máximo 3-5 reintentos antes de marcar el e-CF para revisión manual. Loggear el intento, el timestamp, el estado de respuesta y el secuencial en cada ciclo.

Endpoint de consulta de estado: cómo usarlo

La DGII ofrece un endpoint de consulta que permite verificar el estado de un e-CF enviado previamente, usando el RNC emisor y el número secuencial del e-CF. Este endpoint es esencial para resolver el estado 'En Proceso' y para los escenarios de contingencia donde el ISV no está seguro de si el e-CF fue recibido. La consulta devuelve el estado actual del e-CF y, si fue autorizado, el eNCF. Si el e-CF no existe en los sistemas de la DGII (nunca llegó), la respuesta indica que no se encontró el secuencial.

Protocolo de contingencia cuando el servicio DGII no está disponible

La Norma General DGII establece el procedimiento de contingencia para emisiones durante caïdas del servicio. El ISV debe: (1) detectar la indisponibilidad después de 3 intentos fallidos con 30 segundos de espera entre cada uno, (2) activar el modo contingencia en el sistema, (3) generar e-CF con el campo eIndicadorModoContigencia = 1, (4) asignar secuenciales del rango de contingencia (si el ISV tiene rango de contingencia asignado por la DGII), (5) persistir todos los e-CF de contingencia en una cola durable, (6) al recuperar conectividad, transmitirlos a la DGII en orden cronológico dentro de las 72 horas siguientes.

Preguntas frecuentes sobre el flujo de autorización e-CF DGII

¿Cuál es la diferencia entre un e-CF Aprobado y uno Aprobado Condicionalmente?

Ambos tienen validez fiscal y pueden entregarse al receptor. La diferencia es que el Aprobado Condicionalmente contiene observaciones de la DGII sobre campos no obligatorios que están ausentes o tienen valores inesperados. Estas observaciones no impiden el uso del comprobante pero el ISV debe registrarlas y corregir los campos en futuros comprobantes para evitar que en actualizaciones normativas se conviertan en errores bloqueantes.

¿Cómo puedo saber si un e-CF que quedó en estado 'En Proceso' fue finalmente autorizado?

Usando el endpoint de consulta de estado de la DGII. Se invoca con el RNC del emisor y el número secuencial del e-CF. Si fue autorizado, la respuesta devuelve el estado Aprobado y el eNCF. Si aún está en proceso, el estado se mantiene. Si no se encontró, el XML nunca fue procesado y se puede reenviar. Implementar un job de reconciliación que consulte periódicamente todos los e-CF que quedaron en estado En Proceso hasta resolver su estado definitivo.

¿Qué diferencia hay entre el timeout de conexión y el timeout de lectura en la integración con la DGII?

El timeout de conexión ocurre cuando el socket no puede establecerse con el servidor de la DGII: el XML nunca fue transmitido y es seguro reenviarlo. El timeout de lectura ocurre después de que la conexión fue establecida y el XML fue enviado, pero la DGII no devolvió respuesta en el tiempo configurado: el XML puede haber llegado a la DGII y estar en proceso. Ante un timeout de lectura, NO reenviar directamente: consultar primero el estado del secuencial.

¿Es posible anular un e-CF Aprobado en República Dominicana sin emitir una nota de crédito?

No directamente. Una vez que la DGII autoriza un e-CF, la forma regulatoria de cancelar su efecto fiscal es emitiendo un e-CF tipo 34 (Nota de Crédito) que referencia el e-CF original en el campo eNCFModificado. La DGII no tiene un mecanismo de anulación directa post-autorización para la mayoría de los tipos de e-CF. La excepción son errores detectados dentro de las primeras horas con procedimiento de solicitud especial a la DGII.