Procesamiento de Facturas CFDI Mexicanas
Más de 50 XML de 14 Proveedores, una Hoja de AP Limpia
Un solo XML CFDI 4.0 de un proveedor mexicano es, estructuralmente, un problema resuelto. El esquema del Anexo 20 valida más de 100 campos antes de que el PAC (Proveedor Autorizado de Certificación) aplique el timbre fiscal digital. El XML que llega a tu bandeja de AP ya pasó la validación del SAT. La calidad de los datos de un solo CFDI es casi perfecta. El problema de lotes en cuentas por pagar mexicanas no es la precisión en la captura de datos — es lo que sucede cuando 50 XML validados de 14 proveedores, con diferentes registros RFC, diferentes valores de Método de Pago y diferentes tipos de CFDI, deben fusionarse en una sola hoja de cálculo que tu ERP pueda consumir antes de la fecha límite de presentación del DIOT el día 17. En 2025, el SAT rechazó más de 8 millones de facturas por errores a nivel de campo. Cada rechazo que se filtra a tu cola de AP — un código de Uso CFDI incorrecto, un RFC no coincidente en el bloque del receptor, una factura PPD sin un Complemento de Pago correspondiente — crea una obligación fiscal. Si te equivocas, el gasto se vuelve no deducible, exponiendo a tu empresa a hasta un 36% en impuestos y multas sobre el valor de la factura.
Puntos Clave
- Procesar 50 XML CFDI manualmente toma 2.5 horas de captura de datos — pero esa es la parte barata, porque el resultado no contiene ninguno de los campos necesarios para la conciliación.
- Sin UUID, Método de Pago y Uso CFDI en tu hoja de cálculo, cotejar 18 facturas PPD con sus complementos de pago toma otras 3–4 horas de referencias cruzadas manuales cada fin de mes.
- ImageToTable.ai extrae por lotes todos los campos críticos para la conciliación — UUID, Método de Pago, Uso CFDI, Exportación — en un solo resultado, eliminando la pasada de conciliación que los flujos de trabajo manuales nunca pueden saltarse.
Cuando 50 XML de CFDI Llegan a Fin de Mes — La Diferencia Entre "Cada XML es Válido" y "El Lote está Limpio"
El sistema de CFDI en México opera bajo un modelo de validación tripartita: el proveedor genera un XML conforme al Anexo 20, un PAC certificado lo valida y lo timbra con un UUID (el Folio Fiscal de 36 caracteres), y el SAT lo recibe en tiempo real. Cuando un CFDI llega a tu departamento de cuentas por pagar como receptor, el XML ya está certificado. Esto es diferente a las facturas en papel o las facturas de proveedores solo en PDF en la mayoría de otros países, y crea una primera impresión engañosa.
Debido a que cada XML es individualmente válido, los equipos de cuentas por pagar asumen que el lote también estará limpio. No es así. Surgen cinco problemas estructurales cuando reúnes 50+ XML de CFDI de múltiples proveedores e intentas consolidarlos en una sola hoja de cálculo de cuentas por pagar:
Mezcla de PUE y PPD. Las facturas de CFDI llevan un campo Método de Pago que divide todo tu lote en dos procesos fundamentalmente diferentes. Las facturas PUE (Pago en una sola exhibición) son completas por sí mismas: la factura es el registro fiscal final. Las facturas PPD (Pago en parcialidades o diferido) están incompletas hasta que llegue un CFDI de Pago correspondiente con un Complemento de Pago. En un lote de 50 XML de proveedores, podrías tener 32 PUE y 18 PPD. Las PPD no se pueden contabilizar hasta que se reciba y verifique el complemento de pago contra el UUID de la factura original. Si tu hoja de cálculo de cuentas por pagar las trata a todas como partidas equivalentes, contabilizarás 18 transacciones que aún no son deducibles para efectos del IVA.
Fragmentación del Uso CFDI. Cada CFDI lleva un código Uso CFDI obligatorio, un valor del catálogo del SAT que determina cómo el receptor (tu empresa) aplicará la factura para fines fiscales. G01 (adquisición de mercancías general), G03 (gasto en general) y D01 (adquisición deducible para operaciones específicas) son comunes en un lote de proveedores, pero desencadenan diferentes tratamientos fiscales, diferentes categorías de reporte DIOT y diferentes reglas de acreditamiento del IVA. Una hoja de cálculo que agrupa todos los CFDI en una sola columna de "Impuesto" sin el código Uso CFDI es inútil para presentar la DIOT, la declaración mensual de compras de IVA que vence el día 17.
Fallo en la deduplicación basada en UUID. La mayoría de los sistemas de cuentas por pagar deduplican por nombre de proveedor + número de factura. En CFDI, el número de factura (Folio) solo es único dentro de una Serie de un solo proveedor, e incluso así, un proveedor podría agregar un nuevo UUID después de cancelar y reemitir una factura corregida. El identificador único real es el Folio Fiscal (UUID) de 36 caracteres asignado por el PAC durante el timbrado. Sin extraer el UUID de cada XML, dos CFDI diferentes de diferentes proveedores con el mismo valor de Folio se marcarán como duplicados, o un CFDI de reemplazo corregido no se reconocerá como sustituto del original.
Retraso en la conciliación del Complemento de Pago. Para las facturas PPD, el comprobante de pago (CFDI Tipo Pago con Complemento de Pago) llega por separado, a veces días o semanas después de la factura de Ingreso original. Hace referencia al UUID de la factura original, registra el monto del pago, la fecha y el método, y debe cotejarse con la partida abierta de cuentas por pagar. En un flujo de trabajo manual, cotejar 18 facturas PPD con su respectivo Complemento de Pago en un lote de más de 50 documentos es un ejercicio de conciliación que puede llevar horas, y una sola omisión deja un gasto no deducible en tu contabilidad.
Variaciones del RFC en el bloque del receptor. CFDI 4.0 exige el RFC exacto en el nodo del receptor (tu empresa). Sin embargo, algunos proveedores —especialmente pequeños o productores agrícolas— emiten CFDIs con el RFC genérico XAXX010101000 cuando no tienen tus datos fiscales completos. Otros envían facturas al RFC de tu subsidiaria mientras tu sistema de cuentas por pagar espera el RFC de la matriz. Estas discrepancias se marcan a nivel SAT: el CFDI existe, está certificado, pero el RFC del receptor no coincide con tu RFC registrado, lo que puede negar el acreditamiento del IVA durante una auditoría.
Estos cinco problemas no ocurren en un solo CFDI. En 50, los cinco se activan simultáneamente — y resolverlos es lo que separa un flujo de cierre mensual de "abrir cada XML, copiar los campos, pasar al siguiente."
PUE vs PPD en Lote — Por Qué un Solo Campo Divide Todo tu Proceso de Cierre Mensual
En el sistema CFDI de México, el Método de Pago no es una conveniencia de reporte. Es una clasificación fiscal que determina si una factura se puede deducir de inmediato o solo después de presentar un comprobante de pago coincidente. Según la Resolución Miscelánea Fiscal (RMF), las facturas PUE son deducibles al momento de su emisión. Las facturas PPD se vuelven deducibles solo cuando se emite el Complemento de Pago y se registra el evento de pago ante el SAT.
Para el procesamiento por lotes, este binario crea una bifurcación práctica en tu flujo de trabajo:
| Atributo | PUE (Pago en una sola exhibición) | PPD (Pago en parcialidades o diferido) |
|---|---|---|
| Número de CFDIs por transacción | Uno — la factura de Ingreso es completa | Dos mínimo — la factura de Ingreso + un CFDI de Pago por cada parcialidad |
| Deducible para IVA | Inmediatamente al recibirla | Solo después de emitir el Complemento de Pago |
| Regla de procesamiento por lotes | Extraer y contabilizar directamente | Extraer, mantener en espera, cotejar con el complemento de pago antes de contabilizar |
| Reporte DIOT | Reportado en el mes de la fecha del CFDI | Reportado en el mes de cada pago, por RFC del proveedor |
| Uso común del proveedor | Proveedores pequeños, compras esporádicas, servicios únicos | Proveedores recurrentes con plazos de pago, contratos a plazos, grandes distribuidores |
La implicación para el procesamiento por lotes: antes de ejecutar cualquier extracción, primero debes clasificar los XML de CFDI por Método de Pago. El lote PUE puede ir directamente a extracción y contabilización. El lote PPD necesita una segunda pasada — cada Ingreso debe cotejarse con su CFDI de Pago correspondiente antes de ingresar al libro mayor. Si no divides el lote desde el principio, tendrás 18 transacciones contabilizadas que aún no están fiscalmente completas, y tu DIOT discrepará con tu libro mayor de cuentas por pagar.
Para los equipos de cuentas por pagar que procesan 50+ XML de CFDI al cierre de mes, clasificar por Método de Pago —y mantener una lista actualizada de UUIDs de PPD no conciliados— es el paso de preprocesamiento más importante. También es el que más frecuentemente se omite, porque la mayoría de las herramientas de procesamiento por lotes tratan todas las facturas como equivalentes.
Ordenamiento por Uso CFDI — Por qué G01, G03 y D01 no pueden compartir la misma conciliación
El catálogo de Uso CFDI (c_UsoCFDI) es una lista de códigos mantenida por el SAT que el receptor — tu empresa — debe asignar correctamente en cada CFDI recibido. No es decisión del proveedor; es tu declaración de cómo se tratará el gasto. Los tres códigos más comunes en un lote de proveedores:
| Código | Significado | Tratamiento Fiscal | Tipo de Proveedor Típico |
|---|---|---|---|
| G01 | Adquisición de mercancías | IVA acreditable, reportado en DIOT por RFC del proveedor | Proveedores de inventario, materias primas, mayoristas |
| G03 | Gastos en general | IVA acreditable, pero con reglas de deducibilidad distintas según si el gasto es estrictamente indispensable (Art. 27 LISR) | Prestadores de servicios, servicios públicos, honorarios profesionales, papelería |
| D01 | Deducciones | IVA acreditable para operaciones específicas — aplicado a insumos de manufactura exportadora o I+D | Proveedores industriales especializados, equipos |
Los CFDI G01, G03 y D01 fluyen a diferentes renglones de la DIOT — la declaración mensual de IVA de compras en México, vence el día 17 de cada mes y ahora se presenta completamente en línea a través de la plataforma web del SAT. Si tu extracción por lotes trata los tres códigos como una sola columna "Impuesto", quien prepara la DIOT debe reordenar manualmente los datos extraídos por Uso CFDI antes de presentar. Eso es una pasada extra sobre 50+ filas.
La solución es simple: extrae el código de Uso CFDI como una columna dedicada en tu salida por lotes. Así tu hoja de cálculo de cuentas por pagar se puede ordenar, pivotar o filtrar por código antes de presentar la DIOT — y tu conciliación de fin de mes puede validar que cada línea G01 del lote coincida con un RFC de proveedor en la sección G01 de la DIOT, cada G03 en su sección respectiva, y así sucesivamente. Una extracción de dos columnas (Monto + Impuesto) es un lote roto. Una extracción de múltiples columnas que conserva Uso CFDI, UUID, Método de Pago y RFC del proveedor es un ciclo cerrado.
Desduplicación por UUID — Por qué el Folio Fiscal, y no el Folio, es tu verdadero número de factura
Cada XML de CFDI lleva dos identificadores que parecen similares pero cumplen propósitos muy distintos: el Folio (número de factura asignado por la secuencia propia del proveedor) y el UUID (el Folio Fiscal de 36 caracteres asignado por el PAC al timbrarse). Para la desduplicación en cuentas por pagar, el Folio no es confiable. El UUID es la única clave de confianza.
Tres modos de fallo en desduplicación específicos del procesamiento por lotes de CFDI:
Colisión de Folios entre proveedores. El proveedor A emite el Folio #1523 en la Serie A. El proveedor B también emite el Folio #1523 en la Serie F. Si tu sistema de cuentas por pagar desduplica solo por nombre de proveedor + Folio, ambos se reconocen como únicos — pero si el mismo proveedor retransmite el mismo CFDI tras una corrección, el sistema no lo detectará como duplicado porque el UUID cambió mientras el Folio se mantuvo igual. Necesitas desduplicación a nivel de UUID.
Corrección mediante sustitución de CFDI. Según las reglas de cancelación del SAT, un proveedor puede cancelar un CFDI con Motivo 01 ("factura emitida con errores que contiene datos incorrectos") y reemitir una versión corregida con un nuevo UUID. El UUID anterior se invalida, pero un sistema que desduplica por Folio verá el mismo Folio tanto en el XML cancelado como en el corregido — y podría marcar la versión corregida como duplicada, suprimiendo la factura válida.
Reenvío en un ciclo de lote diferente. Los proveedores ocasionalmente reenvían XML que ya procesaste — especialmente si usan entrega por correo electrónico por lotes al cierre de mes. Sin desduplicación basada en UUID, el mismo CFDI llega en dos lotes consecutivos de fin de mes y se contabiliza dos veces.
Para cuentas por pagar por lotes, la salida de extracción debe incluir el UUID como columna dedicada. Antes de contabilizar cualquier línea en el libro mayor, verifica el UUID contra tu historial de transacciones. Un recuento de UUID distintos que coincida con el número de XML en el lote es una verificación rápida de integridad — si 50 archivos producen 47 UUID distintos, tienes 3 duplicados que investigar antes de contabilizar.
El problema del Complemento de Pago: cuando la factura dice PPD y el recibo de pago llega días después
El Complemento de Pago es el mecanismo que completa la vida fiscal de una factura PPD. Cuando un proveedor emite un Ingreso CFDI con Método de Pago = PPD, la transacción no se cierra fiscalmente hasta que llega un Pago CFDI independiente, que contiene un Complemento de Pago que hace referencia al UUID de la factura original.
Para los equipos de AP, el Complemento de Pago crea un problema de conciliación de dos documentos que se agrava a escala de lote:
Desfase temporal. El Ingreso llega durante el mes. El Pago CFDI con el complemento de pago llega días o semanas después, a menudo en un período contable diferente. Su lote al cierre del mes puede contener 35 Ingresos PPD CFDI y solo 28 Pagos CFDI coincidentes. Los 7 no coincidentes no se pueden cerrar. Si los contabiliza de todos modos, el gasto no es deducible para el IVA, y la conciliación algorítmica del SAT marcará la discrepancia.
Seguimiento de parcialidades. Cuando un pago a proveedor se realiza en plazos, cada pago parcial genera su propio Pago CFDI. Un Ingreso de $100,000 MXN pagado en tres plazos produce tres Pagos CFDI, cada uno referenciando el mismo UUID original pero registrando un monto y fecha de pago diferentes. Su hoja de cálculo de AP debe rastrear el estado del pago a nivel de plazo, no de factura, porque el crédito de IVA se vuelve disponible de forma incremental a medida que se emite cada Complemento de Pago.
Conciliación entre lotes. En la práctica, el Complemento de Pago rara vez llega en el mismo lote que el Ingreso original. El cierre de AP a fin de mes requiere extraer la lista de UUIDs PPD abiertos del lote del mes anterior, cotejarlos con los Pagos CFDI recién recibidos y luego cerrar los pares coincidentes. Este es un trabajo de conciliación manual que escala linealmente con el tamaño del lote: 35 elementos PPD abiertos = 35 búsquedas manuales, cada una requiere encontrar el XML de Pago, extraer los campos del complemento y verificar que los montos coincidan.
Si su herramienta de extracción de lotes puede cotejar UUIDs de CFDI entre lotes, emparejando automáticamente los complementos de pago con sus facturas de Ingreso originales, reemplaza 35 búsquedas manuales con un único resultado consolidado. El problema del Complemento de Pago no es un problema de complejidad del CFDI. Es un problema de automatización de conciliación, y es la mejora de mayor apalancamiento que puede hacer en un flujo de trabajo de lotes de AP mexicano.
Variaciones del Formato RFC — Por Qué XAXX010101000 Rompe tu Búsqueda de Proveedores
El CFDI 4.0 endureció significativamente los requisitos de identificación del receptor en comparación con la versión 3.3. Bajo CFDI 4.0, el nodo del receptor debe contener el RFC exacto, nombre legal, código postal (DomicilioFiscalReceptor) y régimen fiscal (RegimenFiscalReceptor), todo prevalidado contra la base de datos de contribuyentes del SAT antes de que el PAC aplique el timbre. Esto se diseñó para eliminar el problema del "fantasma fiscal", donde se emitían facturas a contribuyentes inexistentes o no coincidentes.
Para el procesamiento por lotes de AP, la consecuencia práctica es que un lote de 50 XML de CFDI de proveedores no tendrá un RFC de receptor uniforme, incluso si todos están dirigidos a tu empresa:
| Patrón RFC | Significado | Regla de Gestión del Lote |
|---|---|---|
| XAXX010101000 | RFC genérico para receptor extranjero no identificado. Se usa cuando el proveedor carece de tus datos fiscales completos | CFDI válido pero IVA no acreditable. Marcar y solicitar reemisión con tu RFC correcto |
| XEXX010101000 | RFC genérico para receptor extranjero no identificado con RFC en el país emisor | Igual que arriba — sin crédito de IVA. Requiere corrección del proveedor |
| RFC de Filial | RFC de tu filial cuando tu sistema de AP espera el de la matriz | CFDI válido para la filial. Puede requerir transferencia intercompañía o RFC de receptor corregido según estructura del ERP |
| Tu RFC correcto | Coincide y es válido | Procesar normalmente |
En un lote de 50 XML de CFDI de proveedores, especialmente de proveedores pequeños (productores agrícolas, distribuidores rurales, prestadores de servicios independientes), el 5–10% llevará un RFC genérico o no coincidente. Estos CFDI están certificados y son técnicamente válidos — el SAT los aceptó — pero tu empresa no puede reclamar el crédito de IVA sobre ellos. La salida del lote debe marcar estos por separado, y el equipo de AP debe dar seguimiento con el proveedor para reemitir el CFDI con el RFC de receptor correcto antes de que cierre la ventana de presentación de la DIOT de fin de mes.
Validación de campos CFDI 4.0 en lote — Lo que el SAT rechaza antes de que su equipo lo vea
El CFDI 4.0, obligatorio desde el 1 de abril de 2023, introdujo validaciones de campo más estrictas y nuevos campos obligatorios. Para los equipos de AP que reciben lotes de XML, los cambios relevantes son:
RegimenFiscalReceptor ahora es obligatorio. En CFDI 3.3, el régimen fiscal del receptor era opcional. En 4.0, todo CFDI debe incluir el código de Régimen Fiscal del receptor (del catálogo SAT c_RegimenFiscal). Si su empresa opera bajo múltiples regímenes — por ejemplo, Régimen General de Ley Personas Morales (código 601) para operaciones principales y Régimen de Actividades Empresariales con ingresos a través de plataformas tecnológicas (código 625) para una línea de negocio separada — los CFDIs en su lote deben reflejar bajo qué régimen cae cada transacción. Un desajuste entre el RegimenFiscalReceptor de la factura y su régimen registrado crea una exposición fiscal.
Validación cruzada RFC + Nombre. CFDI 4.0 pre-valida el RFC del receptor contra el nombre legal registrado en la base de datos del SAT. Si un proveedor ingresa su RFC correcto pero un nombre legal ligeramente incorrecto (ej., "SA de CV" en lugar de "S.A. de C.V."), el PAC rechaza el CFDI antes del timbrado. Esto significa que los XMLs CFDI 4.0 que llegan a su bandeja son estructuralmente más confiables — pero la contraparte es que los errores en la emisión tienen más probabilidad de resultar en un rechazo total en lugar de una factura defectuosa pero timbrada. El lote que procesa es más limpio pero más pequeño: algunos proveedores habrán tenido sus facturas rechazadas y quizás aún no las hayan reemitido.
Campo Exportación. CFDI 4.0 introdujo un campo Exportación obligatorio (c_Exportacion) — valores 01 (no sujeto a exportación), 02 (exportación definitiva, A1), 03 (exportación definitiva, A2) o 04 (exportación temporal). Para empresas que exportan bienes, un lote de CFDIs de proveedores contendrá facturas tanto con Exportación=01 como Exportación=02/03. Los CFDIs 02/03 tienen un tratamiento de IVA diferente (IVA al 0% en ventas de exportación) y a menudo incluyen el Complemento de Comercio Exterior (Complemento de Comercio Exterior 2.0, obligatorio desde enero de 2024). Estas facturas con marcación de exportación deben segregarse de las facturas nacionales en la salida del lote porque la declaración DIOT separa las compras nacionales de las relacionadas con exportación.
Para el validador de lotes, un escaneo rápido de pre-extracción puede generar señales útiles: contar los valores distintos de RegimenFiscalReceptor (más de 1 = posible desajuste de régimen), verificar la distribución del campo Exportación (lote mixto nacional/exportación) y contar los RFC de receptores distintos (RFC genéricos marcados). Un pre-vuelo de 3 segundos en un lote de 50 XMLs ahorra media hora de clasificación posterior.
Límites de descarga masiva del portal SAT — Lo que puedes (y no) obtener del Buzón Tributario
Una limitación práctica que condiciona el flujo de trabajo de cuentas por pagar en México: el portal SAT permite a los contribuyentes descargar sus CFDIs recibidos a través del Buzón Tributario, pero con límites que importan a escala. La descarga masiva del portal suele tener un tope de 500,000 registros por solicitud — muy por encima de lo que necesita un equipo de AP de mercado medio — pero la interfaz web impone una restricción práctica: las sesiones de descarga manual expiran, y navegar mes a mes entre CFDIs recibidos para seleccionar XMLs individuales no es más rápido que solicitarlos directamente a los proveedores.
Para equipos de AP que procesan de 50 a 200 XML de CFDI al mes, el cuello de botella más común no son los límites de descarga del SAT, sino la consistencia en la entrega de los proveedores. Los proveedores grandes que usan PACs como CONTPAQi (#1 en México) o EDICOM suelen entregar automáticamente los XML certificados al comprador. Los proveedores pequeños que usan herramientas gratuitas del SAT o PACs de bajo costo pueden generar el CFDI sin entrega automática al receptor — lo que significa que la versión PDF (con código QR para verificación SAT) llega a tu equipo de AP, mientras que el XML debe solicitarse por separado.
El flujo de trabajo por lotes para CFDIs esporádicos o de proveedores pequeños donde falta el XML implica dos enfoques prácticos: solicitar el XML al proveedor (lo que añade de 1 a 3 días hábiles al cierre de mes) o usar la versión PDF con una herramienta de extracción de datos que pueda leer datos de facturas desde PDFs e imágenes — extrayendo los mismos campos en las mismas columnas junto con los XMLs que sí tienes. Esta consolidación de fuentes mixtas es donde el procesamiento por lotes pasa de "ejecutar un parser de XML 50 veces" a un flujo de trabajo operativo real.
De 50 XML de CFDI a una hoja de cálculo de AP — Un flujo de cierre de mes
Aquí tienes un flujo de trabajo por lotes que considera los desafíos estructurales descritos. Está diseñado para un analista de AP al cierre de mes, con 50+ XML de CFDI de 14 proveedores y una fecha límite de importación a CONTPAQi o Aspel-COI al día 3 después del cierre.
Clasificar por Método de Pago
Abre la carpeta del lote. Ejecuta un escaneo rápido de atributos XML en cada archivo y clasifícalos en dos montones: PUE y PPD. El montón PUE está listo para extracción y contabilización inmediatas. El montón PPD va a una cola de espera — cada uno necesita un Complemento de Pago correspondiente antes de ingresar al libro mayor.
Validar RFC del receptor y marcar genéricos
Escanea el nodo RFC del receptor en cada XML. Cualquier entrada XAXX010101000 o XEXX010101000 se marca para seguimiento con el proveedor — estos CFDIs no generarán IVA acreditable. Cualquier RFC de subsidiaria que no coincida con el RFC fiscal principal de la empresa se marca para gestión intercompañía.
Extraer lote PUE con conjunto completo de campos CFDI
Procesa los XML PUE mediante extracción. Las columnas de salida deben incluir: UUID (36 caracteres), RFC Emisor, Nombre Emisor, Folio + Serie, Fecha (ISO), SubTotal, tasa y monto de IVA, Total, Método de Pago (PUE confirmado), Uso CFDI, Exportación, Moneda. Esta no es una extracción mínima — cada columna tiene un propósito posterior en la declaración DIOT, el cálculo del IVA acreditable o la pista de auditoría. Una herramienta de extracción por lotes que maneje fuentes XML puede analizar estos datos directamente de la estructura CFDI, en lugar de depender del OCR visual de la representación PDF.
Cotejar lote PPD contra Complemento de Pago
Para cada Ingreso PPD, busca en los CFDIs de Pago recibidos un nodo Complemento de Pago que haga referencia al UUID original. Empareja por UUID, verifica el monto del pago en el complemento contra el saldo pendiente y confirma la fecha de pago. Cuando coincida, extrae el valor de Método de Pago del CFDI de Pago (el método de pago real: transferencia, cheque, efectivo, etc.) y la fecha de pago como columnas separadas. Un Ingreso PPD no emparejado permanece en la cola de espera — no lo contabilices.
Verificar deduplicación de UUID
Antes de fusionar, verifica que el lote no contenga UUID duplicados. Un conteo de UUID distintos que difiera del conteo de archivos indica reenvíos o correcciones. Márcalos y determina la versión correcta antes de contabilizar.
Combinar y ordenar por Uso CFDI para preparación de DIOT
Combina las filas PUE y PPD coincidentes en una sola salida. Ordena o agrupa por código de Uso CFDI (G01, G03, D01, etc.). Para cada grupo, subtotaliza el IVA acreditable (el monto de IVA que puede acreditarse) — este subtotal debe coincidir con el monto de IVA reportado en la sección correspondiente de la DIOT. Exporta la hoja combinada a formato Excel para importarla a CONTPAQi, Aspel-COI o al módulo de AP de tu ERP.
Seguimiento de la cola de retención
Revisa la cola de retención: CFDIs PPD no coincidentes, CFDIs con RFC genérico y cualquier Complemento de Pago entre lotes aún pendiente. Esta es la lista de excepciones del lote — no para el cierre de este mes, sino para el rastreador de seguimiento del equipo de AP rumbo al siguiente ciclo.
Este flujo procesa el lote aproximadamente en el mismo tiempo que un analista tarda en extraer datos manualmente de 6 a 8 PDF de CFDI uno por uno — pero maneja 50+ y produce resultados listos para DIOT, no solo "datos en una hoja de cálculo".
Para profundizar en los fundamentos de la extracción de datos estructurados de XML y PDF de CFDI — incluyendo cómo manejar lotes de formato mixto donde no todos los proveedores entregan el XML — consulta nuestra guía sobre extracción de facturas CFDI mexicanas a Excel.
Preguntas Frecuentes — Procesamiento por Lotes de Facturas CFDI Mexicanas
¿Puede el procesamiento por lotes de CFDI manejar facturas PUE y PPD mixtas en la misma ejecución?
Técnicamente sí — una herramienta por lotes puede extraer datos de ambas. Pero para precisión contable, deben procesarse como sublotes separados. Las facturas PUE pueden contabilizarse de inmediato. Las facturas PPD deben emparejarse con su Complemento de Pago antes de contabilizar. Fusionar ambas en la misma salida sin el paso de conciliación PPD crea pasivos abiertos en tu libro mayor.
¿Cuál es el límite práctico para la descarga por lotes de CFDIs recibidos en el portal del SAT?
La descarga masiva del portal del SAT a través del Buzón Tributario admite hasta 500,000 registros por solicitud — superando con creces los volúmenes típicos de AP. Sin embargo, la interfaz web tiene sesión temporizada y no está diseñada para la recuperación rápida de XMLs individuales de proveedores. Para AP de fin de mes, solicitar XMLs directamente a los proveedores o usar un servicio automatizado de entrega PAC-a-receptor es más rápido que las descargas manuales del portal del SAT.
¿ImageToTable.ai procesa archivos XML CFDI directamente, o solo versiones PDF?
ImageToTable.ai procesa PDFs, imágenes JPG, PNG y puede manejar capturas de pantalla de documentos. Para archivos XML CFDI, puedes subir la representación PDF del CFDI (que todo proveedor mexicano debe proporcionar junto con el XML), y la herramienta extrae los mismos campos — UUID, RFCs, montos, fechas, Método de Pago — en columnas estructuradas. Para lotes mixtos XML + PDF donde algunos proveedores solo enviaron la versión impresa, todo se fusiona en una sola hoja de cálculo.
¿Cómo se maneja la deduplicación de UUID de CFDI en múltiples lotes de fin de mes?
Mantén un registro continuo de UUIDs. Antes de contabilizar cada nuevo lote, verifica cada UUID contra el registro. Un conteo de UUIDs distintos que coincida con el conteo de archivos confirma que no hay duplicados. Los UUIDs que aparecen en dos lotes separados indican una reenvío (mismo CFDI enviado dos veces) o una corrección (cancelado y reemitido con un nuevo UUID — el anterior invalidado). En ambos casos, investiga antes de contabilizar. Una salida de extracción por lotes que incluya la columna UUID convierte esta verificación en un ejercicio de tabla dinámica de 30 segundos.
¿Por qué algunos CFDIs usan un RFC genérico como XAXX010101000 y puedo contabilizar esas facturas?
XAXX010101000 es el RFC genérico designado por el SAT para un receptor extranjero cuyo RFC mexicano no está disponible. Puedes contabilizar la factura en tu libro mayor, pero el IVA de ese CFDI no es acreditable — no se puede deducir para efectos de IVA. Para reclamar el crédito de IVA, debes solicitar al proveedor que reexpida el CFDI con el RFC correcto y registrado de tu empresa. Esta es una de las excepciones más comunes en un lote de más de 50 CFDIs de proveedores, y los RFC genéricos deben marcarse antes de la contabilización.
¿Se puede emparejar automáticamente el Complemento de Pago con su factura original en un lote?
Sí, si tu herramienta de procesamiento por lotes extrae el UUID de la factura original de cada nodo Complemento de Pago del CFDI de pago — el elemento <pago20:Pago> referencia el UUID de la factura original en su hijo DocumentoRelacionado — y lo cruza con los UUIDs de las facturas de Ingreso PPD abiertas. Esta es una coincidencia estructurada de XML a XML y se puede automatizar por completo, convirtiendo 18 conciliaciones manuales en cero.
¿Qué tipos de CFDI debo esperar en un lote típico de múltiples proveedores?
En un lote de grandes distribuidores y proveedores industriales, espera principalmente Ingreso (Tipo I) con Método PPD. Fabricantes y proveedores de servicios pueden usar tanto PUE como PPD según los términos del contrato. También puedes recibir notas de crédito de Egreso (Tipo E) por devoluciones o ajustes — estas deben emparejarse con su Ingreso original y tratarse como contra-asientos, no como partidas independientes. Los CFDIs de nómina (Tipo N, Nómina) se procesan por separado y deben filtrarse de tu lote de cuentas por pagar.
El verdadero cuello de botella en las cuentas por pagar mexicanas no es la velocidad de captura de datos — es la integridad de la conciliación
Si cada CFDI XML toma 3 minutos para abrirse, revisarse y copiar manualmente 8 campos a una hoja de cálculo, procesar 50 facturas de proveedores consume 2.5 horas del cierre de mes de un analista de cuentas por pagar. Pero ese cálculo ignora el costo real. Las 2.5 horas de captura de datos son seguidas por otras 3–4 horas de conciliación — emparejar facturas PPD con complementos de pago, verificar UUIDs contra lotes anteriores, clasificar por Uso CFDI para la declaración DIOT, y rastrear RFC genéricos con los proveedores.
El cuello de botella en las cuentas por pagar mexicanas no es la velocidad de captura de datos. Es que el resultado de una extracción manual — una hoja de cálculo con Nombre del Proveedor, Monto e Impuesto — no contiene ninguno de los campos necesarios para la conciliación. UUID, Método de Pago, Uso CFDI, Exportación, RegimenFiscalReceptor — estos son los campos que convierten una lista plana de facturas en un lote de cuentas por pagar listo para DIOT y auditable. Una extracción por lotes que conserve todos ellos simultáneamente elimina el paso de conciliación, que es donde realmente se gasta el tiempo.
La primera vez que proceses un lote de 50 CFDIs XML de 14 proveedores y exportes una hoja de cálculo donde la columna UUID esté poblada, la división PUE/PPD esté preclasificada y la agrupación por Uso CFDI coincida con las secciones del DIOT — te darás cuenta de que la extracción nunca fue la parte difícil. La parte difícil era la conciliación que solías hacer después.