e-CF en República Dominicana: guía técnica de integración para desarrolladores

Cuando un equipo de desarrollo en República Dominicana recibe el encargo de habilitar la facturación electrónica en su plataforma, el primer obstáculo real no es técnico — es conceptual. El e-CF (Comprobante Fiscal Electrónico) no es una versión digital del NCF tradicional: es un documento fiscal estructurado en XML firmado digitalmente, con validación en tiempo real por la DGII antes de que el receptor lo pueda usar.

Esta guía cubre los componentes técnicos esenciales del e-CF: la estructura del XML, el proceso de firma SHA-256, el flujo de envío y respuesta de la DGII, y los puntos de integración donde los equipos de desarrollo acumulan más errores.

Qué es el e-CF y por qué difiere del NCF

El NCF (Número de Comprobante Fiscal) era un número de secuencia asignado por la DGII que el contribuyente imprimía en papel. El e-CF es un documento XML completo que contiene todos los datos del comprobante, firmado digitalmente por el emisor, transmitido a la DGII y respondido con un código de aceptación o rechazo antes de llegar al receptor.

La diferencia operacional es significativa: con el NCF, la validez fiscal dependía del número de secuencia. Con el e-CF, la validez depende de la firma digital y de la aceptación explícita de la DGII. Un e-CF no aceptado por la DGII no tiene validez fiscal, aunque el XML esté bien formado.

Estructura del XML del e-CF

El XML del e-CF sigue un esquema XSD publicado por la DGII. Los elementos principales son: el encabezado del comprobante (tipo, secuencia, fecha, emisor, receptor), las líneas de detalle (bienes o servicios, cantidades, precios unitarios, impuestos por línea), los totales (subtotal, ITBIS, ITBIS retenido, total a pagar) y la sección de firma digital.

El tipo de comprobante determina el esquema aplicable. Los tipos más comunes son: 31 (Factura de Crédito Fiscal), 32 (Factura de Consumo), 33 (Nota de Débito), 34 (Nota de Crédito). Cada tipo tiene campos obligatorios distintos — especialmente en la identificación del receptor, que es opcional en el tipo 32 para consumo individual.

<eCF>
  <Encabezado>
    <Version>1.0</Version>
    <CodigoSeguridadeCF>XXXXXX</CodigoSeguridadeCF>
    <IdDoc>
      <TipoeCF>31</TipoeCF>
      <eNCF>E310000000001</eNCF>
      <FechaVencimientoSecuencia>31-12-2026</FechaVencimientoSecuencia>
      <IndicadorMontoGravado>1</IndicadorMontoGravado>
      <TipoIngresos>01</TipoIngresos>
      <TipoPago>1</TipoPago>
    </IdDoc>
    <Emisor>
      <RNCEmisor>123456789</RNCEmisor>
      <RazonSocialEmisor>Empresa Ejemplo SRL</RazonSocialEmisor>
    </Emisor>
    <Comprador>
      <RNCComprador>987654321</RNCComprador>
      <RazonSocialComprador>Cliente Ejemplo SRL</RazonSocialComprador>
    </Comprador>
    <Totales>
      <MontoGravadoTotal>100000.00</MontoGravadoTotal>
      <ITBIS1>18</ITBIS1>
      <TotalITBIS1>18000.00</TotalITBIS1>
      <MontoTotal>118000.00</MontoTotal>
    </Totales>
  </Encabezado>
</eCF>

Firma digital con SHA-256

El e-CF debe firmarse con el algoritmo SHA-256 usando un certificado digital emitido por una CA (Autoridad Certificadora) reconocida por la DGII. El proceso de firma usa el estándar XAdES-BES, que incorpora la firma dentro del mismo documento XML.

El flujo técnico de firma es: (1) generar el XML sin la sección de firma, (2) calcular el digest SHA-256 del XML canonicalizado, (3) firmar el digest con la clave privada del certificado, (4) insertar la firma como nodo `<ds:Signature>` dentro del XML. El XML resultante es el documento completo listo para envío.

Flujo de envío y respuesta de la DGII

El envío del e-CF a la DGII se realiza mediante el servicio web `eCF Envío Comprobante` disponible en el portal de la DGII. La respuesta incluye el estado del comprobante: `Aceptado`, `Aceptado Condicional` o `Rechazado`, junto con los mensajes de validación correspondientes.

El tiempo de respuesta de la DGII en condiciones normales es inferior a 5 segundos para documentos individuales. Para envíos en lote, el tiempo varía según el volumen. La DGII provee un mecanismo de consulta de estado por eNCF para los casos en que la respuesta inicial no se recibió correctamente.

Errores más comunes en la integración

El error de integración más frecuente es la canonicalización incorrecta del XML antes de la firma. El estándar XAdES-BES requiere canonicalización C14N exclusiva del elemento que se va a firmar. Si el XML no está canonicalizado correctamente, la firma generada no coincidirá con lo que la DGII espera y el e-CF será rechazado con error de firma.

El segundo error más frecuente es el manejo incorrecto del eNCF (número de secuencia electrónico). Cada eNCF debe ser único por tipo de comprobante y emisor. Los gaps en la secuencia (números salteados) y los reenvíos con el mismo eNCF generan rechazos que pueden ser difíciles de recuperar si no se tiene un sistema de control de secuencias.

Preguntas frecuentes

¿Cuál es la diferencia entre el eNCF y el NCF tradicional?

El NCF era un número de secuencia impreso en papel asignado por la DGII a un rango. El eNCF es el número de secuencia electrónico del e-CF: comienza con 'E' seguido del tipo de comprobante (2 dígitos) y el número de secuencia (10 dígitos). El eNCF se autogenera dentro de los rangos autorizados por la DGII, sin necesidad de solicitar cada número individualmente.

¿Cómo puedo probar la integración antes de ir a producción con la DGII?

La DGII provee un ambiente de certificación (`eCF Homologación`) donde los emisores pueden probar el envío de e-CF sin consecuencias fiscales. Los comprobantes emitidos en este ambiente tienen eNCF de certificación que no afectan los rangos de producción. Se requiere credenciales de acceso al portal DGII y un certificado de prueba para el proceso de homologación.

¿Qué diferencia hay entre 'Aceptado' y 'Aceptado Condicional'?

'Aceptado' indica que el e-CF cumple todos los requisitos. 'Aceptado Condicional' indica que el comprobante tiene observaciones que no impiden la aceptación, pero que deben revisarse. Las notificaciones de tipo condicional incluyen el código y descripción de la observación. En producción, deben registrarse y evaluarse para evitar que se conviertan en rechazos en documentos futuros del mismo tipo.

¿Es posible emitir e-CF sin certificado propio usando un proveedor tecnológico?

Sí. El esquema e-CF de la DGII permite que el proveedor tecnológico firme en nombre del emisor usando su propio certificado, siempre que exista una autorización formal entre ambas partes. Esta modalidad elimina la necesidad de gestionar certificados propios pero implica dependencia del proveedor para la firma. Revisar los términos del proveedor tecnológico antes de optar por esta alternativa.