Qué valor prevalece cuando
el XML de factura ZATCA y el PDF no coinciden

Una factura ZATCA son dos registros en un solo contenedor

El XML firmado es la factura; el PDF/A-3 es una representación que puede contenerlo. ZATCA, la Zakat, Tax and Customs Authority, exige que toda factura de la Phase 2 se genere y almacene como XML ZATCA UBL 2.1, o como archivo PDF/A-3 con ese XML incrustado. El XML es el objeto que se firma y luego ZATCA lo valida antes de que una factura estándar llegue al comprador, o se reporta en un plazo de 24 horas en el caso de una factura simplificada. El PDF es la copia legible para las personas.

Las ZATCA Detailed Guidelines for E-Invoicing responden directamente a la pregunta habitual: si un contribuyente quiere enviar un PDF, el PDF/A-3 con XML incrustado es obligatorio. En la Phase 2, un PDF simple, un archivo de Word o un escaneo no son una factura electrónica conforme en absoluto. La copia legible también debe estar en árabe, y se permite cualquier idioma adicional junto a ella. Por eso el mismo nombre de proveedor puede aparecer dos veces, una en árabe y otra en inglés, y por eso las dos versiones no son intercambiables en una regla de coincidencia.

UBL 2.1 es el estándar XML de OASIS que subyace al formato. Sus elementos se agrupan en dos familias: cbc para valores como ID, IssueDate y TaxAmount, y cac para contenedores como AccountingSupplierParty e InvoiceLine. Los prefijos habituales son alias. Un proveedor puede usar distintos nombres de prefijo para el mismo namespace, por lo que un analizador debe resolver los namespaces en lugar de comparar la cadena cbc:. El ZATCA XML Implementation Standard añade las reglas saudíes sobre UBL y EN 16931.

PDF/A-3 es una variante de PDF de archivo que permite archivos incrustados. Una factura híbrida es una página de aspecto normal más un adjunto. El adjunto es lo que se analiza; la página es lo que lee una persona. El código QR es un tercer registro, más pequeño: una cadena Base64 de registros tag-length-value, de hasta 500 caracteres. Los tag 1 a 9 contienen el nombre del vendedor, el número de VAT del vendedor, la marca temporal, el total con VAT incluido y el total de VAT; los tag 6 a 9 contienen el hash, la firma, la clave pública y, en las facturas simplificadas, la firma de ZATCA sobre esa clave. El programa de facturación electrónica de ZATCA se llama Fatoora (فاتورة).

Qué llega realmente a una bandeja de entrada de AP

La extensión no le dice casi nada; la colección de adjuntos le dice qué puede analizar. El ERP de un proveedor puede producir un híbrido correcto y el comprador puede recibir igualmente un PDF aplanado. Los portales de compras vuelven a renderizar los adjuntos, las pasarelas de correo los eliminan y los auxiliares de AP imprimen a PDF antes de archivar. La factura en la bandeja de entrada puede parecer perfecta y estar estructuralmente vacía. El informe anual de 2025 de ZATCA sitúa el volumen de facturas electrónicas del año por encima de 8 mil millones, por lo que una bandeja de entrada mixta no es un caso límite. Los cuatro estados siguientes requieren un tratamiento distinto.

También ocurre lo contrario. El foro de desarrolladores de ZATCA tiene un hilo de un proveedor que pregunta si los valores pueden entregarse como una imagen en un PDF/A-3. El archivo declara conformidad, pero los caracteres no se pueden seleccionar ni copiar porque no hay fuentes, solo píxeles. En ese caso, el XML incrustado es la única capa legible por máquina, y el OCR pasa a ser un recurso de reserva en lugar de la opción predeterminada. El hilo del foro es un recordatorio útil de que "PDF/A-3" describe el contenedor, no la legibilidad de la página.

Compruebe el adjunto, no el nombre del archivo. Abra el panel de adjuntos en un lector de PDF, o inspeccione la entrada /AF, extraiga el archivo a una carpeta de trabajo controlada, confirme que se analiza como XML y deje los bytes originales intactos. Si el adjunto falta, está corrupto o es inaccesible, registre esa condición antes de usar la página. Los cuatro estados anteriores no son equivalentes, y tratar una página observada como una carga útil analizada es el primer punto donde se pierde una excepción de AP.

