Paid in Ninety Days: Running a Clinic's Insurance Receivable
A clinic can be profitable on paper and unable to pay salaries, because the money is sitting with SHA and four insurers at four different ages. How to run the receivable when the payer, not the patient, owes you.
Ask a Kenyan clinic owner what their margin is and you will get an answer. Ask what they are owed, by whom, and for how long, and you will get a pause — then a spreadsheet that was last accurate in March. This is the defining financial problem of a facility that takes insurance: the service is delivered today, the cash arrives in sixty to a hundred and eighty days, and in between the clinic funds the payer's float out of its own working capital. Nothing about that is unusual or improper. What is improper is not knowing the size of it.
The cash-flow trap is arithmetic, not misfortune. A facility billing KES 4m a month to payers who settle at ninety days is permanently carrying about KES 12m of other people's money on its balance sheet. Grow 30% and the receivable grows 30% too — which is why a busy, growing, genuinely profitable clinic can find itself unable to pay a locum. Growth consumes cash before it produces any.
The number nobody has: age since submission
Most clinics that measure anything measure days since the visit. That figure conflates two very different failures. A claim that is ninety days old because the payer is slow is a collections problem. A claim that is ninety days old because it sat in a drawer for six weeks before anyone submitted it is a process problem, and it is the more common of the two. Until the two ages are separated, every conversation about arrears is a conversation about the wrong thing.
Where the ninety days actually went
Visit to invoice raised
Usually days. Sometimes weeks, if the clinical notes are incomplete and nobody chased them.
Invoice to claim submitted
The silent killer. Batching claims weekly is fine; batching them whenever someone remembers is not.
Submitted to first response
The payer's clock, and the only stretch you genuinely cannot compress.
Rejection to resubmission
Yours again — and a rejected claim nobody resubmits is simply a write-off with extra steps.
Only the third band belongs to the insurer. Clinics that blame payers for their entire ageing profile are usually responsible for a third to half of it, and that half is the half they can fix without a single phone call.
Run it as one receivable per payer, not one per patient
The structural mistake is treating each patient as the debtor. Clinically the patient is the subject; financially the payer is the debtor, and there are perhaps six of them. Six accounts with running balances, six ageing profiles, six settlement rhythms and six relationship owners is a manageable problem. Four thousand patient accounts, most of them owing nothing because a scheme covers them, is not.
That reframing makes the co-payment sit where it belongs, too. When a scheme covers 80% and the patient pays 20% at the desk, those are two debtors on one visit — the patient's share collected immediately as a till transaction, the scheme's share invoiced and chased. Facilities that put the whole amount on one document end up chasing insurers for co-payments already collected in cash, which is how a reconciliation becomes unwinnable.
What a ninety-day payer actually costs to carry
This is why a discount for faster settlement is often worth giving. Four percent of billing is a real margin line, and a payer who settles at thirty days instead of ninety hands two thirds of it back. Most facilities have never computed this, so they negotiate hard on tariff and not at all on terms — and the terms are frequently worth more.
SHA changed the timing, not the discipline
The move from NHIF to the Social Health Authority reset portals, benefit packages and submission rules, and every facility spent 2024 and 2025 relearning them. What did not change is the underlying control: a claim has a date it was raised, a date it was submitted, a date it was answered and a date it was paid, and a facility that cannot produce those four dates per claim is not managing a receivable — it is hoping. Build the discipline so it survives the next portal change, because there will be one.
The rejection loop is where the money actually dies
Nobody loses money on claims that are paid. The loss sits in the ones rejected for a missing pre-authorisation, an expired member number, a diagnosis code that does not support the procedure, or a signature — each individually trivial, each fixable in ten minutes, and collectively the difference between a clinic that collects 97% of what it bills and one that quietly collects 84%. The pattern is always the same: a rejection arrives, nobody owns it, and it ages out of the resubmission window unnoticed.
The five controls that recover most of a leaking claims process
- One named owner per payer. Not "the front office" — a person, with the account and its ageing as their number.
- A fixed submission rhythm, weekly or better, that happens whether or not the batch feels big enough.
- A rejection log with an outcome per line. Resubmitted, written off, or still open — nothing sits in a state called "we saw it".
- Pre-authorisation captured before the procedure, not reconstructed afterwards. It is the single most common rejection reason and the most preventable.
- A monthly ageing review with the two ages side by side, so a worsening internal delay cannot hide behind a slow payer.
Questions worth asking any vendor selling you claims management
Can you age a receivable from the submission date rather than the invoice date?
What a good answer sounds like
Either yes with a named field, or a straight no.
Why it matters
If it only ages from the invoice date you cannot separate your delay from theirs, which is the whole diagnosis.
Is a payer an entity in the system, or just a text field on an invoice?
What a good answer sounds like
A real record with a balance, terms and a history.
Why it matters
A text field cannot carry an ageing profile, so per-payer analysis becomes a manual export every month.
What happens to a rejected claim?
What a good answer sounds like
A state, an owner and a resubmission link.
Why it matters
If the answer is "you would raise a new invoice", the original loses its history and your recovery rate becomes unmeasurable.
Show me a statement of account for one payer, on screen, right now.
What a good answer sounds like
A running balance with invoices and receipts in date order.
Why it matters
This is the document you will actually argue from in a reconciliation meeting. If it takes engineering to produce, you will never have it when you need it.
What this looks like on the generic finance modules
A payer is a customer. A claim batch is an invoice. A settlement is a receipt against it, usually partial. Put that way, most of the machinery a claims process needs is ordinary receivables management, and the honest question is not whether the concepts map — they do — but which of the payer-specific behaviours survive the translation. The block below answers that without decoration.
What AWRA OpsHub does today
- Customer invoices with partial payments, so a claim settled at 80% leaves a balance rather than an argument. Amount paid and balance due are maintained on the invoice.
- An AR ageing report grouping outstanding receivables into age buckets, which is the payer-mix picture this post is built around.
- A statement of account per customer — opening balance, invoices as debits, receipts as credits, in date order, over any date range — rendered as a PDF and emailed to the payer from the customer record. This is the document the probe above asks for.
- Credit limits with live exposure. An invoice records the credit limit, the exposure before and after, and can be held with a reason when the limit is breached — plus a logged override with its own reason. A payer whose balance has quietly become your largest business risk can be capped.
- Credit notes as first-class documents, so a partially disallowed claim is reduced with a numbered document rather than by editing history.
- KRA eTIMS filing on the invoice — status, receipt number, signature, QR and filing timestamp are all held on the record, with the error captured when a submission fails.
What it does not do
- There is no claim entity. A claim is an invoice with a number. There is no submission date distinct from the invoice date, so the single most useful measurement in this post — ageing from submission — is not available. You can approximate it by not raising the invoice until you submit, which distorts your revenue recognition to fix your ageing.
- No rejection or resubmission cycle. No rejection reason, no resubmission link, no recovery rate. A rejected claim is handled by issuing a credit note, which is correct accounting and loses the operational history entirely.
- No payer or scheme entity beyond the customer record. No benefit package, no member roster, no per-scheme tariff, and no pre-authorisation record — so the most common rejection reason has nowhere to live before the procedure happens.
- No batch submission of any kind, and no integration with SHA or any insurer portal. Submission is a person on a website, always.
- No recurring invoice generation, which matters for capitation and retainer arrangements — those get raised by hand every month.
- No bank statement matching. Settlements are receipted by hand against invoices; nothing reads a bank feed and proposes the match, so a lump-sum payment covering forty claims is allocated manually.
- No co-payment split on one document. The patient share at the till and the scheme share on an invoice are two unlinked records, so the visit-level reconciliation this post recommends is a convention you maintain, not one the system enforces.
The receivables half is genuinely strong — ageing, statements, partial settlement, credit limits with live exposure and eTIMS on the invoice are all real, and they cover more of this problem than most clinic managers expect. The claims half does not exist. If your bottleneck is knowing what each payer owes and being able to prove it in a meeting, this fits today. If your bottleneck is the rejection loop — submission tracking, reasons, resubmission, recovery rate — that is a claims system and we are not one. Say so to us before you buy, not after.
The short version
Measure two ages, not one. The stretch between the visit and the submission is yours, it is usually a third of your ageing, and it is the only part you can fix this month without anyone else's cooperation.
The upstream half of this problem is what the visit actually cost you to deliver — covered in cost per visit — because a payer tariff below your cost per visit is not a receivables problem at all. And the discipline that keeps the whole ledger arguable is the same receivables control any Kenyan business needs, with a payer in place of a customer.
Know what each payer owes you
Customer invoices with partial settlement, AR ageing by bucket, a statement of account emailed per payer, credit limits with live exposure, credit notes and [eTIMS](/glossary/etims) on the invoice. Claim submission tracking and the rejection cycle are not built — the note above is specific about it.
See clinic finance in AWRAFrequently asked questions
Why is a profitable clinic short of cash?
Because insurance revenue is recognised when the service is delivered and collected sixty to a hundred and eighty days later. A facility billing KES 4m a month at ninety-day settlement permanently carries around KES 12m of receivable, and every shilling of growth increases it. The profit is real; the cash is with the payer. This is a working-capital problem, not a margin problem, and cutting costs does not solve it.
Should we age claims from the visit date or the submission date?
Both, side by side — they diagnose different failures. Age from the visit and you see your total exposure; age from submission and you see how much of the delay is the payer's. The gap between the two is your internal processing lag, and in most facilities it is a third to a half of the total ageing. Reporting only one age guarantees you blame the wrong party.
What is the single highest-return fix in a claims process?
Owning the rejection loop. Claims that get paid do not lose money; claims rejected for a fixable reason and never resubmitted do. Give rejections a named owner, a log with an outcome per line, and a weekly review against the resubmission window. Most facilities recover several points of collection rate from this alone, without renegotiating a single tariff.
Is it worth offering a discount for faster settlement?
Often, yes — and almost nobody computes it. Carrying a ninety-day receivable costs roughly 4% of the amount billed at Kenyan funding rates. A payer who moves to thirty days hands back about two thirds of that, so a 2% settlement discount can be straightforwardly profitable. Compute your own number before negotiating, because it also tells you when the answer is no.
How many payer accounts should a clinic actually manage?
As many as you have payers — typically five to ten, including SHA — not as many as you have patients. The payer is the debtor; the patient is the subject of the claim. Handle the patient co-payment at the till as cash and the scheme share as an invoice to the scheme. Facilities that maintain thousands of patient debtor accounts are managing a ledger where almost every line is zero.
Can generic accounting software run a claims process?
It can run the receivable — invoices, partial payments, ageing, statements, credit notes, credit limits — and that covers more ground than most people expect. It cannot run the claim: submission dates, rejection reasons, resubmission links and recovery rates need a claim entity. Decide which of the two is your actual bottleneck before you evaluate anything, because the answer changes what you should buy.
What happens to the receivable when a payer disallows part of a claim?
Issue a credit note against the original invoice rather than editing it. The invoice keeps its number and its history, the credit note carries the reason and its own number, and the balance reduces to what is genuinely collectable. Editing the original destroys the audit trail and makes your disallowance rate — a number worth watching per payer — impossible to compute.
