e-CF sin respuesta: recupera el TrackId antes de reenviar

Qué hacer primero cuando un e-CF se queda sin respuesta

Tu conector o proveedor envió el XML a la DGII y no te devolvió TrackId. Antes de reenviar, emitir otro comprobante o cambiar el e-NCF, haz dos cosas: consulta el resultado oficial por TrackId si lo conservas (Informe Técnico e-CF v1.0, DGII, marzo 2026, §4.5), o pide al proveedor que consulte por e-NCF con delegación del emisor (§4.7) si el TrackId se perdió. Hasta no tener un estado oficial, el documento se trata como desconocido y la decisión la cierran tu proveedor y tu contador, no el conector.

Una respuesta perdida no te dice si la DGII recibió o procesó el e-CF. Tampoco te dice que no lo hizo. Es incertidumbre pura, y por eso reintentar a ciegas o crear un segundo comprobante introduce un riesgo que después hay que revisar caso por caso. Esta guía separa lo que dice la DGII, lo que recomienda la ingeniería y lo que decide tu contador, sin saltar ninguna capa: las reglas de fuente son el Informe Técnico e-CF v1.0 (§4.2, §4.5, §4.7, §8 y las definiciones de acuse de recibo); las recomendaciones de ingeniería son de Antreva y no son mandato de la DGII; la corrección o el cierre del documento lo revisan tu proveedor y tu contador sobre la evidencia preservada.

Qué pasa realmente y cómo se diferencia lo local de lo oficial

La Recepción del e-CF (§4.2) recibe el XML firmado y devuelve un TrackId que sirve para consultar el resultado después. Ese TrackId no es aceptación, autorización ni constancia de pago; es solo el identificador de la entrega. Si tu sistema no muestra un TrackId para esa operación, la respuesta de Recepción no está disponible en tu conector en ese momento. Lo que ocurrió del lado de la DGII no se puede deducir solo de eso: pudo completarse sin que tu conector recibiera la respuesta, o no haber llegado hasta Recepción. Tu conector no tiene forma de saberlo por sí mismo, así que la respuesta faltante no prueba ni descarta nada sobre la entrega.

Tu sistema interno maneja un estado propio: pendiente, enviado sin respuesta, error de transporte o desconocido. Son marcas tuyas, útiles para operar, no prueba fiscal. La DGII maneja otro reloj con los cuatro estados de procesamiento del §8: aceptado, aceptado condicional, rechazado y en proceso. La respuesta oficial no equivale al acuse del receptor ni al cierre comercial del negocio, así que no se debe cerrar la venta en tu sistema solo porque el resultado oficial diga aceptado: hace falta también la confirmación comercial o de pago que tu propio flujo defina. Cada uno de los cuatro estados requiere una acción distinta revisada por tu proveedor; esta guía no prescribe un remedio fiscal.

Mientras no tengas estado oficial, el documento se trata como desconocido. No hay base para emitir otro e-CF, anular el primero ni dejarlo pasar: cualquier movimiento se hace con la evidencia preservada y la revisión del proveedor y el contador.

Trazabilidad mínima y bloqueo de clics repetidos

Lo que conservas del intento original es lo único que te va a servir para consultar y para explicar lo que pasó. Tres piezas, guardadas localmente, sin publicar XML ni credenciales:

• XML firmado original, con su hash y el identificador de petición del proveedor. Es la pieza que confirma exactamente qué enviaste.
• Marca de tiempo del intento y referencia del proveedor, para que el proveedor y la DGII puedan correlacionar con sus logs.
• Número de e-NCF que ibas a usar, tomado de tu secuencia fiscal. Es el dato que pide §4.7 cuando no hay TrackId.

Evitar que un doble clic o una doble pulsación disparen un segundo envío es una buena práctica de ingeniería. Lo que sirve es un bloqueo por operación en el conector: un lock del lado servidor que impida reintentar mientras la primera emisión sigue en curso, implementado correctamente y combinado con la preservación de la evidencia. Un identificador como un UUID ayuda a correlacionar, pero el bloqueo debe estar bien implementado en el servidor que llama a la DGII; un UUID local sin ese control no te garantiza nada frente a clics repetidos o procesos paralelos.

Recuperación por TrackId cuando sí lo tienes (§4.5)

Si tu conector guardó el TrackId que devolvió la Recepción, la ruta directa es la consulta de resultado del emisor del §4.5, con el usuario autorizado y autenticado, comparando contra el documento original. Lo que obtienes es el estado oficial de procesamiento (§8) de ese envío en concreto.

Después, la decisión la revisan tu proveedor y tu contador. Si el estado es aceptado, ese resultado oficial se cruza con tu flujo comercial para confirmar el cierre de la venta. aceptado condicional no es un rechazo: requiere una acción distinta revisada por tu proveedor sobre las reglas aplicables. en proceso significa que la DGII todavía no tiene un resultado final, así que el documento sigue sin estado fiscal cerrable hasta que vuelva a consultarse. Esta guía no te dice qué hacer con cada estado, porque la corrección fiscal no se prescribe en un artículo.

Recuperación por e-NCF con delegación cuando el TrackId se perdió (§4.7)

