ZATCA E-Invoicing Requirements: Saudi Arabia FATOORAH Guide

ZATCA e-invoicing requirements mandate that all VAT-registered businesses in Saudi Arabia generate, transmit, and store invoices electronically through the FATOORAH portal. What began as Phase 1 in December 2021, requiring businesses to produce and store invoices in a standardized electronic format, has evolved into something far more demanding. Phase 2 requires real-time API integration with ZATCA's platform, where B2B invoices must be validated and cleared by the authority before they can be delivered to the buyer. This clearance model sets Saudi Arabia apart from the post-audit approaches used across most of Europe and Latin America, where tax authorities review invoices after the fact.

The KSA e-invoicing mandate is not a standalone regulatory exercise. It sits at the center of Saudi Arabia's strategy to diversify government revenue beyond oil. E-invoicing functions as a tax administration enforcement mechanism, giving ZATCA real-time visibility into commercial transactions and closing gaps in VAT collection. According to the IMF's 2024 Article IV assessment of Saudi Arabia, the kingdom needs to close a 9 percent tax gap with the G20 average, and Saudi Arabia's tax administration was enhanced through e-invoicing as part of its non-oil revenue mobilization strategy. That fiscal context explains why ZATCA has pursued one of the most technically rigorous e-invoicing frameworks anywhere in the world.

The urgency is escalating. Phase 2 integration is rolling out in waves based on annual revenue thresholds, and the timeline is accelerating as those thresholds drop. Wave 23 (March 2026, SAR 500,000) and Wave 24 (June 2026, SAR 375,000) are sweeping tens of thousands of smaller businesses into the clearance model for the first time. Many of these companies have limited IT infrastructure and are only now confronting the technical demands of real-time ZATCA integration.

The distinction between the two phases is significant:

Phase 1 (Generation) requires businesses to generate invoices electronically in a structured format, store them digitally, and include specific fields such as the VAT registration number, QR code, and UUID. Manual or handwritten invoices are prohibited.
Phase 2 (Integration) requires businesses to connect their invoicing systems directly to ZATCA's FATOORAH platform via API. B2B invoices go through a clearance process where ZATCA validates the invoice data, applies a cryptographic stamp, and returns the cleared invoice before it can be shared with the buyer. B2C invoices follow a reporting model with near-real-time submission.

Understanding both sides of the ZATCA FATOORAH requirements is critical for businesses operating in the kingdom. Compliance means more than just sending invoices correctly. Most guides stop at the generation side, but you also need to process the ZATCA-cleared invoices you receive, extracting structured data from UBL 2.1 XML or PDF/A-3 documents that arrive with cryptographic stamps and validation metadata. This guide covers both. For a broader view of how e-invoicing systems work globally, the clearance model Saudi Arabia uses represents the most interventionist end of the spectrum, and the FATOORAH e-invoicing system in Saudi Arabia reflects that ambition in every technical requirement it imposes.

The Clearance Model: Why Saudi Arabia's System Is Different

Not all e-invoicing mandates work the same way. The technical architecture behind a country's system determines what your business actually needs to build, and Saudi Arabia's approach is fundamentally different from what most finance and IT teams have encountered elsewhere.

Globally, e-invoicing systems fall into three broad architectural models:

Post-audit models are the most common, particularly across the EU. Businesses generate and exchange invoices freely between each other. The tax authority receives invoice data later, either through periodic reporting or on-demand audits. Your systems don't need to interact with the government in real time. You issue the invoice, deliver it to the buyer, and report it on the authority's timeline.

Network-based (Peppol) models use a four-corner architecture where certified access points route invoices between buyers and sellers through a standardized network. The tax authority can observe transactions flowing through the network, but it doesn't insert itself into the delivery chain. The UAE's upcoming Peppol-based e-invoicing mandate is a regional example of this approach, offering an instructive contrast to Saudi Arabia's path.

Clearance models place the tax authority directly in the transaction flow. This is Saudi Arabia's approach, and it carries the most significant technical implications.

Under ZATCA's clearance model, standard B2B and B2G invoices cannot legally reach the buyer until ZATCA's FATOORAH platform has validated and "cleared" them. Every invoice your system generates must be submitted to ZATCA via API, checked against validation rules in real time, and stamped with a cryptographic hash before you can deliver it to your counterparty. ZATCA is not a passive observer. It is a gatekeeper on every business-to-business transaction.

