Your Payroll Rail Is a Phone Number, Not a Bank Account
Most payroll systems assume money leaves for a bank account, in the currency of the country. Where it leaves for a phone number, in dollars, and is never cashed out, four ordinary assumptions break at once — and none of them break loudly.
There is a field in every payroll system that nobody thinks about, because in most countries it is boring: where the money goes. A bank, a branch, an account number. It is stable, it belongs to an institution, it is not the employee, and there is a statement at the end of the month written in the same currency as the payslip.
Change that one field to a phone number and four things stop being true. Not dramatically — no error appears, no reconciliation refuses. They just quietly become somebody's manual job.
Somalia is the clearest case of this we have written about. Mobile money penetration is around 73% — 83% urban, 72% rural, 55% among nomadic communities — the services are dollar-denominated, more than half the country is paid that way, and roughly 63% of users keep all their funds on the phone rather than cashing out. EVC Plus, Zaad, Sahal and e-Dahab are not an alternative rail here. They are the rail.
Said before anything else: we connect to none of them
This post is not a feature announcement. Our one mobile-money integration is M-Pesa and it is Kenya-only. In Somalia the disbursement is keyed and the reconciliation is done against a provider statement by a person. We are writing about the shape of the problem because the shape is the same whether or not the connection exists — and because a vendor who describes this rail accurately is at least telling you they have looked at it.
What breaks, one assumption at a time
One: the destination is a person, not an institution
A bank account belongs to a bank. A wallet belongs to a number, and a number belongs to a SIM. That difference has consequences a payroll system was never designed for.
A number changes — a lost handset, a switched provider, a second SIM for a second network. A number is also lendable in a way an account is not: the person collecting for a relative, the supervisor whose phone the team uses because it has the balance. None of that is irregular and none of it is anybody's fault. It simply means the destination field has a shorter half-life than the employee record it sits on, and a stale one does not bounce. It pays somebody.
| Assumption | What it relies on | What happens here |
|---|---|---|
| A wrong destination fails safe | An institution rejecting a mismatched name and number | A valid number receives the money. There is no name to mismatch |
| The destination is stable between periods | Accounts changing rarely and by request | Numbers change without anyone thinking to tell payroll |
| One destination, one person | Legal account ownership | A number is a device, and devices are shared for practical reasons |
| Proof of payment is a bank advice | A statement line with a reference | A confirmation on a handset, and whatever the provider statement carries |
A wrong bank account bounces. A wrong phone number pays someone. That single asymmetry is why the destination field deserves the same discipline here as the amount.
Two: the payslip currency and the payment currency are not the same question
The wallet services are dollar-denominated. For anything substantial the dollar is the unit of account here — and as recently as this year worn shilling notes were being refused outright in ordinary trade. Meanwhile our own reference row for this country carries the shilling, because provisioning has to resolve some currency, and that is a fact about our schema rather than a claim about your books.
So the honest position for any system operating here is: what a wage is expressed in, what it is paid in, and what the country's tax row says can be three different answers, and a system that assumes one currency per country will silently pick the wrong one somewhere. The test is not whether a vendor supports multi-currency in the abstract. It is whether an amount keeps the currency it actually happened in, all the way through to the report.
Three: there is no bank statement, and the substitute behaves differently
Reconciliation in a payroll system is usually built on the assumption of a bank file: a known format, a stable identifier, a reference field long enough to carry something useful. A provider statement is a different artefact. What identifiers it carries, what it can be exported as, and whether anything on it ties back to a payslip number is a question with a per-provider answer — and we are not going to publish a claim about any of them, because we have not read their agreements and the answers change.
What is safe to say is the structural part: if the reference cannot travel with the money, the tie between a disbursement and the record that authorised it has to be created on your side. That is not a limitation of mobile money. It is a requirement it places on whatever system you use.
Four: paid and banked collapse into one event
When most users never cash out, the wallet is not a step on the way to money — it is the account. There is no second event where funds land somewhere more permanent, which removes a checkpoint that payroll processes in other markets quietly rely on. The cash-out that would have surfaced a problem does not happen.
The practical consequence is that the last moment anybody can catch an error is before the transfer, not after it. Which moves the entire weight of the process onto the thing that happens beforehand: is the destination current, is the amount authorised, and is there a record saying who approved it.
What that means a system has to be good at
Notice what the four points above have in common: not one of them is solved by an integration. An integration removes keying and speeds reconciliation, and it is worth having — but every failure described above happens before the money moves, in the record. So the division of labour is clearer than it looks.
The wallet held as the destination on the record
A destination that lives on the employee or supplier record rather than in the head of whoever does the paying, with changes to it visible as changes rather than as an overwrite.
Disbursement coded at the moment it is made
Project, grant, site and cost centre on the payment as it is entered, so a per-grant or per-location labour cost is a filter later rather than an excavation.
One register for money out
Transfers, cash and wallet disbursements in the same place with the supporting document attached to each, which matters most exactly where the rail is not a bank.
Amounts kept in the currency they happened in
The original amount and the rate actually applied retained on the transaction, and no report silently converting two currencies and adding them together.
A live connection to a Somali provider
EVC Plus, Zaad, Sahal, e-Dahab — collection, disbursement or both. Not built, not started. Commissionable on a written specification, a timeline and a price; M-Pesa exists in this product only because Kenyan clients needed it and paid for it, which is the evidence rather than a promise.
A maintained Somali statutory payroll engine
Income tax bands, contributions, filing. Not built, and we do not state what those obligations are because we do not maintain them. Buy that locally if you need it; the labour-cost attribution above is the half worth buying from a system like ours.
The test, and it takes one payroll run
- Pick five employees paid last month. Is the destination on file today the one the money actually went to?
- For one disbursement, how long does it take to get from the payment back to the record that authorised it? If the answer involves opening a second file, that is the gap.
- Ask who currently knows that an employee changed number. Is it a process or a person?
- Take one report with a total on it. Is the currency of that total stated, and is it one currency?
- Ask any vendor: which provider, which direction, live integration or file export, and what is still keyed? Four answers, not one — and "we support mobile money" is not any of them.
Why the last question is worth insisting on
"Mobile money support" is a category claim, and categories hide the work. Collection and disbursement are separate builds. A file export and a live integration are different products. And a connection to one provider says nothing about the other three. A vendor answering all four specifically has done the work or is honest about not having done it; a vendor answering the category has told you they have not been asked before.
The general shape
This is not really about Somalia and it is not really about mobile money. It is about what happens when the destination of a payment stops being an institution and becomes an attribute of a person — which is happening in a lot of markets, at different speeds, with the local rail as the reason each time.
The question to carry into any of them is the same one: if this destination is wrong, does anything stop it? Where the answer is yes, a payment system can be casual about the record. Where the answer is no, the record is the control, and it deserves the attention the transfer usually gets.
What is built here, what is on the roadmap with a price on it, and what we would decline is set out on the Somalia market page. The field-finance version of the same rail — per diems and activity advances, written for grant-funded teams — is per diem, field advances and mobile money reconciliation. The four questions to put to any vendor here are in the buyer's guide.
What is not built for Somalia 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 Somalia. 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 a mobile-money connection, a per-port cost dimension, 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.
A cost dimension for the port, and no claim about whose rule applies
The port that cleared a consignment held as a reportable attribute, so margins can be compared across Berbera, Bosaso and Mogadishu instead of averaging into one figure that describes neither landing. What is deliberately not on this list at any price is a national fiscal position: there is more than one administration collecting revenue here, the arrangements between them are not ours to characterise, and software that resolved that ambiguity for you would be selling a tax opinion. The 5% is a single-stage sales tax with no input credit — where a particular amount belongs is your adviser's call.
Dollar-denominated wallets and multi-currency at the applied rate
EVC Plus, Zaad, Sahal and e-Dahab disbursement and collection files pulled into the Payments Register, so wages and supplier payments reconcile against a telco statement without re-keying. This is the first thing to build here rather than the second: mobile money is around 73% penetration, the services are dollar-denominated, and more than half the country is paid into a wallet and never cashes out — so the rail the money actually moves on is the one we have no connection to.
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
Income tax and statutory contribution schedules produced in the layout each filing body expects, from live payroll records. Not built — our maintained engine covers Kenya only, and the wallet disbursement half above is the part worth commissioning first.
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