Recibir e-CF de proveedor: del XML al Excel y al 606

Este artículo es para el receptor del e-CF, no para el emisor. El flujo del receptor bajo Ley 32-23 tiene cinco pasos:

1. Descargar el XML del e-CF (por correo del PSFE del proveedor, desde la Oficina Virtual DGII, o por integración con tu sistema).
2. Validar la firma digital del emisor.
3. Enviar el acuse de recibo (ARECF) confirmando recepción.
4. Conservar el XML por 10 años.
5. Extraer los datos al registro de compras y mapearlos a las columnas del Formato 606.

La guía está pensada para la mipyme dominicana o el contador externo que recibe un .xml de un proveedor y necesita convertirlo en una fila correcta del registro de compras antes de preparar el 606.

La clave para el receptor es simple: recibes lo que tu proveedor está obligado a emitir, aunque tu propia fase como emisor todavía no haya empezado. Por eso una mipyme puede estar recibiendo XMLs de proveedores grandes antes de emitir sus propios e-CF.

Hay una regla central que ordena todo lo que sigue: el XML es el documento fiscal. El PDF sirve para revisión humana; el XML es el comprobante fiscal porque contiene la firma digital validable. Si el proveedor mandó solo el PDF, pídele el XML antes de registrar la compra. Por eso el receptor necesita un flujo propio: no está recibiendo una versión visual de la factura tradicional, sino un documento firmado, estructurado y verificable.

Cómo te llega el e-CF: los tres canales reales del receptor

Una vez que el proveedor emite el e-CF y lo certifica con su PSFE, el comprobante no aparece automáticamente en la contabilidad del receptor. Llega por uno de tres canales, y conviene saber cuál opera cada proveedor — porque el día que un comprobante "no aparezca", el primer paso del diagnóstico es preguntarte por dónde debió haber entrado.

Canal 1 — Correo del PSFE del proveedor. Es el canal más común para mipymes, y el que produce más confusión operativa. El proveedor configura en su plataforma de PSFE el correo electrónico del receptor; cuando emite el e-CF, el PSFE envía un email automático con el XML adjunto y, casi siempre, una representación impresa en PDF. Los PSFE certificados que verás escritos en el remitente son varios — Alegra, Citrus, GuruSoft, Ekomercio, Claro Facturación NCF, entre otros — y la lista oficial vigente la publica la DGII. El problema operativo real con este canal: los correos automáticos de PSFE caen con frecuencia en la carpeta de promociones o spam de Gmail, Outlook y Hotmail, sobre todo en cuentas que no han marcado al PSFE como remitente confiable. Vale la pena crear, desde el primer e-CF que recibas, una regla de filtrado por dominio del PSFE para que los siguientes lleguen directo a la bandeja principal.

Canal 2 — Descarga desde la Oficina Virtual DGII. Es el respaldo. Entras a la OFV con tu RNC y tu clave; navegas hasta la sección de Comprobantes Electrónicos Recibidos (o el nombre vigente de la sección equivalente en la versión actual del portal); ahí figura la lista completa de e-CF que cualquier emisor le ha emitido a tu RNC en el período. Desde ahí descargas los XML directamente desde DGII, sin depender del correo ni del PSFE del proveedor. Para una mipyme, la práctica útil es descargar e-CF de la Oficina Virtual DGII al menos una vez al mes, antes del cierre del período, para detectar comprobantes que figuren en el sistema pero no hayan llegado por correo. Es una verificación, no la entrada principal del flujo, pero captura los casos que el Canal 1 perdió.

Canal 3 — Integración API con el sistema del receptor. Cuando el receptor tiene un sistema (un ERP, una contabilidad propia, o la plataforma del PSFE elegido) conectado vía API, los e-CF entran automáticamente al sistema sin intervención manual. Es el canal típico de empresas medianas o grandes con volumen alto y un equipo de cuentas por pagar trabajando dentro del sistema. Para mipymes que viven en Excel y correo electrónico, este canal aplica solo si contratas una plataforma de PSFE que también funcione como inbox del lado receptor — opción válida, pero distinta a la operativa habitual del segmento.

