The FEC (Fichier des Écritures Comptables) is a standardized file containing all the accounting entries of a fiscal year, in a standard tabular format that the tax authority can read and audit directly. In an OHADA context, it lets the inspector check your accounting without depending on your software. Here is what it is for, what it must contain, when to produce it, and how to generate it cleanly.

What the FEC is for

The principle of the FEC is simple: make your accounting independently auditable. Rather than digging through your software, the inspector imports a flat, standardized file and runs it through their own analysis tools.

Concretely, the FEC serves to:

  • Verify completeness: all entries for the year are present, with no numbering gap.
  • Check balance: the sum of debits equals the sum of credits.
  • Cross-check with returns: VAT, result, account balances must match what you declared.
  • Detect anomalies: backdated entries, broken numbering, inconsistent amounts.

The FEC is not optional once an audit triggers. Not being able to produce it, or producing it in an unreadable proprietary format, puts the business in a poor position.

What a FEC contains

A FEC is a tabular file (often in TSV format — tab-separated values), where each line is an entry line and each column a standardized field. The expected fields revolve around:

  • Journal — code and label of the journal (sales, purchases, bank, misc.).
  • Entry — sequential number, posting date.
  • Account — SYSCOHADA account number and label.
  • Auxiliary account — for third parties (411 clients, 401 suppliers).
  • Document — reference and date of the supporting document.
  • Label of the entry.
  • Debit / Credit — the amounts, in XAF.
  • Reconciliation — code and date of reconciliation where applicable.
  • Validation date — to prove immutability.

The exact order and naming of columns follow a standardized format: it is precisely this standardization that makes the file usable by the tax authority.

When to generate it

The classic mistake is to wait for the audit notice to produce the FEC. By then the team is under pressure, and the risk of omission rises (unreconciled social charges, missing adjustments, sloppy cut-off).

Best practice:

  1. Generate the FEC at each closing, once the definitive balance is settled.
  2. Archive it outside the accounting software (immutable cloud storage, physical media) to keep a frozen copy.
  3. Forget it until the next audit — it is ready, dated, consistent.

Generating the FEC cold, at closing time, guarantees it reflects exactly the settled accounting, with no entry added after the fact.

The controls to pass before delivering

Before considering a FEC deliverable, check:

  • Global balance: Σ debits = Σ credits.
  • Continuous numbering: no gap or duplicate in entry numbers.
  • Consistency with the trial balance: FEC account balances = those of the closing balance.
  • VAT consistency: the 443/445 accounts reconcile with your returns.
  • Immutability: validated entries must not have been modified after validation.

A FEC that fails one of these controls signals a bookkeeping problem — better to catch it at closing than during the audit meeting.

How SynkriaOps exports the FEC

SynkriaOps generates a statutory FEC per fiscal year, in the standard tabular format, directly from validated entries. The associated guarantees:

  • Per-year generation: one file per closed fiscal year, consistent with the closing balance.
  • Standardized format usable by the tax authority (no proprietary export).
  • Immutable entries: validated documents are frozen by an immutability mechanism (an amount cannot be changed after validation), and a chained SHA-256 hash detects any retroactive alteration of history.
  • Locked sequential numbering: no gap, no number reuse.

Because the FEC is produced from immutable and traced accounting, it is not only compliant in form: it is credible in substance the day the inspector runs it through their tools.

What to do if the FEC does not balance

A FEC that does not balance (Σ debits ≠ Σ credits, or balances diverging from the trial balance) is not a file problem: it is the symptom of accounting with an anomaly. The approach:

  1. Compare to the ledger — the total of the FEC’s debits and credits must equal that of the year’s general trial balance.
  2. Isolate the faulty journal — regenerate by journal to spot where the gap appears (often a misc. or bank journal).
  3. Find the unbalanced entry — a validated document is supposed to be balanced; a gap reveals a manual entry or a dubious import.
  4. Check the cut-off — an entry straddling two fiscal years can distort the scope carried into the file.

The good news: with immutable documents and locked numbering, these anomalies are rare and locatable — not gaping holes in history.

FEC, backup and document retention

Be careful not to confuse three different things:

  • The FEC — a standardized, complete file readable by the tax authority. It is an audit deliverable, not a mere technical copy.
  • The software backup — a copy of the database, often in a proprietary format. Useful to restore your tool, but unusable as-is by an inspector.
  • The supporting documents — invoices, statements, contracts. The FEC references them (document number and date) but does not replace them.

In the OHADA zone, accounting documents (books, supporting documents) must be kept for several years — ten years in practice under the Uniform Act. The FEC facilitates the audit, but it adds to this obligation to retain the originals: keep both, the standardized file and the supporting documents it points to.

In summary

The FEC is the bridge between your accounting and the inspector: a standardized, complete, balanced file consistent with your returns. Generate it at each closing (not on audit day), archive it offline, and make sure it rests on immutable entries. It is the best insurance in case of a tax audit.

To generate your statutory FEC per fiscal year in one click, start free on SynkriaOps.