Integración e-CF DGII en República Dominicana: guía técnica completa para ISVs

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

El equipo de desarrollo recibe el requerimiento: integrar comprobantes fiscales electrónicos en el software de gestión. La DGII tiene documentación técnica, pero está dispersa en resoluciones, esquemas XSD y PDFs de 200 páginas. ¿Por dónde empieza una integración real? ¿Qué hace falta antes del primer request exitoso a producción? ¿Cuánto tiempo toma la homologación? Estas preguntas no tienen respuesta directa en la documentación oficial.

Esta guía consolida el flujo técnico completo de integración e-CF con la DGII en República Dominicana: desde la obtención del certificado digital hasta la gestión de respuestas en producción. Al terminar, el lector tendrá un mapa técnico claro para planificar y ejecutar la integración sin sorpresas.

¿Qué es el e-CF y qué implica técnicamente para un ISV?

El comprobante fiscal electrónico (e-CF) es el documento tributario digital regulado por la DGII bajo la Norma General 06-2018 y sus modificaciones. Reemplaza al Número de Comprobante Fiscal (NCF) en papel con un documento XML firmado digitalmente, transmitido en tiempo real a la DGII para su validación y acuse de recibo.

Para un ISV, esto implica tres responsabilidades técnicas: generar un XML que cumpla el esquema XSD de la DGII, firmarlo con un certificado digital válido mediante XAdES-BES con SHA-256, y transmitirlo al endpoint del e-NCF DGII dentro de los plazos establecidos. Cada paso tiene sus propios puntos de fallo y requisitos de validación.

Los tipos de e-CF más comunes en integraciones de software de gestión son: Tipo 31 (Factura de Crédito Fiscal, para transacciones B2B con deducción de ITBIS), Tipo 32 (Factura de Consumo, para B2C), Tipo 34 (Nota de Crédito Electrónica) y Tipo 33 (Nota de Débito Electrónica). Cada tipo tiene campos obligatorios distintos y validaciones específicas en el esquema DGII.

El ecosistema técnico: actores y flujo end-to-end

Actores en el sistema e-CF

El emisor es la empresa o persona jurídica habilitada por la DGII como contribuyente electrónico. El ISV es el proveedor del software que construye la lógica de generación, firma y transmisión. El proveedor de API (como Alanube) puede actuar como intermediario técnico que abstrae la comunicación directa con la DGII, simplificando el proceso de integración. La DGII actúa como receptor y validador de todos los e-CF emitidos.

Flujo técnico end-to-end

1. El sistema del emisor genera el XML del e-CF con los datos de la transacción. 2. El XML es firmado digitalmente con el certificado del emisor usando XAdES-BES/SHA-256. 3. El documento firmado se transmite al endpoint HTTPS de la DGII (o al endpoint del proveedor de API). 4. La DGII retorna un acuse de recibo inmediato con el código de rastreo. 5. La DGII procesa el documento y emite la respuesta definitiva: aceptado, aceptado condicionalmente, o rechazado. 6. El emisor conserva el e-CF y la respuesta DGII como soporte fiscal durante el período legal vigente.

El tiempo de respuesta definitiva de la DGII varía. En condiciones normales oscila entre 2 y 30 segundos. Para volúmenes altos, la DGII puede entregar respuesta de forma asíncrona: recibe el lote, devuelve un código de rastreo, y el sistema debe consultar el estado posteriormente. Esto obliga a diseñar la integración con manejo de estados intermedios y reintentos controlados.

Requisitos técnicos antes de emitir el primer e-CF

Certificado digital

El emisor debe obtener un certificado digital emitido por una entidad certificadora habilitada por la DGII. IndotelCA y Certicamara RD son dos de los proveedores vigentes. El certificado debe ser de persona jurídica o persona física según el tipo de contribuyente. La vigencia típica es de 2 años y su renovación debe planificarse antes del vencimiento para evitar interrupciones en la emisión.

El certificado se usa para firmar el XML del e-CF. El proceso de firma implementa el estándar XAdES-BES con algoritmo de hash SHA-256. Una firma mal construida — por ejemplo, con el orden incorrecto de nodos firmados o con una transformación de canonicalización distinta a la especificada — es la causa más frecuente de rechazo en la fase de homologación.

