Does ZATCA e-invoicing apply to a company registered outside Saudi Arabia?

Not because of where it is registered, and not because it has Saudi customers. The obligation attaches to a taxpayer: an entity registered for VAT in the Kingdom and resident there for tax purposes. In almost every real case the entity issuing Saudi invoices is a Saudi branch, subsidiary or establishment, and that entity is the one in scope. Whether your specific structure creates a registration obligation is a question for a tax adviser and for zatca.gov.sa, not for an article.

We sell to Saudi businesses and the buyer accounts for the VAT under reverse charge. Do we still e-invoice?

Reverse charge decides who accounts for the VAT, not whether an entity is subject to the e-invoicing regulation. If a Saudi-resident entity of yours issues the invoice, that invoice follows the same rules as any other. If no Saudi entity issues it, the question goes back to registration and residency, which is adviser territory. This is the single situation where paying for an hour of professional advice is cheapest.

Which VAT number goes on the invoice when the parent company is abroad?

The VAT number of the Saudi entity that is the seller, in the seller field (BT-31) — never the parent's foreign tax number. If that entity belongs to a Saudi VAT group, the group number is what is written. A missing seller VAT number is rejected outright under BR-KSA-39, and a foreign tax identifier cannot stand in for it in any case: the field is checked for the Saudi format of fifteen digits beginning and ending with 3, under BR-KSA-40. Both are setup errors rather than typing ones, so they fail every invoice until they are fixed.

Can we issue our Saudi invoices in English only?

No. The Authority's published requirements on zatca.gov.sa put Arabic on the tax invoice. A bilingual invoice is entirely acceptable, and is what most companies with a foreign parent end up using: Arabic alongside English, one document. The underlying XML carries the structured data either way, but the readable document handed to a buyer has to be in Arabic.

Can we invoice in US dollars or euros?

An invoice may be denominated in a foreign currency, but the total VAT has to be carried in SAR. This is the requirement that catches systems built for other markets, because they convert nothing and present a tax total in the invoice currency only. In the XML it has a specific shape: once the invoice declares a tax accounting currency, the schema expects a second tax total block holding the SAR figure alone, with no breakdown inside it — and that shape is what BR-KSA-EN16931-09 checks. Confirm the conversion rate rule that applies to you on zatca.gov.sa before you configure it.

Our servers run on UTC. Does that matter?

Yes, and it is the most avoidable rejection a foreign team hits. The invoice date is judged against the date at the Authority, in Riyadh time. A server building "today" from UTC will, for part of every day, stamp an invoice with a date the Authority reads as the future, and reject it under BR-KSA-04. Build the issue date in Riyadh time, not in your own.

We have no Saudi entity and no Saudi VAT registration. What should we do?

Confirm that with a tax adviser, and then do nothing. There is no ZATCA onboarding for a business that is not a taxpayer in the Kingdom, no certificate to obtain and no invoice to clear. Buying an e-invoicing solution before you know the answer is spending money on a problem you may not have.

Our company is outside Saudi Arabia. Does ZATCA e-invoicing apply to us?

Your company is registered in Dubai, London, Bangalore or Austin. You sell to Saudi customers. Someone — a customer's finance team, a marketplace, an auditor — has told you your invoices have to go through ZATCA, and every English page you find is a sales pitch or a translated rule that does not quite answer the question.

Here is the answer, with one limit stated up front and repeated on purpose: whether your business has to register for VAT in the Kingdom is a question for a tax adviser and for zatca.gov.sa. No article can decide it. What this one settles is everything downstream of that answer — which entity is the taxpayer, and what its invoices have to carry.

The deciding question is not where you sit

The e-invoicing regulation is not attached to a postal address or a country of incorporation. It attaches to a taxpayer, and two things decide whether a business is one: whether it is registered for VAT in the Kingdom, and whether it is resident there for tax purposes. Where your holding company was incorporated is neither of those.

So the question is almost never "does this apply to our company". It is "which legal entity issues the invoice a Saudi customer receives, and what is its status in the Kingdom". Name the entity and most of the confusion goes.

The honest corollary, which nobody selling software leads with: a business with no Saudi VAT registration and no taxable supplies in the Kingdom is not a taxpayer, is not subject to the regulation, and should do nothing. There is no certificate to obtain and no invoice to clear. Confirm it with an adviser and close this tab.

The situations, and who the taxpayer is in each

