"Solo hay que leer el XML" es la frase que más subestima este trabajo. Un CFDI (Comprobante Fiscal Digital por Internet) no es un recibo cualquiera: es un documento fiscal mexicano con reglas de negocio propias, un ciclo de vida (puede cancelarse después de emitido) y un servicio de verificación externo que tu aplicación depende de él sin controlarlo. Esto es lo que aprendí integrando importación de CFDI con verificación SAT en un sistema de comprobación de gastos de viáticos.
La estructura de un CFDI 4.0
Un CFDI es un XML con un nodo raíz Comprobante que incluye, entre otros, los nodos Emisor y Receptor, una lista de Conceptos (los productos o servicios facturados) y los Impuestos desglosados. La versión 4.0 (vigente desde 2022) agregó campos que rompieron integraciones construidas para la 3.3: ahora RegimenFiscalReceptor y UsoCFDI del receptor son obligatorios y deben ser consistentes con el régimen fiscal real registrado del RFC receptor ante el SAT — un dato que antes bastaba con capturarlo, ahora hay que validarlo contra un catálogo.
Estructural válido no es lo mismo que vigente
Un XML puede parsear perfecto — todos los nodos en su lugar, el sello digital con formato correcto — y aun así corresponder a un CFDI que el emisor canceló después. Por eso la validación no puede quedarse en "el XML tiene la forma correcta"; hay que consultar el servicio público de verificación del SAT con el UUID del comprobante, el RFC emisor, el RFC receptor y el total, y ese servicio responde con el estatus real: vigente, cancelado, o no encontrado.
Esto tiene una consecuencia práctica en el diseño: el estatus de vigencia no se guarda una sola vez. Un comprobante que era vigente al momento de subirlo puede cancelarse después (facturas canceladas hasta con semanas de diferencia no son raras), así que si tu aplicación toma decisiones de negocio importantes basadas en ese estatus (por ejemplo, aprobar un reembolso), conviene revalidar antes de la aprobación final, no solo en el momento de la carga inicial.
El servicio del SAT no es instantáneo ni infalible
El endpoint público de verificación del SAT puede tardar varios segundos en responder, y en horas pico o durante mantenimientos simplemente no responde. Diseñar el flujo de carga de un comprobante para que bloquee al usuario esperando esa respuesta síncronamente es una mala experiencia garantizada. El patrón que funciona mejor: aceptar el XML de inmediato, marcarlo como "pendiente de verificación", y resolver la consulta al SAT en segundo plano (o en un reintento posterior), notificando al usuario solo si el resultado cambia su estatus a algo que requiera atención.
El PDF es una representación, no el documento fiscal
Muchos proveedores solo entregan el PDF ("factura" impresa) y no el XML, especialmente en negocios pequeños poco familiarizados con sus obligaciones. Es tentador aceptar solo el PDF por conveniencia, pero el PDF no tiene validez fiscal por sí mismo — es el XML, con su sello digital, el documento real. Una aplicación seria de gestión de gastos debe exigir el XML como fuente de verdad y usar el PDF únicamente como representación visual para el usuario, nunca como sustituto de la validación.
Errores comunes al integrar CFDI
- No validar que el RFC receptor coincide con la empresa que aprueba el gasto. Es fácil que un empleado suba, por error o de mala fe, una factura emitida a nombre de otra empresa o a su nombre personal.
- Tratar todos los
Complementoigual. Un CFDI de nómina, uno de pago (recibo electrónico de pagos) y uno de ingreso/egreso normal tienen estructuras de complemento distintas; un parser que asume un solo formato falla silenciosamente con los otros dos. - No manejar RFC genéricos. El RFC público genérico (
XAXX010101000) para ventas al público en general tiene reglas de validación distintas a un RFC real y no debe tratarse como un error de captura. - Confiar en el total del PDF sin cruzarlo contra el total del XML. Ambos deberían coincidir siempre, pero validarlo explícitamente detecta PDFs mal generados o adulterados antes de que lleguen a un flujo de aprobación.
Conclusión
Integrar CFDI y verificación SAT bien hecho es más un ejercicio de manejar reglas de negocio fiscales y la naturaleza cambiante (cancelable) del documento, que un problema de parsing de XML. La parte técnica — leer un XML, llamar un servicio REST — es la más fácil; la parte que realmente distingue una integración robusta de una frágil es diseñar el sistema asumiendo que el estatus puede cambiar después y que el servicio externo no siempre va a responder rápido.