Two currencies, one ledger
Liberia runs on Liberian and US dollars simultaneously. Most accounting software assumes you picked one. Here is what that costs, and how to model it properly.
Wilbert L. Gbatu
Chief Technology Officer (CIO) · 23 August 2026
A business here takes payment in Liberian dollars in the morning and US dollars in the afternoon, at a rate that moved between the two. Standard accounting software offers a single functional currency with foreign transactions converted at entry. That model quietly destroys information.
The problem is that conversion at entry is lossy. Once you have stored only the converted figure, you can no longer answer the question of what actually happened — how much cash of which kind moved, and at what rate. Every subsequent reconciliation becomes an attempt to reconstruct that from memory.
The fix is unglamorous: store the original amount, the original currency, and the rate applied, as three separate immutable facts on the transaction. Reporting currency becomes a derived view rather than stored state. This costs a little more space and considerably more discipline, and it makes month-end close a query rather than an investigation.
It also means that when the rate assumptions turn out to have been wrong, you can restate without re-entering anything.
