Closing a SYSCOHADA fiscal year is rarely the most relaxing moment for an SME. Here are five errors that consistently appear in the Cameroonian SMEs we support, ranked by correction cost.

1. Mis-generated carry-forward entries

The first pitfall — and the most painful — is switching to a new fiscal year without generating the carry-forward journal (« à-nouveaux »).

The carry-forward is the pseudo-entry that re-injects on day one of fiscal N+1 the balance sheet balances (classes 1 to 5) from fiscal N. Without this journal, your opening balance is empty. Your 411 client accounts appear at zero, your 401 supplier accounts too, your cash too. Your accountant gets nervous. So do you.

How to detect:

  • N+1 opening balance = empty balance or N-1 columns at zero
  • General ledger of a regular client’s 411 account: 0 movement before the first N+1 receipt

How to fix:

  • Re-generate the carry-forward from the final balance of fiscal N
  • Verify that debit sum = credit sum on the carry-forward journal
  • Spot-check a few known accounts to validate the extrapolation

In SynkriaOps, carry-forward regeneration is automatic upon re-closing fiscal N (see LOT-RECLOTURE-AUTO-AN, PR #279). Which reduces this pitfall to zero occurrences for users after the first closing.

2. Wrong result allocation

Second pitfall: confusing the P&L statement (the calculation) with the balance sheet allocation account (12).

The fiscal year result is computed from class 6 (charges) and class 7 (revenues). Once computed, it is allocated to a liability account:

  • 1301 — Net result: profit
  • 1309 — Net result: loss

The account 12 is an aggregation account, not a destination account for allocation. If your software sends the result to account 12, the balance sheet rebalances visually but the next step (reserve allocation, dividend distribution) will be off.

3. The FEC export forgotten until the audit

The « Fichier des Écritures Comptables » (FEC) is a normalized format allowing tax authorities to audit your accounting. It is not optional when an audit triggers — and it must be generated in the revised SYSCOHADA format, not in a proprietary format.

What many forget: the FEC must be generated for each closed fiscal year, not just “if we get audited”. Generating it on the day of the audit notice is technically possible but stresses the team and increases the chance of omissions (unreconciled social charges, missing adjustments).

Best practice: generate the FEC at closing, archive it outside your ERP (immutable cloud, physical media) and forget it exists until the next audit.

4. Unbalanced class 6 and 7 accounts at year-end

Before computing the result, charge and revenue accounts (classes 6 and 7) must be balanced. This is the automatic mechanism that flips them to account 12 then to 1301/1309.

The pitfall: some software lets regularization entries dated after the closing date linger on 6/7 accounts — typically supplier invoices received in January N+1 but relating to fiscal year N.

How to avoid: a clean cut-off. If a charge belongs to N, it goes to invoices to receive (4081) or prepaid expenses (4886) depending on case, with a counterpart on class 6 in fiscal N.

5. Unreconciled entries on auxiliary accounts

Reconciliation (« lettrage ») is the mechanism for matching Debit↔Credit entries on the same third-party account. A properly-reconciled client account (411######) clearly shows which invoices have been paid and which are outstanding.

An unreconciled client account shows a mass of entries that may or may not offset. At closing, it is technically valid (the balance correctly adds to the balance sheet) but it pollutes client reminders and aging analysis.

Recommendation: reconcile continuously during the fiscal year, not in a marathon at closing time. SynkriaOps automatically reconciles matching receipts detected via bank reconciliation.

Going deeper

  • The SynkriaOps immutability trigger prevents any modification of a validated accounting document — see apps/api/src/migrations/1782100000000-TightenPiecesValideeImmutability.ts.
  • The chained SHA-256 hash on validated documents detects any retroactive alteration — see apps/api/src/modules/pieces-comptables/services/piece-hash.service.ts.
  • The SYSCOHADA FEC is automatically generated by apps/api/src/modules/exercice-fiscal/fec-generator.service.ts.

These three mechanisms do not replace the rigor of accounting practices, but they guarantee that history is reliable when the auditor walks in.