Mismo e-CF del proveedor importado dos veces: evita duplicar la cuenta por pagar

Cuando el mismo e-CF firmado por tu proveedor entra dos veces a tu sistema, esta guía aborda el control técnico de la importación; no determina la situación fiscal de cada comprobante. Aceptación ante la DGII, transmisión del emisor, acuse de recibo del receptor, revisión de compras y pago siguen su propio canal y ritmo; el acuse formal que tu receptor electrónico devuelve no se posterga ni se suprime por un conflicto interno de importación.

Recibir el mismo archivo firmado dos veces no se confunde con recuperar un TrackId ausente, ni con asignar número fiscal a tus ventas desde dos cajas, ni con exportar un resumen de consumo (RFCE es un resumen, no el comprobante completo). Tampoco con el mapa de los cuatro planos del receptor (aceptación DGII, acuse, aprobación comercial, pago B2B).

Tres objetos que se confunden al recibir

Conviene separar tres cosas antes de decidir qué se duplica y qué no.

El archivo son los bytes del XML firmado. En un reingreso los bytes pueden venir idénticos o venir con cambios sin explicación documentada; tratar ambos casos como el mismo es el error típico.

La identidad del documento, dentro del negocio receptor, se construye leyendo los campos documentados del emisor y del comprobante (por ejemplo emisor y e-NCF) en el XML firmado. Esa llave local no se infiere del nombre del archivo ni del total, ni se construye con campos no documentados ni con relaciones inventadas entre etiquetas. Es una llave de ingeniería interna, no un esquema fiscal.

El evento de importación es cada vez que tu sistema recibe un archivo concreto, a la hora y desde el origen concretos. Un mismo archivo puede generar dos eventos si entra dos veces.

Cuando tu rutina trata los tres como si fueran uno, el resultado típico es duplicar la cuenta por pagar por nombre de archivo parecido, o ignorar un reingreso porque el sistema cree que ya lo vio.

Identidad local de importación: emisor + e-NCF

La llave local de importación es la pareja (emisor, e-NCF) leída de los campos documentados del XML firmado. Vive en tu sistema y se mantiene dentro del negocio; no es un esquema DGII ni un campo fiscal. Sirve para decidir, antes de crear una cuenta por pagar, si el documento que entra ya fue visto por tu sistema.

El discriminador secundario es el hash de bytes. Permite comparar huellas; el cotejo de bytes confirma coincidencia exacta. No prueba autenticidad fiscal, no prueba aceptación de la DGII ni deuda exigible. El Informe Técnico e-CF v1.0 de la DGII, marzo 2026, publicación informativa sin validez legal, describe cómo viaja el XML y la firma entre las partes; lo que tu rutina hace con esa llave local es una decisión de ingeniería separada.

Conviene pactar con tu proveedor técnico cómo se protege esa fuente de verdad bajo condiciones de carrera. Preguntar antes de insertar no basta cuando dos procesos corren a la vez; pide que explique y documente las salvaguardas de unicidad y concurrencia del lado servidor. No existe garantía universal de exactamente una vez, ni un log que por sí solo demuestre atomicidad.

Mismo archivo, identidad repetida con bytes distintos, total coincidente

Tres situaciones, tres reglas.

Mismo archivo o bytes repetidos. Si la llave local coincide y el cotejo de bytes confirma coincidencia, registra un nuevo evento local con marca de tiempo, origen y resultado, no crees un segundo registro de cuenta por pagar. No equivale a aprobación ni a pago: la cuenta por pagar interna es un registro técnico sujeto a revisión de compras, administración autorizada y contador.

Identidad repetida con bytes distintos. Si la llave local coincide pero los bytes difieren, pon el nuevo archivo en una cola de conflicto etiquetada con el identificador del registro original. Preserva el archivo original sin tocarlo: no sobrescribir, no modificar sus bytes, no reemplazar por una versión corregida del proveedor. Notifica a compras para que converse con el proveedor fiscal. Esta pieza no prescribe pedirle al proveedor que corrija el mismo XML ni un remedio fiscal: la decisión administrativa la revisan el proveedor fiscal y tu contador por el canal que corresponda.

