ZATCA Invoice XML Extraction: An AP Workflow

For ZATCA invoice XML extraction, parse the UBL 2.1 XML as the primary data source whenever it is present. Keep repeating invoice lines as rows, retain the original artifact and its identifiers, and use the human-readable PDF and decoded QR payload to reconcile selected values. Schema checks, arithmetic checks, cryptographic verification, and AP approval remain separate controls.

That distinction matters because extraction answers a narrow question: what values does this artifact declare? It does not prove that the signature is valid, the invoice was cleared or reported successfully, the VAT treatment is correct, or the document is approved for payment. A parser can accurately return an invoice number and total from a file that later fails a business rule or cryptographic check.

For a received Saudi supplier invoice, the practical workflow is therefore XML first, comparison second, validation through the appropriate control services, and AP review last. A PDF/A-3 file may package the same UBL payload beside a visual rendering. A plain PDF or scan may contain only pixels or selectable text, in which case OCR becomes an exception path rather than the default extraction method.

The review dataset should preserve the invoice-level identity, repeating line structure, source location, and a pointer to the untouched received file. Those elements allow finance and systems teams to trace a row back to the cleared artifact, distinguish source data from normalized values, and route each disagreement to the team that owns it.

Decide which inbound artifact contains the authoritative data

Route the file according to what it actually contains, not its extension or appearance.

Inbound artifact	Primary extraction source	What to verify first
Raw UBL XML	The XML itself	The file is well formed, its root and namespaces identify the expected UBL invoice, and the received bytes are preserved with a recorded checksum; cryptographic integrity is assessed later
PDF/A-3 with embedded XML	The embedded XML attachment	The attachment collection contains an accessible XML file that can be opened and parsed
Visual PDF without accessible XML	Selectable text or OCR output	No usable XML attachment exists and the page content belongs to the invoice rather than a cover sheet or rendering artifact
Image-only PDF, JPG, or PNG	OCR output	Page quality, orientation, language, and document boundaries support reliable recognition

A PDF should not be classified as an XML-bearing invoice merely because it has a .pdf filename, searchable text, or a visible QR code. Inspect its embedded-file or attachment collection. Extract the attachment to a controlled working area, confirm that it is XML, and parse it without modifying the received container. If the attachment is missing, corrupt, or inaccessible, record that condition before using the visual layer as a fallback.

This XML-first decision follows the structure of the regime itself. ZATCA's detailed e-invoicing guideline describes e-invoicing as the exchange and processing of invoices in a structured electronic format, with official examples that include XML and human-readable PDF/A-3 files containing embedded XML. The PDF representation helps a person read the invoice; it does not replace the structured payload when that payload is available.

The container idea is similar to how hybrid PDF/XML invoices work in ZUGFeRD: one artifact can carry both a visual representation and machine-readable invoice data. The profiles, business rules, and validation authorities differ, so that comparison explains the packaging pattern rather than making the formats interchangeable.

Mandate phases and invoice-content rules should stay outside the intake decision. Teams that need that background can use the separate guide to Saudi Arabia VAT invoice requirements. For inbound processing, the decisive question is simpler: does this received artifact contain an accessible structured payload, and can the untouched source be preserved while it is parsed?

Map ZATCA business terms to a review-ready field set

UBL parsing must be namespace-aware. The familiar cbc and cac prefixes are aliases used in the standard; a supplier's XML can use different prefix names for the same namespace URIs. Resolve the namespaces, select the Invoice root, and treat the paths below as relative to that root.