Your structure	Who issues the Saudi invoice	Is it in scope
No Saudi entity, no VAT registration, no taxable supplies in the Kingdom	Nobody, for ZATCA purposes	No. Nothing to do
Foreign parent with a Saudi subsidiary	The subsidiary, under its own VAT number	Yes, for that entity
Foreign company with a registered branch in the Kingdom	The branch	Yes, for that entity
Saudi entity inside a VAT group	The entity, carrying the group VAT number	Yes, for that entity
Cross-border B2B where reverse charge applies	Depends on which entity supplies	Ask a tax adviser
Selling online to Saudi consumers with no local entity	Decided by registration and residency	Ask a tax adviser

A foreign parent with a Saudi branch or subsidiary

This is the common case and the easy one. The Saudi entity is the taxpayer. It onboards to the Fatoora platform with its own VAT number and its own OTP from the portal, and its VAT number goes in the seller block of every invoice — not the parent's foreign tax number, however much the parent dominates the letterhead.

If that entity sits inside a Saudi VAT group, the group's number is what belongs on the invoice. Getting this wrong is not a warning; it is a rejection on every document, under BR-KSA-39.

Selling B2B to Saudi businesses

Where a non-resident supplier sells to a VAT-registered Saudi customer, VAT accounting commonly shifts to the buyer under the reverse charge mechanism: the buyer self-accounts, and there is typically no Saudi VAT for you to charge. Foreign finance teams read that as "so e-invoicing does not apply to us", and sometimes they are right.

Say it plainly: reverse charge decides who accounts for the VAT. It is not a general exemption, and it does not change the position of a Saudi-resident entity issuing invoices of its own — if your Saudi subsidiary raises the invoice, it is cleared like any other. Whether reverse charge applies to a particular supply, and what document you should issue alongside it, is the one point in this article where an hour with a tax adviser is cheaper than every other option.

E-commerce selling to Saudi consumers

There is no VAT-registered buyer to self-account here, which is why registration questions bite hardest in this case — and the answer moves depending on whether you sell direct, through a marketplace, or through a local distributor that resells. That is a structural question, not a software one: take it to an adviser and check zatca.gov.sa.

If the outcome is that a Saudi entity of yours issues the sales, those are simplified invoices: handed to the customer immediately and reported within 24 hours, rather than cleared first.

What changes once you are in scope

Assume the answer came back yes. A system built for another market needs four things it probably does not:

Arabic on the invoice. The Authority's published requirements put Arabic on the tax invoice; see zatca.gov.sa. A bilingual Arabic and English document is fine, and is what most foreign-owned companies settle on, but an English-only invoice does not meet the requirement.
SAR for the tax amount. You may denominate the invoice in another currency; the total VAT still has to be carried in SAR, in a tax total block of its own once the invoice declares a tax accounting currency. That block's shape is what BR-KSA-EN16931-09 checks, and it is the code a system built for another market meets first.
The national short address. Six elements for the Saudi entity: building number, street, district, city, a five-digit postal code and the country code SA. International address formats do not map onto it, the district is the element most often missing because it appears on no foreign document, and a gap raises BR-KSA-09.
Riyadh time. A server on UTC will stamp future-dated invoices for part of every day, and they are rejected under BR-KSA-04.

Then the mechanics every taxpayer faces regardless of ownership: standard B2B invoices are cleared before the buyer sees them, simplified B2C invoices are reported within 24 hours, each invoice carries a counter and the hash of the one before it, and the signed XML is kept six years in the form it was issued — not a PDF of it. Our Phase 2 walkthrough covers that ground, and the rejection code reference covers what goes wrong.

Where we fit, briefly

ZATCA Tools issues signed invoices with a QR for the Saudi entity: standard invoices cleared, simplified ones reported within 24 hours, and the signed XML archived six years and downloadable. Connecting takes one OTP from the Fatoora portal, and a group with several locations can give each branch its own device, certificate and chain. Rejections come back with the official code and a link to its guide — 135 codes documented, around twenty written up in full. It is not an accounting system — no ledger, no journals, no inventory, no payroll — which for a group already running an ERP abroad is usually the point: the ledger stays where it is and the compliance layer sits in front of it, over the REST API. Software companies serving several Saudi merchants use the Partner API instead. It is free during the launch period, so you can test the mechanics before your adviser has finished with the structure — or contact us.

One last time, because it is the part that costs money: this article covers invoicing mechanics. Registration is not our call, and it should not be any software vendor's.