A finance team facing repeated failed transmissions to ZATCA usually has an integration design problem to investigate, although certificate expiry, data errors and provider outages can also be causes.

Many businesses do not build ZATCA connectivity themselves. They integrate their ERP or billing system to a certified e-invoicing solution which handles XML generation, signing, clearance and reporting. The integration work is mapping your data into that solution correctly and handling every response it can return, which is where Phase 2 projects succeed or fail.

Mapping the data correctly

ZATCA's schema demands fields many ERP systems hold loosely or not at all. These include the buyer VAT registration number validated to the correct format, item-level VAT category codes, and prepayment references. Discounts must be treated correctly at line and document level, and credit notes linked to the original invoice. Mapping exercises often uncover that customer master data has incomplete VAT numbers or that discounts are recorded in a way ZATCA's schema cannot represent.

Multiple source systems

Many businesses issue invoices from more than one place: an ERP for project billing, a point of sale for retail, a separate rental or service system. Each needs to reach ZATCA, and each may need different treatment because one issues standard invoices requiring clearance and another simplified invoices requiring reporting. The integration architecture has to account for all of them, including the smaller ones.

Monitoring and reconciliation

Once live, someone must know daily that every invoice issued was successfully transmitted. We implement a reconciliation between invoices in the source system and invoices acknowledged by ZATCA, with exception alerting. The failure mode that causes real damage is silent: invoices that were never transmitted, discovered weeks later during a VAT return preparation or, worse, during an audit.

A hypothetical example

Consider a Riyadh equipment rental business that integrates its ERP successfully, then finds that invoices from a separate maintenance contract system were never in scope and have not been reported to ZATCA. Bringing them into compliance means correction work that scoping every invoice source at the start would have avoided.

Choosing the solution provider

Certified providers differ in ways that matter operationally. These include how they handle outages, whether archival meets the statutory retention requirement, and how errors are surfaced to finance staff instead of hidden in logs. Support in Arabic within Riyadh business hours is another point of difference. We evaluate these alongside price, not after selection.

Who owns it after go-live

An integration without a named owner degrades quietly. Someone must watch the daily reconciliation, act on rejected invoices, renew the cryptographic stamp identity before it expires and re-test after any ERP or POS update. We define that ownership and document the runbook, or where the client prefers, the operation is handled as part of outsourced ZATCA compliance. Either way, ownership continues as part of ongoing e-invoicing compliance after go-live.

Testing every invoice type you issue

Testing with a standard sample hides more problems than it finds. We list every document type your business issues, and run each in the sandbox before go-live. Examples are standard and simplified invoices, credit and debit notes, prepayment invoices, foreign-currency invoices and invoices mixing zero-rated and exempt lines. An untested type is the one most likely to fail once live operation starts.