En la práctica, una mipyme depende del Canal 1 como entrada por defecto y del Canal 2 como verificación periódica.

Anatomía del XML e-CF: los bloques que importa leer

Abres el XML por primera vez y ves una pared de etiquetas. Es normal, y se demistifica rápido. El XML del e-CF sigue el estándar UBL (Universal Business Language) en la versión adaptada por la DGII, y aunque la especificación completa enumera cientos de campos, el receptor solo necesita leer cinco bloques para hacer su trabajo. La anatomía del XML e-CF, en sus campos UBL relevantes, es la que sigue.

Identificación del comprobante. Aquí vive el e-NCF. Tiene 13 caracteres y comienza con la letra E, donde la NCF tradicional comenzaba con B. El segundo y tercer carácter codifican el tipo de comprobante: E31 para factura de crédito fiscal electrónica, E32 para factura de consumo electrónica, E41 para comprobante de compras electrónico (el caso del proveedor sin RNC, que cubrimos más adelante), E45 para comprobante gubernamental, E46 para comprobante de exportación, E47 para pagos al exterior y E48 para regímenes especiales. Después del código de tipo viene la secuencia, que se extendió a 10 dígitos (la NCF tradicional tenía 8). En el mismo bloque vive la fecha de emisión.

Datos del emisor. RNC del emisor, razón social, dirección, datos de contacto. La verificación práctica que hace el receptor es directa: el RNC y la razón social tienen que corresponder al proveedor real con el que hiciste la operación. Si el e-CF dice una razón social que no reconoces, conviene llamar al proveedor antes de procesarlo.

Datos del receptor. RNC del receptor y nombre. Aquí toca hacer la otra validación cruzada: el RNC tiene que ser el tuyo. Un e-CF dirigido a un RNC equivocado no se registra como tuyo, no se le envía acuse de recibo positivo, y se le pide al proveedor que corrija (volveremos a este punto cuando veamos los cuatro motivos de No Recibido).

Detalle de líneas. Cada producto o servicio facturado aparece como una línea con su descripción, cantidad, unidad de medida, precio unitario, ITBIS aplicado por línea e ISC si corresponde. Este bloque es el que alimenta la conciliación contra orden de compra, contra entrega, o contra factura comercial cuando hay un proceso de aprobación interno.

Totales. Monto bruto, ITBIS facturado total, ISC total y monto neto. Estos son los campos que terminan poblando el registro de compras y, eventualmente, las columnas del Formato 606.

Firma digital y sello de tiempo. Al final del XML hay un bloque criptográfico que prueba autenticidad: prueba que el documento se emitió desde el RNC que dice ser el emisor, y que no fue alterado después de firmarse. No se lee a ojo. Es la entrada del proceso de validación que tratamos en la sección siguiente.

Una nota práctica: abrir el XML para revisarlo es seguro siempre que se use un visor que no lo modifique — un navegador en modo de visualización, un editor de texto en solo lectura, o la herramienta de visualización del PSFE. Si lo abres en un editor que reformatee saltos de línea, encoding o espacios al guardar, invalidas la firma digital y, con ella, el comprobante. Para revisar, mejor un visor; para archivar, el archivo original tal como llegó.

Validar la firma digital del emisor antes de registrar

La firma digital es lo que convierte al XML en un documento fiscal en lugar de un archivo de texto cualquiera. Está vinculada al certificado digital del emisor — un certificado emitido a nombre del RNC del proveedor y registrado ante la DGII — y prueba dos cosas a la vez: que el comprobante salió genuinamente desde ese RNC, y que el contenido del XML no fue alterado en tránsito. Sin firma válida no hay e-CF. Por eso, antes de registrar la compra o enviar un acuse positivo, conviene validar la firma digital del e-CF y confirmar que corresponde al emisor.

En la práctica hay tres caminos para hacerlo:

• Portal de validación de la DGII. Permite cargar el XML y obtener un veredicto. Es la opción de referencia cuando hay duda y se quiere la respuesta directa de la fuente normativa.
• Validador del PSFE. La mayoría de los PSFE certificados ofrecen un validador integrado, ya sea para los e-CF que pasaron por su propia plataforma o para XMLs cargados manualmente desde fuera. Para una mipyme que ya está operando dentro de un PSFE, suele ser el camino más rápido.
• Librerías de validación XML. Para receptores con integración API o flujos automatizados de procesamiento, librerías técnicas validan la firma como parte del pipeline. Es la opción de quienes procesan volumen y no toman decisiones manuales por cada comprobante.

La validación arroja uno de tres resultados.

Válida. La firma corresponde al certificado vigente del RNC emisor y el contenido del XML no fue modificado desde que se firmó. El comprobante es procesable: se le envía ARECF positivo, se archiva, y entra al registro de compras.

Inválida. La firma no corresponde al certificado del RNC declarado, o el contenido del XML fue modificado después de firmarse. El comprobante NO se registra. La acción correcta es comunicarle al proveedor que el e-CF llegó con firma inválida y pedirle que re-emita.

Expirada. El certificado del emisor estaba vencido al momento de firmar. Es un caso poco frecuente — los PSFE serios alertan a sus clientes antes del vencimiento — pero puede ocurrir y se trata como inválida.

La decisión de negocio para el receptor es directa: solo se registra y se envía acuse de recibo positivo a un e-CF con firma válida. Una firma inválida es, además, una de las cuatro causas oficiales por las que el receptor puede marcar el comprobante como No Recibido en el ARECF, lo cual aterrizamos a continuación.

Acuse de recibo (ARECF): técnico, no comercial

El receptor puede enviar dos respuestas distintas, y confundirlas causa muchos errores: el acuse de recibo es técnico y obligatorio; la aprobación o rechazo comercial trata el contenido del comprobante. Así se maneja en la práctica el acuse de recibo de e-CF en República Dominicana.

Acuse de recibo (ARECF) — la respuesta técnica. Es un mensaje XML que el receptor envía al emisor (a través de su PSFE o a través de la Oficina Virtual) confirmando dos cosas: que recibió el e-CF, y que el comprobante pasó las validaciones técnicas (firma digital válida, datos del receptor correctos, no es un duplicado). El ARECF NO implica que el receptor esté de acuerdo con el contenido comercial — los precios, las cantidades, la descripción de lo facturado. Solo confirma recepción y validación técnica. Es la respuesta obligatoria del flujo.

Los cuatro motivos oficiales de No Recibido. Cuando el e-CF falla alguna de las validaciones técnicas, el receptor envía el ARECF marcando el comprobante como No Recibido y especificando la causa. Formato oficial del Acuse de Recibo (ARECF) publicado por la DGII define exactamente cuatro motivos por los que el receptor puede marcar un e-CF como No Recibido: error de especificación, error de firma digital, envío duplicado, y RNC del comprador no corresponde. Cada uno tiene una guía operativa específica:

• Error de especificación. El XML no cumple con el esquema técnico publicado por la DGII — campos faltantes, estructura mal formada, valores fuera de rango. Pedirle al proveedor que re-emita; el problema es de su PSFE o de la configuración de su sistema.
• Error de firma digital. La firma no valida (caso de la sección anterior). Pedirle al proveedor que re-emita; con frecuencia significa que el certificado del emisor caducó o que hubo un problema en el proceso de firmado.
• Envío duplicado. El mismo e-NCF llegó dos veces al receptor. Esto pasa cuando el PSFE del emisor reintenta un envío que ya había llegado. Se rechaza el segundo y se conserva el primero — registrar el mismo e-CF dos veces sería un error grave en el 606.
• RNC del comprador no corresponde. El e-CF está dirigido a un RNC que no es el del receptor. El proveedor lo emitió contra el RNC equivocado y debe corregir. Es importante: rechazar este e-CF no significa rechazar la operación, significa que la operación se reactivará cuando el proveedor emita un comprobante dirigido al RNC correcto.

