Run a finance team across more than one African market
Multi-currency expense management becomes one of your most persistent headaches. An employee in Lagos submits in NGN. One in Nairobi submits in KES. Your Accra office works in GHS. Your reporting needs to make sense of all three — and then exchange rates move, and the accounting problem gets genuinely complex if you don't have a systematic approach. Most expense tools weren't built for this. They support multi-currency in the sense that they won't reject a non-USD figure, but the workflows, approval thresholds, and reporting were designed around a single base currency with occasional foreign expenses as the exception. For pan-African companies, multiple currencies aren't the exception — they're the norm. This guide covers the decisions and processes that make multi-currency expense management workable, whether you're running two markets or ten.
Decide on a base reporting currency early
The first decision is what currency your finance team uses for internal reporting and consolidation. This is usually one of two things: USD for internationally structured companies or holding entities, or the local currency of your primary operating market. There's no universally right answer, but there are consequences to each choice.
USD as a base currency makes consolidated reporting cleaner if you have investors or a parent entity expecting dollar-denominated figures — but it adds a translation step for every local market and means your NGN or KES expenses are always one exchange rate away from the number in your reports.
A local base currency keeps things grounded for the primary market but can complicate reporting for subsidiaries operating in different currencies.
Whatever you choose, make the decision explicit and document it. The problems that emerge in multi-currency reconciliation almost always trace back to inconsistency — different team members applying different base currencies at different times without a defined policy to anchor to.
Record the original currency, always
The most common and most damaging mistake in multi-currency expense management is converting everything to a base currency at the point of submission and only storing the converted figure. It feels like it simplifies things. In practice it creates three problems:
Reconciliation becomes harder when rates were applied inconsistently. If one employee used the rate from Monday and another used the rate from Thursday, your converted totals are already wrong — and you have no way to detect or correct it because the original figures are gone.
Auditing becomes nearly impossible. An auditor asking to verify a KES expense needs to see the original KES amount, the rate applied, and the resulting converted figure. If you only have the converted figure, you can't reconstruct the audit trail.
You lose the ability to report by market. If you ever need to understand what your Nairobi operation actually spent in local currency terms — for local tax purposes, for a local management review, for benchmarking against local budgets — you need the original KES figures. Converted-only storage makes that impossible.
Always store the original currency and amount alongside the converted figure and the exchange rate applied. It takes marginally more space in your system and saves a significant amount of confusion at every month-end and audit.
Log the exchange rate with every expense
Storing the original currency solves half the problem. The other half is recording which exchange rate was used to convert it. For African currencies, this matters more than it might for stable currency pairs. NGN, GHS, and ZAR can move meaningfully within a single month. An expense submitted on the 3rd of the month and converted at a rate that's 8% different from the rate on the 28th isn't a rounding error — it's a material difference in your reported figures.
Your options for rate sourcing are:
Mid-market rate at date of submission — the most defensible for audit purposes and the most commonly used approach for expense management. Your expense tool should pull this automatically and log it with the record.
Month-end rate applied retrospectively — used by some finance teams for simplicity, but creates a reconciliation gap between what was submitted during the month and what appears in the closed accounts.
Fixed internal rate set monthly — common in large multinationals with formal treasury functions. Reduces variance in reporting but requires a process to set and communicate the rate at the start of each month.
Whichever approach you use, the rate needs to be recorded against each expense at the time of conversion — not reconstructed later.
Set up per-currency approval thresholds
Approval thresholds that make sense in one currency are often meaningless in another. A 50,000 NGN threshold sounds significant until you convert it — at current rates it's roughly $30. A 5,000 KES limit is a similar story in a different direction. If your expense policy defines approval thresholds only in a base currency and relies on employees to convert before deciding whether approval is needed, you will have inconsistency. Some employees will convert carefully. Others will guess. Others will submit first and ask later.
The cleaner approach is to define thresholds in each currency separately. Your Nigerian team sees their policy in NGN. Your Kenyan team sees theirs in KES. The rules are unambiguous regardless of where a submission comes from, and no one needs to mentally convert before deciding whether to seek approval. Farthingly lets you configure per-currency approval limits directly, so the policy is enforced at the point of submission rather than left to individual interpretation.
Reconciliation is where the approach proves itself
At month-end, a well-maintained multi-currency expense system should give you three things without manual reconstruction: total spend per currency in original terms, total spend converted to your base currency, and every exchange rate on record for the period. If your month-end reconciliation doesn't look like that, the issue is almost always one of two things:
Inconsistent rate application — different rates being used by different team members or at different times, with no single source of truth. The fix is to centralise rate sourcing in your expense tool so the rate is applied automatically and consistently.
Missing original currency data — expenses converted and stored without the source figures. The fix is a process change: original currency and amount become mandatory fields, and your tool enforces that at submission rather than allowing it to be skipped.
Fix the data capture and the reconciliation takes care of itself. The complexity in multi-currency expense management isn't the maths — it's the discipline of capturing the right information consistently across every market, every month.
What to look for in an expense tool for multi-currency teams
If you're evaluating expense management software for a pan-African operation, the multi-currency functionality to look for goes beyond a dropdown of currency codes. The questions that matter are:
Does it support NGN, KES, GHS, ZAR, and other African currencies natively — or does it treat them as unsupported edge cases?
Does it log the exchange rate automatically at the point of submission, or does it require manual entry?
Does it store original currency data alongside converted figures, or only the converted amount?
Can approval thresholds be configured per currency, or only in a single base currency?
Does month-end reporting give you a clean view by currency and by converted total without manual reconciliation work?
Farthingly was built to answer yes to all of those — because for African finance teams, multi-currency isn't an advanced feature. It's a baseline requirement.