SYSCOHADA closing: what it reveals about your ERP.

We have made a habit, when arriving at a client, of sitting with the accounting team during a close before reading any documentation at all. Not out of a taste for folklore: because the close concentrates in a few days everything the rest of the year conceals. Upstream processes can live for a long time with their approximations. The close, however, must produce a figure that is accurate, dated, and defensible before the statutory auditor and the tax authorities. It therefore absorbs, month after month, the cost of everything that was badly recorded, bypassed or patched together upstream. Its duration and its pain are the consolidated invoice for those compromises.

What the ERP must produce natively

In the OHADA area, the close is not merely an internal exercise. The Uniform Act on accounting law and financial reporting imposes a set of statements: the balance sheet, the income statement, the cash flow statement, which replaced the former TAFIRE, and the notes. These statements must come out of the ERP. Not out of an Excel rework starting from an extracted trial balance, not out of an outside firm that rebuilds the cash flows by hand every quarter. A system that cannot produce its SYSCOHADA statements from its own data is not localised; it is tolerated.

The same requirement applies to VAT. In Senegal, the standard rate is 18%, with its special regimes, its exemptions and its reporting obligations. The system must calculate, post and declare without manual intervention on the amounts. As soon as a team recalculates VAT in a spreadsheet “because the module does not produce the right base”, the problem is not a tax problem. It is in the configuration, or in a process that bypasses the system.

Three symptoms, three causes

The first symptom is manual reconciliation. When a team spends its evenings reconciling the general ledger with cost accounting, inventory with the ledger, intercompany accounts between subsidiaries, the problem is not the accountants’ competence. It is that the data does not match at the source: the same operations recorded twice under two logics, diverging master data, account assignments left to the choice of whoever enters them. The month-end reconciliation repairs by hand what the upstream data should have guaranteed.

The second symptom is Excel reworks. Every workbook tells the same story: somewhere, a real process no longer goes through the system. The discount granted outside the tool, the provision calculated separately, the SYSCOHADA statement rebuilt line by line because “the standard does not produce it that way”, the inventory valuation corrected after the fact. The spreadsheet is rarely laziness; it is the trace of a workaround that has become an institution. It works, until the day its author changes jobs.

Which leads to the third and most revealing symptom: the close that rests on two people. If the closing calendar is organised around the holidays of two employees, it is because whole sections of the system, custom developments, bespoke reports, chains of batch jobs, exist only in their memory. An undocumented custom development is not an asset; it is a risk waiting for a date. The close is simply the place where that risk becomes visible twelve times a year.

The close absorbs, month after month, the cost of everything that was badly recorded, bypassed or patched together upstream. Its duration is the consolidated invoice.

The case of multi-entity groups in UEMOA

A group present in several States of the union shares a currency, the CFA franc, and an accounting framework, SYSCOHADA. On paper, consolidation should be simple. In practice, each subsidiary has its own tax system, its own reporting obligations, sometimes its own detailed chart of accounts, often its own tool. The group close then turns into a collection of files, reworks of intercompany entries and reconciliations of balances that do not talk to each other. The time spent consolidating is the time missing for analysis.

What we look for in a regional group ERP: a common chart of accounts with its national variants, legal entities configured in a single system, intercompany flows that eliminate because they were recorded on both sides in the same way, and a close that runs in the same order in Dakar, Bamako and Cotonou. That is not a technical feat. It is a harmonisation decision, taken by finance leadership before configuration.

What the universal journal changes, and what it does not

SAP S/4HANA brings a fundamental change on this ground: the universal journal. General ledger, cost accounting, fixed assets and inventory valuation stop being parallel worlds reconciled after the fact; they are written into a single set of data, as they happen. A whole category of reconciliations disappears, not because it was automated, but because the discrepancy it corrected can structurally no longer occur. SYSCOHADA statements and management reporting then start from the same source, which ends the “two truths” between accounting and management control.

But the universal journal changes the data, not the discipline. If upstream processes continue to be bypassed, the rework workbooks will survive the migration; they will simply start from fresher extracts. If account assignments remain a matter of individual preference, the single data set will carry inconsistent choices with perfect fidelity. A new core inherits the habits you bring to it. Technology removes structural reconciliations; it removes none of the cultural ones.

Reading your own close as an audit

Hence a suggestion we often make, because it costs nothing: instrument your next close as you would instrument an industrial process. List every task, its owner, its duration, and above all its nature: legitimate control, or repair of an upstream defect? Every manual reconciliation points to data that needs to be made reliable at the source. Every Excel workbook points to a process to bring back into the system, or a gap in localisation to fill. Every task that only one person knows how to do points to a custom development to document, standardise or remove. You will obtain a map of your ERP’s weaknesses more honest than many audits, drawn up by the people who suffer them.

This exercise takes on particular relief as the 2027 deadline approaches. The list of recurring repairs in your close is exactly the list of what a poorly prepared conversion will carry as is into SAP S/4HANA. Conversely, it is in the close that a successful conversion is judged: the first close afterwards says immediately whether the program has cleaned up the data, produced the SYSCOHADA statements natively and harmonised the subsidiaries, or whether it has moved the problems into a faster system. We encourage our clients to make it an explicit criterion of their SAP · S/4HANA & ERP program, alongside data migration and staying within budget.

That is the whole conviction of our finance expertise: the close is not a chore to speed up, it is the most reliable measuring instrument a finance department has on its own system. You still have to accept reading what it shows.