Review field	ZATCA business term	Relative UBL path	Normalization note
Invoice number	BT-1	cbc:ID	Preserve the source string; do not coerce leading zeros away
UUID	KSA-1	cbc:UUID	Keep separate from the supplier's invoice number
Issue date	BT-2	cbc:IssueDate	Parse to an ISO date while retaining the raw value
Issue time	KSA-25	cbc:IssueTime	Preserve the supplied time-zone form, including AST or UTC notation
Invoice type	BT-3	cbc:InvoiceTypeCode	Store the code and its attributes before deriving a display label
Invoice currency	BT-5	cbc:DocumentCurrencyCode	Validate as a currency code; do not infer it from a symbol in the PDF
Seller legal name	BT-27	cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName	Preserve Arabic and English forms separately when both exist
Seller VAT identifier	BT-31	cac:AccountingSupplierParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID	Keep as text and retain all digits
Buyer legal name	BT-44	cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName	Evaluate required presence against the invoice type and applicable rule
Buyer VAT identifier	BT-48	cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID	Absence can be context-dependent; never manufacture a value
Total VAT	BT-110	cac:TaxTotal/cbc:TaxAmount	Retain the currencyID attribute and distinguish invoice from accounting currency totals
VAT taxable amount	BT-116	cac:TaxTotal/cac:TaxSubtotal/cbc:TaxableAmount	One row can exist for each VAT category breakdown
VAT category tax	BT-117	cac:TaxTotal/cac:TaxSubtotal/cbc:TaxAmount	Join it to the category and rate from the same TaxSubtotal
VAT category and rate	BT-118, BT-119	cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:ID and cbc:Percent	Keep category codes distinct from percentages
Sum of invoice line net amounts	BT-106	cac:LegalMonetaryTotal/cbc:LineExtensionAmount	Reconcile to the sum of BT-131 line net amounts
Total before VAT	BT-109	cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount	Compare with the line, allowance, and charge calculation
Total with VAT	BT-112	cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount	Do not substitute the amount due when prepayments or rounding exist
Prepaid, rounding, amount due	BT-113, BT-114, BT-115	cac:LegalMonetaryTotal/cbc:PrepaidAmount, cbc:PayableRoundingAmount, cbc:PayableAmount	Store each component separately
Invoice line ID	BT-126	cac:InvoiceLine/cbc:ID	Use with the invoice key to identify a line
Quantity and unit	BT-129	cac:InvoiceLine/cbc:InvoicedQuantity and its unitCode attribute	Parse the decimal and retain the unit code
Line net amount	BT-131	cac:InvoiceLine/cbc:LineExtensionAmount	Retain currencyID and reconcile to document totals
Item name	BT-153	cac:InvoiceLine/cac:Item/cbc:Name	Preserve the original Unicode text
Line VAT category and rate	BT-151, BT-152	cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategory/cbc:ID and cbc:Percent	Do not infer a missing category from the percentage alone
Item net price and base quantity	BT-146, BT-149	cac:InvoiceLine/cac:Price/cbc:PriceAmount and cbc:BaseQuantity	Use both values when recalculating a unit price
Line VAT amount	KSA-11	cac:InvoiceLine/cac:TaxTotal/cbc:TaxAmount	Keep separate from the line amount including VAT

The table is an extraction map, not a replacement for the rules. ZATCA's current Electronic Invoice XML Implementation Standard defines the UBL 2.1 syntax, EN 16931-derived business terms, KSA-specific rules, calculations, and validation phases. Its Data Dictionary and Schematron rules remain authoritative for cardinality and conditions. A buyer VAT number, for example, must be assessed in the invoice's actual context rather than treated as universally present.

This is also why a country-specific field map is more useful than copying a vendor sample. Samples show one valid shape, while the standard covers optional elements, repeating groups, invoice types, allowances, charges, prepayments, and conditional requirements. The broader guide to how UBL compares with other invoice data schemas helps place these paths in context, but the ZATCA rule set governs the Saudi profile.

Keep invoice headers, line rows, and provenance connected

A review dataset needs two grains: one record per invoice and one record per invoice line. They may be separate database tables, separate workbook sheets, or two logical datasets in a pipeline, but they should share an internal invoice key that does not depend solely on the supplier's invoice number.

The invoice record should contain the source filename or object key, source type, invoice number, UUID, invoice type code, issue date and time, document currency, supplier identity and VAT identifier, buyer identity where supplied, tax totals, monetary totals, and a pointer to the untouched original. Add operational metadata such as parser version, schema or rule-set version, extraction timestamp, extraction status, and exception code. Record a clearance or reporting identifier only when it is present in authoritative evidence; do not create one from a filename or QR value.

