Two CFA Francs, One Peg, and Software That Cannot Tell Them Apart
The Central African and West African CFA francs are pegged to the euro at exactly the same rate. They are still two currencies, under two central banks and two sets of exchange rules — and most systems store both as one label.
A hundred thousand XAF is worth exactly a hundred thousand XOF. Not approximately, not on most days — exactly, by arrangement, because both are pegged to the euro at the same fixed rate. It is one of the very few pairs of currencies in the world where you can say that with no qualification at all.
They are nonetheless two separate currencies, issued by two separate central banks, circulating in two separate monetary unions under two separate exchange regulations, and they are not interchangeable. You cannot spend one in the other's zone. A payment from Douala to Abidjan is a cross-border transfer between two currencies that never move against each other.
That is a genuinely strange fact, and strange facts are exactly what software gets confidently wrong.
What the mistake actually looks like
Nobody sets out to merge them. It happens through a label. A chart of accounts says CFA. A price list says CFA. A spreadsheet column says CFA. Everybody knows what is meant, until the day they do not.
| Where it shows up | What actually happens |
|---|---|
| A group balance sheet | A payable in Libreville and a receivable in Lomé net against each other on a report. Arithmetically correct. Operationally meaningless — they are obligations in two banking systems that cannot settle one another |
| A cash position | A consolidated CFA cash figure that tells you the total and not which half of the group can actually spend it |
| An intercompany transfer | Treated as a same-currency movement because the rate is one, so nobody applies the exchange-control treatment it actually requires |
| A supplier record | One currency field, one label, and no way to filter for counterparties outside your own monetary union |
A report that is arithmetically perfect and operationally useless is more dangerous than one that is obviously wrong, because nobody goes looking for the error.
The risk here is not the rate
Because the peg does not move, teams reasonably conclude there is no currency risk in this zone and stop paying attention to currency. The conclusion is right and the inference is wrong.
Rate risk
Effectively absent while the peg holds, which it has for a long time. This is the risk everybody knows how to think about, and it is the one that is not here.
Administrative risk
Whether and when a transfer is permitted to happen. This is the real exposure in the zone, it is measured in elapsed days rather than basis points, and no exchange-rate hedge addresses it.
Classification risk
Whether your system can tell you which side of the boundary a balance is on. Cheap to get right at setup and expensive to reconstruct later.
Record-keeping
Storing the actual currency code on every transaction rather than a shared label. Costs nothing while the peg holds and is the only reason you would ever be able to answer the question if it stopped.
Inside the CFA zone can still be outside your monetary union
This is the practical trap, and it catches groups with operations either side of the boundary more or less every time.
A payment from Cameroon to Senegal feels domestic in every way that matters commercially. Same currency name, same value, same language, frequently the same accounting framework, often the same banking group. For the purposes of the CEMAC exchange regulation it is a transfer out of the monetary area, and it needs the same treatment as a payment to Rotterdam.
The rule that avoids this permanently
Drive the exchange-control treatment from the counterparty's monetary zone rather than from whether the currency looks familiar. That turns a judgement somebody makes per transaction — under time pressure, usually correctly, occasionally not — into a rule the system applies every time. It is a five-minute configuration decision that removes an entire category of avoidable delay.
What to actually do about it
Nothing here is difficult and none of it requires special software. It requires a system that refuses to let two different things carry the same label, which is the same discipline that makes stock counts and supplier balances trustworthy — applied to a currency code.
- Store XAF and XOF as distinct codes on every transaction, account and price list. Never "CFA".
- Make sure a report can be produced per zone, not only in total.
- Drive exchange-control treatment from the counterparty's zone, not the currency label.
- Check whether your consolidated cash figure can be split by monetary union today. If not, that is the first thing to fix.
- If you operate either side of the boundary, confirm that intercompany transfers between them are being treated as cross-border.
The last one is worth a specific look. Groups that grew from one side to the other almost always started by treating the new entity as an extension of the old, and the currency label is usually the last piece of that assumption still in place years later.
A note on why this is worth writing down
Most of what gets published about the CFA franc is about monetary policy — the peg, the arrangement with the French treasury, the reform debates, whether the whole thing should exist. Those are real arguments and they are not this one.
This is a much smaller and much more immediate point: whatever happens to any of that, a business operating in the zone today needs its system to know which of the two it is holding. That is true under every possible future for the currency, and it costs nothing to be right about now.
What is not built for Central Africa 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 Central Africa. 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 national e-invoicing pipeline, a French interface, 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.
National tax pipelines and a clean handoff to your ledger
Electronic invoicing against your administration's published interface, and a defined monthly export mapped to your expert-comptable's chart of accounts. The statutory SYSCOHADA ledger itself stays with them by design — the same refusal we apply in every OHADA member state, for the same reason.
Mobile money, banks, French interface and the exchange-control file
MTN MoMo, Orange Money and bank statement feeds into the Payments Register, French interface text and document templates, and the CEMAC exchange-control file assembled from the purchase record rather than rebuilt by hand for each transfer.
Payroll and statutory returns
National income tax and social security schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt 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 integrated