Aprobación o rechazo comercial — la respuesta de contenido. Es un mecanismo separado del ARECF, para los casos en que el e-CF es técnicamente válido (firma OK, datos OK, no duplicado) pero el contenido es incorrecto: el precio no corresponde a lo acordado, la descripción no coincide con lo entregado, las cantidades están equivocadas, o las condiciones difieren del contrato comercial. Aquí el receptor tiene dos opciones: aprobar comercialmente — que en muchos flujos no requiere acción explícita, simplemente no rechazar — o rechazar comercialmente, lo que obliga al proveedor a emitir una nota de crédito o un e-CF rectificativo que cancele o ajuste el original.

La regla operativa que cierra esto: el ARECF se envía siempre que llega un e-CF, marcado como Recibido o como No Recibido según las validaciones técnicas. El rechazo comercial es una herramienta distinta, que se usa con criterio cuando hay disputa de contenido, no como sustituto del acuse técnico.

Conservar el XML por 10 años: la obligación operativa para mipymes

La Ley 32-23 obliga al receptor a conservar el XML del e-CF por 10 años, en condiciones que permitan exhibirlo ante una auditoría de DGII. Eso, traducido a la realidad operativa de una mipyme, significa tres cosas concretas: el archivo existe, el archivo es íntegro (no fue modificado después de recibirlo), y se puede recuperar cuando alguien lo pida. Conservar el XML del e-CF por 10 años, como exige la Ley 32-23, no requiere infraestructura corporativa; requiere una rutina que una mipyme pueda cumplir todos los meses.

Una rutina suficiente suele verse así:

• Crear una carpeta por año y mes, por ejemplo eCF/2026/05/.
• Guardar el XML original sin abrirlo y volverlo a guardar en editores que puedan reformatearlo.
• Mantener un segundo respaldo fuera de la cuenta o dispositivo principal, sea otro proveedor de nube o un disco externo.
• Nombrar los archivos con un patrón buscable, por ejemplo RNC_emisor-eNCF.xml.

La regla crítica es preservar el XML bit-exacto al recibido. Si hace falta revisarlo, usa un visor de solo lectura y nunca guardes sobre el archivo original; cambios de saltos de línea, encoding o espacios pueden invalidar la firma digital cuando alguien la verifique más tarde.

Tres métodos para pasar el XML a Excel

Una vez el XML está validado, con el ARECF enviado y el archivo guardado, queda el paso operativo del flujo: convertir esos campos del XML en una fila del registro de compras, en la planilla donde efectivamente se arma el 606. Hay tres métodos en la práctica para convertir XML e-CF a Excel, y la elección depende menos de "cuál es mejor" y más del volumen mensual y de la capacidad técnica disponible. No es una tarea aparte: es el paso donde el XML se convierte en registro de compras.

Método 1 — Captura manual. Abres el XML en el navegador o en un visor de solo lectura, identificas los campos a ojo (e-NCF, RNC del emisor, fecha, monto bruto, ITBIS, neto), y los tipeas en la planilla. Cuándo aplica honestamente: 5 a 10 e-CF al mes, donde el costo de configurar otra cosa supera el costo del tipeo. Cuándo deja de aplicar: en cuanto los errores empiezan a aparecer. Tipear un e-NCF de 13 caracteres a mano produce errores de transcripción que se detectan tarde, normalmente cuando el pre-validador del 606 rechaza el envío y toca rastrear cuál fila está mal. Ese costo de error escalonado es la razón por la que la captura manual deja de tener sentido más rápido de lo que parece.