B2C simplified invoices follow a reporting model rather than clearance: they can be delivered immediately but must be reported to ZATCA within 24 hours. The compliance obligation exists, but the real-time bottleneck does not.

This architecture creates three non-negotiable requirements for IT teams that post-audit and network-based systems do not:

Real-time API connectivity to ZATCA. Your invoice generation system must maintain a live integration with FATOORAH. If the connection fails, you cannot legally issue B2B invoices until it is restored.
ZATCA-compliant XML generation. Every invoice must conform to ZATCA's UBL 2.1-based schema, complete with cryptographic signing, QR codes, and specific mandatory fields. Partial compliance means rejection.
Rejection handling workflows. When ZATCA returns validation errors, your system needs to surface those errors, allow correction, and resubmit. Unlike post-audit systems where errors surface weeks or months later, clearance model rejections happen in seconds and block the transaction.

This design is deliberate. Saudi Arabia's clearance model is a cornerstone of its Vision 2030 economic diversification strategy. Real-time tax visibility gives the government immediate insight into commercial activity across the kingdom, supporting non-oil revenue collection and reducing the shadow economy. Waiting for quarterly VAT returns to understand economic activity is no longer acceptable when every B2B invoice can be validated at the moment of issuance.

The practical consequence is straightforward: you cannot treat Saudi e-invoicing as a reporting exercise bolted onto existing workflows. The clearance model demands that compliance is embedded into your invoice generation process itself.

Phase 1 vs Phase 2: What Each Stage Requires

Saudi Arabia's e-invoicing mandate rolled out in two distinct phases, each with fundamentally different compliance obligations. Understanding where your business stands across these phases determines the scope of work ahead.

Phase 1: Generation Phase

Phase 1 went live on December 4, 2021, and applies to all VAT-registered taxpayers in Saudi Arabia. The core requirement is straightforward: businesses must generate and store invoices electronically through a compliant invoicing solution. Handwritten invoices, PDF scans, and manually created documents are no longer legally valid.

Under Phase 1, every invoice must be produced in a structured electronic format and include specific mandatory fields such as the seller's VAT registration number, invoice date, line item details, and VAT amounts. Simplified invoices issued for B2C transactions must also contain a QR code that encodes key invoice data for verification.

The critical distinction of Phase 1 is what it does not require. There is no integration with ZATCA's systems. Businesses generate compliant invoices locally, store them according to retention requirements, and deliver them to buyers through their existing channels. No data flows to the tax authority in real time.

Phase 2: Integration Phase

Phase 2, the integration phase, began on January 1, 2023 and represents a far more demanding technical undertaking. Rather than simply generating invoices locally, businesses must connect their invoicing systems directly to ZATCA's FATOORAH platform through API integration.

The obligations differ by invoice type:

Standard invoices (B2B and B2G) must be submitted to ZATCA for clearance before they can be delivered to the buyer. ZATCA validates the invoice data, applies a cryptographic stamp, and returns the cleared invoice. Until ZATCA clears it, the invoice cannot legally be issued.
Simplified invoices (B2C) operate under a reporting model. These must be transmitted to ZATCA within 24 hours of issuance, but do not require pre-clearance before the transaction completes.

Phase 2 also introduces strict technical format requirements. All invoices must conform to UBL 2.1 XML format with ZATCA-specific extensions. Each invoice must carry an ECDSA cryptographic stamp that proves its authenticity and integrity. QR codes expand beyond Phase 1 requirements to include additional security fields that enable verification against ZATCA's records.

Before a business can issue any Phase 2 invoice, it must obtain a Cryptographic Stamp Identifier (CSID) from ZATCA. This identifier is bound to the invoicing solution and used to digitally sign every invoice the system produces.

The Gap Between Phases

Businesses already compliant with Phase 1 still face a substantial jump to Phase 2. Phase 1 required selecting a compliant invoicing tool and ensuring correct field formatting. Phase 2 demands API connectivity to the FATOORAH e-invoicing platform, cryptographic signing infrastructure, UBL 2.1 XML generation capabilities, and the operational resilience to handle real-time clearance workflows without disrupting invoice delivery to buyers. The technical integration, testing, and certification process typically requires months of preparation before a business's designated compliance wave arrives.

Wave Rollout Schedule and Your Compliance Deadline

ZATCA is enforcing Phase 2 integration through a wave-based rollout, each wave targeting businesses above a specific annual revenue threshold. The threshold has dropped steadily since Wave 1 launched in January 2023 for businesses exceeding SAR 3 billion. With each successive wave, smaller businesses are pulled into mandatory integration, and the pace is accelerating through 2026.