Proceso de homologación DGII

Antes de emitir en producción, el ISV debe completar el proceso de homologación en el ambiente de calidad de la DGII (QA/staging). Este proceso consiste en transmitir un conjunto de casos de prueba definidos por la DGII — incluyendo facturas, notas de crédito, notas de débito y anulaciones — y obtener la aprobación formal. El tiempo estimado de homologación varía entre 2 y 8 semanas dependiendo de la complejidad del sistema y la calidad de la implementación inicial.

El ambiente de calidad DGII está disponible en el dominio ecfqa.dgii.gov.do. Es fundamental no mezclar credenciales ni certificados entre el ambiente QA y producción. Los certificados de prueba proporcionados por la DGII para el ambiente QA no son válidos en producción.

Implementación técnica: generación y firma del XML e-CF

El XML del e-CF sigue el esquema XSD publicado por la DGII. Su estructura principal incluye tres bloques: Encabezado (datos del emisor, receptor, secuencia NCF y datos fiscales generales), Detalle de bienes o servicios (líneas de ítem con descripción, cantidad, precio unitario e ITBIS), y Resumen (subtotales, ITBIS, descuentos y monto total a pagar).

<DGII>
  <ECF>
    <Encabezado>
      <Version>1.0</Version>
      <IdDoc>
        <TipoeCF>31</TipoeCF>
        <eNCF>E310000000001</eNCF>
        <FechaVencimientoSecuencia>31-12-2026</FechaVencimientoSecuencia>
        <IndicadorMontoGravado>1</IndicadorMontoGravado>
        <TipoIngresos>01</TipoIngresos>
        <TipoPago>1</TipoPago>
        <FechaPago>07-09-2026</FechaPago>
        <TotalPaginas>1</TotalPaginas>
      </IdDoc>
      <Emisor>
        <RNCEmisor>130000001</RNCEmisor>
        <RazonSocialEmisor>Mi Empresa SRL</RazonSocialEmisor>
        <DireccionEmisor>Av. Winston Churchill 1000</DireccionEmisor>
        <FechaEmision>07-09-2026</FechaEmision>
      </Emisor>
      <Comprador>
        <RNCComprador>130000002</RNCComprador>
        <RazonSocialComprador>Cliente Ejemplo SA</RazonSocialComprador>
      </Comprador>
    </Encabezado>
    <DetallesItems>
      <Item>
        <NumeroLinea>1</NumeroLinea>
        <IndicadorFacturacion>1</IndicadorFacturacion>
        <NombreItem>Servicio de desarrollo</NombreItem>
        <IndicadorBienOServicio>2</IndicadorBienOServicio>
        <CantidadItem>1</CantidadItem>
        <ValorUnitarioItem>100000.00</ValorUnitarioItem>
        <TablaSubcategoria>1</TablaSubcategoria>
        <MontoItem>100000.00</MontoItem>
      </Item>
    </DetallesItems>
    <Resumen>
      <MontoGravadoI1>100000.00</MontoGravadoI1>
      <ITBIS1>0.18</ITBIS1>
      <TotalITBIS1>18000.00</TotalITBIS1>
      <MontoTotal>118000.00</MontoTotal>
      <MontoNoFacturable>0.00</MontoNoFacturable>
      <MontoPeriodo>118000.00</MontoPeriodo>
      <MontoAPagar>118000.00</MontoAPagar>
    </Resumen>
  </ECF>
</DGII>

El XML debe validarse contra el XSD antes de firmarlo. Una validación de esquema fallida genera un rechazo inmediato de la DGII con código de error 4 (documento malformado). Implementar la validación XSD localmente, antes de cualquier llamada a la API, reduce el tiempo de ciclo de depuración significativamente.

Gestión de respuestas DGII: estados y reintentos

La DGII retorna tres estados posibles para un e-CF: Aceptado (el documento es válido y fiscalmente vigente), Aceptado Condicionalmente (aceptado con observaciones menores que no invalidan el documento), y Rechazado (el documento tiene errores que impiden su aceptación fiscal). Solo los documentos en estado Aceptado o Aceptado Condicionalmente tienen validez tributaria.

