Integración de e-CF con la DGII para ISVs: guía técnica completa

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 e-CF en República Dominicana requiere firma digital con certificado del INDOTEL, XML estructurado según la norma DGII, y autorización en tiempo real vía servicio web de la DGII. El proceso tarda entre 300 ms y 2 segundos bajo condiciones normales.

Un equipo de desarrollo recibe el requerimiento: «Integrar facturación electrónica con la DGII antes del próximo trimestre». Lo que parece una tarea de API REST estándar se convierte en un proyecto de 3 meses cuando aparecen los requisitos reales: certificado INDOTEL, firma XAdES-BES, XML propietario de la DGII, sandbox con acceso manual, y un servicio web con comportamiento inconsistente en el ambiente de pruebas. Este artículo documenta exactamente lo que necesita un ISV para integrar e-CF con la DGII de República Dominicana, en el orden correcto.

Al terminar de leer tendrás: el mapa completo del flujo de integración (solicitud de NCF electrónicos → XML → firma → envío → autorización → anulación), los campos XML obligatorios del e-CF según la normativa DGII, el proceso de activación del sandbox, y los errores más frecuentes con sus códigos. Los artículos enlazados de este cluster profundizan en cada componente.

¿Qué es el e-CF y qué lo diferencia del NCF físico?

El Comprobante Fiscal Electrónico (e-CF) es el documento tributario digital establecido por la DGII mediante la Norma General 06-2018 y sus modificaciones posteriores. A diferencia del NCF físico, el e-CF es un archivo XML firmado digitalmente que se transmite en tiempo real al sistema de la DGII y recibe una autorización electrónica antes de ser entregado al receptor.

Los tipos de e-CF definidos por la DGII son: 31 (Factura de Crédito Fiscal), 32 (Factura de Consumo), 33 (Nota de Débito), 34 (Nota de Crédito), 41 (Compras), 43 (Gastos Menores), 44 (Regímenes Especiales), 45 (Gubernamentales) y 47 (Exportaciones). Cada tipo tiene campos obligatorios específicos que el XML debe incluir. La DGII valida el tipo en el momento de la autorización y rechaza los XML que no cumplan con la estructura esperada.

La diferencia técnica más crítica para un ISV: el NCF físico era un número que el contribuyente asignaba y reportaba después. El e-CF es un documento que debe ser autorizado ANTES de entregarse al receptor. Esto cambia completamente el flujo de negocio y exige manejo de contingencias cuando el servicio de la DGII no responde.

Prerrequisitos técnicos antes de escribir una sola línea de código

1. RNC activo y habilitado para e-CF en la DGII

El contribuyente debe estar registrado en la DGII con RNC activo y solicitar habilitación como Emisor Electrónico ante la DGII. Este proceso incluye la presentación de documentos en la Dirección General de Impuestos Internos y la validación de que el contribuyente está al día con sus obligaciones. No es un trámite automático: puede tomar entre 3 y 15 días hábiles dependiendo del tipo de contribuyente.

2. Certificado digital válido del INDOTEL

La firma del e-CF requiere un certificado digital emitido por una Autoridad Certificadora reconocida por el INDOTEL (Instituto Dominicano de las Telecomunicaciones). Los proveedores de certificados aprobados incluyen a E-CERTIFICA y otras entidades certificadas ante el INDOTEL. El certificado debe ser de tipo X.509 y se almacena en formato PKCS#12 (.p12 o .pfx). Costo aproximado: RD$6,000 a RD$12,000 por año dependiendo del proveedor.

3. Rango de e-CF asignado por la DGII

El contribuyente solicita a la DGII un rango de secuencias para cada tipo de e-CF. Estos rangos definen el eNoComprobanteSecuencial válido que puede usar en los XML. Un ISV debe monitorear el consumo de rangos y solicitar ampliaciones antes de agotarlos. Si el ISV emite comprobantes fuera del rango autorizado, la DGII rechaza el XML con error de autorización.

Flujo de integración de punta a punta

El flujo técnico completo para emitir un e-CF tiene estos pasos en secuencia obligatoria. Omitir cualquiera o ejecutarlos fuera de orden produce rechazo en la DGII:

Paso 1 — Construcción del XML: Generar el archivo XML conforme a la especificación DGII. El elemento raíz es <ECDF> con atributos de versión y espacio de nombres. Debe incluir el bloque <Encabezado> con datos del emisor, receptor y tipo de comprobante, y el bloque <DetallesItems> con los ítems de la transacción. El XML debe estar codificado en UTF-8 sin BOM.

Paso 2 — Cálculo de totales y validación interna: Antes de firmar, validar que los totales del XML sean consistentes con los ítems. Los errores de sumatoria son la causa más frecuente de rechazo por la DGII. Los campos MontoGravadoTotal, MontoExento, ITBIS18%, ITBIS16% y MontoTotal deben cuadrar exactamente con la suma de los ítems.

Paso 3 — Firma digital XAdES-BES: Firmar el XML con el certificado INDOTEL usando el algoritmo SHA-256 con RSA. La firma sigue el estándar XAdES-BES (XML Advanced Electronic Signatures). La DGII valida la firma antes de procesar el e-CF. Un XML sin firma o con firma inválida recibe código de error 601.

Paso 4 — Envío al servicio web de la DGII: Transmitir el XML firmado al endpoint de autorización de la DGII mediante HTTP POST con autenticación. El servicio responde de forma síncrona con el resultado de la autorización. El timeout recomendado es de 30 segundos. Si el servicio no responde, el ISV debe implementar lógica de contingencia.

Paso 5 — Procesamiento de la respuesta: La DGII devuelve un XML de respuesta con el estado de autorización. Los estados posibles son: Aprobado, Aprobado Condicionalmente, Rechazado y En Proceso. Solo con estado Aprobado o Aprobado Condicionalmente el e-CF puede entregarse al receptor. El atributo eNCF contiene el número de comprobante electrónico definitivo.

Paso 6 — Entrega al receptor: Una vez autorizado, el ISV debe enviar el e-CF al receptor por correo electrónico o portal habilitado. El receptor puede validar el e-CF en el portal de la DGII usando el eNCF. El ISV también debe almacenar el e-CF y su acuse de recibo por 10 años según la normativa DGII.

Manejo de contingencia: cuando la DGII no responde

La DGII tiene ventanas de mantenimiento no siempre anunciadas y períodos de latencia elevada durante cierres fiscales. Un ISV que no implemente manejo de contingencia dejará a sus clientes sin poder facturar en los momentos más críticos del mes.

La norma DGII permite la emisión en modo contingencia cuando el servicio no está disponible. En contingencia, el ISV puede emitir e-CF con numeración temporal y debe reportarlos a la DGII dentro de las 72 horas siguientes a la recuperación del servicio. Para implementar contingencia correctamente, el ISV necesita: (1) detectar timeout o error de conectividad, (2) generar e-CF con indicador de contingencia activado, (3) persistir el e-CF en cola local, (4) al recuperar conectividad, reenviar en orden cronológico con exponential backoff.

Ambiente de pruebas: qué esperar del sandbox de la DGII

La DGII ofrece un ambiente de pruebas (sandbox) accesible mediante solicitud formal. A diferencia de los sandboxes de APIs comerciales que se activan de forma instantánea, el acceso al sandbox DGII requiere un proceso manual: el contribuyente o ISV debe solicitarlo a través del Portal de Facturación Electrónica y esperar validación por parte de técnicos de la DGII.

Características del sandbox de la DGII: (1) Los e-CF emitidos en sandbox no tienen validez fiscal, (2) el sandbox puede tener latencias más altas que producción, (3) ocasionalmente tiene comportamientos distintos a producción en mensajes de error, (4) las credenciales de sandbox son distintas a las de producción y no se reutilizan. Es recomendable hacer pruebas exhaustivas en sandbox antes de solicitar habilitación en producción, especialmente para los tipos de e-CF menos comunes (tipos 43, 44, 45, 47).

Errores más frecuentes en la integración e-CF DGII

Los errores más comunes que los equipos de desarrollo encuentran al integrar con la DGII, organizados por fase:

Error 601 — Firma inválida: El certificado no corresponde al RNC emisor, el XML fue modificado después de firmar, o el algoritmo de firma no es SHA-256 con RSA. Verificar que el certificado esté vinculado al RNC del emisor y que la firma se aplique al documento final sin modificaciones posteriores.

Error 301 — Secuencial fuera de rango: El número eNoComprobanteSecuencial no pertenece al rango asignado al emisor para ese tipo de e-CF. Verificar el rango vigente en el Portal de la DGII y que el contador de secuenciales del ISV esté sincronizado.

