A pharmacy that bills insurers is paid late, in part, and sometimes not at all. Al Jawad Software House built an accounting extension in Odoo for TruDoc, a pharmacy operator in the UAE, so that each claim can be followed from the sale to the final payment.
The business
When a patient pays only a share at the counter, the pharmacy sends the rest to the insurer as a claim. That money stays owed until the insurer pays. For a pharmacy operator, insurance claims are a large part of what is owed to the business, so finance needs to know what is open, with whom and for how long.
Where the work gets hard
Payments do not match claims one to one. An insurer pays through a remittance advice, a statement listing what it paid and what it refused. A payment can be partial, and refusals come with reasons that differ from one source to another.
Rejections are a real cost. Some refused amounts will never be recovered. The business needs to set money aside for them rather than discover the loss later.
Branches keep their own books. Where a branch is its own company, its claims have to land in that company's accounts.
A rejected claim is sent again. The second submission has to be traceable to the first, and the same claim must never be entered twice.
What we implemented
One record for every claim
Each claim moves through clear stages: draft, submitted, in suspense, paid, partly paid, rejected, resubmitted and closed. Booking the sales creates the invoice to the insurer in the right branch, split by pharmacy.
Remittance files read for you
The finance team uploads the remittance file the insurer sends. Odoo works out the file type, reads each line, finds the matching claim and proposes how the payment should be shared out. Once the team approves the proposal, Odoo records the payment, the amount refused and the balance owed, and settles the claim invoice. The team can undo it before posting.
Resubmitting rejected amounts
A rejected or partly paid claim can be sent again as a new claim for the refused amount. The new claim stays linked to the original, so the full history is one chain.
Provision and ageing
A monthly step sets money aside for expected rejections, branch by branch. An ageing report shows what each insurer owes each branch and how long it has been owed. Opening balances can be loaded from a file, and loading the same claim twice does not create a duplicate.
How the work gets easier
| The usual way | With the new process |
|---|---|
| Staff match insurer payment lines to claims by hand | Odoo reads the remittance file and proposes the matches |
| A partial payment leaves the claim unclear | The claim shows as paid, partly paid or rejected |
| Rejected amounts surface as a surprise | A monthly provision sets money aside for them |
| A resubmitted claim loses its link to the first | Each resubmission stays linked to the original claim |
| Finance builds ageing in a spreadsheet | The ageing report shows insurer and branch together |
| The same claim can be imported twice | A claim already in Odoo is not created again |
The result is less retyping and a clearer view of what each insurer still owes. Finance spends its time on the claims that need a decision.
