ZATCA Phase 2: What Clearance Changes About Your System
Phase 1 asked you to generate a structured invoice. Phase 2 asked you to hand it over before you may issue it. That is not a bigger compliance task — it is a different system architecture, and most shortlists have not caught up with what it implies.
There is a sentence that used to be true of every business system ever sold and is no longer true in Saudi Arabia: your system issues your invoice. Under the integration phase of ZATCA e-invoicing, a standard tax invoice is sent to the authority, validated, stamped and returned before it may go to your customer. The document your customer receives was finished somewhere else.
Almost everyone treats this as a compliance project — a thing to be procured, implemented and then forgotten about. It is worth about an hour of a different kind of attention, because it quietly changes what an ERP is for, and therefore what you should be shopping for.
Nothing here is tax advice. Wave scope, deadlines and technical specifications are set by ZATCA and are notified to taxpayers individually. Confirm your own obligation and its timing with ZATCA or your tax adviser — not with a software vendor, including this one.
Generating and handing over are different problems
The generation phase asked for a structured electronic invoice carrying certain fields and a QR code. That is a formatting requirement. Your system did more work, but it was still your system doing the work, at your own pace, on your own infrastructure.
The integration phase asks for something categorically different: a live connection to ZATCA's Fatoora platform from an onboarded generation unit holding its own cryptographic certificate, and — for standard invoices — a real-time exchange in the middle of your sales process. The two document types are handled differently, and the difference is the whole story.
Standard invoice (B2B) — clearance
- The signed XML goes to ZATCA before the invoice reaches your customer.
- ZATCA validates it, applies its own cryptographic stamp and returns the cleared document.
- Until that returns, you do not have an invoice to send. This is a synchronous dependency inside your sales process.
- A rejection is not a filing problem. It is a stopped transaction, in business hours, with a customer waiting.
Simplified invoice (B2C) — reporting
- The invoice is stamped on your side and given to the customer immediately.
- It is reported to ZATCA afterwards, within twenty-four hours.
- The counter does not wait, which is the entire reason the two models differ.
- The failure mode is quieter and therefore worse: a batch fails overnight and nobody finds out for a week.
The consequence nobody puts on a slide
Once clearance is in place, your operations system is no longer the system of record for its own sales document. It holds a sale. ZATCA holds the invoice that legally exists. Those are two different objects and they are stored in two different places by two different parties.
For most of the time this distinction is academic and nothing goes wrong. It stops being academic at exactly three moments: when an invoice is rejected and the goods ship anyway, when a month-end total does not match what the authority has, and when somebody asks a question that requires both halves at once.
You have not bought one system with a compliance feature. You have bought two systems with a seam between them, and the seam is where the work is.
What actually crosses, and which direction
It helps to be concrete about the artefacts. There are four of them, they are born in different places, and the question that decides your architecture is whether each one ends up where it is needed.
| The artefact | Born where | Needed where | Usually arrives? |
|---|---|---|---|
| The sale — customer, lines, quantities, prices | Your operations system | Both | Yes |
| The signed XML document | The e-invoicing solution | ZATCA | Yes |
| ZATCA's cryptographic stamp and cleared XML | ZATCA | Your archive | Usually, in the provider's portal |
| The UUID and invoice hash | The clearance exchange | Your sales record | Frequently not |
| The clearance status, including failures | The clearance exchange | Whoever can act on it | Almost never |
| The goods movement behind the invoice | Your operations system | Nowhere fiscal | Not applicable |
The two bolded rows are the entire subject of this post. Everything else is handled by any competent provider. Those two are the ones that fall on the floor, because they are the return leg, and the return leg is nobody's deliverable.
How this goes wrong, in order
Nothing dramatic happens. That is what makes it worth writing down.
-
The e-invoicing project is scoped as an integration to ZATCA
Which it is. The scope document describes everything going out and says nothing about anything coming back, because the obligation is discharged the moment the document clears. The provider delivers exactly what was asked for.
-
Clearance status lives only in the provider's portal
A separate login, held by one or two people in finance. It is perfectly good software. It is simply not where anybody in sales, dispatch or the warehouse works, so nobody looks at it during the working day.
-
A rejection happens and the operation does not notice
A field is malformed, a customer's registration number is wrong, a certificate has expired. The operations system shows a completed sale. The goods leave. The absence of a cleared invoice is discovered later — by someone reconciling, not by someone who could have stopped it.
-
Month-end becomes a reconciliation nobody owns
Two lists, exported, matched by reference in a spreadsheet. It takes half a day when it works. When it does not, it takes a week and the answer is a judgement call rather than a fact.
-
An audit asks for the trail and it has to be assembled
The cost is not the penalty. The cost is that three people spend a fortnight proving something that a well-drawn seam would have made a two-second query.
The discipline that prevents all of it
This is not sophisticated. It is four decisions, all of which are nearly free before go-live and irritating afterwards.
Four things to insist on before you sign
- The UUID, hash and clearance status come back and are written onto your sales record. Not into a log, not into the provider's portal alone — onto the transaction your team already looks at. This is the single decision that makes everything below possible.
- The cleared document is attached to that transaction. Storing the authority's copy of a document in a different system from the sale it belongs to is a filing decision you will regret exactly once.
- A failed clearance produces a visible, owned exception. Named owner, somewhere a human already looks, with an escalation if it is still open after some agreed number of hours. Silence must not be indistinguishable from success.
- "Sales with no clearance identifier" is a report you can run. If you cannot run it on demand, in under a minute, you do not have a reconciliation process — you have a monthly act of faith.
Where AWRA OpsHub sits in this, plainly
On the near side of the seam, and nowhere else. We have no ZATCA integration: no onboarded generation unit, no cryptographic certificate, no UBL 2.1 output, no stamping, and no clearance or reporting call to Fatoora. Our only fiscal e-invoicing integration anywhere is Kenya's eTIMS and it is not portable. In Saudi Arabia, AWRA cannot be the system that issues your tax invoices — we would rather write that sentence here than have you discover it in a demo. What we do is everything upstream: procurement, stock, site materials, plant, cost and evidence, with the discipline above applied at the join.
Questions worth putting to an e-invoicing provider
These are not gotchas. They are the four questions whose answers determine how much manual work you inherit, and a good provider will answer them briskly.
Four questions, and what a vague answer usually means
Do the clearance identifiers come back to our other systems?
The answer you often get
Everything is available in the portal and via our API.
What to press for instead
Available is not the same as delivered. Ask specifically: does your solution push the UUID, hash and status back, or must we poll for it? Who builds that? Is it in this scope or a change request? "Via our API" with no line item usually means "not in this project".
What happens when a clearance fails?
The answer you often get
Failures are logged and can be resubmitted.
What to press for instead
Logged where, and who is told? Ask to see the actual notification path for a rejection at three in the afternoon. If the answer is that someone checks the portal, that is a person, not a process, and it will fail during their annual leave.
How do we reconcile our sales to what ZATCA holds?
The answer you often get
You can export from both and compare.
What to press for instead
That is a description of the problem, not a solution. Ask what the intended monthly routine is, how long it takes, and who owns it. If nobody has thought about it, you have just found the work that lands on your finance team by default.
What happens if we change providers in two years?
The answer you often get
Migration is straightforward.
What to press for instead
Ask what you keep. The cleared XML archive, the identifiers, the mapping to your own references — in an open format, exportable without their assistance? If the clearance identifiers only ever lived in their system, the switching cost is much higher than the licence difference suggests.
What AWRA OpsHub does today
- Sales, purchases and stock movements with net, tax and gross separated at capture, and a 15% VAT preset shipping built in.
- Documents attached to the transaction they belong to, checksummed and access-logged — so an attached cleared invoice is retrievable rather than filed somewhere adjacent.
- An API and a custom fields layer, which is the mechanism by which a returned identifier would land on a sales record.
- Reports you can build yourself over your own transaction data, which is what turns "sales with no clearance identifier" from a request into a saved view.
What it does not do
- No ZATCA or Fatoora integration of any kind. No generation unit, no certificate, no UBL 2.1 XML, no stamping, no clearance call, no reporting call.
- No prebuilt connector to any Saudi e-invoicing provider. The seam described above is a build, and we would scope it as one rather than imply it ships.
- No VAT return, Zakat or corporate income tax computation, and no statutory accounts.
- No Arabic interface and no right-to-left layout, which in this market is frequently the disqualifying item rather than this one.
We have put the fourth "not built" item last deliberately, but it is often first in importance. A system your storekeeper cannot read is not fixed by an elegant integration.
What is not built for Saudi Arabia today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Saudi Arabia. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a clean seam to your ZATCA provider, an Arabic interface, a bank or mobile money feed, a statutory return format or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
The ZATCA seam, not a ZATCA integration
A two-way link to the accredited provider that clears your invoices: our sale handed over in the shape their generation unit expects, and the UUID, hash and clearance status written straight back onto our transaction with the cleared document attached. That turns "which sales have no clearance record?" into a daily report. We will not offer to become the clearing party ourselves — that certificate belongs with an accredited provider and we would rather say so than sell you the pipe.
Arabic interface, banks and acquirers
Arabic interface text with right-to-left layout and bilingual document templates, plus bank statement feeds, card acquirer settlements and SADAD or instant-payment files wired into the Payments Register so collections match invoices without anyone re-keying a statement.
Payroll and statutory returns
A Saudi payroll engine with GOSI contributions calculated on live employee records, Mudad wage files in the layout the Wage Protection System expects, and the establishment's Saudization position visible before a deadline rather than after one.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedSo what should you actually do
- Confirm your own wave and deadline with ZATCA, directly. Waves are notified to taxpayers individually and the threshold has moved repeatedly; a vendor's summary is not a substitute for your own notification.
- Buy clearance from someone accredited to provide it. This is not a place to be clever, and it is not a place where an international operations product should be asking for your trust.
- Then negotiate the seam, in writing, before either contract is signed. Which system holds the identifier, who is told about a failure, and what the monthly reconciliation looks like. One page.
- Treat the return leg as a deliverable with a name against it. If it is in nobody's scope, it is in your finance manager's scope, and they have not been told.
- Only then shop for the operations layer. Stock, procurement, cost and evidence are a genuinely separate purchase, and thinking about them while the compliance question is unsettled produces bad decisions in both.
Our take
Clearance did not make Saudi businesses buy more compliance software; it made every Saudi business a multi-system business whether they planned for it or not. The winners are not the ones with the best integration — most providers clear invoices perfectly well — but the ones who noticed that the return leg had no owner and gave it one. That is an afternoon of thinking and it is worth more than the difference between any two products on your shortlist.
Mapping the seam around your ZATCA provider?
We are the operations half, not the clearance half, and we will say so on the first call. If what you need is the upstream — procurement, stock, materials, plant and cost — with a clean join to whoever clears your invoices, that is a conversation worth having.
Talk to us about Saudi ArabiaFrequently asked questions
Does AWRA OpsHub integrate with ZATCA?
No. There is no onboarded generation unit, no cryptographic certificate, no UBL 2.1 XML output, no stamping, and no clearance or reporting call to the Fatoora platform. Our only fiscal e-invoicing integration anywhere in the product is Kenya's eTIMS, which was commissioned by Kenyan clients and does not transfer to another regime. The practical meaning is unambiguous: in Saudi Arabia, AWRA cannot be the system that issues your tax invoices. We sit upstream of that and alongside it.
What is the difference between clearance and reporting?
Clearance applies to standard tax invoices — broadly the business-to-business ones. The signed document goes to ZATCA first, is validated and stamped, and only then may be issued to the customer, which makes it a live, synchronous step inside your sales process. Reporting applies to simplified invoices, broadly the business-to-consumer ones: those are stamped on your side and given to the customer immediately, then reported to ZATCA within twenty-four hours. The distinction matters operationally because the two have completely different failure modes — a clearance failure stops a transaction visibly, while a reporting failure is silent and can accumulate for days before anyone notices.
Who is in scope for the integration phase now?
The integration phase has been rolled out in waves, each defined by a revenue threshold and notified by ZATCA to the taxpayers concerned. Successive waves have brought that threshold steadily down, and it has now reached the same figure as the VAT registration threshold itself, which in practical terms means the phase reaches essentially every VAT-registered business in the Kingdom. That said, your own scope and deadline are a matter of the notification ZATCA sends you. Check it with ZATCA or your tax adviser rather than relying on any vendor's summary, including this paragraph.
Can we keep our existing ERP and add a compliance layer?
Yes, and this is the most common architecture in the market — it is what clearance effectively forces. The thing to get right is not the choice of layer but the join between them: whether the UUID, hash and clearance status come back onto the sales record in the system your team actually works in, whether the cleared document is attached to that transaction, and whether a failure produces an exception that a named person sees. Agree those three things in writing before either contract is signed, because retrofitting them costs several times what specifying them costs.
What does a good reconciliation between the two systems look like?
It looks like a report rather than a routine. If the clearance identifier is stored on your own sales record, then "show me every sale this period with no clearance identifier" is a query you can save and run in seconds, and the reconciliation becomes an exception list that is normally empty. If the identifier only lives in the provider's portal, you are instead exporting two lists and matching them by reference in a spreadsheet every month — which works, but is a recurring half-day of skilled time and produces a judgement rather than a fact whenever the references do not line up cleanly.
Is the interface available in Arabic?
No — English only, with no right-to-left layout, and documents produced in English. We flag this in a post about e-invoicing because it is frequently the more decisive limitation of the two. An integration gap can be closed with a second product; a system your storekeepers, site supervisors and finance staff cannot comfortably read cannot. Test it with the people who would key transactions, and treat "they will manage" as a no.
