A weekday morning at a dental clinic: thirty appointments, half of them paying in full by card at the desk, the other half insured, paying a co-payment and leaving the rest to the insurer, whose share goes out at month-end as one bill. Two streams of money, two different e-invoices, and the costly mistake is treating them as one. The second costly mistake is less obvious: a Saudi patient's zero-rated invoice that goes out without the patient's national ID is rejected, even at the desk.
Two payers, two documents
The invoice type follows who pays, not how much (standard versus simplified in full):
- The patient paying for themselves gets a simplified tax invoice. It is handed over at once and reported to ZATCA within 24 hours, and it needs no buyer VAT number. How to issue one.
- The insurer, or a company paying for its employees' check-ups, gets a standard tax invoice carrying its VAT number and national address. It goes to the Fatoora platform and is cleared before you share it.
Because clearance comes first, the insurer's customer record is worth getting right once. Its VAT number is fifteen digits beginning and ending with 3; a malformed one breaks BR-KSA-44, an error-level rule, and the invoice is rejected, so check it with the VAT number lookup. Gaps in your own clinic's address are milder and easier to miss: they come back as a warning under BR-KSA-09, the invoice is accepted, and nobody notices for months.
Splitting a visit: the co-payment and the insurer's share
What the patient pays at the desk and what the insurer pays at month-end are not two halves of one invoice. They are two documents, to two buyers, at two different times. Take a visit worth SAR 600 before VAT, a consultation at 200 and a filling at 400, for an expatriate patient with a 20% co-payment:
| Before VAT | VAT 15% | Total | Document | |
|---|---|---|---|---|
| The whole visit | 600.00 | 90.00 | 690.00 | — |
| Patient's co-payment (20%) | 120.00 | 18.00 | 138.00 | Simplified, at the desk |
| Insurer's share (80%) | 480.00 | 72.00 | 552.00 | Standard, to the insurer |
A percentage co-payment gives the same riyal figure whether you take it off the net or off the VAT-inclusive total, because VAT is proportional: 20% of 690 is 138. A fixed co-payment does not. SAR 50 including VAT is 43.48 plus 6.52 of VAT; SAR 50 before VAT means the patient pays 57.50 at the desk. That is SAR 7.50 a visit, every visit, in one direction, so settle once which one the insurer's contract means and price the procedure that way. How the visit is divided in the first place is set by that contract, not by the invoice.
A Saudi patient: the State bears the VAT, and the national ID is mandatory
Here the rules come from named official sources, not from us. Royal Order No. A/86 of 18/4/1439H (January 2018) directed that the State bear the VAT on private healthcare supplied to Saudi citizens. When the General Authority of Zakat and Tax, ZATCA's predecessor, announced the mechanism that month, it said private hospitals and medical centres registered for VAT issue tax invoices to Saudi citizens without VAT after confirming the patient's identity, and put the patient's national ID details on the invoice, while services to non-citizens carry VAT as normal. It also said insurers pay the VAT on services their policy covers, and the State bears it on what the citizen pays, such as the co-payment.
On the e-invoice the case has its own code in ZATCA's exemption reason list: VATEX-SA-HEA, "Private healthcare to citizen", under the zero-rated category (Z) at 0%. Once a document carries that code, BR-KSA-49 makes the buyer's identifier mandatory, and its kind must be the Saudi national ID, NAT: ten digits beginning with 1. Not an Iqama, not a passport. It is an error-level rule, so without the ID the document is rejected and never recorded, and it does not exempt simplified invoices, the one document that normally names no buyer at all. A neighbouring rule, BR-KSA-25, a warning, wants the patient's name on it too.
So, under the mechanism as announced, the same insured visit for a Saudi patient becomes:
| Before VAT | VAT | Total | Document | |
|---|---|---|---|---|
| Patient's co-payment (20%) | 120.00 | 0.00 | 120.00 | Simplified, zero-rated, VATEX-SA-HEA, national ID |
| Insurer's share (80%) | 480.00 | 72.00 | 552.00 | Standard, to the insurer |
An uninsured Saudi patient paying the full SAR 600 gets one simplified invoice, zero-rated, SAR 600.00, with the code and the national ID. Two cautions. That is how the mechanism was announced; confirm with your accountant that it applies to your licence, your services and your insurance contracts before you set anything up. And the code follows the patient, not the clinic: an expatriate's invoice stays at 15%.
Setting it up in ZATCA Tools
In Settings, under Establishment profile, the VAT treatments field lists every treatment you trade under: keep Standard 15% and add Zero-rated 0%. Every invoice starts standard-rated. For a Saudi patient's share you choose Zero-rated 0% and the reason Private healthcare to a citizen on the invoice itself; the code is written onto every line of the XML, as ZATCA requires, and a setting prints the reason on the PDF as well. In the web form one treatment applies to the whole document, so a visit that mixes treatments is two documents there; through the API each line carries its own tax_category and tax_reason_code.
The patient's record holds the national ID with its kind set to National ID. Without it, ZATCA Tools refuses the zero-rated invoice before signing it, in the form, at issue and through the API (customer_national_id_required), so the rejection never reaches ZATCA. Patient lists can be imported from a CSV or Excel file with the identifier and its kind, and procedure prices saved as items are picked by name at the desk.
Cancellations, refunds and rejected claims: credit notes
An issued invoice is never edited or deleted. A cancelled appointment that was already invoiced, a refunded procedure, a line the insurer rejects on the claim: each is a credit note against the original invoice for the amount reversed. It needs a written reason, and a note without one is rejected under BR-KSA-17. It should also reference the original invoice, but a missing reference only comes back as a warning under BR-KSA-56, which is how orphaned notes slip through. Write "Appointment of 20 September cancelled, filling not performed", not "refund".
Say the insurer rejects a SAR 150 cleaning on the month's claim. The credit note against the insurer's invoice is 150.00 plus 22.50 of VAT: 172.50. Whether the rejected amount can then be billed to the patient depends on your contract with the insurer; if it can, that is a new invoice to the patient, not an edit to anything. A credit note on a Saudi patient's zero-rated invoice needs the same code and therefore the same national ID, and in ZATCA Tools the note inherits the original's treatment line by line. The guide to credit and debit notes covers the mechanics.
More than one branch: one device each
Medical groups grow by opening a second site before they add chairs. Each branch that issues invoices needs its own device: its own certificate, invoice counter and chain of invoice hashes. Issuing two branches from one device makes two invoices compete for the same place in one chain. A missing previous-invoice hash comes back as a warning under BR-KSA-61, not a rejection, so the damage surfaces at an audit rather than on the day. In ZATCA Tools each branch gets its own device, certificate and chain.
Where ZATCA Tools stops
It is not a clinic management system: no patient files, no appointments, no insurance-claim files and no connection to any insurer's claim system, no stock of consumables. It is not accounting software: no ledger, no VAT return. It issues in SAR only. It has no automatic recurring invoices, so the insurer's monthly invoice is built each month, and can wait as a draft while the claim file is agreed. And it cannot issue a prepayment invoice (type 386) for a deposit on a treatment plan that is deducted later; agree that one with your accountant first.
If you run a clinic management system, keep it as the source of truth and let it issue through the API. If you don't, issue from the browser, with insurers saved as customers and each payment recorded as a receipt voucher, so every invoice reads paid, partly paid or unpaid. Connecting takes one OTP from the Fatoora portal (what that handshake does), and a rejected document comes back with its official code and a guide in the error reference. A working clinic issues dozens of documents a day, so treat the free week as a trial, not a runway, and subscribe the day you go live. One week free, no payment, from the day you connect, then very competitive plans: 49 SAR a month for Growth and 149 for Business, on a smooth, fast system that signs each invoice and sends it to ZATCA in seconds — start here.