Si la respuesta de Recepción no quedó disponible localmente y el conector no conserva un TrackId, existe una segunda puerta: la Consulta de TrackID e-CF del §4.7. Para un e-NCF dado, devuelve la colección de identificadores de respuesta asociados a ese comprobante y el estado de cada uno. Para usarla sin equivocarte:

• El usuario debe estar autenticado y delegado por el emisor del e-CF. Sin delegación, el servicio no responde con la información del comprobante.
• Debes conocer el e-NCF que se intentó usar. Lo maneja tu secuencia fiscal y lo guarda tu conector.
• La disponibilidad no es universal. Que tu proveedor no exponga esta consulta no significa que el documento no exista; significa que el camino pasa por el proveedor o por el canal de soporte de la DGII.

Una colección vacía o un error de delegación no prueban que la DGII no haya recibido el XML. Antes de sacar conclusiones, pide a tu proveedor que verifique los permisos, la evidencia preservada y la posibilidad de lanzar la consulta con la delegación correcta; si la respuesta sigue sin ser concluyente, escalas con tu contador. No inventes un veredicto oficial sobre la base de una respuesta vacía.

Caso ilustrativo: e-CF de Crédito Fiscal, sin identificar cliente

Una ferretería emite un e-CF de Crédito Fiscal desde su POS con el XML completo. El proveedor devuelve un error de timeout y la pantalla nunca muestra TrackId. El operador no hace un segundo clic; la operación queda marcada como desconocida en su sistema, con el XML firmado, el timestamp y el e-NCF que iba a usar guardados localmente. El proveedor revisa primero los registros del conector: como no hay un TrackId guardado para esa operación, no hay identificador con el cual llamar al §4.5, así que pasa directo a la consulta del §4.7 con el e-NCF, usando la sesión autenticada y la delegación del emisor. La respuesta que obtiene no le permite determinar el estado de manera concluyente, por lo que la ferretería no emite un nuevo comprobante, no anula el primero y deja la decisión en manos del proveedor y el contador, con la evidencia preservada. Este caso no es un testimonio ni un resultado real; solo ilustra el camino.

Escenarios de prueba que puedes pedir hoy (ambiente de pruebas, no producción)

Estos escenarios sirven para que tu proveedor demuestre, en un ambiente de pruebas autorizado, que el conector hace lo que dice. No se ejecutan contra producción ni inyectando fallas reales, y la configuración exacta la defines con tu proveedor.

• Emisión normal con respuesta de TrackId. El conector debe guardar TrackId, e-NCF e ID de venta.
• Timeout antes de la respuesta. El conector debe marcar desconocido, conservar el XML firmado y no reintentar solo.
• Clics repetidos sobre la misma venta. El segundo intento debe quedar bloqueado por el servidor mientras la primera emisión sigue en curso.
• Consulta por TrackId con resultado oficial. El conector debe contrastar el estado oficial con el estado local y registrar cualquier divergencia.
• Consulta por e-NCF con delegación del emisor. El conector debe llamar al §4.7 solo con delegación activa y mostrar la colección de respuestas.

Cierre

Si tienes TrackId, consulta por §4.5. Si no lo tienes y el proveedor tiene delegación del emisor, consulta por §4.7. Si el resultado no es concluyente, escalas con la evidencia preservada y esperas a tu proveedor y tu contador. Reenviar a ciegas introduce un riesgo que después se paga en tiempo y en corrección fiscal.

Si tu conector no guarda la evidencia mínima o no expone la consulta por e-NCF, Antreva revisa tu flujo técnico de e-CF con tu CRM, POS o integrador actual. Para preparar datos y excepciones del día a día, la lectura relacionada es e-CF en la operación diaria: cómo preparar datos, responsables y excepciones en una mipyme dominicana. Conversemos.

Preguntas frecuentes

¿Puedo reenviar el mismo XML si la conexión cayó? Reenviar el mismo XML no es lo mismo que emitir un comprobante nuevo, y esta guía no te autoriza ni te prohíbe ninguna de las dos acciones a nivel fiscal. Lo que sí es claro: sin un TrackId o un estado oficial de la DGII no tienes base para decidir; consulta primero por §4.5 si conservas un TrackId, o por §4.7 con e-NCF y delegación si no lo conservas, y deja que tu proveedor y tu contador determinen, sobre la evidencia preservada, el siguiente paso. El estado DGII, el acuse del receptor y la confirmación comercial o de pago son tres cosas distintas y se confirman por separado.

¿Qué hago si mi proveedor no expone la consulta por e-NCF del §4.7? El §4.7 exige autenticación y delegación del emisor, y no todos los proveedores la exponen igual. Escala al proveedor o al canal de soporte de la DGII con la evidencia preservada (XML firmado, timestamps, e-NCF intentado); no construyas un nuevo comprobante sobre la incertidumbre.

¿Esto aplica al consumo electrónico? Esta guía cubre el flujo normal de e-CF con XML completo y los servicios §4.5 y §4.7. El RFCE, procedimiento específico de consumo regulado por §4.3 y §9 del Informe Técnico, queda fuera de esta pieza. Si tu operación utiliza un procedimiento distinto al flujo XML completo, consúltalo por separado.