Los campos que deciden el pago

Cuentas por pagar necesita alrededor de una docena de campos de encabezado y cinco por línea, y el XML nombra cada uno de ellos. Una vez clasificado el artefacto, la lista de campos es la misma, ya provengan los valores de un analizador o de una página. La tabla es un mapa de trabajo, no el diccionario de datos completo. Conserva los campos que modifican un pago, un registro de impuestos o una verificación de duplicados, y omite los que solo importan al despacho del vendedor. Las rutas son relativas a la raíz Invoice.

Dos reglas hacen utilizable el mapa. Extraiga LineExtensionAmount y PayableAmount como columnas propias incluso cuando también extraiga cantidad y precio. Recalcular un valor que el documento ya declara es la forma en que Cuentas por pagar crea una discrepancia que no existe. Conserve también la cadena sin procesar junto al valor normalizado. Un número de factura con un cero inicial, un nombre legal en árabe y una marca de tiempo en Arabia Standard Time pierden información cuando se fuerzan demasiado pronto. Los nombres en árabe también pueden mostrarse en un orden visual distinto aunque los caracteres sean correctos, así que conserve la cadena sin procesar y ajuste la dirección de visualización en lugar de volver a escribir el valor. Si la división entre encabezado y línea es nueva para usted, la guía completa de extracción de datos de facturas cubre el modelo general.

Dónde discrepan realmente las dos capas

La mayoría de las discrepancias no son corrupción. Son dos representaciones correctas de campos distintos. Los cinco casos siguientes explican la mayoría de las excepciones de Cuentas por pagar que parecen errores de datos pero en realidad son errores de mapeo.

Un descuento de línea modifica el neto de la línea, no el precio unitario

El estándar de implementación de ZATCA define el neto de la línea como ((precio neto del artículo ÷ cantidad base) × cantidad facturada) menos el descuento de línea más el cargo de línea. Una línea con 10 unidades a SAR 100 y un descuento de línea de SAR 50 tiene un neto de línea de SAR 950, mientras que el precio unitario impreso sigue siendo SAR 100. Si el PDF muestra el precio unitario y el total de la línea pero no el descuento, la página parece aritméticamente incorrecta. No lo es. El descuento está en el XML, dentro de cac:InvoiceLine/cac:AllowanceCharge.

Si el equipo de cuentas por pagar extrae la cantidad y el precio unitario y calcula un total de línea, obtiene SAR 1,000 frente a un documento que indica SAR 950. La factura falla entonces una verificación que debería haber superado, o un empleado ajusta el campo equivocado para cuadrarla. Extraiga el neto de línea declarado y mantenga el descuento en su propia columna para que la aritmética pueda reproducirse después.

Una columna calculada es útil para verificar. No sustituye al neto de línea que declara el documento.

Un prepago divide el total en dos cifras

El propio ejemplo de prepago de ZATCA muestra el patrón: SAR 230 con IVA incluido, SAR 104 ya prepagados, SAR 126 por pagar. TaxInclusiveAmount es 230, PrepaidAmount es 104, PayableAmount es 126. Los tres son correctos y cada uno responde a una pregunta distinta. Asigne el importe adeudado a PayableAmount, el valor de la factura a TaxInclusiveAmount y el anticipo a su propia columna. Si el ERP tiene un único campo de total, coloque allí el valor de la factura y lleve el importe por pagar en el calendario de pagos. Sobrescribir uno con el otro oculta el anticipo y lo paga dos veces.

Una factura en moneda extranjera lleva dos totales de impuestos

Cuando la moneda del documento no es SAR, ZATCA exige que TaxCurrencyCode sea SAR y un segundo total de impuestos en SAR. El PDF a menudo imprime solo la moneda del documento. Un equipo de cuentas por pagar que convierta el total impreso al tipo de cambio de fin de mes obtendrá una cifra de IVA en SAR distinta de la del XML, y la diferencia recaerá en la cuenta de recuperación de IVA. Lea ambos totales de impuestos, registre el de SAR y conserve el de la moneda del documento para el libro del proveedor.

El PDF puede contener campos que el XML no está obligado a incluir

