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.

Esta es la guía para la mipyme dominicana cuyo proveedor de cemento, ferretería o repuestos le acaba de mandar por correo un archivo .xml con un nombre raro y la palabra "e-CF" en el asunto, y que necesita saber qué hacer con eso antes de que llegue la fecha de subir el 606. Recibir el e-CF XML del proveedor y pasarlo a Excel y al 606 es la disciplina práctica que hoy todo dueño de mipyme y todo contador externo está aprendiendo bajo presión de calendario.

El calendario de la Ley 32-23 ya entró a tres cohortes. Los Grandes Contribuyentes Nacionales emiten e-CF desde el 15 de mayo de 2024. Los Grandes Contribuyentes Locales y Medianos desde el 15 de mayo de 2025, con prórrogas a noviembre de 2026 para casos específicos. La última cohorte — Pequeños, Micro y No Clasificados — comienza a emitir el 15 de mayo de 2026. La implicación para el receptor es directa: tú recibes lo que tu proveedor está obligado a emitir, independientemente de tu propia fase como emisor. Si tu suplidor de cemento es Grande Nacional, hace dos años que sus facturas son e-CF, y los XMLs ya están llegando a tu correo; el hecho de que tú apenas estés entrando como emisora no cambia tu posición como receptora.

Hay una regla central que ordena todo lo que sigue: el XML es el documento fiscal. La representación impresa que muchos PSFE adjuntan al correo (el PDF que parece una factura tradicional) es solo una vista visual del comprobante para revisión humana. Para auditoría DGII, para soportar la deducción de ITBIS, y para el archivo de 10 años, el archivo que importa es el .xml. Esa es la razón por la que el flujo del receptor existe como disciplina aparte — no es un upgrade visual de la factura impresa, es un tipo de documento distinto, con firma digital, con estructura de campos legible por máquina, y con responsabilidades del receptor que no existían en el régimen tradicional.

Lo que sigue cubre el flujo de principio a fin: los tres canales por los que el e-CF puede llegar, qué bloques del XML lee un practicante, cómo se valida la firma, cuándo se envía el ARECF y cuándo el rechazo comercial, qué archivar y por cuánto tiempo, las tres formas de pasar los campos del XML a la planilla, y el mapeo campo-por-campo al 606.

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 nada en el registro de compras y antes de enviar acuse de recibo positivo, conviene validar la firma digital e-CF 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 le envía al emisor dos tipos de respuesta diferentes, y conflarlas es la fuente más común de errores en este flujo. El acuse de recibo es técnico y obligatorio; la aprobación o rechazo comercial es un mecanismo separado, opcional, que trata el contenido del comprobante. Saber cuál enviar y cuándo es lo que distingue al receptor que opera el flujo correctamente del que acumula confusiones que aparecen meses después en una auditoría. Esta es la disciplina del acuse de recibo e-CF República Dominicana en la práctica.

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.

Representación impresa vs XML: cuál es el documento fiscal

Lo digo directo: el XML es el comprobante. El PDF de representación impresa es solo eso, una representación visual del XML pensada para revisión humana. Para auditoría DGII y para el archivo de 10 años, lo que importa es el XML. La distinción de representación impresa vs XML e-CF parece sutil cuando uno mira los dos archivos lado a lado — el PDF se ve como una factura tradicional, con e-NCF, RNC, totales y todo prolijo — pero la asimetría legal es total: el .xml carga la firma digital validable; el .pdf carga su apariencia.

¿Para qué sirve la representación impresa, entonces? Sirve para varias cosas legítimas: revisión visual rápida cuando llega un comprobante y queremos confirmar a ojo que los totales corresponden a lo esperado; comparación contra orden de compra o albarán de entrega en un proceso de aprobación interno; entrega física al cliente final cuando hace falta soporte impreso; uso en flujos de aprobación donde varias personas ven el documento antes de pagarlo. Es útil. No es el documento fiscal.