Total coincidente, identidad distinta. Dos e-CF con el mismo monto pero con (emisor, e-NCF) distintos son documentos distintos. El total por sí solo no basta para descartarlos como duplicados. El total no es llave; es un dato más del archivo. En operaciones reales aparecen totales repetidos: dos compras la misma semana, dos servicios con el mismo monto, dos facturas del mismo día. La política interna de riesgo puede, según tu negocio, marcarlos para revisión; eso es una decisión del negocio, no una regla de la importación local.

Falla entre archivo y registro interno. Si el sistema cae después de calcular el hash y antes de persistir el evento, no lances un segundo intento a ciegas. Reconcilia por evidencia antes de reejecutar: qué archivo ya entró, qué intento ya quedó registrado, qué identificador de operación estás viendo. La revisión tras una caída exige un enlace durable entre el evento registrado y el registro interno, no basta con la línea de log.

Cómo Antreva Tech puede ayudar en este tramo

Antreva Tech propone, como alcance acordado por escrito junto a tu proveedor fiscal y tu contador, un trabajo de ingeniería sobre la capa entre el archivo que entra y la cuenta por pagar interna. El alcance se acuerda caso por caso; aquí se describe trabajo propuesto según alcance, no funciones ya desplegadas ni resultados verificados. El objetivo es que administración pueda rastrear qué archivo originó cada registro y revisar los conflictos antes de aplicar cambios internos.

Sobre esa capa se propone una llave local leída de los campos documentados del XML firmado (emisor y e-NCF); un registro de eventos con marca de tiempo, hash de bytes, identificador de origen y resultado (registrado, reingreso sin nuevo registro, en cola de conflicto); una cola de conflicto que pausa la autoaplicación y notifica a compras; y pruebas sin firma, sin red, sin emisión y sin datos reales. La cuenta por pagar interna queda sujeta a revisión de compras, administración autorizada y contador; la aceptación fiscal la determina la DGII; las implicaciones tributarias las revisan tu proveedor fiscal y tu contador.

Como ilustración sin valor fiscal, esta tabla offline con cuatro casos y etiquetas ficticias sirve para conversar el diseño con tu proveedor técnico.

Caso	Entrada	Llave local	Hash de bytes	Acción recomendada
A	PROV-DEMO / DOC-DEMO, mismo archivo dos veces	coincide	coincide	registrar dos eventos y un solo registro interno, sujeto a revisión
B	PROV-DEMO / DOC-DEMO, identidad repetida, bytes distintos	coincide	difiere	poner en cola de conflicto, preservar original, notificar a compras
C	PROV-DEMO2 / DOC-DEMO2, identidad distinta, igual total	distinta	no se usa	registrar evento, no descartar por total; revisión interna según política del negocio
D	archivo entra, hash calculado, sistema cae antes de persistir	n/d	calculado	reconciliar por evidencia antes de reejecutar; enlace durable evento-registro

Las etiquetas PROV-DEMO y DOC-DEMO son ficticias y no representan datos fiscales reales. Las pruebas locales no demuestran aceptación fiscal, autenticidad por hash ni deuda exigible. La decisión sobre cada comprobante la cierran tu proveedor fiscal y tu contador; la DGII determina la aceptación.

Para conversar el alcance, parte de la página de desarrollo de software a la medida. Para contexto general sobre cuándo conviene integrar antes de comprar software, mira esta guía para mipymes con sistemas desconectados.

Preguntas frecuentes

¿Un hash que coincide basta para considerar aceptada la factura?

No. El hash permite comparar huellas; el cotejo de bytes confirma coincidencia exacta, pero no prueba aceptación fiscal ni deuda exigible. La aceptación la determina la DGII por su canal; el pago lo revisan compras autorizadas, administración y contador.

¿Qué pasa si llega la misma identidad con bytes distintos?

Por recomendación de ingeniería, los archivos originales permanecen sin modificar; el archivo nuevo va a una cola de conflicto para que compras decida. Esta pieza no prescribe pedirle al proveedor que corrija el mismo XML ni un remedio fiscal: cualquier acción la revisan el proveedor fiscal y tu contador por el canal que corresponda.

¿Esta lógica evita que la DGII reciba dos veces el mismo e-CF?

Esta pieza controla únicamente la importación del receptor; no controla la transmisión del emisor a la DGII.

Nota sobre la fuente: el Informe Técnico e-CF v1.0 de la DGII, marzo 2026, citado arriba, es una publicación informativa y no tiene validez legal por sí mismo.