A Liability With No Deadline Attached to It
It accrues from month one, nothing asks about it until somebody resigns, and the only record of how long anyone has been here is a folder.
Most obligations announce themselves. A return is due, a payment has a date, a filing window opens and closes, and the calendar does the remembering. Whatever else is true of them, they are hard to forget.
End-of-service entitlement is not like that. It accrues from the first month of employment and is settled at the end — and between those two points nothing obliges anybody to look at it. No deadline arrives. No form is due. It simply grows, quietly, across a workforce that in this market is largely non-national and therefore substantially made up of people whose employment will one day end.
The result is a liability that is real, growing, and unexamined until the month it becomes payable — at which point somebody has to establish how long a person has worked here, from whatever records exist.
There is no formula in this post and there will not be one
We do not maintain the calculation, so publishing a version of it would be publishing something we do not stand behind — and somebody would plan a cash position around it. What the entitlement is, how it is computed, and what your contracts and the law require are questions for your adviser. What this post is about is narrower and entirely ours: whether the facts the calculation needs exist in a form anybody can use.
Why a small finance team makes this worse rather than easier
The argument on our Bahrain page is that the risk here is documentary rather than operational: a compliance surface sized for a much larger company, administered by three or four people. That shapes this problem specifically.
A large finance function has redundancy. Somebody notices that a provision has not moved in a while, because somebody's job includes noticing. With three people there is no spare reviewer, so anything that does not generate an alert does not get looked at — and this generates nothing, by nature.
| What the calculation needs | Where it usually is |
|---|---|
| Continuous service length per person | A contract in a folder, plus institutional memory of any break |
| Contract type and its terms | A PDF, possibly superseded, possibly not the signed version |
| Any change of terms, and when | An email, if it was written down at all |
| Who is still employed today | Reliable — this is the one fact everybody has |
| Which entity or site employed them | Frequently nowhere, and it matters for attribution |
The number is not hard to calculate. It is hard to calculate from a folder — and a folder is what most operations are keeping.
The two failures, and the second is the expensive one
The obvious failure is a surprise: somebody leaves, the settlement is larger than anyone assumed, and it lands in a month that had other plans. Uncomfortable, survivable, and usually a one-off.
The expensive failure is structural under-provision across the whole workforce. If nobody can produce service length reliably, nobody can produce a total — so the provision is either a rough figure carried forward or a number somebody built once. That does not fail on any particular month. It fails when several people leave in the same period, or when a business is being valued, or when a buyer's adviser asks for the working.
What is actually ours
Employee records with start dates and contracts
Service length as a fact on a record rather than a document in a drawer, with contracts and their documents attached to the person they belong to.
Expiry dates the system watches
Permits, certifications and contract dates tracked rather than remembered — which matters for the same reason the rest of this does: nothing external is going to ask.
Labour cost attributed to a site, project or cost centre
So the cost of a workforce is answerable by the place or the job that carries it, not only in total.
Access control and an audit trail
Who changed a record and when. With three or four people in a finance function, the permission does the work a second reviewer would have done, and the trail is what makes a change reviewable after the fact.
The entitlement calculation itself
Not built. We hold the service history it would be computed from and we do not compute it. This is deliberate rather than pending: a figure produced by software nobody has validated is worse than a figure produced by an adviser who has.
A maintained Bahraini statutory payroll engine
Not built. The maintained engine covers Kenya only — which is also the evidence that a second one is possible, and it is commissionable with a written specification, a timeline and a price rather than a date on a page.
One question, this week
Pick three employees at random and ask your system — not a person — how long each has worked for you.
If three answers come back in a minute, this is not your problem and the provision is a conversation with your accountant rather than a data exercise. If the answer to any of the three requires opening a folder or asking a colleague, then the largest quietly-growing liability in the business is being tracked by memory — and the fix is not a payroll module, it is that a start date should be a field.
What is built here, what is not, and what we would decline is on the Bahrain market page. The evidence-retrieval version of the same small-team problem is twenty-five kilometres, two tax regimes, one finance manager. The market where this liability sits alongside no periodic obligation at all is Kuwait.
What is not built for Bahrain today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Bahrain. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If an NBR e-invoicing pipeline once the format is published, an Arabic interface, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
The zero rating, and the evidence that holds it up
Electronic invoicing against whatever the National Bureau for Revenue publishes, built when there is a format to build against. The nearer-term work is the one that costs Bahraini exporters real money: a zero-rated cross-border supply that carries its own proof — customs entry, transport document and delivery evidence attached to the invoice rather than filed somewhere else — so the rating survives a review instead of being reconstructed during one.
Arabic interface, banks and acquirers
Arabic interface text with right-to-left layout and bilingual document templates, plus bank statement feeds, card acquirer settlements and instant-payment files wired into the Payments Register.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
A Bahraini payroll engine with Social Insurance Organisation contributions on live employee records, wage files in the layout the Labour Market Regulatory Authority expects, and the Bahrainisation position visible before a deadline rather than after one.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integrated