El estándar de ZATCA es un mínimo. En el foro de desarrolladores de Fatoora, un proveedor preguntó si la información adicional impresa en el PDF/A-3 debía aparecer en el XML. La respuesta fue que los campos fuera del diccionario de datos no son obligatorios en el XML, aunque pueden añadirse si cumplen con UBL. Ahí suelen residir los números de orden de compra, las referencias de albaranes, los centros de coste internos y los sellos de aprobación. Están en la página, no en el payload.

Para un flujo de trabajo puramente XML, eso es una laguna. La conciliación de tres vías necesita la orden de compra, y la programación de pagos necesita la fecha de vencimiento. El XML tiene cac:OrderReference y cac:PaymentTerms, pero un proveedor no está obligado a rellenarlos en cada factura. El diseño práctico es una columna de origen a nivel de campo: impuestos e identidad del XML, contexto operativo de la página, y un estado explícito de "no presente" cuando ninguno lo tiene.

Una nota de crédito es un documento nuevo, no una factura negativa

Una nota de crédito utiliza el código de tipo de factura 381, lleva una referencia de facturación a la factura que corrige, indica un motivo y normalmente mantiene sus importes en positivo porque el tipo de documento determina la dirección. Si la registra como una factura de compra negativa, el signo puede invertirse dos veces: una por el tipo, otra por su asiento. El resultado es un crédito que aumenta el saldo.

Compense la nota contra la factura referenciada y verifique que la referencia se resuelva. La guía de ZATCA permite que una nota de crédito haga referencia a varias facturas originales como un rango de texto, por lo que la referencia no siempre es una clave única. Cuando es un rango, divida el crédito o reténgalo hasta que el proveedor proporcione un desglose por factura.

La tabla siguiente convierte los casos comunes en una hoja de enrutamiento.

El código QR es una verificación de consistencia, no un certificado de validación

Que un QR coincida con la página demuestra que ambos se generaron a partir de los mismos valores; no demuestra que la factura haya sido validada. Los tag 1 a 9 son los únicos valores comerciales del código. No hay número de factura, ni línea de detalle, ni pedido, ni NIF del comprador. Un QR es un resumen, y uno breve.

Usados como verificación de recepción, los tag 1 a 5 siguen siendo útiles. Normalice antes de comparar: el número de VAT como dígitos, la marca temporal como instante, porque Arabia Standard Time y UTC pueden describir el mismo momento, y los importes con dos decimales. Una discrepancia suele significar que el QR pertenece a otra factura, o que la página se reconstruyó después de generar el código. Ambas merecen una pausa.

Los tag 6 a 9 no pueden verificarse a simple vista ni con un escáner de teléfono. Verificarlos requiere el XML firmado, la forma exacta a nivel de byte sobre la que se calculó la firma, la cadena de certificados y una comprobación de revocación. Un escaneo que muestra nueve campos ha mostrado nueve campos. No ha verificado la firma.

A los equipos de AP les dicen cosas distintas sobre esto. En el foro de desarrolladores de Fatoora, un profesional de AP escribió: "El equipo de soporte de ZATCA dice que es obligatorio escanear los códigos QR de las facturas de proveedores. Planteo mi pregunta desde la perspectiva de Accounts Payable". La respuesta del líder de la comunidad fue que el escaneo es una verificación opcional, y que una factura que ya ha sido reportada o validada con éxito cumple los requisitos de facturación electrónica. El mismo hilo recoge que la aplicación de ZATCA no puede escanear códigos fuera de Arabia Saudí, lo que supone un problema práctico para un centro de servicios compartidos en otro país.

La postura viable: use el QR como control de muestreo y verificación de la integridad de los adjuntos. No lo convierta en una puerta obligatoria por factura, y no trate un escaneo como prueba de validación. La prueba es el XML validado o reportado, conservado junto con su respuesta.

Un QR copiado puede estar en una página manipulada. Compare los valores; no trate el cuadro como prueba.

Un flujo de trabajo de seis pasos que resiste las excepciones

El flujo de trabajo de cuentas por pagar para facturas electrónicas saudíes debe producir una fila por línea de factura, una etiqueta de origen para cada campo y un estado de excepción que nadie pueda sobrescribir en silencio. Los pasos son deliberadamente aburridos. Lo aburrido es lo que hace que el resultado sea defendible seis años después.

