Ninety Days, Two Meanings
Two finance managers open the same aging report on the same morning. One is in Lagos and one is in Abidjan, and the ninety-day column means something completely different to each of them. Only one of them can safely treat it as a collection problem.
An aging report is one of the few pieces of finance software that everybody reads the same way. Current, thirty days, sixty, ninety, over ninety. The further right a number sits, the worse it is. Nobody needs the columns explained, which is exactly why nobody examines what they assume — and what they assume is that the only thing changing as an invoice moves right is the likelihood of being paid.
That assumption is correct in most of the world most of the time, and it is worth being precise about why. It holds when the unit of account holds still. If a hundred thousand of your currency is worth the same when you collect it as when you issued it, then aging measures exactly one thing — collection risk — and the standard escalation ladder is the whole of the response.
West Africa is the place to notice this, not because the region is uniquely difficult, but because it contains both cases at once. That is unusual, and it makes the point in a way a single-country example cannot.
One region, two currency regimes
The West African CFA franc, used across the eight countries of the monetary union, is pegged to the euro at a fixed parity. It is not a market rate that happens to be stable; it is a rate set by arrangement. For a business invoicing in CFA francs and collecting in CFA francs, the ninety-day column is a collection-risk ladder and nothing else. The classical reading of the report is simply correct.
The naira and the cedi float. For a business invoicing in either, an invoice at ninety days has been exposed to whatever the currency did over those ninety days, and that exposure is independent of whether the customer is good for the money. A perfectly reliable customer who pays on day ninety, exactly as agreed, has still handed you something whose purchasing power is decided by events neither of you controls.
So the same report, with the same columns, carries two different meanings inside one region. In Abidjan, ninety days is a question about the customer. In Lagos, it is a question about the customer and a question about the money, and the report cannot tell you which part is which.
exchange_rate field and not one of them fills it in What the aging report does, exactly
Start with what is true, because it changed recently and the change matters more than it sounds. The AR/AP aging report totals its buckets separately for each currency and adds nothing across them. If you invoice in naira and in dollars, you get a naira bucket set and a dollar bucket set, each labelled, sitting beside each other. Nothing is converted. Nothing is summed into a single headline.
That is worth stating plainly because the previous behaviour was the obvious one and it was wrong: a single set of buckets containing the arithmetic sum of unlike currencies, with no currency named anywhere on the page. It produced a number that looked entirely normal and meant nothing. If you have used a report like that — in any system — it is worth checking what it does with a second currency, because a page that shows one clean total is not evidence that it only found one currency.
The instinct on reading "nothing is converted" is that this is a limitation to be fixed. It is worth resisting, because refusing to convert is the correct behaviour, and for reasons that have nothing to do with effort.
A converted total
- Needs a rate, which means somebody has to decide which rate.
- Needs an as-at date, and the honest choices — issue date, period end, today — give three different answers.
- Changes between two viewings of the same closed period, because the rate moved and the period did not.
- Reconciles to no ledger. The figure exists only on that screen.
- Looks authoritative. That is the problem: it is the most confident number on the page and the least defensible.
Currencies kept apart
- Needs no rate, so there is nothing to argue about.
- True at every viewing, including a re-run of a closed period a year later.
- Each figure ties to invoices you can list.
- Makes the reader aware there is more than one currency — which the single total actively concealed.
- Costs you a single-number summary, and that is a real cost. It is the right trade.
A total that changes when you look at it twice is not a total. It is a snapshot of an exchange rate wearing a receivables label.
The thing that is genuinely missing, and it is not conversion
Here is the gap, stated as precisely as it deserves. The system can convert a figure for display: an organisation can nominate a display currency, and amounts are then shown with a "≈" prefix, converted at the live rate, under a note that says in plain words that this is indicative and that invoices and statements remain in the original currency. That is a well-behaved feature and it is honest about what it is.
What it cannot do — what nothing in the product can do — is tell you what an invoice was worth on the day you issued it. No transaction table stores an exchange rate. Not invoices, not point-of-sale, not quotations, not payments, not expenses. The financial snapshot taken at invoicing declares a field for one and no code path anywhere fills it in.
The consequence is specific and easy to miss. Because the display conversion always uses today's rate, a ninety-day-old invoice and one raised this morning are converted identically. The old one appears as though it was always worth what it is worth now. The erosion does not show up as a smaller number; it does not show up at all. It is concealed by the very feature that looks like it is handling currency for you.
The same invoice, read three ways
None of this is unique to one product. Storing a rate against every transaction is a real design commitment — it implies a revaluation run, a realised-versus-unrealised distinction, and gain and loss accounts to post the difference to. Systems that do it are noticeably heavier to operate. The point is not that the commitment should have been made; it is that you should know which side of it your system is on, because in a floating-currency market the answer determines what your aging report is capable of telling you.
What to do while that is true
The practical response is not to wait for a feature. It is to stop asking the aging report a question it was never built to answer, and to move the currency decision earlier — to the point where you still have options.
-
Decide the currency at quotation, not at collection
The only genuinely effective lever is which currency the invoice is denominated in, and it is available exactly once — before the customer agrees. By the time an invoice is in a ninety-day bucket every option has expired. This is a commercial decision that finance usually inherits and rarely gets to make.
-
Shorten terms rather than chase harder on the ones you have
In a stable currency, thirty-day and sixty-day terms differ by collection risk alone, and the difference is often worth conceding to win the work. Where the currency floats they also differ by exposure, which does not care how good the customer is. Terms are the second lever and, unlike the currency, they are usually yours to set.
-
Read the buckets per currency and never in aggregate
This is now what the report gives you. Treat each currency's ninety-plus column as its own problem with its own urgency, because they genuinely are — an aged CFA receivable and an aged naira receivable of the same size are not the same amount of trouble.
-
Record the rate at issue yourself, if the number matters to you
Custom fields are available on invoices, and they carry through to reports and exports. A rate-at-issue field entered at invoicing is not a substitute for a revaluation engine and should not be described as one. But it is the difference between being able to work the number out later and not being able to.
-
Keep the display conversion switched on, and keep reading the note
The indicative conversion is useful for the question it answers — what is this worth to me now. The note under it, saying invoices and statements remain in the original currency, is not boilerplate. It is the exact boundary of what the figure means.
The part that does work well, and is easy to overlook
One thing worth crediting, because it is the sort of detail that quietly signals whether a system was built with the region in mind. CFA francs have no minor unit. There are no centimes to display, and a system that prints two decimal places against a CFA amount is telling every reader that it does not know what currency it is handling. Both West African CFA francs and Guinean francs are treated as whole-number currencies throughout — amounts, reports and exports. The naira and the cedi carry two decimals, as they should.
It is a small correctness. It is also the kind that is very hard to retrofit and very obvious when it is absent.
What AWRA OpsHub does today
- Aging buckets totalled separately per currency, each labelled, with nothing added across them and nothing converted — on the report and on the API.
- A currency on every invoice, recorded at issue and carried through the register, the aging report and the exports.
- Indicative display conversion, opt-in per organisation, at the live rate, clearly marked with "≈" and a note stating that invoices and statements remain in the original currency.
- Live rates fetched and cached, with each pair persisted as last-known-good, so a provider outage degrades to the last good rate rather than to nothing.
- Correct precision per currency — CFA and Guinean francs as whole numbers, naira and cedi to two decimals, in every figure the system prints.
- Custom fields on invoices, reportable and exportable, which is how a rate-at-issue becomes a field you can actually query.
What it does not do
- No exchange rate is stored against any transaction. Not on invoices, sales, quotations, payments or expenses. The rate on the day is not recorded anywhere.
- No revaluation. Nothing re-states an open receivable at a later rate, on a schedule or on demand.
- No foreign exchange gain or loss accounting. There is no realised or unrealised distinction and no account for the difference to post to.
- No conversion in the aging report itself, deliberately. The buckets are never expressed in a common currency, because doing so would require a rate and an as-at that no two readers would agree on.
- No hedging, forward cover or exposure reporting of any kind. If you need to know your net position by currency at a date, that is not a report we produce.
- No warning when a receivable ages in a floating currency. The report does not know which currencies float, and it does not treat any of them differently.
What is not built for Nigeria 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 Nigeria. 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 FIRS e-invoicing, 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.
FIRS e-invoicing and tax pipelines
Invoice transmission against the authority's published interface, plus WHT credit handling and sector levies — with the parts vendors gloss over: retries, a failure queue and a daily report of sales carrying no fiscal reference.
Banks, cards and transfers
Bank statement feeds, card acquirer settlements and bulk-payment files pulled into the Payments Register, so money in and out reconciles without anyone re-keying a statement.
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
PAYE, pension and NHF 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 integratedThe question worth taking away
If you operate on both sides of this region — and a great many organisations do, with a Lagos or Accra operation and a francophone one under the same roof — the useful exercise is not to compare the two aging reports. It is to notice that you have been reading them with the same instincts, and that only one of those readings was complete.
The collections argument for the stable case is set out in full in receivables and collections, and every word of it still applies where the currency holds still. The credit-limit side of the same problem — stopping the next invoice to a customer who has stopped paying — is covered in credit limits and holds. What this post adds is the second axis, and the honest position on it: the report will tell you what is owed, in what currency, and for how long. It will not tell you what it was worth when you agreed to it. Knowing that the system does not know is worth more than a number that pretends otherwise.
Frequently asked questions
Why does the aging report not just convert everything into one currency?
Because a converted total needs a rate and an as-at date, and the honest candidates — issue date, period end, today — give three different answers. Worse, it moves between two viewings of the same closed period and reconciles to no ledger. Currencies are kept apart, each set of buckets labelled, so that every figure on the page ties to invoices you can list.
Does the system record what the exchange rate was when I raised an invoice?
No. No transaction table stores an exchange rate — not invoices, point-of-sale, quotations, payments or expenses. Live rates are fetched for indicative display conversion, but that conversion always uses the current rate, so an old invoice and a new one are converted identically. If a rate-at-issue matters to you, a custom field on the invoice will hold it and will carry through to reports and exports.
Can I see all my receivables as one number if I invoice in more than one currency?
Not on the aging report, deliberately. You get one labelled set of buckets per currency. Elsewhere in the product, where a single figure genuinely has to be shown, the convention is to show the largest single currency, labelled, and disclose how many others exist — never to add unlike currencies together.
Are CFA francs handled correctly, given they have no cents?
Yes. West African CFA francs and Guinean francs are treated as zero-decimal currencies throughout — amounts, reports and exports — so no fictional centimes are printed. Naira, cedi, leone, Liberian dollars and dalasi carry two decimal places.
Does an aged receivable in naira get flagged differently from one in CFA francs?
No, and it is worth being clear about that. The report separates currencies but does not rank them by risk — it has no notion of which currencies float. The judgement that a ninety-day naira receivable is a different problem from a ninety-day CFA one is yours to make; the report gives you the two figures apart rather than merged, which is what makes the judgement possible.
