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.

Uno de los puntos de mayor fricción en implementaciones de e-CF en República Dominicana es la validación del comprobante desde el lado del receptor. Un comprador que recibe un e-CF necesita poder verificar que ese comprobante fue realmente aceptado por la DGII — no solo que el XML está bien formado. Esta guía cubre cómo hacer esa verificación técnicamente, qué elementos del e-CF intervienen y cuáles son los casos de error más frecuentes.
La guía aplica tanto para equipos que implementan la verificación en sistemas propios como para los que evalúan si el mecanismo de validación de su proveedor tecnológico es suficiente.
El código de seguridad del e-CF: primer filtro de autenticidad
El e-CF incluye un campo `CodigoSeguridadeCF` que es un hash calculado a partir de datos específicos del comprobante: RNC del emisor, tipo de e-CF, eNCF, fecha, monto total e ITBIS. Este código puede recalcularse con los datos del comprobante para verificar que los datos no fueron alterados. Si el código calculado no coincide con el del XML, el documento fue modificado después de la firma.
El algoritmo exacto para calcular el `CodigoSeguridadeCF` está documentado en el Anexo Técnico de la DGII. La implementación requiere conocer el orden exacto de concatenación de los campos y el algoritmo de hash aplicado (SHA-256). Variaciones en el orden o en el formato de los campos producen códigos distintos, incluso con los mismos datos.
Consulta de estado por eNCF en el portal DGII
La DGII provee un servicio de consulta de e-CF por eNCF. Dado el eNCF, el RNC del emisor y el monto total, el servicio retorna el estado actual del comprobante: Aceptado, Aceptado Condicional, Rechazado o No Encontrado. Este servicio puede usarse desde sistemas del receptor para verificar que el e-CF fue aceptado por la DGII.
El servicio de consulta tiene restricciones de uso: no está diseñado para consultas masivas en tiempo real. Para sistemas que reciben alto volumen de e-CF, la estrategia recomendada es validar el código de seguridad localmente y usar el servicio de consulta DGII solo para los casos donde hay dudas sobre la autenticidad del documento.
El portal DGII también provee una consulta manual de e-CF en su sitio web, accesible sin credenciales técnicas. Útil para verificaciones individuales por usuarios no técnicos.
Verificación de la firma digital XAdES-BES
La firma XAdES-BES en el e-CF puede verificarse con cualquier librería estándar de firma XML que soporte el estándar XAdES. La verificación confirma que: (1) la firma es válida criptográficamente con la clave pública del certificado, (2) el certificado fue emitido por una CA reconocida por la DGII, y (3) el certificado estaba vigente en el momento de la firma.
El tercer punto merece atención especial: la verificación del estado del certificado en el momento de la firma se hace usando el sello de tiempo (timestamp) incluido en la firma XAdES-BES. Si el timestamp no está presente o es inválido, no se puede verificar si el certificado estaba vigente al momento de firmar.
# Verificación de firma XAdES-BES — pseudocódigo
from lxml import etree
from xades import XAdESContext
def verificar_firma_ecf(xml_firmado_str):
root = etree.fromstring(xml_firmado_str.encode())
ctx = XAdESContext()
ns = {'ds': 'http://www.w3.org/2000/09/xmldsig#'}
sig_node = root.find('.//ds:Signature', ns)
if sig_node is None:
return {'valido': False, 'error': 'Firma no encontrada en el documento'}
try:
ctx.verify(sig_node)
return {'valido': True}
except Exception as e:
return {'valido': False, 'error': str(e)}Estados de respuesta DGII y qué significan para el receptor
'Aceptado' — el e-CF es válido fiscalmente. El receptor puede registrarlo en sus libros. 'Aceptado Condicional' — el e-CF tiene observaciones pero es fiscalmente válido. 'Rechazado' — el e-CF no tiene validez fiscal. El receptor no debe registrarlo. 'No Encontrado' — el eNCF no existe en los registros DGII: puede indicar un e-CF fabricado, un eNCF incorrecto en el XML, o un problema de transmisión del emisor.
Un e-CF 'No Encontrado' en la DGII puede ser señal de fraude fiscal. Si el receptor recibe un XML con eNCF que la DGII no encuentra, debe contactar al emisor para aclaración antes de registrarlo.
Preguntas frecuentes
¿Cuál es el plazo máximo para que un e-CF enviado a la DGII aparezca como Aceptado?
En condiciones normales, la respuesta de la DGII es casi inmediata (segundos). Si el emisor recibió confirmación de envío pero el comprobante no aparece en la consulta DGII dentro de las 24 horas, debe contactarse con el soporte de la DGII o con su proveedor tecnológico para verificar el estado del envío.
¿Cómo puedo verificar masivamente los e-CF recibidos sin saturar el servicio DGII?
Implementar la verificación del código de seguridad localmente como primer filtro — es un cálculo matemático que no requiere llamadas a la DGII. Para los documentos que pasan el filtro local, usar el servicio DGII solo en los casos donde hay dudas adicionales o donde la política interna exige verificación en la fuente.
¿Qué diferencia hay entre la verificación del código de seguridad y la verificación de la firma digital?
El código de seguridad verifica la integridad de los datos del encabezado del e-CF. La firma digital verifica la integridad de todo el documento XML y la autenticidad del firmante. Ambas verificaciones son complementarias. En una implementación robusta, se realizan las dos: el código de seguridad como verificación rápida, la firma digital como verificación completa.
¿Es posible rechazar un e-CF recibido si el receptor encuentra errores en los datos?
Sí, dentro de los plazos establecidos por la DGII. El receptor puede emitir una notificación de rechazo mediante el mecanismo de 'Acuse de Recibo e-CF' si detecta errores en los datos del comprobante recibido. Este mecanismo es distinto del rechazo que hace la DGII por incumplimiento técnico.
Artículos Relacionados
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.
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.