RFCE: qué evidencia pedir antes de aceptar al proveedor (consumo menor a DOP 250.000)

Por qué este momento merece su propia conversación

Estás por firmar o renovar con un proveedor de facturación electrónica. Te ofreció emisión, paneles, RI y sincronización con tu POS. También dijo que conserva la factura. Lo que casi nunca queda claro de entrada es cómo puedes sacar la factura de consumo electrónica completa desde un archivo que controlas tú, sin pasar por el panel del proveedor, cuando emites a consumidor final por un monto inferior a DOP 250.000.

Esa pregunta no es accesoria. Es la diferencia entre un comprobante que solo el proveedor te puede mostrar y un archivo que puedes abrir, copiar y mover con tus propias manos. La DGII lo describe con cuidado en el Informe Técnico e-CF v1.0 (marzo 2026, publicación informativa sin validez legal), sobre todo en §4.3, §6.1 y §9.1. Vale la pena leerlo antes de aceptar nada.

RFCE no es la factura de consumo completa: tres objetos que se confunden

Cuando operas con un consumidor final y el monto total es estrictamente inferior a DOP 250.000, intervienen tres documentos que se mezclan fácilmente:

• El RFCE (Resumen de Factura de Consumo Electrónica). Es un resumen con los datos principales del comprobante, que el emisor envía a DGII. Por diseño no contiene el documento completo (§4.3).
• La Representación Impresa (RI). Es la versión en papel del XML, la que se entrega al cliente no electrónico y la que termina en tu impresora.
• El e-CF subyacente, o factura de consumo completa. Es el XML firmado electrónicamente con la estructura detallada en §6.1 y §11.1. Según §9.1, el emisor debe almacenar y conservar ese XML en forma electrónica por un período de diez (10) años; en la misma sección, el emisor debe además ponerlo a disposición del receptor no electrónico para fines de consulta. Esta guía no extrapola ese plazo a otros comprobantes ni afirma que otros documentos carezcan de obligaciones de conservación.

La confusión común: el RFCE no reemplaza al e-CF subyacente, y la RI no es el archivo fiscal. Si tu archivo local solo guarda la RI, no tienes el documento fiscal completo. Si solo guarda el RFCE, tampoco.

Siete evidencias locales que puedes pedir antes de firmar

Una demostración con datos sintéticos, en un ambiente aislado y bajo tu permiso, sirve más que cualquier promesa verbal. Las siguientes son propuestas de ingeniería, no obligaciones de la DGII. Si tu proveedor las ejecuta y tú puedes revisarlas después en tu propia máquina, vas por buen camino.

• E1. Manifiesto de archivo. Un listado que muestra la relación uno a uno entre cada resumen enviado a DGII y el XML subyacente guardado localmente, junto con un índice lateral por archivo.
• E2. Exportación fuera del panel. Un camino documentado para sacar el XML completo y su índice sin pasar por la interfaz web del proveedor: acceso directo, script local o endpoint bajo tu control.
• E3. Lectura local del XML. Abrir el archivo exportado con un lector de XML que tú controlas y verificar que sea un XML bien formado de e-CF. Esto prueba que el archivo se lee y se interpreta. No prueba que sea válido para DGII ni que la firma esté vigente.
• E4. Comparación de bytes contra un original preservado. Recalcular un hash del XML exportado y compararlo con el hash guardado al almacenar el original. Si coincide, los bytes son los mismos: eso prueba identidad de bytes. No prueba aceptación fiscal ni cadena de auditoría inmutable.
• E5. Roles de acceso. Una demostración, dentro de la muestra acordada, de quién puede listar, exportar y auditar el archivo y quién no. Es un control propuesto, parte de lo que pactes con tu proveedor. Esta guía lo plantea como ingeniería; §9.1 describe conservación y disponibilidad, no justifica aquí un procedimiento de exportación universal.
• E6. Registro de archivos faltantes. Si un resumen figura en el manifiesto pero el XML subyacente no está (o al revés), el sistema marca el hueco como pendiente de investigación. No entrega un sustituto silencioso.
• E7. Términos de salida documentados. Por escrito: el formato del archivo, la estructura del índice y el método de acceso. Lo que el escrito sí puede asegurar es que las condiciones, dependencias y límites de la salida quedan registrados: nada de buenas voluntades, algo que puedes mostrar.

Lo que ninguna de estas pruebas te asegura

Conviene decirlo con la misma fuerza con la que pediste las pruebas:

• Un hash que coincide prueba identidad de bytes. No prueba que la firma siga vigente ni que falte algún documento. La aceptación fiscal no se deduce del estado del archivo local; la revisan tu proveedor y tu contador por el canal documentado.
• Que el archivo esté en tu infraestructura no implica que DGII lo haya recibido o lo considere válido. Una prueba de exportación independiente no exige alojamiento físico local: el arreglo de almacenamiento y sus obligaciones se confirman con tu proveedor y tu contador.
• Un hueco entre el manifiesto y el XML subyacente no significa, por sí mismo, que DGII rechazó la factura. Es un hueco técnico a investigar.
• Esta guía propone las pruebas anteriores como ingeniería; §9.1 describe conservación y disponibilidad, no justifica aquí un procedimiento de exportación universal. El plazo de diez años de §9.1 aplica a la factura de consumo electrónica emitida a receptor no electrónico por monto inferior a DOP 250.000; esta guía no extrapola ese párrafo a otros comprobantes ni afirma que otros documentos carezcan de obligaciones de conservación.

Un ejemplo sintético, sin un solo e-NCF real

Para no exponer datos productivos, la prueba se hace con etiquetas claramente ficticias. Supón dos archivos locales:

• RESUMEN-DEMO-A.xml, que simula el resumen enviado a DGII.
• FACTURA-DEMO-A.xml, que simula el XML subyacente completo.

Una nota importante: este es un archivo local ficticio, sin firma fiscal, sin certificado productivo y sin llamada a la red de DGII. Sirve para revisar la mecánica, no como muestra de un comprobante válido. En producción, lo que se conserva como XML subyacente es exactamente el archivo XML firmado originalmente, sin alterar; la meta de toda esta verificación es confirmar que esos bytes firmados se pueden recuperar tal cual. Recalcular una exportación a partir del catálogo actual no es lo mismo que preservar los bytes originales. Una vista PDF no sustituye el XML subyacente completo.

La demostración debería mostrar, como mínimo:

1. Que RESUMEN-DEMO-A y FACTURA-DEMO-A están asociados en el manifiesto.
2. Que ambos se pueden exportar por un camino distinto al panel del proveedor.
3. Que FACTURA-DEMO-A se abre como un XML bien formado de e-CF.
4. Que el hash del archivo exportado coincide con el del índice lateral.
5. Que un usuario autorizado pactado puede listar y exportar, y un usuario de prueba no autorizado, dentro de la misma muestra acordada, no puede.
6. Que un hueco en el manifiesto queda registrado, no se rellena en silencio.
7. Que un paquete portable se puede abrir en otra máquina autorizada, lo que muestra que la exportación no depende exclusivamente de la interfaz del proveedor.

Poder leer el paquete sin el panel no prueba independencia de la infraestructura del proveedor. La muestra tampoco demuestra que el historial esté completo, que puedas migrar sin ajustes ni que la conservación durante diez años esté resuelta.

Cómo Antreva Tech puede acompañar este tramo

En desarrollo de software a la medida, Antreva Tech propone, junto con tu proveedor fiscal ya contratado, un trabajo acotado a este tramo. El objetivo es ayudarte a leer tu propio archivo: mapear el flujo desde el POS hasta el archivo local, dejando por escrito qué objeto es el resumen y cuál es el XML subyacente; preservar los bytes firmados tal cual, sin reconstruir el archivo a partir del catálogo; definir el formato del manifiesto y del índice lateral; levantar una vista de exportación que no dependa del panel del proveedor, junto a un acceso privado para roles autorizados y pruebas de denegación a usuarios ficticios no autorizados; y correr contigo las pruebas sintéticas descritas arriba, con etiquetas que no se parecen a un e-NCF real.

El beneficio práctico es ver los huecos del archivo antes de aceptarlo, no después: cuando el resumen y el XML no cuadran, o cuando una exportación cambia bytes respecto al original preservado, lo notas en la prueba, con tiempo para conversar con tu proveedor. Nada de esto se ofrece como una certificación ni como una garantía de aceptación: las obligaciones fiscales las revisan tu proveedor y tu contador por el canal documentado, y DGII es quien determina la aceptación. La recuperación de sistemas operativos en general es un tema aparte, que tratamos en cómo probar la recuperación de respaldos. Si quieres revisar la verificación local del archivo de facturas completas asociadas al RFCE junto a tu proveedor fiscal, conversemos.

Preguntas frecuentes

¿El RFCE sirve como comprobante fiscal completo?

No. Es un resumen con la información principal (§4.3). La factura de consumo completa es el XML subyacente firmado, que se conserva localmente.

¿La DGII exige que el archivo esté físicamente en mi local?

Esta prueba de ingeniería evalúa una exportación que puedas leer fuera del panel; no establece una obligación de alojamiento físico en tu local. Confirma con tu proveedor y tu contador el arreglo de almacenamiento y las obligaciones aplicables a tu caso.

¿Si el hash coincide, la factura está validada por DGII?

El hash prueba identidad de bytes. La aceptación fiscal no se deduce del estado del archivo local; la revisan tu proveedor y tu contador por el canal documentado.