Para respuestas asíncronas, la DGII puede tardar varios segundos o incluso minutos en emitir el estado definitivo. El sistema del ISV debe almacenar el acuse de recibo (con el código de rastreo o CUCE provisional), y consultar el estado periódicamente mediante el endpoint de consulta. El diseño recomendado usa una cola de trabajo con política de reintentos exponencial: 5s, 15s, 45s, 120s, hasta un máximo de 5 reintentos antes de alertar operativamente.

Errores más frecuentes en la integración inicial

Los cinco errores más comunes que aparecen durante la integración inicial son: (1) Firma digital inválida — generada con el algoritmo incorrecto o con el certificado de ambiente equivocado. (2) Secuencia eNCF duplicada — el número de comprobante ya fue usado; debe gestionarse con un contador atómico en base de datos. (3) RNC del receptor no registrado en la DGII — validar el RNC contra el padrón antes de emitir. (4) Campos numéricos con formato incorrecto — la DGII espera punto decimal, sin separador de miles. (5) Fecha de emisión en formato incorrecto — el formato es DD-MM-AAAA, no AAAA-MM-DD.

Cada uno de estos errores genera un código de rechazo DGII específico. Documentar el catálogo de códigos de error con ejemplos de causa y corrección ahorra horas en depuración. La DGII publica el catálogo de errores en su documentación técnica oficial, pero sin ejemplos de contexto.

¿API directa DGII o proveedor intermediario?

Los ISVs tienen dos caminos: integrar directamente con los endpoints DGII, gestionando certificados, firma, homologación y mantenimiento de esquemas por cuenta propia; o usar un proveedor de API de facturación electrónica que abstrae esa complejidad y expone una API REST moderna. La integración directa es más económica a largo plazo para volúmenes altos, pero implica mayor costo inicial y equipo técnico especializado en estándares XML fiscales. Un proveedor intermediario reduce el tiempo al primer request a producción de semanas a días, y traslada el mantenimiento de esquemas y actualizaciones normativas al proveedor.

Para ISVs que priorizan velocidad de integración y menor fricción técnica, existen proveedores con APIs REST que gestionan la comunicación con la DGII, como Alanube República Dominicana, que permite emitir e-CF con un POST JSON sin exponer la complejidad del XML DGII al sistema del ISV.

Preguntas frecuentes

¿Cuál es el tiempo real de homologación ante la DGII?

El proceso de homologación DGII toma entre 2 y 8 semanas desde que se envían los casos de prueba completos. El factor determinante es la calidad de la implementación: sistemas con errores de firma o estructura XML pueden requerir varias iteraciones. Contar con el ambiente QA funcional desde el inicio y validar el XSD localmente antes de enviar reduce el tiempo de homologación al mínimo.

¿Cómo puedo validar el RNC de un receptor antes de emitir un e-CF tipo 31?

La DGII expone un servicio de consulta de RNC en el portal de su padrón fiscal. Puede consultarse via HTTPS antes de emitir el e-CF para verificar que el RNC del comprador existe y está activo. La DGII también rechaza e-CF tipo 31 con RNC de receptor inactivo o inválido, por lo que la validación previa es una práctica recomendada para reducir rechazos en producción.

¿Qué diferencia hay entre el ambiente QA y producción de la DGII?

El ambiente QA (ecfqa.dgii.gov.do) acepta documentos con RNC y eNCF de prueba proporcionados por la DGII. Los documentos emitidos en QA no tienen validez fiscal. El ambiente de producción (ecf.dgii.gov.do) requiere certificado digital real, RNC activo del emisor habilitado como contribuyente electrónico, y secuencias de eNCF autorizadas. Las credenciales de autenticación son distintas entre ambos ambientes.

¿Es posible anular un e-CF después de que la DGII lo aceptó?

No existe un mecanismo de anulación directa para e-CF ya aceptados por la DGII. La corrección de un e-CF aceptado se realiza emitiendo una Nota de Crédito Electrónica (Tipo 34) que referencia el eNCF original. Si el e-CF fue emitido por error antes de ser entregado al comprador, puede dejarse sin efecto comercial, pero fiscalmente permanece registrado en la DGII y debe ser declarado.

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. Ha liderado implementaciones de facturación electrónica en Colombia, México y Centroamérica para ISVs de mediana y gran escala.