Tres responsables, tres preguntas. El auxiliar de cuentas por pagar es responsable de la conciliación comercial y de la consulta al proveedor. El responsable del ERP o de la integración es responsable del adjunto, del espacio de nombres y del analizador. El responsable fiscal saudí es responsable de la categoría de VAT, de la evidencia de despacho y de la decisión de retención. Un único indicador de "válido" colapsa esas respuestas en una sola y oculta qué equipo debe actuar. Almacene los estados por separado: analizado, esquema fallido, valores en desacuerdo, evidencia criptográfica no verificada, retención de AP, aprobado para pago.

Qué puede y qué no puede hacer la extracción visual aquí

Una herramienta de extracción visual lee la página, no el adjunto, por lo que pertenece al lado PDF de este flujo de trabajo. Esa es la parte que cubre ImageToTable.ai, y es un rol más acotado que "extracción de facturas ZATCA". Aun así es útil en tres lugares.

El primero es el campo que existe solo en el PDF. Cuando el ERP analiza el XML, la página puede seguir siendo el único lugar donde aparecen el número de PO, el albarán o la aprobación interna. Custom Column Extraction le permite escribir los nombres de columna que desea, como "PO Number", "Payment Due Date" y "Delivery Note", y el modelo encuentra los valores por significado en lugar de por coordenadas fijas. Los nombres de columna que ingresa se convierten en los encabezados de la tabla de salida.

El segundo es la excepción sin XML. Cuando un proveedor envía un PDF simple o un PDF/A-3 solo de imagen, no hay nada que analizar. La página se convierte en la fuente. El procesamiento por lotes maneja una carpeta de diseños de proveedor mixtos en una sola pasada y fusiona las filas en una hoja de cálculo, que es la diferencia entre una cola de excepciones viable y un montón de conversiones puntuales.

El tercero es la comparación visual. Review Mode con resaltado Bbox le permite pasar el cursor sobre una celda y ver la región de la página original que la produjo, y hacer clic en una región para volver a la celda. Para una factura ZATCA, así es como un auxiliar compara el importe a pagar impreso con el valor del XML sin imprimir la página y usar una regla. El valor original de la IA se conserva y se puede restaurar si una edición fue errónea. Para escaneos solo de imagen y diseños bilingües densos, un Model Tier superior usa un modelo de visión más potente. El estándar cubre la mayoría de las tablas impresas; el caso difícil es una impresión escaneada con texto árabe pequeño y un sello sobre el total.

Los límites importan igual. No abre el XML incrustado, no valida el sello criptográfico, no verifica el hash del código QR, no incorpora un proveedor a ZATCA ni presenta nada. Una extracción visual de un PDF/A-3 es una observación de la página renderizada, no un análisis del payload firmado. Etiquételo así en la salida. Si la página omite un descuento de línea, la observación también lo omitirá, y la verificación aritmética del paso 4 es lo que detecta la diferencia.

La misma distinción se aplica en otros mercados. El sistema de facturas cualificadas de Japón no tiene un payload XML obligatorio, por lo que la capa visual suele ser la única fuente, y por eso la misma disciplina se aplica a las facturas cualificadas japonesas. El mandato de Alemania hace que el archivo estructurado sea la factura, lo que cambia el orden de recepción para las facturas de proveedores alemanes. Un equipo que maneja ambos necesita un mapa de campos y dos reglas de recepción.

El Archivo Es Parte de la Extracción

La hoja de cálculo no es la factura, y un PDF por sí solo no es el registro que un auditor puede validar. Article 66 del Reglamento de Aplicación del IVA de Arabia Saudita exige que las facturas, libros, registros y documentos contables se conserven durante al menos seis años desde el final del período fiscal al que se refieren. Los registros de activos de capital se conservan durante el período de ajuste del Article 52 más cinco años, es decir, 11 años para activos muebles y 15 para inmuebles. Los registros deben estar en árabe y almacenarse en el Reino, de forma electrónica o física, con acceso desde un terminal en el Reino.

Conserve el XML recibido, o el contenedor PDF/A-3 intacto, en lugar de solo una copia extraída del adjunto. Conserve la respuesta de validación o reporte para las facturas estándar, porque esa es la evidencia de que la factura fue aceptada. Conserve el contador de facturas y la cadena de hash anterior intactos; una brecha es en sí misma evidencia. Conserve las notas de crédito junto con las facturas que corrigen, ya que la modificación está prohibida.