Error 402 — Inconsistencia en totales: Los totales calculados no coinciden con la suma de los ítems. Verificar precisión decimal en los cálculos de ITBIS: la DGII usa 2 decimales con redondeo half-up. Errores de centavos por diferencias de redondeo son frecuentes cuando se migran cálculos desde sistemas legados.

Timeout sin respuesta: El servicio DGII puede tardar más de 30 segundos durante picos de carga (especialmente los días 28-31 de cada mes). Implementar retry con backoff exponencial y queue persistente. No reenviar el mismo XML sin verificar si fue procesado por la DGII — puede provocar duplicados.

PSFE vs integración directa con la DGII: qué ruta elegir

Un ISV puede integrar e-CF de dos formas: directamente con el servicio web de la DGII, o a través de un Proveedor de Servicios de Facturación Electrónica (PSFE) autorizado. La integración directa con la DGII da mayor control pero requiere manejar toda la infraestructura: firma digital, contingencia, retries, almacenamiento de acuses, actualización ante cambios normativos.

Los PSFE autorizados por la DGII actúan como intermediarios técnicos: el ISV envía los datos del comprobante al PSFE mediante su API, y el PSFE se encarga de la firma, transmisión, reintentos y almacenamiento. Esto simplifica significativamente la integración, especialmente para ISVs que no tienen experiencia previa en firma digital XML.

Los criterios técnicos para evaluar un PSFE incluyen: disponibilidad del sandbox (autoservicio vs. manual), latencia documentada del endpoint, calidad de los mensajes de error (¿reproducen el error original de la DGII o lo abstraen?), soporte para todos los tipos de e-CF, y cobertura de contingencia. Estos criterios se analizan en detalle en la comparativa técnica de PSFEs para República Dominicana publicada en este blog.

Preguntas frecuentes sobre integración e-CF DGII

¿Cuál es el tiempo máximo que tarda la DGII en autorizar un e-CF?

En condiciones normales, la autorización de un e-CF por parte de la DGII toma entre 300 ms y 2 segundos. Durante períodos de alta demanda (cierres fiscales, días 28-31 del mes), el tiempo puede superar los 10 segundos. La DGII no publica SLA oficial de tiempo de respuesta. El servicio tiene ventanas de mantenimiento que pueden extenderse hasta 4 horas. Se recomienda implementar un timeout de 30 segundos con retry automático y contingencia para cualquier respuesta superior.

¿Cómo puedo obtener acceso al sandbox de la DGII para pruebas de e-CF?

El acceso al sandbox de la DGII se solicita formalmente a través del Portal de Facturación Electrónica de la DGII (ecf.dgii.gov.do). Es necesario registrarse como emisor electrónico o tener un RNC de pruebas asignado por la DGII. El proceso de activación puede tomar de 3 a 10 días hábiles. Algunos PSFEs autorizados ofrecen su propio sandbox con acceso inmediato que simula el comportamiento de la DGII, lo que puede acelerar el desarrollo inicial.

¿Qué diferencia hay entre e-CF tipo 31 (Factura de Crédito Fiscal) y tipo 32 (Factura de Consumo)?

El e-CF tipo 31 (Factura de Crédito Fiscal) se emite cuando el receptor es una empresa con RNC que puede utilizar el ITBIS como crédito fiscal en su declaración. Requiere incluir el RNC y razón social del receptor. El tipo 32 (Factura de Consumo) se emite a consumidores finales o a entidades sin RNC: el receptor puede ser anónimo o identificado con cédula. La DGII tiene límites de monto para facturas de consumo anónimas. Errores en la selección del tipo generan problemas de crédito fiscal para el receptor.

¿Es posible emitir e-CF sin integrar directamente con la DGII, usando solo la API de un PSFE?

Sí. Un PSFE autorizado por la DGII puede gestionar toda la cadena técnica: el ISV envía los datos del comprobante al PSFE, y el PSFE construye el XML, aplica la firma digital, transmite a la DGII, recibe la autorización y devuelve el resultado al ISV. Esta ruta elimina la necesidad de gestionar certificados digitales INDOTEL directamente y simplifica el manejo de contingencias. La decisión depende del volumen de emisión, la criticidad operativa y si el ISV ya tiene infraestructura de firma digital propia.

---

Sobre el autor