Twenty-four waves have been announced to date. The two most relevant for businesses not yet integrated:

Wave	Enforcement Date	Revenue Threshold
Wave 23	March 2026	Exceeding SAR 500,000
Wave 24	June 2026	Exceeding SAR 375,000

These thresholds mean that the vast majority of VAT-registered businesses in Saudi Arabia will fall under Phase 2 requirements by mid-2026. If your business generates annual revenue above SAR 375,000, you have a concrete deadline on the calendar.

Do Not Wait for ZATCA Notification

ZATCA notifies affected taxpayers directly before each wave's enforcement date. However, treating that notification as your starting signal is a mistake. The integration process involves selecting and configuring a compliant ERP or invoicing solution, completing CSID registration, passing conformance testing, and running production validation. That sequence takes weeks at minimum, often months for businesses without existing API infrastructure. Begin preparation based on your revenue bracket, not the arrival of an official letter.

Tax Amnesty Initiative: A Narrowing Window

ZATCA's Tax Amnesty Initiative, relaunched in January 2026 and running through mid-2026, offers reduced penalties for businesses that regularize their compliance status during this period. The window closes around the same time Wave 24 takes effect, so businesses in the SAR 375,000 to SAR 500,000 revenue range face a convergence of deadline and opportunity. The specific penalties the amnesty addresses are covered in the non-compliance section below.

Planning Your Compliance Timeline

Start with three questions: Are you currently Phase 1 compliant (generating and storing invoices in the mandated XML or PDF/A-3 format)? Does your revenue place you in Wave 23, Wave 24, or a future wave? Do you have an integration-ready invoicing system, or will you need to implement one?

If you are Phase 1 compliant and your ERP vendor supports ZATCA integration, your primary tasks are CSID registration and conformance testing. Budget four to eight weeks for this process, including time for failed test submissions and resubmissions.

If you are not yet Phase 1 compliant, you face a compressed timeline that requires simultaneous work on generation requirements and integration readiness. Prioritize selecting a ZATCA-certified solution provider and beginning the onboarding process immediately. The CSID registration process cannot begin until your system can produce structurally valid invoices.

Technical Requirements for Phase 2 Integration

Phase 2 (Integration Phase) demands a significant technical lift compared to Phase 1's relatively straightforward generation requirements. Businesses must produce invoices in a specific structured format, cryptographically sign each document, generate compliant QR codes, and integrate directly with ZATCA's platform for clearance or reporting. Below is a breakdown of each technical requirement.

Invoice Format: UBL 2.1 XML with ZATCA Extensions

ZATCA mandates that all e-invoices conform to Universal Business Language (UBL) 2.1 XML, but with Saudi-specific extensions that go beyond standard Peppol UBL schemas. ZATCA has published detailed technical guidelines specifying the exact XML schema, mandatory fields, and validation rules that each invoice document must satisfy. These extensions cover Saudi-specific tax treatment codes, supply type identifiers, and additional buyer/seller identification fields beyond what generic UBL supports.

PDF/A-3 format is also accepted, provided the compliant UBL 2.1 XML is embedded within the PDF file. This approach lets businesses generate human-readable invoices while still carrying the machine-readable XML payload that ZATCA's systems require for validation. Regardless of format choice, the XML content is what ZATCA's clearance platform actually processes and validates.

A full list of mandatory fields on Saudi Arabia VAT invoices, including buyer and seller identification requirements, is covered in the companion guide on Saudi VAT invoice compliance.

Cryptographic Signing and Stamps

Every invoice submitted under Phase 2 must carry an ECDSA (Elliptic Curve Digital Signature Algorithm) cryptographic stamp that conforms to ETSI standards. This stamp serves two purposes: it guarantees the invoice has not been altered after issuance (integrity), and it provides non-repudiation, meaning the issuing business cannot deny having generated the invoice.

The cryptographic stamp is generated using the business's Cryptographic Stamp Identifier (CSID), which is obtained through the ZATCA onboarding process covered in the next section. Each invoice's XML payload is signed at the point of generation, and ZATCA's platform verifies this signature during the clearance or reporting process. If the stamp is invalid or missing, the invoice is rejected.

Invoice Identifiers and Sequencing

Two identification requirements apply to every Phase 2 invoice:

UUID (RFC 4122): Each invoice must include a universally unique identifier generated according to the RFC 4122 standard. This UUID serves as the primary identifier within ZATCA's systems and must be unique across all invoices issued by the business.
Invoice Counter Value (ICV): Invoices must carry a sequential counter value that increments with each new document. Gaps in the sequence are flagged during validation, so ERP systems must maintain strict sequential integrity even across system restarts or multi-user environments.

QR Code Requirements

ZATCA QR codes use TLV (Tag-Length-Value) encoding, Base64 encoded, with a maximum of 500 characters. The minimum print size is 2x2 cm on any physical or PDF representation of the invoice.

Phase 1 QR codes require a minimum of five mandatory fields:

Seller name
VAT registration number
Invoice timestamp
Invoice total (inclusive of VAT)
VAT total

Phase 2 QR codes expand on this by adding three additional fields:

Cryptographic stamp
Public key
Signature hash

These additional fields allow any party scanning the QR code to verify the invoice's authenticity and integrity without needing access to ZATCA's platform. ZATCA publishes an official QR Code Reader app for both iOS and Android, which businesses, auditors, and tax inspectors can use to validate QR codes against the expected data structure.

Sandbox Environment for Developer Testing

ZATCA provides a sandbox environment at sandbox.zatca.gov.sa where development teams can test their integration before submitting real invoices. The sandbox mirrors the production clearance and reporting APIs, allowing businesses to validate XML schema compliance, test cryptographic signing workflows, verify QR code generation, and confirm proper API authentication using test CSIDs.

This testing infrastructure is one of the most practical resources available for compliance preparation. Running invoices through the sandbox before go-live catches formatting errors, signing issues, and field validation failures that would otherwise result in rejected invoices in production. Businesses should plan for at least one full billing cycle of sandbox testing before switching to the live environment.

Handling ZATCA Rejections

When ZATCA's clearance platform rejects an invoice, it returns a structured error response identifying the specific validation failure. Common rejection categories include XML schema violations (missing mandatory elements, incorrect data types, namespace errors), cryptographic stamp failures (invalid signature, expired CSID, hash mismatch), mandatory field omissions (missing UUID, seller VAT number, or supply type code), and tax calculation mismatches (where the line-item VAT totals do not reconcile with the invoice-level VAT amount).

Your invoicing system must be designed to handle these rejections gracefully. The practical workflow is: receive the rejection response, parse the error code and description, surface the issue to the relevant user or system, correct the underlying data, and resubmit. Because clearance rejections block the invoice from being delivered to the buyer, unresolved errors directly impact your ability to conduct business. Systems that queue rejected invoices for manual review without clear error categorization create bottlenecks during high-volume periods.

Building rejection handling into your integration from the start, rather than treating it as an edge case, prevents operational disruption once you move from sandbox to production.

CSID Registration: Step-by-Step Process

The Cryptographic Stamp Identifier (CSID) is the digital certificate ZATCA issues to each business, authorizing it to cryptographically sign invoices. Without a valid CSID, your ERP or invoicing solution cannot submit documents to the FATOORAH platform for clearance. Most compliance guides mention CSID in passing, but the actual registration workflow involves multiple sequential steps, each with its own requirements and potential failure points.

Think of the CSID as your business's cryptographic identity within the ZATCA ecosystem. It binds your tax registration number, organization details, and a unique cryptographic key pair into a certificate that ZATCA recognizes and trusts. Every invoice your system signs with this certificate carries verifiable proof of origin.

Step 1: Generate a One-Time Password from the ZATCA Portal

The process begins in the ZATCA online portal, where an authorized representative logs in and generates a One-Time Password (OTP). This OTP serves as a short-lived authorization token that links the upcoming certificate request back to your verified business identity. OTPs expire within a limited window, so the technical team responsible for the next step should be ready to proceed immediately after generation.

Step 2: Create and Submit a Certificate Signing Request

Using the OTP, your technical team generates a Certificate Signing Request (CSR). The CSR is a structured data file containing your organization's legal name, tax identification number, VAT registration number, and the public key from a newly generated cryptographic key pair. This CSR is submitted to ZATCA's designated API endpoint, authenticated by the OTP from Step 1.

The CSR must conform to ZATCA's exact formatting requirements. Common causes of rejection at this stage include mismatched organization names (the name must exactly match your tax registration), incorrect encoding of Arabic characters, and improperly formatted key parameters.

Step 3: ZATCA Compliance Validation