Método 2 — Macro Excel o Power Query. Power Query, incluido en versiones modernas de Excel, lee XMLs y los convierte en tablas. Con un mapeo configurado una vez (qué nodo del XML va a qué columna), los XMLs siguientes entran en lote y la planilla se puebla automáticamente. Aplica para volumen medio — 30 a 200 e-CF al mes — y receptores con capacidad técnica básica para configurar la consulta inicial o seguir un tutorial. La limitación que aparece en producción: Power Query asume estructura UBL consistente, y cuando un PSFE entrega un XML con variaciones menores de namespace, prefijos distintos o etiquetas opcionales presentes en algunos comprobantes y ausentes en otros, el mapeo configurado falla y hay que ajustarlo. Para una mipyme con suplidores que usan dos o tres PSFE distintos, mantener el mapeo termina consumiendo tiempo del contador.

Método 3 — Extracción automatizada. Entregar los XMLs a un sistema de extracción que los lee, los mapea al schema del registro de compras y devuelve la fila lista para la planilla. La diferencia respecto a la extracción de PDFs es que el XML ya es estructurado — no hace falta OCR, los campos vienen etiquetados — pero se necesita un parser que entienda el UBL adaptado por la DGII y un mapeo al esquema del 606 que funcione independientemente del PSFE de origen. Aplica naturalmente cuando el volumen pasa de 30 e-CF al mes y, sobre todo, cuando el receptor procesa documentos de varios proveedores con PSFE distintos. Para esa realidad, la extracción automática de XMLs e-CF a planillas listas para el 606 absorbe las variaciones entre PSFE en lugar de obligar al receptor a corregirlas manualmente.

En la práctica, se sube el lote de XMLs del período, se describe en lenguaje natural lo que se necesita ("Extraer e-NCF, RNC del emisor, fecha de emisión, monto gravado, monto exento, ITBIS facturado; una fila por e-CF") y la salida llega como Excel, CSV o JSON, sin templates por configurar.

La elección depende del volumen mensual, de cuántos PSFE distintos usan tus proveedores y de cuánto tiempo puede dedicarle tu contador externo.

Mapear los campos del XML al Formato 606

Las columnas del Formato 606 no cambian porque el origen del dato sea un XML en lugar de un PDF — lo que cambia es de dónde se lee cada campo. El pre-validador del 606 de la DGII acepta tanto NCF tradicional (prefijo B, 8 dígitos de secuencia) como e-NCF (prefijo E, 10 dígitos) en la misma fila sin distinción de tratamiento. Mapear el XML del e-CF al Formato 606 consiste, en lo esencial, en leer las etiquetas correctas y volcarlas en el orden que espera la planilla del 606.

La tabla de mapeo, en su forma mínima:

Campo del XML e-CF	Columna del Formato 606
Encabezado/eNCF	NCF (Número de Comprobante Fiscal)
Encabezado/Emisor/RNCEmisor	RNC o Cédula del proveedor
Encabezado/FechaEmision	Fecha del Comprobante
Totales/MontoGravadoTotal	Monto Facturado en Bienes o en Servicios
Totales/MontoExento	Monto Exento
Totales/MontoITBISTotal	ITBIS Facturado
Totales/MontoISCTotal (si aplica)	ISC
Retenciones declaradas (si aplica)	Columnas de Retención de ITBIS / ISR
Fecha de pago (registro interno del receptor)	Fecha de Pago

La columna específica para el monto facturado depende de la naturaleza de la operación: bienes o servicios, según la clasificación que aplica al proveedor y al tipo de transacción. Esa decisión la hace el receptor según el detalle de líneas del XML — no la decide el XML por él. Cuando una factura mezcla bienes y servicios, suele convenir capturar dos filas en el 606 (una por cada naturaleza) en lugar de una fila combinada.

Sobre la diferencia operativa B → E. El prefijo del NCF cambia (de B a E) y la secuencia se extiende (de 8 a 10 dígitos). Esto cambia el aspecto visual de la fila pero no su tratamiento en el 606 ni en el pre-validador. Una fila con NCF tradicional y una fila con e-NCF pueden convivir en el mismo archivo de 606, lo que es lo habitual durante la transición — proveedores Grandes ya emiten e-CF, proveedores en cohortes posteriores todavía emiten en papel o PDF, y todos terminan en el mismo 606 del período.