The line dataset should hold the internal invoice key, line ID, item description, quantity, unit code, price, base quantity, net line amount, tax category, tax rate, and line tax amount. A normalized design avoids copying every header field onto every row. For a flat Excel review sheet, repeating the invoice key, invoice number, UUID, supplier VAT identifier, currency, and source pointer on each line is a reasonable tradeoff because a filtered row remains traceable.

One row per invoice works for header-level AP review but discards line repetition if descriptions or values are concatenated into cells. One row per line preserves spend and tax detail, yet totals must not be summed naively across repeated header columns. Label the grain, separate document totals from line amounts, and make the join relationship explicit.

Keep source values beside normalized values. The raw issue date, decimal string, currency code, Arabic or English name, and identifier provide audit evidence; parsed dates, typed decimals, standardized codes, and display labels make the data usable. If normalization fails, retain the raw value and attach an exception instead of silently replacing it.

This structure supports a UBL 2.1 Saudi invoice to Excel workflow without pretending Excel is the authoritative invoice. The spreadsheet is a review and transfer surface. The XML or XML-bearing PDF/A-3 remains the source artifact from which the rows were derived.

Reconcile XML, PDF, and QR without overstating the result

Use the XML as the source record, then compare selected identity and amount fields with the PDF rendering and decoded QR payload. The shared business-value set is narrow: seller name, seller VAT registration number, invoice timestamp, invoice total including VAT, and VAT total.

ZATCA QR content is a Base64-encoded sequence of tag-length-value tuples. Tags 1 through 5 carry those five business values. Under the current security specification, the later tags carry the invoice hash and cryptographic material: the ECDSA signature, public key, and the technical authority's signature over that public key where applicable. Decode bytes according to the specification before comparing normalized values; do not compare the printed Base64 string with XML text.

Disagreement	Plausible cause	Routing action
XML total differs from the PDF total	Stale rendering, transformation error, or altered visual layer	Hold the invoice; retain both artifacts and send the evidence to the supplier or e-invoicing integration owner
XML seller VAT number differs from QR tag 2	QR generated from different source data, wrong attachment, or corrupted document assembly	Stop automated matching and route to the e-invoicing validation owner
Timestamp looks different but represents the same instant	AST versus UTC notation, formatting, or time-zone normalization	Compare parsed instants and retain both raw values before raising an exception
QR is missing or unreadable	Render quality, damaged page, or a document-type and rule-context issue	Record the missing evidence and evaluate it under the applicable invoice rules; do not invent QR data
Hash or signature verification fails	Payload alteration, wrong verification input, invalid certificate path, or revoked or expired credential	Quarantine the artifact and route it to the cryptographic or e-invoicing component owner

Matching tags 1 through 5 proves only that the decoded QR values agree with the selected XML and PDF values after controlled normalization. It does not validate the document hash, ECDSA signature, certificate chain, certificate status at signing time, clearance or reporting response, UBL schema, ZATCA business rules, or VAT calculation.

Those cryptographic checks require the canonicalization, transforms, hashing, certificate-path validation, and revocation checks set out in ZATCA's Security Features Implementation Standards. A QR reader or AP workbook can expose evidence for comparison. It cannot replace a compliant verification component.

Route failures by control family and owner

A single valid flag collapses evidence that comes from different systems and belongs to different owners. Store independent statuses so a successfully parsed invoice can still be held for a rule, signature, commercial, or payment issue.

Control family	What it tests	Typical evidence	Owner	Failure route
XML and ZATCA rules	XML well-formedness, UBL 2.1 schema, code lists, EN 16931-derived rules, and KSA-specific business rules	Parser output, schema errors, Schematron assertions, rule-set version	Integration or data engineering for parsing; tax/compliance or a validated rule service for business rules	Quarantine the payload, retain the error detail, and return it to the supplier or integration owner as appropriate
Arithmetic and business-value reconciliation	Line extensions, allowances, charges, tax subtotals, document totals, and agreement among XML, PDF, and QR values	Recalculation results and field-level comparison records	Finance systems or tax operations	Hold the affected record for value investigation; never overwrite the source to make totals agree
Cryptographic and platform evidence	Invoice hash, ECDSA signature, certificate path and status, and applicable clearance or reporting evidence	Verification result, certificate chain, revocation response, platform response identifier	Security, the e-invoicing integration, or another compliant verification component	Quarantine and prevent release until the evidence is resolved or a new authoritative artifact is received
Internal AP approval	Supplier master match, duplicates, PO and receipt match, coding, approval authority, and payment status	ERP and workflow records	Accounts Payable and business approvers	Place an AP hold, request supporting information, or reject under the organization's payment controls

