OHADA, SYSCOHADA & Your Operations System: Where the Line Falls
In seventeen countries the chart of accounts is not a design choice, it is legislation. Our ledger has no account numbers at all. This post explains why that is deliberate, why it is the right answer, and exactly where the handoff belongs.
Most software vendors, asked whether they support OHADA accounting, will say something encouraging and change the subject. We are going to do the opposite, because the honest answer is more useful than the encouraging one and because in this particular market the encouraging answer causes real damage.
Here is ours. Our chart of accounts contains no account numbers. Not the wrong numbers — none. There is no code column in the table. Accounts have a name, a description and a nature, and there are fourteen of them out of the box. Nothing about that structure can produce a statutory presentation under the harmonised accounting act, and no amount of configuration will change it.
That is not an apology. It is a design decision, and the rest of this post argues that it is the correct one — and, more usefully, sets out precisely how the arrangement should be built so that having two ledgers costs you almost nothing.
Nothing here is accounting or legal advice. Your expert-comptable and the applicable law govern; confirm everything with them.
What OHADA actually requires
For readers arriving from markets without an equivalent: OHADA is a treaty organisation harmonising business law across its member states, and its accounting act prescribes a common accounting system for all of them. This is genuinely unusual and genuinely valuable — an accountant in Dakar and one in Douala are working to the same framework.
The part that matters for software is that the chart of accounts is prescribed rather than proposed. Accounts are organised into numbered classes, each with a defined meaning, and statutory financial statements have a mandated presentation derived from those numbers. An account is not merely called "Suppliers"; it sits at a specific coded position within a specific class, and the position is what makes the statutory output computable.
A system that stores account names but not account codes has not implemented a slightly incomplete version of this. It has implemented a different thing entirely — a thing that happens to also be called a chart of accounts.
A prescribed chart of accounts is a data structure written into law. You either implement the structure or you do not. There is no partial credit.
What our ledger actually is
Being specific is more useful than being vague, so here is the shape of the thing, described accurately.
- Fourteen seeded accounts, of which nine are locked system accounts the platform posts to automatically — cash, bank, receivables, payables, inventory, purchases, sales revenue, expenses, taxes payable.
- Each account has a name, an optional description and a nature: debit or credit. That is the entire classification.
- No code field. No numeric identifier, no class, no sub-account hierarchy, no parent. You cannot enter one because there is nowhere to put it.
- Grouping for internal reports — what counts as revenue, expense, asset, liability — comes from a fixed configuration file inside the application that maps account keys to groups. It is not per-organization and not per-country.
- That mapping's equity group is presently empty, which tells you something honest about the ambition of the design: it was built to make operational postings coherent, not to close a set of books.
Read that list as a description of what it is for, and it stops looking deficient. It is the accounting spine of an operations system — enough structure to make a stock movement, a supplier invoice or a payroll posting land somewhere sensible and reconcilable. It was never a statutory ledger wearing a disguise.
Why we are not going to fix this
The obvious question is why we do not simply add a code column and ship a SYSCOHADA plan. It would not be difficult. We have decided against it, for three reasons worth stating.
Because the numbers are the easy part. Shipping a numbered plan would take a week. Keeping it correct as the accounting act is revised, defending a mapping decision to an auditor, handling the presentation rules and the disclosure requirements, and being accountable for the resulting statements across seventeen jurisdictions — that is not a week, it is a business, and it is a business already competently occupied by local accounting software and by the profession itself.
Because a half-implemented statutory ledger is worse than none. If we shipped account codes, a reasonable buyer would infer that our output is statutory. They would rely on it. The failure would surface at year end, in front of someone with authority, and it would be our fault for implying a competence we do not have.
Because the split is genuinely better. The next section is the actual argument.
The two-ledger arrangement
Nearly every well-run business in an OHADA country already operates two ledgers, whether or not anyone has named it. There is what the business knows day to day, and there is what the expert-comptable formally records. The failure mode is not having two — it is having two that nobody has connected on purpose.
Where the line falls, and what crosses it
Your operations system
Answers "what is happening?" — continuously, at capture, by the people doing the work.
- Stock on hand, by location, including what is currently on a truck
- Purchase requisitions, approvals, orders, receipts and three-way matching
- Supplier invoices with the approval chain and supporting documents attached
- Sales, customer balances and what is genuinely collectable
- Assets, custody, condition and depreciation schedules
- Project and cost-centre attribution as work happens, not reconstructed later
- Who did what, when, and what the record looked like before they changed it
Your statutory ledger
Answers "what must be reported?" — periodically, to a prescribed structure, by someone accountable for it.
- The numbered SYSCOHADA chart of accounts, in its prescribed classes
- Journals and postings in the statutory form
- Statutory financial statements in their mandated presentation
- Tax computations, returns and filings
- Year-end adjustments, provisions and closing entries
- Professional judgement, and professional responsibility for it
What crosses the boundary, and how often
- Monthly, operations to statutory: purchases with supporting documents and approvals, sales, stock valuation movements, payroll cost, asset additions and disposals — as a defined extract, in an agreed format, on an agreed date.
- Monthly, statutory to operations: confirmation that the extract reconciled, and a list of anything that did not, so it is corrected in the operational record rather than silently adjusted out of sight.
- At year end, one direction only: closing adjustments and provisions live in the statutory ledger. They do not come back. Your operational stock figure is not restated because an accountant made a provision.
- Continuously, on request: the underlying document. Every operational transaction carries its attachment, so "send me the invoice for this" is a search, not an excavation.
The single most valuable hour of any implementation in an OHADA country is spent with your expert-comptable agreeing the four items above. Businesses that skip it do not avoid the conversation — they have it in March, under pressure, with worse information.
What your expert-comptable actually wants from you
It is worth stating what the accounting profession complains about, because software rarely addresses it and it is nearly always the same complaint. It is not that clients use the wrong system. It is that clients arrive with a carrier bag.
The billable time in a small-business engagement is overwhelmingly spent establishing what happened: which of these receipts is a business expense, was this invoice ever approved, why does the stock figure differ from last month, who authorised this payment, where is the delivery note. None of that is accounting. It is archaeology, and you are paying professional rates for it.
An operations system does not replace your expert-comptable. It replaces the archaeology. That is the whole value proposition of the split, and it is worth considerably more than a numbered chart of accounts you would not have maintained correctly anyway.
A question to put to your accountant this month
Ask them what proportion of their time on your file is spent obtaining and verifying source information, rather than doing accounting. The answer is usually uncomfortable and it is the honest business case for everything in this post — better than any figure a software vendor could put in front of you.
Setting the boundary up properly
-
Get your expert-comptable in the room during selection
Not after. They will tell you in ten minutes what they need to receive, and that requirement should shape the configuration rather than be discovered by it. They are also the right person to spot a vendor overclaiming on statutory coverage.
-
Write the extract specification on one page
Which records, at what level of detail, in what format, on which day of the month, sent how. One page, agreed by both sides, revisited once a year. This is the artefact that makes the arrangement work.
-
Agree the reconciliation points
Bank, receivables, payables, stock valuation. For each, who checks, against what, how often, and what happens when it does not agree. Unreconciled differences that nobody owns become permanent.
-
Decide where adjustments live
Our recommendation is firm: statutory adjustments stay in the statutory ledger and are never pushed back. The operational record should reflect operational reality. Two ledgers that agree on everything are not two ledgers, they are one ledger maintained twice.
-
Attach documents at capture, always
Every purchase, every invoice, every asset. The discipline costs seconds per transaction and it is the entire reason the archaeology disappears. A record without its document is a claim.
-
Close operational periods on a schedule
Lock the operational period once it has been extracted and reconciled, so that last month stops moving underneath a set of accounts already prepared from it. A period that stays open indefinitely guarantees the two ledgers diverge.
How to test a vendor claiming OHADA support
"Show me your chart of accounts. I want to see the account numbers."
What you will hear
A numbered plan in its classes, on screen, in under a minute.
How to read it
Names without numbers means what it means. Ours has names without numbers, which is why we open with it rather than wait to be caught.
"Show me a statutory balance sheet your system produced for a real client."
What you will hear
An actual document, in its mandated presentation, that was actually filed.
How to read it
A demo report titled "Balance Sheet" is not evidence. The question is whether a professional signed something your system generated.
"When the accounting act is revised, who updates the plan, and how did you handle the last revision?"
What you will hear
A specific account of a specific past change, with dates.
How to read it
A vendor maintaining a statutory plan has a history of maintaining it. No history means the plan was shipped once and left.
"What do you expect our expert-comptable to do?"
What you will hear
A clear description of a handoff, or a clear claim to replace them entirely.
How to read it
The dangerous answer is the vague middle — implying replacement while quietly assuming an accountant is still there. Make them pick one.
"Is your accounting output statutory or management?"
What you will hear
A one-word answer, immediately.
How to read it
Hesitation here is the whole story. Ours is management, and we say so without being asked.
When you should not buy from us
To be concrete, because the split does not suit everyone. If you are a small business whose principal software need is to produce statutory accounts and file them, and whose operational complexity is low — modest stock, few suppliers, no multi-site — then a local accounting package built for OHADA is a better purchase than we are, and buying an operations layer first would be solving a problem you do not have. We would tell you that on the call.
The split earns its keep when the operational side is where the complexity and the money actually are: stock across locations, procurement that needs governing, assets to track, projects to cost, donors or customers who audit you. Then the statutory ledger is a monthly obligation and the operations system is where you run the business.
Where to go next
Country-level buying advice, where this boundary shows up as the deciding factor, is in the Senegal buyer's guide and the Côte d'Ivoire buyer's guide. For groups across several member states, one currency, eight tax authorities covers the multi-country structure. The language question — which is the other half of why this market is distinctive — is in a French-language business buying English-language software.
Our take
Do not buy an operations system as a statutory ledger, and be sceptical of any foreign vendor who lets you. Keep your OHADA books where the accountability sits — with a local package, your expert-comptable, or both — and use an operations system to make their job about accounting rather than archaeology. Write the handoff down on one page before go-live. Done that way, the two-ledger arrangement is not a compromise you tolerate; it is a cleaner division of labour than a single system pretending to do both, and it is what the better-run businesses in these markets already do.
Bring your expert-comptable to the call
Genuinely — the conversation goes faster with them in it, and they will ask us the sharp questions. We will tell you plainly where we stop.
Talk to us about the splitFrequently asked questions
Does AWRA support the SYSCOHADA chart of accounts?
No. Our chart of accounts has no account-number field at all — accounts carry a name, a description and a debit or credit nature, and there are fourteen seeded by default. There is no class structure, no hierarchy and no code column, so a numbered statutory plan cannot be entered even manually. This is a deliberate design decision rather than an unbuilt feature, and we do not intend to change it. Your statutory books belong with a local accounting package or your expert-comptable.
Can AWRA produce OHADA statutory financial statements?
No. We produce management reporting from operational data — stock valuation, purchases, sales, receivables, payables, project and asset costs — which is genuinely useful for running the business and is not a statutory presentation. Statutory financial statements under the harmonised accounting act have a mandated structure derived from the numbered chart of accounts, which we do not implement. Confirm your filing obligations with your expert-comptable.
Why not just add account codes?
Because the codes are the least of it. A credible statutory implementation means maintaining the plan through revisions of the accounting act, defending mapping decisions to auditors, implementing presentation and disclosure rules, and accepting responsibility for the resulting statements in every member state. That is an ongoing professional commitment, not a feature, and it is already well served locally. Shipping codes without that commitment would imply a competence we do not have, and a buyer would reasonably rely on it.
So do we need two systems?
In practice most well-run businesses in OHADA countries already have two — an operational reality and a statutory record — and the question is only whether the connection between them is deliberate. Our recommendation is a defined monthly extract from operations to your expert-comptable, a reconciliation confirmation coming back, statutory adjustments staying on the statutory side, and documents attached to operational transactions so source information is never chased. Agree that on one page before go-live.
What does this arrangement actually save?
Mostly the archaeology. A large share of what a small business pays an accountant for is establishing what happened — which receipt belongs to what, whether an invoice was approved, why the stock figure moved, who authorised a payment. When those answers are already recorded, attached and auditable, the engagement shifts toward actual accounting. Ask your accountant what proportion of your file is currently spent on that reconstruction; the answer is usually the honest business case.
Is there any OHADA country where you do produce statutory accounts?
None. Not Senegal, not Côte d'Ivoire, not Cameroon, not any of the member states. There is also no market anywhere in which we produce statutory financial statements — the ledger design that prevents it in OHADA countries prevents it everywhere. Our accounting layer exists to make operational postings coherent and reconcilable, and that is the whole of its ambition.
Should a small business buy this at all?
Not always, and we will say so. If your main need is producing and filing statutory accounts and your operations are simple — modest stock, few suppliers, one site — a local OHADA accounting package is the better first purchase and an operations layer would be premature. The split earns its keep when operational complexity is where the money is: multi-location stock, procurement needing approval chains, assets, project costing, or funders who audit you.
