Seller details
Name and VAT registration number of the clinic, in the encoded QR as well as on the face of the invoice.
What clearance actually means for a clinic, what has to be on every invoice, and why generating it inside the invoice is not the same as adding it afterwards.
Phase 1 asked for electronic invoices in a structured format with a QR code. Most clinics solved it by making their existing invoice look right.
Phase 2 asks for integration: invoices are transmitted to the Zakat, Tax and Customs Authority and, for standard invoices, cleared before they are given to the customer. That is not a formatting change — it is a system that has to talk to ZATCA at the moment the invoice is raised.
This is the point at which "our invoice template has a QR code on it" stops being enough.
Name and VAT registration number of the clinic, in the encoded QR as well as on the face of the invoice.
The invoice timestamp, the total with VAT and the VAT amount, all encoded in the QR in the format the authority specifies.
Net, VAT and total for each line, which for a dental clinic means per procedure rather than one lump sum.
Invoices must be issuable in Arabic. A clinic serving Arabic-speaking patients should be issuing them that way regardless.
A retail invoice is a list of items at a price. A dental invoice has an insurance share, a patient share, a discount that might apply to one line and not another, and a procedure that may be staged across three visits.
Getting the tax right means getting that split right first. If insurance and discount are worked out on a calculator at the desk and typed into an invoice template, the tax breakdown is downstream of a manual step — and it will eventually be wrong.
When the invoice is generated from the treatment recorded on the chart, with the insurance price list already applied, the tax calculation has nothing to guess at.
There are two ways to be compliant. One is a clinic system that produces an invoice, and a second tool that takes it, formats it and submits it. The other is a clinic system where clearance is part of raising the invoice.
The first works until something disagrees: a credit note, a partially paid invoice, an insurance rejection that changes the split. Then you have two records of the same money and a reconciliation problem.
The second has one record. The QR, the tax breakdown and the submission are properties of the invoice rather than a copy of it.
Three documents decide whether a setup actually works, and none of them appears in a demo. A credit note, because a reversal has to reference the invoice it reverses and clear in its own right. A deposit against a treatment plan, because the money arrives before the service and the tax point is not where a shop would put it.
And the insurance correction: a claim partially approved after the invoice was issued changes the split between the insurer share and the patient share. If the invoice was already cleared, what has to happen is a documented adjustment rather than a quiet edit — and a clinic with two systems now has that adjustment in one of them.
Staged treatment is the dental version of the same problem. A course invoiced once and delivered across three visits, or invoiced per visit against a single approved plan, are different tax positions, and the decision should be made deliberately rather than by whatever the software happened to do first.
Clearance runs at the moment of issue, which means the integration is live infrastructure. A clinic is non-compliant the morning the connection fails, not the morning somebody notices — so the question to ask of any system is what happens to the queue when the authority is unreachable, and whether anyone is told.
Then retention. Issued documents have to be held for the statutory period with their clearance status attached, which outlasts at least one system change for most clinics. Ask how they come out at the end of it.
And keep one person responsible. Not for operating it — it should need no operating — but for noticing: the failed submission, the invoice that did not clear, the wave notification from the authority. Five minutes a week on a list of exceptions is the whole ongoing cost when the rest is built in.
It applies to VAT-registered businesses in Saudi Arabia, which includes dental clinics above the registration threshold. Clinics are brought into integration in waves by size, and ZATCA notifies each taxpayer of their window.
The seller name, the VAT registration number, the invoice timestamp, the invoice total including VAT and the VAT amount, encoded in the TLV format ZATCA specifies — not simply a link to the invoice.
Not if your clinic system handles clearance itself. A separate provider means the same invoice exists in two places, which is where reconciliation problems start.
Yes, and you should. Dentolize issues them in either, with the same tax breakdown and QR on both.
Invoices clear with the authority automatically as part of being raised. The QR code and tax breakdown are generated inside the invoice, with the insurance share, discounts and VAT calculated per line from the treatment recorded on the chart.
The invoice cannot be treated as issued, so the practical requirement is a queue that retries, a visible state per invoice, and somebody told when one is stuck. A system that fails silently leaves a clinic non-compliant for however long it takes a person to notice.
Thirty minutes on how your clinic actually runs. We will call you within 24 hours.