Once the CSR reaches ZATCA's servers, the authority runs automated compliance checks. These checks verify that the submitted organization details match existing tax registration records, that the VAT number is active and in good standing, and that the CSR's technical format meets ZATCA's cryptographic standards. This validation step is not instantaneous and may surface discrepancies between your submitted details and what ZATCA has on file.

If the compliance check fails, ZATCA returns specific error codes indicating the nature of the mismatch. Resolving these errors sometimes requires updating your tax registration details through separate ZATCA channels before reattempting the CSR submission.

Step 4: Receive the Compliance CSID

When the compliance check passes, ZATCA issues a compliance CSID. This is a temporary certificate intended exclusively for sandbox testing. The compliance CSID allows your invoicing system to connect to ZATCA's test environment, submit sample invoices, and verify that your XML generation, QR code embedding, and cryptographic signing all conform to FATOORAH specifications.

The sandbox phase is where most integration issues surface. Malformed XML fields, incorrect hash calculations, and timestamp formatting errors are among the frequent problems identified during compliance CSID testing. Resolving them here is far preferable to encountering them in production.

Step 5: Request the Production CSID

After your system passes all sandbox validation scenarios using the compliance CSID, you submit a request for the production CSID. ZATCA reviews the test results and, upon confirmation that your integration meets all technical requirements, issues the live production certificate. This is the CSID your system will use to sign every real invoice submitted for clearance.

The production CSID activates your business within the live FATOORAH clearance system. From this point forward, every invoice your system generates must be signed with this certificate before submission.

Step 6: Track Renewal Deadlines

Production CSIDs carry an expiry date, typically set at one year from issuance. Operating with an expired CSID means your system can no longer sign invoices that ZATCA will accept, effectively halting your ability to issue compliant invoices. Businesses should build renewal tracking into their compliance calendar and initiate the renewal process at least 30 days before expiry to account for any delays in ZATCA's processing.

Renewal follows a similar flow to the initial issuance: generate a new OTP, submit a fresh CSR, and receive an updated production CSID. The transition should be planned so that the new certificate is active before the old one expires, avoiding any gap in signing capability.

Multi-Entity Considerations

Each VAT-registered entity within your organization requires its own CSID. Multinational businesses operating multiple legal entities, branches, or VAT groups in Saudi Arabia must complete the registration process separately for each one. Plan for parallel registration workstreams and account for the possibility that compliance validation may surface different issues across entities, particularly where registration details vary between branches.

Start Early

The full CSID registration process, from OTP generation through production certificate issuance, can take several weeks when accounting for compliance check delays, sandbox testing iterations, and error remediation. Businesses approaching their wave enforcement date should begin the CSID process months in advance rather than treating it as a last-minute task. A failed compliance check or a sandbox integration issue discovered two weeks before your deadline leaves almost no margin for correction.

Penalties for Non-Compliance

ZATCA enforces e-invoicing requirements through a structured penalty framework that escalates with each repeated violation. Understanding this framework is essential for assessing the financial exposure your business faces if compliance timelines slip.

The baseline penalties cover three categories of non-compliance:

Failure to issue or retain electronic invoices: Starting fine of SAR 5,000 per occurrence.
QR code non-compliance: Fines up to SAR 10,000 per invoice missing a valid QR code or containing incorrect QR data.
Failure to integrate with ZATCA's platform (Phase 2): Fines up to SAR 50,000 for businesses that do not complete integration with the FATOORAH portal by their designated wave deadline.

These figures represent starting points. The real risk lies in the escalation mechanism that applies within rolling 12-month periods. For a given violation type, the progression follows a defined pattern:

First offense: Warning notice
Second offense: SAR 1,000
Third offense: SAR 5,000
Fourth offense: SAR 10,000
Fifth and subsequent offenses: SAR 40,000 or more

Each violation is tracked independently, so a business that fails to issue compliant invoices across multiple transactions can accumulate penalties rapidly. A company processing hundreds of invoices monthly could face substantial aggregate fines within a single quarter if systemic issues go unaddressed.

The most severe consequence is reserved for repeat offenders who show a pattern of disregard for the mandate: ZATCA can suspend the business's VAT registration. Since VAT registration is a prerequisite for issuing tax invoices and conducting B2B transactions in Saudi Arabia, suspension effectively halts commercial operations. Reinstatement requires demonstrating full compliance and settling all outstanding penalties.

Businesses that have fallen behind can take advantage of ZATCA's Tax Amnesty Initiative, relaunched in January 2026 and running through mid-2026. The amnesty program allows non-compliant businesses to regularize their status with reduced penalty exposure on late registration, late filing, and late payment of taxes, including penalties connected to e-invoicing obligations.