Use statuses that describe the evidence: parsed, schema failed, business rule failed, values disagree, cryptographic verification failed, AP hold, and approved for payment. Missing evidence should remain missing or pending, not be converted to a pass. The record can carry more than one status because the controls answer different questions.

Ownership should be equally explicit. Data engineering can repair a namespace or parser problem but should not decide whether a KSA tax rule is satisfied. Tax or a validated rule service can interpret business-rule failures but should not waive a broken signature. AP can approve the commercial transaction but cannot turn an unverified artifact into cryptographic evidence.

An extraction-ready record is therefore not automatically payment-ready, tax-valid, or cryptographically verified. Release depends on the statuses required by the organization's risk policy and the invoice's actual regulatory context.

Handle bilingual display and image-only exceptions separately

Arabic and English values can be extracted correctly from XML yet appear wrong in a spreadsheet or review interface. Unicode bidirectional rendering may move punctuation, signs, brackets, or number sequences visually even though the underlying character order has not changed. Treat that as a presentation defect until a byte-level or code-point comparison shows the source value itself differs.

Preserve the raw Unicode string and apply an explicit text direction to the display component when the field's language is known. Isolate identifiers, VAT numbers, dates, and monetary values from surrounding right-to-left text so neutral characters do not inherit an unexpected direction. Test copy and paste, CSV and XLSX export, search, sorting, and field comparison in addition to the on-screen rendering.

When the XML carries Arabic and English names, keep them in separate fields with their language or role recorded. Do not replace the Arabic legal name with a transliteration, merge both variants into one comparison key, or write a visually reordered display string back to the source-value column. Matching logic can use a controlled normalized form while retaining both originals.

OCR belongs on a separate exception path. A visual PDF with no accessible XML attachment, an image-only PDF, or a JPG or PNG can still be processed, but the resulting values are observations from the rendered document rather than values parsed from the structured payload. Mark the source method, confidence or review state, page reference, and any manual correction, then feed those values into the same normalization and reconciliation controls.

This separation prevents a bidirectional display bug from being mislabeled as XML corruption and prevents an OCR result from being treated as cleared structured data. Arabic bilingual invoice XML processing is primarily a Unicode, field-model, and interface problem; OCR quality becomes relevant only when the structured payload is genuinely unavailable.

Preserve the cleared artifact for the applicable retention period

Archive the received XML or PDF/A-3 unchanged. The archive record should contain a stable object identifier, cryptographic checksum, receipt timestamp, supplier and invoice identifiers, source channel, extraction record, validation evidence, and links to any review workbook or downstream posting. For a PDF/A-3 invoice, preserve the container with its embedded XML rather than retaining only an extracted copy of the attachment.

The spreadsheet is not a substitute for the invoice artifact. It contains selected and transformed values, may repeat headers across line rows, and cannot preserve every signature, attachment, attribute, or rule input. Re-running a parser or verifier later requires the same source bytes, so rendering, OCR, normalization, or a manual correction must create a derived record rather than overwrite the original.

Where Saudi VAT record rules apply, Article 66 of the current VAT Implementing Regulations requires invoices, books, records, and accounting documents to be kept for at least six years from the end of the tax period to which they relate. Records concerning capital assets follow the Article 52 adjustment period plus five years from acquisition. ZATCA guidance summarizes those longer minimums as eleven years for movable capital assets and fifteen years for immovable capital assets.

Retention classification belongs to the tax or records owner, not the XML parser. The organization must also account for legal holds, sector requirements, contractual obligations, and any law applying to the entity that received or stores the invoice. These can extend the period beyond the VAT baseline.

FATOORAH compliant invoice archiving is therefore more than saving a visible PDF in a folder. It means preserving the authoritative received artifact, its provenance, the evidence produced by each validation layer, and the relationship between that source and every normalized output for the period that applies to the record.