Retail & POS in Abidjan and Dakar: Cash, Wave and the Till That Balances
Mobile money arrived faster here than the till software did. When a third of the day's takings never touched the cash drawer, "the till balanced" stops meaning anything useful.
Retail in Abidjan and Dakar changed shape faster than most retailers' systems did. A few years ago closing a shop meant counting notes and comparing the total to the till. Now a meaningful share of the day arrives by mobile wallet, some of it into a merchant account, some of it into a number belonging to whoever was on the counter, and the notes in the drawer no longer add up to the day's trade.
The consequence is not that the cash is wrong. It is that the sentence "the till balanced" has quietly stopped being a control, and in most shops nothing has replaced it.
What a till actually controls
It is worth restating the original logic, because once you see it, what mobile money broke becomes obvious.
A cash till is a closed loop. Every sale rung up adds an expected amount. At close, the physical notes should equal the opening float plus expected takings minus payouts. If they do not, either the counting is wrong or something is. The control works because there is exactly one place the money can be and one person who had access to it.
Mobile money does not break that loop by being electronic. It breaks it by creating a second destination that the till has no visibility of. Money can now arrive somewhere the drawer does not know about, from a customer the till does know about, and the two are reconciled by nobody.
A perfectly balanced cash drawer in a shop taking a third of its money by wallet is not evidence of anything. It is a control operating on a shrinking subset of the day.
Two custodies, not one
The mental model that fixes this is to stop thinking about a till and start thinking about two separate custodies that both have to be accounted for at close.
The cash custody
- Physical notes, one drawer, one person on shift, countable at any moment.
- Controlled the way it always was: opening float, recorded sales, recorded payouts, closing count, variance investigated the same day.
- Risks are the familiar ones — miscounting, unrecorded payouts, the informal loan from the drawer that was going to be repaid before close.
- Still works. The mistake is not that cash control failed. It is that it now covers less of the business than the person relying on it believes.
The wallet custody
- Electronic, arriving at one or more numbers, with a provider statement that exists but which nobody at the shop compares to anything.
- The critical question is whose number. A merchant account belonging to the business is a custody you control. A staff member's personal number is a custody you do not.
- Risks are different in kind: a sale received to a personal wallet and settled to the business later, or partially, or after a delay, or at the staff member's convenience.
- This is the one with no control on it in most shops, because it never had one and nobody noticed it needed one.
The single most important question in West African retail operations
Whose wallet number is on the counter? If any part of your takings arrives at a number belonging to an individual rather than to the business, you do not have a reconciliation problem — you have an unsecured advance to a member of staff, granted daily, in an amount nobody records. Fix the destination before you fix the reporting; no software can control a custody it cannot see.
What close of day should look like now
-
Record the tender type on every sale, at the sale
Cash, wallet, card, credit — chosen at the point of sale, not assigned later from memory. This one field is what makes everything below possible, and it is the field most shops skip because it slows the counter by a second.
-
Count the cash against expected cash only
Opening float plus cash sales minus payouts. Not total sales. If your closing procedure still compares notes to the full day's trade, it has been producing a meaningless variance for as long as you have taken wallet payments.
-
Reconcile wallet takings to the provider record
Expected wallet sales from the system against what the provider actually shows received. Daily, by someone who is not the person on the counter. This is the step that does not exist in most shops and the one that would find the problems.
-
Investigate each variance in its own custody
A cash shortfall and a wallet shortfall are different events with different explanations and different people involved. Netting them against each other — which a single combined variance figure invites — hides both.
-
Record a same-day explanation, or it becomes permanent
A variance explained on the day is an incident. The same variance a fortnight later is a write-off with no owner, and the pattern is that they stop being investigated at all once they routinely go unexplained.
-
Bank on a schedule and record the deposit against the days it covers
Both custodies. A wallet balance that stays with the provider indefinitely, or cash that accumulates because banking is inconvenient, are both uncontrolled positions regardless of how well the daily close went.
A worked close, done properly
A single boutique in Abidjan, one counter, one shift. This is what the numbers look like when tender type is recorded and the two custodies are separated — and, at the bottom, what the old single-figure close would have reported instead.
Close of day, two custodies
The cash variance is a counting error and will be found in ten minutes. The wallet variance is twenty-five times larger and is a different question entirely — a payment taken to the wrong number, a customer who did not complete, or a sale recorded as wallet that was never received. A single combined close would have reported a variance of 39,000 XOF and sent someone to recount the drawer, where the answer was never going to be.
Where we stand on mobile money, precisely
This deserves a blunt paragraph rather than a footnote, because it is the thing a retailer here will ask first and the thing most vendors answer evasively.
We have no integration with any West African mobile money provider. Not Wave, not Orange Money, not MTN MoMo, not Moov. There is no API connection, no automatic import of provider transactions, no live confirmation that a payment was received, and no roadmap commitment we are prepared to make on a blog post. Our only mobile money integration anywhere is M-Pesa, it is Kenya-only, and it does not travel.
What we support is the reconciliation pattern rather than the integration: tender type recorded on every sale, a reference field on the transaction, expected receipts by tender for any period, and a variance you can act on. That is genuinely useful and it is materially less than integration. A retailer who needs the provider record pulled in automatically should ask specifically which providers a vendor connects to, when it was last tested, and what happens when the provider changes something — and should expect to be surprised by how many "integrated" answers turn out to mean a manual file upload.
How reconciled do you actually need to be?
One total at close
Cash counted against total sales, wallet ignored. Common, and it means your control now covers only the shrinking part of the day that still arrives as notes.
Tender type recorded, cash reconciled
Cash is genuinely controlled again because it is compared to expected cash rather than total sales. Wallet takings are visible as a figure but not yet checked against anything. A real improvement over the first position and frequently mistaken for the finish.
Both custodies reconciled, provider record checked manually
Wallet expected against wallet received, daily, by someone off the counter. Where we sit. No integration, but the control is complete and the variance is real. For most single-site and small multi-site retailers this is sufficient and considerably cheaper than the alternative.
Provider integration with automatic matching
Transactions pulled in and matched without anyone opening a statement. Genuinely better at volume and across many sites. We do not do this in West Africa and you should buy it from someone who demonstrably does, having checked which providers and when it was last tested.
Note where the biggest single gain is: between the first and second positions, which costs nothing but a field at the point of sale. Most retailers here are on the first position and shopping for the fourth.
The rest of the shop
Two things worth adding, because a post about payments can imply that payments are the whole of retail operations.
Stock is still the larger number. Whatever is going wrong at the till, more money is usually tied up in, or leaking from, inventory. A retailer who fixes reconciliation and never counts stock has improved the smaller problem. Cycle counting a section a week, with variances investigated the same week, is worth more than most till improvements.
Multi-site changes the question. With three or four shops, the issue becomes comparability: whether a variance at one branch is normal or exceptional, whether a price change actually applied everywhere, and whether one branch's stock can be seen from another. That is a different problem from a single boutique's close and it is where an operations system starts to justify itself beyond the till.
Where to go next
Stock movement between shops and depots is covered in distribution from Dakar and Abidjan. Buying advice for the wider system is in the Côte d'Ivoire buyer's guide and the Senegal buyer's guide. Where the accounting boundary falls — including who turns your daily takings into statutory books — is in OHADA, SYSCOHADA and your operations system.
Our take
Record tender type at the point of sale and reconcile the two custodies separately. That is the whole recommendation, it costs a second per transaction, and it recovers a control that most shops here lost without noticing. Before any of it, settle whose wallet number is on the counter — a custody you do not own cannot be reconciled, only regretted. And be sceptical of mobile money integration claims, including by asking us: we have none in West Africa, we support the reconciliation pattern instead, and for most retailers that is enough. For high-volume multi-site operators it is not, and you should buy the integration from someone who can name the providers and the last time they tested them.
What is not built for Senegal 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 Senegal. 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 DGID declarations, a bank or mobile money feed, a statutory return format 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.
DGID declarations and e-invoicing
Declaration output in the format the administration expects and electronic invoicing against any prescribed interface, with retries, a failure queue and a reconciliation report.
Wave, Orange Money and bank feeds
Mobile money settlement files and bank statement feeds pulled into the Payments Register, so collections match invoices without anyone re-keying a statement.
Payroll and statutory returns
IR, IPRES and CSS schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt in a spreadsheet each month.
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 integratedBring us one day's takings
A real close, with the wallet figures. We can usually show you within the hour where the control has a hole in it.
Explore AWRA for retailFrequently asked questions
Does AWRA integrate with Wave or Orange Money?
No. We have no integration with Wave, Orange Money, MTN MoMo, Moov or any other West African mobile money provider — no API connection, no automatic transaction import and no live payment confirmation. Our only mobile money integration anywhere is M-Pesa and it is Kenya-only. What we support is the reconciliation pattern: tender type recorded on every sale, a reference field on the transaction, expected receipts by tender for any period, and a variance you can act on daily.
Can the POS work offline?
Ask this specifically in a demo and test it rather than accepting a general answer, because the important detail is what happens mid-transaction rather than whether the word "offline" appears on the website. What you want to establish is whether a sale in progress survives a connection drop, what a user sees when it happens, and whether anything can be lost or duplicated when the connection returns. Apply the same test to every vendor you shortlist, including us.
How do we control takings that arrive on a staff member's personal number?
You cannot control that with software, and this is worth being direct about. A payment arriving at a number belonging to an individual is a custody the business does not hold, and no reporting layer changes that — it is effectively a daily unsecured advance to a member of staff in an amount nobody records. The fix is operational: takings must arrive at a destination the business owns. Once that is true, the reconciliation described in this post works. Until it is true, reconciliation only measures the size of the exposure.
Should the cash count be compared to total sales?
No, and this is the most common error in shops that have added mobile money without changing their close. Cash should be counted against expected cash only — opening float plus cash sales minus payouts. Comparing notes to the full day's trade produces a variance that includes every wallet payment and is therefore meaningless. Separate the custodies, produce two variances, and investigate each in its own terms rather than netting them into one figure.
Does it handle multiple shops?
Yes — multiple locations with their own stock positions, transfers between them, and reporting that lets you compare branches rather than only totalling them. That comparability is usually the point at which an operations system earns its place beyond a till: knowing whether one branch's variance is normal, whether a price change actually applied everywhere, and whether stock sitting in one shop could serve a customer standing in another. Single-boutique operators generally need much less than this.
Do you print receipts and invoices in French?
No. All printed output — receipts, invoices, delivery notes, purchase orders — is produced in English, because the system is English only with no translation files and no setting to enable one. For a customer-facing retail business this is a genuine commercial consideration rather than a cosmetic one, and it stops some retailers from buying from us. We would rather state it here than have it discovered after installation.