Un caso que vale la pena nombrar aparte: cuando una factura mezcla productos exentos de ITBIS con productos gravados — escenario típico en construcción, donde los materiales tienen tratamientos distintos según el régimen y el producto — el receptor lee por línea, no solo los totales. La detección de qué líneas son exentas y qué líneas son gravadas determina cómo se reparte el monto entre las columnas del 606. Si trabajas con facturas de materiales, la guía sobre cómo separar líneas exentas y gravadas de ITBIS en facturas de materiales de construcción cubre el tratamiento contable del caso con la profundidad que aquí no toca.

Una vez la fila tiene los campos correctos del XML, el resto del armado del 606 — cruces con el 607, retenciones y envío por la Oficina Virtual — lo cubre cómo armar el Formato 606 desde las facturas de proveedores.

Cuando el e-CF no llegó: diagnóstico y caminos adyacentes

El caso operativo que más reaparece: el proveedor dice que envió el e-CF y el receptor no lo encuentra. Antes de asumir que hubo un fallo del PSFE o de DGII, conviene chequear tres lugares; casi siempre se resuelve en uno de ellos.

1. Carpeta de spam o promociones del correo del receptor. Es el primer lugar a mirar y el de mayor probabilidad. Los correos automáticos de PSFE caen ahí con frecuencia, sobre todo cuando es la primera vez que ese remitente le escribe a tu cuenta. Si lo encuentras allí, márcalo como "no es spam" y configura una regla de filtrado por dominio del PSFE para que los siguientes lleguen directo a la bandeja principal.

2. Sección Comprobantes Electrónicos Recibidos en la Oficina Virtual DGII. Si el e-CF se emitió correctamente, figura en la OFV independientemente de si el correo llegó. Es el respaldo cuando el Canal 1 falla por cualquier razón — filtro del correo, error de configuración del PSFE en el correo destino, problema temporal del servidor de email. Si el comprobante figura en la OFV, ahí lo descargas directamente.

3. Pedirle al proveedor el comprobante de envío del PSFE. El PSFE del emisor genera un acuse de envío con TrackId que prueba que el comprobante salió. Si el proveedor puede mostrarte ese TrackId pero el comprobante no figura en la OFV, hay un problema entre el PSFE y la DGII que el proveedor tiene que resolver. Si el proveedor no puede mostrar TrackId, el e-CF no se emitió y debe re-emitirse.

Si después de los tres puntos el e-CF realmente no llegó y no se emitió, el camino correcto es que el proveedor re-emita. El receptor no puede generar el e-CF por su cuenta; la idea de que "yo le hago el comprobante por él" pertenece a un caso distinto — los comprobantes de compras E41 (o B11 en el régimen tradicional) — y aplica solo cuando el proveedor no tiene RNC formal, no cuando hay un proveedor RNC que falló en su emisión.

Caminos adyacentes según tu realidad. Tres situaciones que el receptor encuentra con frecuencia y que tienen su propio flujo:

• Si el proveedor te entrega facturas en PDF (porque está en una fase del calendario que aún no le aplica como emisor obligatorio, o porque está en transición y todavía no migró), procesarlas a Excel sigue otro flujo paralelo a este. La guía sobre cómo extraer facturas dominicanas en PDF a Excel para el registro de compras cubre el caso desde el lado del PDF.

• Si el proveedor no tiene RNC — suplidores informales, prestadores ocasionales, individuos no registrados — el comprobante no lo emite el proveedor, lo emite el receptor. El procedimiento para emitir un Comprobante de Compras B11/E41 cuando el proveedor no tiene RNC trata ese caso con su propia disciplina.

• Y para mañana mismo: revisa la carpeta de spam o promociones de tu correo del último mes con el filtro "PSFE", "e-CF" o el RNC de tus proveedores grandes. Si llevas semanas sin recibir comprobantes que esperabas, lo más probable es que estén ahí.