The initial warning and lower fines give businesses a genuine opportunity to identify and correct issues before financial consequences become severe. But the steep escalation means that a systemic invoicing defect, not just a single missed invoice, can generate six-figure aggregate exposure within a single year.

Processing Received ZATCA-Compliant Invoices

Most ZATCA compliance guides focus entirely on generating invoices that meet Phase 2 requirements. But compliance is a two-way street. As the mandate rolls across successive waves, every invoice your business receives from Saudi-based suppliers will arrive as a ZATCA-cleared document in UBL 2.1 XML or PDF/A-3 format. For AP teams processing hundreds or thousands of supplier invoices each month, this shift from unstructured PDFs to standardized electronic documents represents a fundamental change in how received invoice data can be captured and used.

What a ZATCA-Cleared Invoice Contains

A ZATCA-compliant invoice that has passed through the clearance portal carries far more structured information than a traditional PDF. The UBL 2.1 XML schema organizes every data point into machine-readable fields: seller and buyer tax identification numbers, invoice issue date and supply date, line-item descriptions with quantities and unit prices, VAT category codes and tax amounts per line, invoice totals and rounding adjustments, and payment terms. Beyond the transactional data, each cleared invoice includes a cryptographic stamp that proves ZATCA validated the document, along with a QR code encoding the seller's name, VAT registration number, invoice date, total amount, and VAT amount.

This standardization is the key difference from pre-ZATCA invoicing. Where AP teams previously dealt with inconsistent PDF layouts across suppliers, ZATCA-cleared invoices follow a single data schema. The fields are in predictable locations, use standardized code lists, and carry verified tax calculations.

The PDF/A-3 Extraction Challenge

While some suppliers transmit invoices as pure XML, many send PDF/A-3 files, which are archival-quality PDFs with the full UBL 2.1 XML embedded as an attachment. The human-readable PDF layer shows the invoice visually, while the embedded XML contains the structured data. This dual-layer format creates a specific extraction requirement: your processing tools need to parse both the visual document and the embedded XML to capture complete, verified data.

Businesses receiving invoices in Arabic face an additional consideration. Arabic script runs right-to-left, and many invoices include both Arabic and English text. Extraction tools that cannot handle bidirectional text layout will produce garbled or misaligned output, particularly in line-item descriptions and address fields.

Building a Receiving-End Workflow

AP teams that build their extraction workflow around the ZATCA standard gain a reliability advantage. Because every compliant invoice follows the same UBL 2.1 schema, extraction rules work consistently across all suppliers rather than requiring per-vendor templates. A practical workflow looks like this:

Ingest supplier invoices in whatever format they arrive (XML, PDF/A-3, or mixed batches).
Extract structured fields: invoice numbers, dates, supplier details, line items with quantities and unit prices, VAT breakdowns by category, and totals.
Validate the cryptographic stamp and QR code data against the extracted fields to confirm the invoice passed ZATCA clearance.
Map the extracted data to your accounting or ERP system's chart of accounts and vendor master records.
Archive the original ZATCA-compliant document alongside the extracted data for audit purposes, since Saudi tax law requires retention of e-invoicing records for the standard statutory period.

The volume dimension matters here. A business receiving invoices from dozens or hundreds of Saudi suppliers cannot manually key in data from each UBL 2.1 document. Tools that automate invoice data extraction from ZATCA-compliant documents turn the standardized ZATCA format into an advantage: batch processing of mixed PDF and XML files, with extraction covering both invoice-level summaries and individual line items including product codes, quantities, tax categories, and amounts. Arabic script and right-to-left text layout must be handled natively, not as an afterthought, since a significant share of Saudi supplier invoices will contain Arabic descriptions and addresses.

Why Standardization Works in Your Favor

The irony of ZATCA's strict compliance requirements is that they make the receiving side easier, not harder. Before e-invoicing mandates, AP teams dealt with wildly inconsistent invoice formats. A supplier in Riyadh might send a scanned PDF with handwritten notes, while another in Jeddah used a custom ERP-generated layout. Each format required different extraction logic or manual handling.

Under Phase 2, every cleared invoice contains the same field structure, uses the same tax category codes, and has been validated by ZATCA before it reaches you. This consistency means that once your extraction process handles the UBL 2.1 schema correctly, it works for every ZATCA-compliant supplier without per-vendor customization. The data arrives pre-validated, structured, and ready for automated capture into your financial systems.