La implicación práctica para el receptor es clara. Si el proveedor te mandó solo el PDF y no el XML, el comprobante todavía no te ha llegado a efectos fiscales — el archivo que respalda la deducción de ITBIS y la entrada al 606 es el .xml, no el .pdf. Hay que pedirle al proveedor el XML. Una aclaración paralela que confunde a más de uno: el e-NCF que aparece impreso en el PDF se ve idéntico al e-NCF dentro del XML, y eso da la sensación de que tener el PDF basta. No basta. La firma digital validable, la que prueba autenticidad ante la DGII, vive solo en el archivo .xml.

La práctica común y razonable es archivar XML y PDF juntos por comprobante, con el mismo nombre y distinta extensión. El PDF acelera la revisión visual del día a día; el XML cumple la obligación legal y es el que se entrega en una eventual auditoría.

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 XML e-CF 10 años Ley 32-23 no requiere infraestructura corporativa; requiere una rutina disciplinada que cualquiera con Drive o un disco externo puede mantener.

Estrategia 1 — Respaldo en nube. Una carpeta dedicada en Google Drive, Dropbox, OneDrive o equivalente, organizada por año y mes — estructura tipo eCF/2026/05/ — funciona bien para volúmenes mipyme. La nube agrega redundancia automática y acceso desde cualquier lugar a un costo bajo o cero hasta cierto volumen. Vale la pena tener un respaldo cruzado (un segundo proveedor de nube o una sincronización local) para no quedar sujeto a un solo proveedor en caso de pérdida de cuenta o terminación de servicio.

Estrategia 2 — Respaldo local con disco duro externo. Para receptores que prefieren control físico o tienen restricciones de subida a la nube. Misma estructura de carpetas por año y mes; rotación periódica del disco para refrescarlo; idealmente dos discos alternados, uno guardado fuera del local de trabajo, para que un evento físico (robo, incendio, daño de hardware) no se lleve la única copia.

Estrategia 3 — Doble respaldo. Combinar nube y disco externo es lo que reduce el riesgo a casi cero. Para una mipyme que recibe entre 50 y 500 e-CF al mes, el costo total de una solución dual es despreciable comparado con el costo de no poder exhibir un comprobante en una fiscalización.

Una nota crítica sobre la integridad del archivo: el XML guardado debe ser bit-exacto al recibido. No abrir-y-guardar el XML en editores que reformatean. Algunos editores reescriben los saltos de línea, cambian el encoding del archivo o normalizan espacios al guardar; cualquiera de esas modificaciones invalida la firma digital cuando alguien la verifique más tarde. Si hace falta abrir el XML para revisar, usar un visor de solo lectura (un navegador con la extensión apropiada, o un editor configurado en modo lectura) y nunca guardar sobre el archivo original.

Un detalle operativo que se agradece cuando llega una solicitud de auditoría: nombrar los archivos con un patrón que permita ubicarlos rápido, por ejemplo RNC_emisor-eNCF.xml. Esa convención, aplicada de manera consistente desde el primer e-CF que se recibe, ahorra horas de búsqueda cuando hay que producir un comprobante específico de hace tres años.

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. Esto sigue siendo parte del mismo trabajo de qué hacer cuando recibes un e-CF de tu proveedor.

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 — típicamente cuando el pre-validador del 606 rechaza la submission y toca rastrear cuál fila tiene el error. 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 entre los tres métodos no es ideológica. Es una función del volumen mensual, la heterogeneidad de los PSFE de tus proveedores, y cuánto vale tu tiempo o el de 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 XML e-CF al Formato 606 es, en lo esencial, leer las etiquetas correctas del XML y volcarlas en el orden que la planilla del 606 espera.

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 está poblada con los campos correctos del XML, el resto del armado del 606 — validaciones cruzadas con el 607, retenciones, formato de submission a la Oficina Virtual — es lo que cubre cómo armar el Formato 606 desde las facturas de proveedores, que es el siguiente eslabón natural del flujo.

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 puntos en orden — el patrón "e-CF no llegó proveedor dice que lo envió" se resuelve casi siempre en uno de los tres.

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í.