NCF vs e-CF en República Dominicana: qué cambia técnicamente en la migración
Comparativa técnica entre el NCF tradicional y el e-CF electrónico en RD: qué cambia en firma, transmisión, estructura del documento y arquitectura del sistema de facturación.

República Dominicana lleva varios años en transición entre el régimen de NCF en papel y el e-CF electrónico. Para los equipos de desarrollo que mantienen sistemas de facturación con soporte NCF activo, la pregunta práctica no es 'qué es el e-CF' — es 'qué cambia exactamente en el código y cuánto tiempo tenemos para adaptarlo'.
Este artículo compara ambos sistemas desde la perspectiva técnica: qué datos se mantienen, qué se elimina, qué se agrega y cuáles son los cambios estructurales que implican mayor esfuerzo de implementación.
Diferencias estructurales: de número a documento
El NCF era un identificador: un número de 11 caracteres que el sistema de facturación generaba e imprimía en el comprobante. La validez fiscal del NCF dependía de que estuviera dentro de un rango autorizado vigente. El documento físico no era transmitido a la DGII.
El e-CF es un documento: un XML estructurado que contiene todos los datos del comprobante, firmado digitalmente, transmitido a la DGII en tiempo real, y cuya aceptación electrónica es condición de validez fiscal. El PDF que recibe el comprador es secundario — el documento fiscal real es el XML aceptado por la DGII.
Cambios técnicos por componente
Generación de número de comprobante
NCF: el sistema genera el número de secuencia dentro del rango autorizado. Control local, sin transmisión. e-CF: el sistema genera el eNCF dentro del rango autorizado y lo incluye en el XML. El eNCF está bajo control local pero debe ser único y secuencial por tipo de comprobante. La DGII valida la unicidad en el momento del envío.
Datos del documento
NCF: los datos del comprobante se almacenan en la base de datos local y se reportan a la DGII mensualmente mediante el archivo 606/607. e-CF: todos los datos deben estar en el XML antes del envío. La DGII valida la estructura y las reglas de negocio en tiempo real. El e-CF reemplaza los formularios 606/607.
Firma digital
NCF: no requiere firma digital. La autenticidad del NCF se verificaba por el rango y la secuencia asignada por la DGII. e-CF: requiere firma digital XAdES-BES con SHA-256 usando certificado emitido por CA autorizada por la DGII. Este es el componente de mayor impacto técnico para sistemas que no tienen experiencia previa en firma digital.
Transmisión a la DGII
NCF: reporte mensual mediante archivos planos (606 compradores, 607 ventas). Sin transmisión por transacción. e-CF: transmisión por transacción vía web service DGII antes de que el documento llegue al receptor. El tiempo real es un cambio de arquitectura, no solo de formato.
Los sistemas que generan NCF en modo batch (fin del día) no pueden trasladar esa arquitectura directamente al e-CF. El e-CF requiere transmisión en tiempo real — el documento no puede llegar al receptor hasta que la DGII lo acepte.
Componentes nuevos que requieren implementación desde cero
Los dos componentes que prácticamente todos los sistemas con soporte NCF deben implementar desde cero son: (1) el módulo de firma digital — generación del digest SHA-256, aplicación de la clave privada, inserción de la firma en el XML; y (2) el cliente del web service DGII — envío del e-CF, manejo de la respuesta, reintentos con backoff en caso de timeout, y consulta de estado cuando la respuesta no llega.
El módulo de gestión de certificados también es nuevo en la mayoría de implementaciones: renovación del certificado, alerta de vencimiento próximo, rotación de clave privada. Un certificado vencido bloquea 100% de la emisión de e-CF — no hay degradación parcial.
Implementar el módulo de firma digital como servicio independiente desde el inicio. Acoplarlo directamente al módulo de facturación genera deuda técnica costosa cuando cambia el proveedor de certificados o cuando la DGII actualiza los requisitos de firma.
Recomendaciones de migración para equipos con NCF activo
La estrategia más común es la operación en paralelo durante el período de transición: el sistema sigue emitiendo NCF para los clientes que todavía no están en el régimen e-CF obligatorio, y emite e-CF para los que ya lo están. Esto requiere que el sistema identifique el régimen de cada cliente y enrúe el documento al flujo correcto.
El riesgo principal de la operación en paralelo es el mantenimiento de dos flujos divergentes. Definir desde el inicio una fecha de corte interna para el soporte NCF permite planificar la migración de manera ordenada.
Preguntas frecuentes
¿Cuál es el plazo oficial para que todos los contribuyentes migren al e-CF?
La DGII ha publicado cronogramas por segmento de contribuyente. Los grandes contribuyentes ya están en el régimen e-CF obligatorio. Los medianos y pequeños tienen cronogramas variables. La consulta definitiva debe hacerse en el portal oficial DGII, ya que las fechas han sido ajustadas en varias ocasiones.
¿Cómo puedo mantener compatibilidad con NCF mientras implemento e-CF en paralelo?
Abstraer el tipo de comprobante como parámetro del módulo de facturación. El módulo decide el flujo (NCF o e-CF) según el tipo de contribuyente del receptor y la fecha. Compartir la lógica de cálculo de impuestos y totales entre ambos flujos, y separar únicamente el módulo de generación de número, firma y transmisión.
¿Qué diferencia hay entre el eNCF y los rangos de NCF tradicionales?
Los rangos de NCF tradicionales debían solicitarse a la DGII con anticipación y tenían fecha de vencimiento. El eNCF se genera localmente dentro de un rango que la DGII autoriza, pero la autorización funciona de manera diferente: el contribuyente solicita habilitación para emitir ciertos tipos de e-CF y la DGII valida el primer e-CF de cada tipo durante el proceso de certificación.
¿Es posible anular un e-CF aceptado por la DGII?
No directamente. El e-CF no tiene un mecanismo de anulación equivalente al 'inutilización' del NCF. Para reversar un e-CF aceptado, se emite una Nota de Crédito (tipo 34) referenciando el eNCF del comprobante original. La Nota de Crédito también debe ser firmada y aceptada por la DGII.
Artículos Relacionados
Cómo validar un e-CF con la DGII: código de seguridad, firma XAdES-BES y consulta de estado
Guía técnica para verificar e-CF en República Dominicana: cálculo del código de seguridad, verificación de firma XAdES-BES, consulta de estado por eNCF en la DGII y manejo de estados de respuesta.
e-CF en República Dominicana: guía técnica de integración para desarrolladores
Estructura del XML del e-CF, firma SHA-256, flujo de envío y respuesta DGII, y los errores más frecuentes en la integración de comprobantes fiscales electrónicos en República Dominicana.
Checklist de go-live e-CF en República Dominicana: de staging a producción DGII
Checklist completo para pasar una integración e-CF de staging a producción DGII en República Dominicana: homologación, certificados, pruebas de carga y monitoreo post-lanzamiento.