Cover not verified before the service
The treatment has happened; the money is gone. This is a scheduling and reception problem long before it is a billing one.
Blog
Insurance and compliance for clinics in Saudi Arabia
Four obligations sit on a Saudi clinic at once: check cover before you treat, get approval where the plan requires it, submit a claim that survives review, and issue an invoice the tax authority can read. They look like four separate problems. They are four readings of the same record.
What is actually required, and by whom
Two authorities set the rules a clinic deals with daily. The Council of Health Insurance governs how insurers and providers exchange eligibility, approvals and claims, and the exchange itself runs over NPHIES. The Zakat, Tax and Customs Authority governs invoices: what an invoice must contain, in what format, and when it has to reach the authority.
Neither is optional and neither is a one-off project. Both are continuous: every visit produces an eligibility check and usually an invoice, and a clinic that treats them as quarterly admin discovers the gap at the end of a quarter, when the money is already owed and the patient has gone home.
The practical point is that the two meet in the clinical record. An invoice ZATCA will accept and a claim an insurer will pay are both generated from what the clinic wrote down about a service. If that record is thin, incomplete, or entered after the fact from memory, both downstream obligations fail — and they fail quietly, weeks later.
NPHIES is a network, not a website
The common misunderstanding is that NPHIES is a portal someone logs into. It is an exchange: the clinic system talks to it, and the insurer answers through it. Eligibility checks, pre-authorisation requests, claims and the remittance that comes back are all messages on that exchange, each with its own structure and its own failure modes.
That distinction decides how the clinic works. If the exchange runs inside the system the front desk already uses, eligibility is something that happens while the patient is standing there. If it runs in a separate browser tab, it becomes a task — and tasks get skipped on a busy morning, which is precisely when the expensive mistakes are made.
The sequence is worth being precise about, because each step protects the one after it. Eligibility establishes that the patient is covered today, for this class of service. Pre-authorisation establishes that this particular service, at this price, is approved before it happens. The claim then asserts that the approved thing was done. Remittance says what the insurer actually paid, and against which line. Skip a step and the one after it is unsupported.
Eligibility is a front-desk problem, not a billing one
The most expensive rejection is the one where the treatment has already happened. Cover that lapsed, a plan that excludes the service, a dependant no longer on the policy: all of these are knowable in seconds, before anyone sits in a chair, and all of them become unrecoverable once the service is delivered.
So eligibility belongs to arrival, not to billing. The question is not whether the clinic checks — most do — but when, and whether the answer is attached to the visit it belongs to. A check done at the desk and remembered is not a record. A check stored against the appointment, with its response and its timestamp, is one that can be produced three months later when a claim is queried.
A clinic running several specialties has a sharper version of the same problem, because cover varies by service. A policy may cover a dermatology consultation and exclude the laser course that follows from it; the eligibility answer that matters is the one for what is about to be done, not for the clinic in general.
Pre-authorisation is where the margin is lost
Pre-authorisation is the step clinics most often run informally, and it is the one that costs the most when it goes wrong. The service is approved verbally, or approved for a different quantity, or approved and then changed in the room without the approval being updated. Each of those produces a claim the insurer can decline while being entirely correct to do so.
The discipline that works is unglamorous: the approval is requested from the same place the service is planned, the reference comes back onto the service rather than into an inbox, and any change to the plan re-opens the question before the work is done. A course of sessions makes this concrete — eight approved sessions is not the same as an approved course, and a ninth session is a new conversation, not a rounding error.
This is also the step where documentation quality starts to matter. An approval request that carries the indication, the prior treatment and the clinical reasoning is answered faster and declined less often than one that carries a service code and nothing else.
Where claims actually fail
Approval missing, stale or for the wrong quantity
Approved in principle, or approved last month, or approved for four sessions and six delivered. All three read the same way to a reviewer.
Documentation that does not support the code
The code says one thing, the note says less. Nothing was done wrong clinically; it simply cannot be demonstrated.
Submitted outside the window
Late is final in a way that the other three are not. The deadline belongs to the contract, and is usually shorter than the clinic assumes.
ZATCA phase two is an integration, not a PDF
E-invoicing arrived in two stages. The first required invoices to be generated electronically in a defined format rather than written or printed from a spreadsheet. The second requires the system that issues them to be integrated with the authority, so that invoices are cleared or reported rather than filed, and it has been phased in by waves defined by turnover, with each wave given its own date.
For a clinic the practical consequences are narrow but strict. Invoices need the required fields and the QR code, the tax treatment has to be right on each line rather than on the total, and the integration has to keep working — a clinic is non-compliant the day the connection breaks, not the day someone notices.
The part that catches medical clinics specifically is the mixed invoice: an insured portion, a patient co-payment, and sometimes a cash item on the same visit. Those are different tax treatments on one document, and getting them right is a property of the system that builds the invoice, not of the person at the desk.
What all of this asks of the system you run
Read the four obligations together and they ask for one thing: a single record of what was planned, approved, done and charged, with each step attached to the one before it. Everything else follows from that. Eligibility attaches to the appointment. The approval attaches to the service. The claim is built from the service rather than retyped. The invoice is built from the same service, so the insured portion and the patient portion cannot disagree.
Where clinics come unstuck is at the seams between systems. A scheduler that does not know about cover, a clinical record that does not know what was approved, and an accounting package that learns about the visit a week later will each work correctly on their own and still produce a rejected claim and a wrong invoice between them.
That is the argument for one system rather than four, and it is worth being honest about its limits: one system does not make a thin note into a good one, and it does not make a missed deadline recoverable. What it removes is the class of failure where the information existed in the building and simply was not where it was needed.
Remittance is where you find out what happened
The claim is not the end of the transaction; the remittance advice is. It says what the insurer actually paid, against which lines, and what it reduced or refused. A clinic that submits diligently and never reads the remittance in detail is running on the assumption that submitted equals paid, and the gap between those two numbers is where a year of margin quietly goes.
The work is reconciliation: match each paid line back to the service it came from, and treat a short payment as an event with a reason rather than a smaller number. Done monthly against the ledger, it turns into a list of patterns — this payer reduces this code, this plan refuses this combination — and patterns are fixable in a way that individual shortfalls are not.
Clinics that tighten the loop from eligibility through to reconciliation report rejection rates falling from around 20% of claims to about 3%, and collection running roughly 60% faster, because the money stops waiting on a person to notice it is missing.
A TPA is not an insurer, and the difference shows
Much of the day-to-day exchange is not with the insurer but with a third-party administrator acting for it. The distinction matters because the TPA sets the operational rules the clinic actually lives with: which services need approval, what documentation they want attached, how long the window runs, and which portal or channel a query goes through.
Two consequences follow. The first is that "we are contracted with that insurer" does not settle how a claim must be prepared — the administrator does. The second is that a clinic working with several payers is working to several sets of operational rules at once, and the only sane way to hold that is in the system rather than in the heads of two experienced people at reception.
It is also the reason a change that looks administrative can be expensive. A payer moving to a different administrator can change approval requirements without changing a single clinical fact, and a clinic that learns about it through a run of rejections has already paid for the lesson.
What to ask a vendor, and what the answers mean
Ask whether the system is integrated with the exchange and the authority, or whether it exports files that someone uploads. Both can be made to work; only one survives a busy Tuesday. The follow-up question is what happens when a connection fails — whether the clinic finds out immediately or at month end.
Ask to see eligibility run from the appointment rather than from a separate screen, and ask where the answer is stored afterwards. Ask how an approval attaches to a service, and what the system does when the plan changes mid-course. Ask how a mixed invoice is built when part is insured, part is a co-payment and part is cash — that single question separates products that were designed for this market from products that were adapted to it.
Finally, ask what the migration looks like for records you already hold, because the cost of compliance is rarely the licence. Clinics moving onto one system report around 60% less staff time spent on this work, and roughly 40% more revenue from follow-ups and automated reminders once the record and the reminder are the same system rather than two.
Where to go next
Each of these goes deeper on one part of the above.
Questions
Does a small clinic need NPHIES, or only hospitals and groups?
Any provider exchanging eligibility, approvals or claims with insurers works through the exchange, whatever its size. What changes with size is how much of it a person does by hand: a single-doctor clinic can survive a manual process for a while, and a complex running several specialties cannot.
We already issue electronic invoices. Is that phase two?
Not necessarily. Issuing an invoice electronically in the required format is the first stage; the second is that the issuing system is integrated with the authority so invoices are cleared or reported rather than simply produced. The question to ask of any system is whether it is integrated, not whether it exports a PDF.
What is the one change that reduces rejections fastest?
Moving the eligibility check to arrival, and storing the answer against the appointment. It costs nothing, it is the cheapest of the four failure points to fix, and it removes the category of rejection where the service has already been delivered.
Do the Saudi rules apply to a clinic treating cash patients only?
The insurance side does not arise without insurers, but the invoicing obligation is about tax, not cover, so it applies regardless. A cash-only clinic still issues invoices the authority must be able to read.
See it on your own clinic
Thirty minutes on how your clinic actually runs. We will call you within 24 hours.