El registro de extracción tiene sus propios campos: hash del archivo de origen, tipo de origen, versión del analizador o del modelo, versión del conjunto de reglas, origen a nivel de campo, valor normalizado, valor sin procesar y estado de excepción. Volver a ejecutar un analizador o un modelo más adelante requiere los mismos bytes. Si sobrescribe el original con un valor normalizado, habrá destruido la evidencia que necesitaría para defender la fila.

Otros modelos de validación señalan lo mismo. El sistema KSeF de Polonia asigna un identificador sin el cual la factura no existe legalmente, y las facturas CFDI de México combinan un archivo estructurado con una representación imprimible. En cada caso, el archivo es el artefacto estructurado más la respuesta de la autoridad, no el PDF.

Preguntas frecuentes

¿Puedo extraer líneas de detalle de un código QR de ZATCA?

No. Las etiquetas 1 a 5 contienen el nombre del vendedor, su número de VAT, la marca temporal, el total con VAT incluido y el total de VAT. No hay número de factura, ni identificador del comprador, ni detalle de líneas. Use el código para contrastar esos cinco valores, no para construir una tabla de líneas de detalle.

¿Toda factura PDF/A-3 es un híbrido con XML dentro?

No. PDF/A-3 es un contenedor que permite archivos incrustados; no garantiza que el proveedor haya incluido uno, que el adjunto sea legible ni que la página se haya generado a partir de él. Abra la colección de adjuntos y analice el archivo antes de tratar el PDF como una fuente estructurada.

¿Qué total registro cuando una factura incluye un prepago?

Registre el valor de la factura desde TaxInclusiveAmount y pague el importe adeudado desde PayableAmount. Lleve PrepaidAmount en su propia columna y vincúlelo a la factura de prepago. No combine los tres en un único campo "total" ni sobrescriba el valor de la factura con el importe a pagar.

¿Es el PDF/A-3 la factura legal?

No. El XML firmado es la factura. El PDF/A-3 es la copia legible que puede contenerlo. Para una factura estándar, conserve el XML validado o el híbrido validado, y archive el contenedor en lugar de un PDF reguardado.

¿Puedo usar OCR en una factura de ZATCA?

Sí, cuando no haya XML utilizable. Un PDF solo de imagen, un escaneo o una foto pueden leerse visualmente, pero el resultado es una observación de la página, no un análisis del payload firmado. Registre el método, aplique las mismas comprobaciones de normalización y aritmética, y contraste los cinco valores del código QR cuando sean legibles.

¿Cómo gestiono una nota de crédito que referencia varias facturas?

Trátela como un documento nuevo con tipo 381 y una referencia de facturación, no como una factura de compra negativa. Si la referencia es un rango, divida el crédito entre las facturas originales o espérelo hasta que el proveedor facilite un desglose por factura. Compénselo con las facturas que corrige y archívelo junto a ellas.

¿ImageToTable.ai analiza el XML UBL incrustado o verifica el código QR?

No. Lee la página del PDF, la imagen o el escaneo y extrae las columnas que usted define, incluidos los campos que solo existen en la página impresa. No abre el archivo XML adjunto, no valida el sello criptográfico, no verifica el hash del código QR, no registra a un proveedor ante ZATCA ni presenta una declaración. El análisis del XML y la verificación de la firma corresponden a su ERP o a su capa de integración.

¿Cuánto tiempo debe conservarse una factura de un proveedor saudí?

Al menos seis años desde el final del periodo fiscal al que corresponde, según el Article 66 del Reglamento de Aplicación del VAT. Los registros de activos fijos se conservan durante el periodo de ajuste más cinco años, es decir, 11 años para los activos muebles y 15 para los inmuebles. Conserve juntos el XML o el contenedor PDF/A-3 sin modificar, la evidencia de validación o declaración y las notas de crédito.

La fila que resiste el interrogatorio

La factura que resiste una auditoría es aquella en la que cada fila puede indicar el campo del que proviene, el artefacto que la respalda y la verificación que la dejó pasar. Una vez que existe ese mapa, la discrepancia entre el PDF y el XML deja de ser un misterio y se convierte en una cola con un responsable.