NCF vs e-CF en República Dominicana: Diferencias Técnicas y Legales para ISVs
Análisis técnico y legal de la transición del NCF al e-CF en República Dominicana: qué cambia estructuralmente, quiénes ya están obligados y qué debe implementar un ISV.
Muchos ISVs que ya operaban en República Dominicana con el sistema de Números de Comprobante Fiscal asumieron que la migración al e-CF era un cambio de formato. En la práctica, la transición implica obligaciones técnicas completamente distintas: firma digital con certificado aprobado por la DGII, transmisión directa al servidor validador de la autoridad y un flujo de aceptación electrónica por parte del receptor que el NCF nunca tuvo. Un ISV que no reconoce esta diferencia lleva al cliente a un esquema de emisión que la DGII puede invalidar, con consecuencias fiscales que recaen sobre el contribuyente y reputacionales sobre el proveedor del software.
Este artículo explica las diferencias técnicas y legales entre el NCF y el e-CF, el calendario de obligatoriedad definido por la DGII y qué cambios concretos debe implementar un ISV que hoy genera NCF y necesita habilitar la emisión de e-CF para los clientes ya obligados. El análisis está basado en la Norma General 06-2018 y sus modificaciones posteriores, así como en la documentación técnica publicada por la DGII para el esquema de comprobantes fiscales electrónicos.
¿Qué es el NCF y por qué la DGII lo está reemplazando?
Estructura del NCF y sus limitaciones técnicas
El Número de Comprobante Fiscal es un identificador alfanumérico de 19 posiciones que la DGII asigna en rangos al contribuyente emisor. El emisor imprime o emite el comprobante de forma local, sin transmisión en tiempo real a la autoridad, y la DGII fiscaliza a posteriori cruzando los NCF reportados en las declaraciones juradas. Esta arquitectura de reporte diferido tiene limitaciones estructurales: no permite verificar la autenticidad de un comprobante en tiempo real, facilita la falsificación de comprobantes y no genera un registro electrónico inmutable en el lado de la autoridad. Estas limitaciones son las que motivaron el diseño del esquema e-CF, donde la DGII valida cada documento antes de que sea legalmente válido.
Marco legal de la migración: Norma General 06-2018 y sus modificaciones
La Norma General 06-2018 de la DGII estableció el marco legal para el esquema de Comprobantes Fiscales Electrónicos en República Dominicana, incluyendo las definiciones de los tipos de e-CF, los requisitos técnicos de firma digital y el proceso de habilitación de emisores. Esta norma ha sido complementada por resoluciones posteriores que amplían los plazos de obligatoriedad por segmento de contribuyente y actualizan los esquemas XML aceptados. La transición no implica la eliminación inmediata del NCF: ambos esquemas coexisten durante los períodos de transición definidos por la DGII para cada segmento, pero los contribuyentes habilitados para e-CF deben emitir en ese esquema para las operaciones cubiertas.
El e-CF: estructura técnica y obligaciones del emisor
Componentes del comprobante fiscal electrónico
El e-CF es un documento XML estructurado según el esquema definido por la DGII, que incluye los datos del emisor, el receptor, los ítems de la transacción, los valores fiscales y los campos de firma digital. A diferencia del NCF, el e-CF lleva una firma electrónica con un certificado digital aprobado por la DGII, un identificador único generado por el emisor (equivalente funcional al CUFE colombiano) y un sello de validación que la DGII agrega al documento tras la aceptación. El documento solo tiene validez fiscal una vez que la DGII lo valida y devuelve ese sello de aceptación; sin él, el comprobante no es válido aunque esté correctamente firmado.
Firma digital y certificados aprobados por la DGII
El emisor de e-CF debe contar con un certificado de firma digital emitido por una autoridad certificadora reconocida por el INDOTEL y aceptada por la DGII. El certificado debe estar vigente en el momento de la firma de cada documento; un certificado expirado invalida todos los e-CF firmados después de la fecha de expiración, incluso si el documento fue aceptado por la DGII antes de que el sistema del ISV detectara la expiración. La gestión del ciclo de vida del certificado —monitoreo de fecha de vencimiento, renovación anticipada, actualización en el módulo de firma— es una responsabilidad operativa del ISV o del PSFE que este contrate, no de la DGII.
Flujo de transmisión y validación ante la DGII
El flujo de transmisión del e-CF sigue un esquema asíncrono en dos fases: el emisor envía el documento XML firmado al servidor de la DGII y recibe un acuse de recibo inmediato que confirma que el documento fue recibido, pero no aún validado. En una segunda fase, que puede tomar desde segundos hasta minutos según la carga del validador, la DGII procesa el documento y devuelve la respuesta definitiva de aceptación o rechazo, junto con el sello de validación en caso de aceptación. El ISV debe gestionar este ciclo asíncrono mediante polling o webhooks, y no debe registrar la factura como emitida hasta recibir la aceptación definitiva de la DGII.
Diferencias clave entre NCF y e-CF para un ISV
Tabla comparativa: NCF vs e-CF
La diferencia central entre ambos esquemas es el momento y el mecanismo de validación fiscal. En el NCF, el contribuyente reporta a posteriori y la DGII fiscaliza con retraso; en el e-CF, la DGII valida en tiempo real y el documento solo existe fiscalmente tras su aceptación. Esto implica diferencias técnicas concretas en la integración: el NCF no requiere firma digital ni conexión a la DGII en el momento de emisión; el e-CF requiere ambas. El NCF admite emisión offline durante horas o días; el e-CF en modo de contingencia tiene restricciones específicas definidas por la norma. El NCF puede generarse con cualquier sistema de facturación; el e-CF requiere un módulo de firma digital integrado y un canal de comunicación hacia el servidor de la DGII.
Impacto en el flujo del software emisor
Para un ISV que ya genera NCF, la migración al e-CF implica como mínimo cuatro cambios en el sistema: primero, integrar un módulo de firma digital que opere con el certificado aprobado por la DGII; segundo, implementar el cliente HTTP para transmitir a los endpoints del servidor validador DGII; tercero, gestionar el ciclo asíncrono de validación y actualizar el estado del comprobante tras la respuesta definitiva; cuarto, almacenar el sello de validación DGII junto al documento, ya que es parte integral del e-CF aceptado. Estos cambios afectan la arquitectura del servicio de emisión, no solo el formato del output, y requieren pruebas exhaustivas en el ambiente de certificación de la DGII antes de pasar a producción.
Calendario de obligatoriedad: quiénes ya deben emitir e-CF
Contribuyentes obligados por segmento
La DGII ha implementado la obligatoriedad del e-CF de forma progresiva por segmentos de contribuyentes, comenzando por las grandes empresas y avanzando hacia medianas y pequeñas en fases sucesivas. Los contribuyentes clasificados como grandes contribuyentes por la DGII fueron los primeros en estar obligados, seguidos por los contribuyentes ordinarios que superan determinados umbrales de ingresos anuales. Los plazos específicos por segmento deben consultarse directamente en la normativa vigente de la DGII, ya que han sido modificados en múltiples oportunidades. Un ISV que asesora a sus clientes debe verificar el estado de obligatoriedad de cada uno individualmente, ya que el incumplimiento es responsabilidad del contribuyente, no del proveedor del software.
Sanciones por incumplimiento
El Código Tributario de República Dominicana y las normas específicas de la DGII establecen sanciones para los contribuyentes obligados que no emitan e-CF en los plazos definidos. Las consecuencias pueden incluir la invalidez fiscal de los comprobantes emitidos como NCF por un contribuyente ya obligado al e-CF, lo que significa que esas facturas no serían deducibles para el receptor ni válidas para el emisor a efectos del ITBIS. Adicionalmente, la DGII puede aplicar multas por incumplimiento de deberes formales. Un ISV que no migra a tiempo a sus clientes obligados los expone a este riesgo fiscal; documentar el estado de migración de cada cliente y los pasos completados es una práctica de gestión de riesgo para el propio proveedor del software.
Pasos técnicos para que un ISV habilite la emisión de e-CF
Requisitos previos ante la DGII
Antes de poder emitir e-CF en producción, el emisor (o el PSFE que actúe en su nombre) debe completar el proceso de habilitación ante la DGII, que incluye el registro como emisor electrónico, la presentación del certificado digital a utilizar y la superación de las pruebas de certificación en el ambiente de desarrollo de la DGII. Este proceso de habilitación puede tomar entre dos y seis semanas dependiendo de la completitud de la documentación presentada y la carga de la DGII en el período de solicitud. Iniciar el proceso con antelación suficiente antes de la fecha de obligatoriedad del cliente es responsabilidad del ISV, y no hacerlo a tiempo es la causa más frecuente de incumplimiento evitable.
Implementación del módulo de firma y transmisión
La implementación técnica del módulo de e-CF comprende tres componentes: el generador del XML según el esquema DGII, el módulo de firma digital que aplica el certificado X.509 mediante SHA-256 y el cliente de transmisión que gestiona el ciclo asíncrono de envío y consulta de estado. Estos componentes pueden desarrollarse internamente o externalizarse a través de un Proveedor de Servicios de Facturación Electrónica (PSFE) habilitado por la DGII, opción que reduce el tiempo de implementación a semanas en lugar de meses. ISVs con clientes en múltiples países pueden considerar infraestructura de facturación multi-país como la de Alanube para República Dominicana, que actúa como PSFE habilitado y abstrae la complejidad de la transmisión directa a la DGII.
Preguntas frecuentes
¿Cuál es la diferencia principal entre un NCF y un e-CF en términos de validez fiscal? La diferencia central es el momento de la validación: el NCF es válido fiscalmente desde el momento en que el emisor lo genera, sin intervención de la DGII en tiempo real; el e-CF solo es válido fiscalmente una vez que la DGII lo acepta y devuelve el sello de validación. Esto significa que un e-CF firmado correctamente pero no transmitido a la DGII —o transmitido pero aún en estado de revisión— no puede ser usado como soporte fiscal por el receptor hasta recibir la aceptación definitiva. Un ISV debe reflejar esta distinción en la lógica de su sistema, evitando que el cliente imprima o entregue el comprobante antes de recibir la aceptación de la DGII.
¿Cómo puedo verificar si un contribuyente ya está obligado a emitir e-CF en República Dominicana? La DGII publica en su portal (dgii.gov.do) las listas de contribuyentes por segmento y los plazos de obligatoriedad asociados a cada uno. La consulta puede hacerse por RNC del contribuyente. Adicionalmente, la DGII notifica directamente a los contribuyentes afectados con antelación a sus fechas de obligatoriedad. Un ISV que gestiona múltiples clientes puede hacer esta consulta de forma automatizada usando los servicios de consulta pública de la DGII e integrarla en su flujo de onboarding de nuevos clientes, de modo que el estado de obligatoriedad quede documentado desde el inicio de la relación comercial y no como gestión reactiva.
¿Qué diferencia hay entre un PSFE y un ISV en el esquema de e-CF de la DGII? Un PSFE (Proveedor de Servicios de Facturación Electrónica) es una entidad habilitada por la DGII para actuar como intermediario entre el emisor y el validador DGII: firma digitalmente en nombre del emisor, gestiona la transmisión y devuelve el sello de aceptación. Un ISV es el proveedor del software de gestión del cliente (ERP, POS, sistema contable) que genera los datos de la factura pero no necesariamente tiene habilitación como PSFE. Un ISV puede integrarse con un PSFE habilitado para ofrecer emisión de e-CF sin obtener su propia habilitación como PSFE, lo que simplifica su entrada al mercado pero crea una dependencia operativa con el proveedor del servicio de transmisión.
¿Es posible emitir e-CF sin conexión a internet si el servidor de la DGII no está disponible? La DGII define un modo de contingencia para escenarios de indisponibilidad del validador, que permite al emisor continuar generando comprobantes bajo un esquema alternativo con obligación de regularización posterior. Sin embargo, este modo tiene restricciones: no todos los tipos de e-CF pueden emitirse en contingencia, la ventana de tiempo permitida es limitada y los documentos emitidos en contingencia deben ser transmitidos a la DGII en cuanto se restablezca la conexión. Un ISV debe implementar este flujo de contingencia desde el inicio, no como mejora futura, ya que los clientes lo necesitarán inevitablemente y la ausencia de contingencia es una causa de incumplimiento en períodos de inestabilidad del validador.
Artículos Relacionados
Nota de Débito Electrónica en República Dominicana: e-CF Tipo 35 Paso a Paso
Guía técnica para implementar la nota de débito electrónica (e-CF Tipo 35) en República Dominicana: estructura XML, campos obligatorios, flujo DGII y errores frecuentes.
Exoneraciones Fiscales en Factura Electrónica de Costa Rica: Cómo Implementarlas Correctamente
Guía normativa sobre exoneraciones en factura electrónica v4.4 de Costa Rica: tipos de documento, campo Exoneracion en el XML, errores frecuentes y validación para ISVs.
Nota de Crédito Electrónica en República Dominicana: e-CF Tipo 34 Explicado
Guía técnica del e-CF Tipo 34 en República Dominicana: cuándo emitirlo, campos de referencia al NCF original, flujo de validación asíncrona DGII y errores frecuentes para ISVs.