synkriaops

Author: stephane

  • Closing a SYSCOHADA fiscal year: the 5 most expensive pitfalls

    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.

  • SynkriaOps vs Sage, Odoo and Excel for an OHADA SME: which tool to choose?

    For an SME in the OHADA zone, the right choice hinges on one decisive criterion: is the accounting natively SYSCOHADA, in CFA francs, with Mobile Money, FEC and tax package? On that ground, Sage and Odoo are solid tools but designed elsewhere, Excel does not hold up on compliance, and SynkriaOps is built from the ground up for CEMAC. Here is a factual, non-disparaging comparison to help you choose with full knowledge.

    The criteria that truly matter in OHADA

    Before comparing brands, let us set the grid — the one that really weighs on a Cameroonian or CEMAC SME:

    1. Native SYSCOHADA revised 2019 (chart of accounts, statements, notes).
    2. XAF currency and CFA-franc presentation.
    3. Mobile Money (booking today; collection to come).
    4. Statutory FEC export for the tax audit.
    5. Tax package + 47 notes generated.
    6. CEMAC VAT (including Cameroon’s 19.25%) and withholding at source.
    7. Provable compliance (immutability, hash, locked numbering).
    8. Business ↔ accountant collaboration and firm mode.
    9. Field mobility (capture, scan, banking).

    Excel: the starting point, not the destination

    Excel (or an equivalent spreadsheet) remains the starting tool for many SMEs. Its strengths are real: total flexibility, zero cost, immediate familiarity.

    But to keep OHADA accounting, its limits are structural:

    • No built-in standard: the SYSCOHADA chart, the statements, the notes must be rebuilt by hand.
    • No FEC usable by the tax authority.
    • No immutability: a cell is edited without a trace — the opposite of what an inspector expects.
    • No reliable real-time collaboration or rights management.
    • Silent formula errors that propagate.

    Excel is fine for tracking, not for standardized, auditable accounting.

    Sage: a robust standard, but a different native framework

    Sage is a historic, robust, well-established vendor. Many firms know it. Its strengths: functional maturity, ecosystem, reliability.

    For an OHADA SME, the points of attention:

    • Sage is primarily designed for other frameworks (the French chart of accounts notably); SYSCOHADA fit depends on the edition and configuration.
    • The very local building blocks — native Mobile Money collection (being brought into service), turnkey 19.25% VAT, CEMAC withholding at source — are not the historical core target.
    • Depending on the editions, the experience can be closer to installed software than to real-time collaborative SaaS.

    Sage remains a serious choice; you simply need to verify edition by edition the fit with the CEMAC criteria above.

    Odoo: a complete ERP, generalist by nature

    Odoo is a powerful modular ERP: sales, purchases, stock, accounting, CRM. Its strength is functional breadth and modularity.

    The flip side for an OHADA SME:

    • Odoo is generalist and international: SYSCOHADA compliance goes through localization modules and configuration, whose depth (tax package, 47 notes, statutory FEC) varies.
    • The power comes with an implementation cost: an ERP is configured, often with an integrator.
    • The Mobile Money and CEMAC tax specifics are not native and require adaptation.

    Odoo shines when you want a full ERP; for an SME that first wants impeccable OHADA accounting quickly, it is sometimes oversized.

    SynkriaOps: built for CEMAC from the start

    SynkriaOps embraces a precise positioning: the “Pennylane” of CEMAC/OHADA. The product is not adapted from a foreign framework — it is built on SYSCOHADA revised 2019. Concretely:

    • SYSCOHADA chart of accounts, bilingual FR/EN, turnkey; native XAF currency.
    • Mobile Money MTN MoMo and Orange Money: clean booking (581 transit); secure collection infrastructure (QR, webhook) ready, service launch to come.
    • Statutory FEC per fiscal year, complete tax package with the 47 notes, balance sheet, income statement, TFT, TVCP.
    • CEMAC VAT across 6 countries (including Cameroon’s 19.25%) + withholding at source.
    • Provable compliance: immutability of validated entries, chained SHA-256 hash, locked numbering.
    • Real-time collaboration business ↔ accountant, multi-file firm mode with isolation.
    • Field mobile app (capture, barcode scan, banking, stock) — in internal pilot distribution.

    Honesty: Mobile Money collection (MTN and Orange Cameroon) is currently being brought into service — the secure infrastructure is built, the connection with the operators is not yet active; the mobile app is in pilot access (APK), not yet on the stores. The accounting core is complete.

    Summary table

    CriterionExcelSageOdooSynkriaOps
    SYSCOHADA revised 2019NoBy editionLocalizationNative
    Native XAF currencyManualBy editionConfigYes
    Mobile Money (collection)NoNot nativeAdaptationIn progress
    Statutory FEC exportNoBy editionVariableYes
    Tax package + 47 notesNoBy editionVariableYes
    VAT 19.25% / CEMACManualConfigLocalizationNative
    Provable immutabilityNoYesYesYes
    Real-time collaborationNoBy editionYesYes
    Field mobile (scan)NoVariableVariableYes (pilot)

    “By edition” = depends on the edition/version and configuration; “Localization” = via a localization module to configure.

    How to decide

    • You are starting and want light tracking → Excel may do for a while, but plan the switch before the first audit or serious closing.
    • You want a complete ERP and can afford to integrate it → Odoo is a candidate, provided you validate the SYSCOHADA/FEC depth.
    • Your firm is already standardized on Sage → check the edition and the CEMAC fit (Mobile Money, 19.25%, withholding at source).
    • You want impeccable, local, collaborative OHADA accounting with no integration project → SynkriaOps is made exactly for this need.

    In summary

    The right tool is not a matter of fame but of fit with the OHADA field. Excel starts but does not hold compliance; Sage and Odoo are solid but designed elsewhere and to be adapted; SynkriaOps is CEMAC-native. Run every candidate through the 9 criteria, test on your real documents, and look at the closing and the FEC — that is where everything is decided.

    To compare on your own entries, start free on SynkriaOps.

  • PostgreSQL RLS for a multi-tenant SaaS: why `app.current_tenant_id` is non-negotiable

    When building a SaaS that hosts the accounting of multiple companies on the same PostgreSQL schema, data isolation is not a detail. One cross-tenant leak and that is the end of the product. Yet many teams still rely on application-layer filtering alone.

    Here is why this is insufficient and how SynkriaOps does it differently.

    Application-layer filtering and its trap

    Classic pattern: each entity carries a tenant_id, and the repository interleaves this filter in every query.

    // Naive pattern — INSUFFICIENT
const invoices = await repo.find({
  where: { tenantId: user.tenantId, status: "validated" },
});

    The trap: a single bug — a missing where, a wrongly-typed join, a queryBuilder that forgets the scope, a raw SQL written too quickly — and a query returns all tenants merged together.

    And this bug can remain latent in production for months without any alert firing. From the user’s side, nothing signals that they just glimpsed a competitor’s invoices.

    Engine-layer filtering (Row Level Security)

    PostgreSQL has offered since version 9.5 a native mechanism: Row Level Security (RLS). Filtering is enforced at the engine level, not the application level. Every query — whether from an ORM, raw SQL, or psql console — is filtered automatically before rows leave the database.

    -- Enable RLS on the table
ALTER TABLE factures ENABLE ROW LEVEL SECURITY;

-- Read policy
CREATE POLICY factures_tenant_isolation ON factures
  FOR ALL
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

    From that point, any query that does not explicitly set app.current_tenant_id receives zero rows. This is a fail-safe, not a best-effort.

    The SynkriaOps architecture

    SynkriaOps uses three-layer defense:

    1. TenantMiddleware (NestJS) — extracts the tenant_id from the JWT, verifies membership, sets set_config('app.current_tenant_id', <uuid>, false) on the DB connection for the duration of the HTTP request.
    2. TenantAccessGuard — verifies at the controller level that the user is authorized to access the current tenant.
    3. PostgreSQL RLS — ultimate safety net: if the two layers above fail, the DB still returns 0 rows.

    The code:

    // apps/api/src/common/middleware/tenant.middleware.ts
async use(req: Request, res: Response, next: NextFunction) {
  const tenantId = this.extractTenantId(req);
  if (!tenantId) {
    throw new UnauthorizedException('Tenant context missing');
  }

  await this.dataSource.query(
    `SELECT set_config('app.current_tenant_id', $1, false)`,
    [tenantId],
  );
  next();
}

    The connection pool trap

    Subtle catch: PostgreSQL set_config(..., false) fixes the variable for the session, not for the transaction. With a connection pool (pgBouncer, TypeORM connection pool), the same connection serves several successive requests. If one query badly resets the context, the next inherits the previous tenant_id.

    Best practices:

    • Always reset set_config at the start of every request (middleware pattern).
    • For critical mutations (UPDATE / DELETE / INSERT), wrap in an explicit transaction with set_config(..., true) which scopes the variable to the transaction.
    • SynkriaOps reference pattern: TenantContextService.setForTransaction().

    Why it is non-negotiable for accounting

    An SME’s accounting includes:

    • Customer invoices (amounts, identities, margins)
    • Supplier contracts (terms, rebates)
    • Salaries (HR filings, payslips)
    • Bank flows (statements, balances)

    A cross-tenant leak on this data = end of the founder’s career. Regulators, press, customers, everyone piles on. This is an existential risk for an accounting SaaS.

    PostgreSQL RLS converts this existential risk into a PostgreSQL risk — that is, a risk managed by a team of hundreds of engineers in open-source for 30 years.

    Regression test

    SynkriaOps includes a dedicated E2E test: test/rls-fail-safe.e2e-spec.ts. It seeds two distinct tenants, makes a query with a wrong tenant_id set, and asserts that 0 rows are returned.

    If someone accidentally disables an RLS policy on a table, the test fails before merge, not in production.

    The full pattern is documented in apps/api/src/common/middleware/tenant.middleware.ts and apps/api/src/common/services/tenant-context.service.ts. See also the LOT-MOMO-C retrospective in docs/audit-correction/ for a real-world RLS silent fail case detected in review.

  • OCR for supplier invoices in CEMAC: what works and what does not

    OCR for supplier invoices is one of the most-requested modules by Cameroonian SMEs switching to SynkriaOps. The need is clear: reduce manual entry from 3-4 minutes per invoice to 30 seconds of visual validation.

    But generalist “Anglo-Saxon” OCR performs poorly on Cameroonian invoices. Here is what we learned to calibrate.

    The photo quality problem

    First field observation: 80% of invoices are photographed with a smartphone, not scanned. Consequences:

    • Inconsistent lighting — often near a window, frequent backlight.
    • Tilt — invoice rarely flat, sometimes hand-held.
    • Reflections — on the glossy paper of hotel chains for example.
    • Folds — especially on delivery slips collected in batch.

    The OCR must perform perspective correction + denoising + deskew preprocessing before attempting text extraction. Without this, the error rate on numbers explodes.

    The NIU format problem

    The NIU (Unique Identification Number) is the Cameroonian equivalent of the French SIRET: 13 alphanumeric characters (e.g., M101212345678A). It identifies a taxpayer and must appear on every invoice.

    A generalist OCR looks for an EU VAT (FR12345678901), a US EIN (12-3456789), or a French SIRET (123 456 789 00012). None of these patterns matches a Cameroonian NIU.

    SynkriaOps uses a dedicated regex and a plausibility score (the first letter is generally M or P depending on status). Without this explicit extraction, tax audits become painful (the NIU is mandatory in the “supplier identity” field of an accounting entry).

    The VAT at 19.25% problem

    Cameroonian VAT stands at 19.25% (since 2005). Many OCRs pre-trained on French or German content calibrate their heuristics on 20% or 19%, and reject a VAT line at 19.25 as “probably not a VAT amount”.

    Required adjustment: widen the VAT plausibility window to common CEMAC rates. Table:

    CountryStandard rateReduced rates
    Cameroon19.25%0% (exemptions)
    Gabon18%5% and 10%
    Chad18%—
    Congo18.9%5% and 8%
    Central African Republic19%5%
    Equatorial Guinea15%—

    Without this table, OCR “smooths” the VAT and loses precision on rounding (see next pitfall).

    The bilingual labels problem

    In Cameroon, many invoices are in primarily French but with English mentions (“Invoice”, “Tax”, “Subtotal”) or pidgin on wholesale delivery slips. The OCR must recognize all of:

    • Montant HT ↔ Subtotal ↔ Net amount
    • Taxe sur la valeur ajoutée ↔ VAT ↔ Sales tax
    • Total TTC ↔ Grand total ↔ Amount due

    Typical error: taking Subtotal for the gross amount and Total for the net amount (full meaning inversion in some US-imported formats).

    What SynkriaOps does — and does NOT do

    What SynkriaOps OCR does:

    • Perspective + denoising + deskew preprocessing (pdfjs-dist + OpenCV)
    • Text extraction per block with coordinates
    • Dedicated patterns: NIU CM/GA/CG, VAT 19.25/18/15, XAF currency
    • Confidence score per field
    • Mandatory human validation before accounting entry (no auto-validation)

    What it does NOT:

    • Auto-validation of invoices > 1 million XAF (configurable threshold)
    • Proprietary learning on each tenant’s data (privacy by design — we do not aggregate data across SMEs)
    • Advanced fraud detection (forged signature, fake NIU) — that is the human accountant’s role

    Field measurement

    On 600 supplier invoices from the Douala pilot SME (see community testimonial), net extraction rate is 100% (every expected field is extracted), with human validation maintained at 100% during the first 6 months — this is a deliberate discipline, not a technical limit.

    Effective human corrections represent 1.8% of fields over the period — typically a debit/credit inverted on a poorly-calibrated credit note or a mis-weighted rounding line.

    Technical details: apps/api/src/modules/ocr/. The service uses @anthropic-ai/sdk 0.78.0 for the final LLM layer (structured extraction), backed by in-house image preprocessing. The full pattern is documented with E2E tests test/ocr-realtime.e2e-spec.ts and test/pdf-ocr-import.e2e-spec.ts.

  • Booking Mobile Money flows in CEMAC: MTN, Orange, 581 transit sub-accounts

    In Cameroon, Mobile Money now weighs heavily in an SME’s cash flow. Many businesses receive and disburse daily via MTN MoMo or Orange Money — yet the booking remains artisanal: flows often land in bulk in account 512 (bank) or worse, are recorded as cash 53.

    Here is how to properly structure your MoMo accounts in a SYSCOHADA chart.

    Why it is NOT a bank account

    Natural temptation: create a 512### sub-account “Mobile Money MTN” and dump movements into it. Wrong.

    The 512 account designates a bank current account in the strict sense: account holder = the company, opened at a regulated banking institution, monthly statement, IBAN. Your MoMo wallet is none of that.

    The MoMo wallet is an electronic money deposit held by a payment institution (MTN MFS Africa, Orange Money), not a bank. From an accounting standpoint, it is an internal transfer pending or liquidity transit account, closer to 581 or 580.

    The proposed pattern

    Here is the structure we apply in the SMEs we support:

    581001 — Internal transfers — MTN MoMo CM (XAF)
581002 — Internal transfers — Orange Money CM (XAF)

For each operator, as a sub-account:
58100110 — MoMo MTN — Main merchant wallet (number 67xxxxxxx)
58100120 — MoMo MTN — Secondary merchant wallet if needed

    Account 581 is a transit account on the liability side of the SYSCOHADA chart. It records flows awaiting reclassification.

    The typical accounting flow

    Customer payment via MoMo

    1. Customer pays 50,000 XAF via MTN MoMo to the merchant wallet.
    2. Webhook notification received (cf. apps/api/src/modules/mobile-money/).
    3. Automatic entry:
      • Debit 581001 (MoMo wallet) — 50,000
      • Credit 411xxxxxx (Customer) — 50,000
    4. The wallet is not the bank. The balance is latent.

    Transfer MoMo → bank

    When the SME transfers the wallet balance to its BICEC or Afriland account:

    1. MTN fees applied (typically 1% of transfer).
    2. Entry:
      • Debit 512100 (BICEC) — 49,500
      • Debit 627100 (Banking services) — 500
      • Credit 581001 (MoMo wallet) — 50,000
    3. Account 581001 is now at zero.

    Pitfalls to avoid

    Pitfall 1 — No automatic reconciliation

    If the SME has 80 MoMo receipts per month and no automatic reconciliation, each MoMo→bank transfer becomes a puzzle: which of the 80 transactions corresponds to this 247,500 XAF payment?

    Solution: import the MoMo wallet statement (or direct webhook integration)

    • reconcile 581 at the operation level.

    Pitfall 2 — Confusing internal transfers with customer flows

    If a salesperson receives a personal payment on their Pro MoMo and then transfers it to the company, it is not a direct customer receipt — it is two distinct operations: (a) salesperson advance, (b) company reimbursement. To be booked separately, otherwise the real customer’s 411 ledger is wrong.

    Pitfall 3 — MoMo fees booked under 512

    Mobile Money operator fees are not bank fees in the classical sense. Account 6271 (Bank fees) is usable but unclear. Prefer a dedicated analytics tag (“Mobile payment services”) to rationally arbitrate operator vs bank cost.

    Webhook and integrity

    SynkriaOps receives MoMo notifications via HMAC-SHA256 webhook + AES-256-GCM secret encryption (cf. apps/api/src/modules/mobile-money/services/webhook-signature.service.ts). The sender IP is filtered by CIDR allowlist to prevent external replays.

    The automatic 581↔411 reconciliation triggers on receipt of an authenticated notification — the entry is booked without human intervention but traceable (audit log + chained hash).

    Updated with the actual SynkriaOps code state as of 2026-05-08. On the collection side, MTN CM and Orange CM are currently being brought into service: the secure infrastructure is built, the connection with the operators is not yet active. Flow booking (581 sub-accounts) and statement import, however, are operational.

  • Best accounting software in Cameroon (2026): how to choose

    The best accounting software in Cameroon in 2026 is the one that is natively SYSCOHADA revised 2019, that handles Mobile Money (MTN MoMo, Orange Money), that generates the FEC and the statutory tax package, and that works in CFA francs (XAF) — not a French or Anglo-Saxon tool retrofitted after the fact. Below are the 8 concrete selection criteria, what separates a real OHADA tool from an imported one, and where SynkriaOps stands in this landscape.

    Why the question deserves real framing

    A Cameroonian SME looking for accounting software quickly runs into two families of tools, neither of which fits as-is:

    • French or Anglo-Saxon suites (designed for the French chart of accounts, 20% VAT, the euro, the SIRET). They are mature but structurally foreign to the SYSCOHADA framework.
    • Excel spreadsheets and standalone invoicing tools, which handle sales but not the standardized accounting required by the tax authority.

    Choosing therefore means first verifying deep compatibility with the OHADA standard — not a list of attractive features. Here is the grid.

    The 8 selection criteria

    1. Native SYSCOHADA revised 2019 framework

    This is the disqualifying criterion. The chart of accounts must be the OHADA one (classes 1 to 8, 411 client accounts, 401 suppliers, 422 payroll, VAT in 443/445), not a “translated” French chart. Verify that the software ships a ready-to-use SYSCOHADA chart the moment you open a file, not an empty chart to rebuild by hand.

    2. XAF currency and CFA-franc presentation

    Amounts must be natively in XAF, with no parasitic euro conversion, and statements presented in CFA francs. Software showing euro cents on a Cameroonian balance sheet betrays a superficial adaptation.

    3. Mobile Money collection

    In Cameroon, MTN MoMo and Orange Money weigh heavily in an SME’s cash flow. Good software must not only book these flows cleanly (581 transit account, never the 512 bank account) but ideally collect directly via Mobile Money with a payment QR code. This is the number-one differentiator of the French-speaking African market. At SynkriaOps, Mobile Money collection is currently being brought into service: the secure infrastructure is built, the connection with the operators (MTN, Orange) is not yet active.

    4. Statutory FEC export

    The Fichier des Écritures Comptables (FEC) is the standardized format the tax authority may request during an audit. The software must generate it for each closed fiscal year, in the revised SYSCOHADA format, not in a proprietary export the inspector cannot read.

    5. Complete financial statements and tax package

    Balance sheet, income statement, cash flow statement (TFT), statement of changes in equity (TVCP), and above all the notes 1 to 47 of revised SYSCOHADA. This is the most time-consuming part of a closing: software that generates them automatically saves you weeks of accounting-firm work.

    6. CEMAC VAT and local taxation

    Cameroonian VAT is 19.25% (a rate many imported tools reject because they are calibrated to 20% or 19%). The software must handle this rate, the VAT return, the deduction proration, and local specifics such as withholding at source (tax advance).

    7. Compliance and immutability

    The tax authority expects immutable accounting. Look for: non-reusable sequential numbering, immutability of validated entries (no retroactive edit possible), traceability (audit trail). These are audit guarantees, not marketing.

    8. Collaboration and firm mode

    If you work with an accountant, the software must let the business record and the accountant validate and review — in real time, on the same file, without emailing Excel files back and forth. For an accounting firm, multi-file management with strict data isolation is essential.

    Comparison of tool families

    CriterionImported suiteExcel / invoicingNative OHADA tool
    SYSCOHADA revised 2019AdaptedNoNative
    Native XAF currencyPartialManualYes
    Mobile Money importNoNoYes
    Mobile Money collectionNoNoIn progress
    FEC exportOther formatNoYes
    Tax package + 47 notesNoNoYes
    VAT 19.25% / CEMACRareManualYes
    Provable immutabilityVariableNoYes

    Pitfalls to avoid

    • “OHADA-compatible” on the brochure, but a French chart in reality. Ask for a demo and check the 411 account and the 19.25% VAT.
    • Invoicing without accounting. Issuing an invoice is not keeping accounts. You need the general ledger, the trial balance, reconciliation.
    • No FEC. Without a FEC, you are exposed on audit day.
    • No mobile strategy. Your field teams must be able to capture an invoice from a phone, not re-enter it at the office in the evening.

    Where SynkriaOps stands

    SynkriaOps is an accounting and management SaaS designed from the ground up for CEMAC and OHADA — the stated positioning is that of a “SYSCOHADA Pennylane”. In practice, it ticks the 8 criteria above:

    • SYSCOHADA revised 2019 chart of accounts, bilingual FR/EN, delivered turnkey per file.
    • Mobile Money collection for MTN MoMo and Orange Money — currently being brought into service: the secure infrastructure (HMAC-SHA256 webhook, AES-256-GCM encryption, payment QR code) is built, the connection with the operators is not yet active.
    • Statutory FEC generated per fiscal year, complete tax package with the 47 notes, balance sheet, income statement, TFT and TVCP.
    • CEMAC VAT across 6 countries (Cameroon, Gabon, Congo, Chad, CAR, Equatorial Guinea) with return, proration and PDF/CSV/XLSX exports; configurable withholding at source.
    • Immutability via chained SHA-256 hash and immutability of validated entries.
    • Collaborative and multi-file firm mode with strict per-file data isolation.
    • Field mobile app (photo capture, banking, stock, barcode scan) — currently in internal pilot distribution.

    We stay honest about the limits: Mobile Money collection (MTN and Orange Cameroon) is currently being brought into service — the secure infrastructure is built, the connection with the operators is not yet active; the mobile app is in pilot access (APK), not yet published on the stores. The accounting core, however, is complete.

    In summary

    The right software is not the best-known one: it is the one that natively speaks SYSCOHADA, CFA francs, Mobile Money and FEC. Run every candidate through the 8 criteria above, demand a demo on your real documents (an invoice with a NIU and 19.25% VAT), and watch the closing: that is where the difference plays out between an attractive tool and one that saves you weeks.

    To check these criteria on your own documents, start free on SynkriaOps and open a test file in minutes.

  • Financial statements and tax package under SYSCOHADA revised 2019: balance sheet, income statement, cash flow and the 47 notes

    The SYSCOHADA revised 2019 tax package is the set of summary financial statements an OHADA company must produce at closing: the balance sheet, the income statement, the cash flow statement (TFT), the statement of changes in equity (TVCP), and the 47 notes that explain each line. It is the deliverable that stands as evidence before the tax authority and third parties. Here is its detailed composition, why it costs weeks of manual work, and how to generate it automatically from your trial balance.

    What the SYSCOHADA package contains

    The revised SYSCOHADA framework (in force since 2018) requires, for the normal system, a package structured into five blocks:

    1. The balance sheet

    A snapshot of net worth at the closing date. It sets assets (fixed assets, inventory, receivables, cash) against liabilities and equity (equity, financial debt, operating payables). The SYSCOHADA balance sheet presents assets in GROSS, DEPRECIATION/IMPAIRMENT and NET — a forgotten depreciation column skews the entire fixed-asset section.

    2. The income statement

    It explains the formation of the result for the year from revenues (class 7) and expenses (class 6), organized by nature and by intermediate balances (value added, gross operating surplus, operating result, financial result, net result).

    3. The cash flow statement (TFT)

    The TFT (sometimes called TAFIRE in the old system) traces where cash comes from and where it goes: operating flows, investing flows, financing flows. It links the accounting result to the actual change in cash — a formidable consistency check.

    4. The statement of changes in equity (TVCP)

    It explains how equity evolved between opening and closing: contributions, result for the year, distributions, reserves.

    5. The 47 notes

    This is the explanatory heart of the package. Notes 1 to 47 detail each line: fixed assets and depreciation, inventory, receivables and payables by maturity, capital, provisions, off-balance-sheet commitments, headcount, and so on. Each note must be consistent with the balance sheet and income statement — for example, the total of a fixed-asset note must equal the corresponding balance sheet line.

    Why it is the most time-consuming part

    Producing this package by hand (or in a spreadsheet) is a marathon:

    • Each note is reassembled from account balances — a line-by-line reconciliation job.
    • The smallest last-minute entry breaks consistency: you must redo the balance sheet, the note concerned, sometimes the TFT.
    • The balancing controls (note total = balance sheet line, Σ maturities = balance, note closing = opening + increases − decreases) must be redone at each iteration.

    Result: in many SMEs, the package ties up the accounting firm for several weeks at year-end, with error risk proportional to the number of manual redos.

    The accounting invariants to respect

    A correct package always satisfies these controls:

    • Assets = Liabilities + Equity (the balance sheet balances).
    • Total of a note = the balance sheet line it details.
    • Σ of maturities in a schedule note = balance of the account.
    • Closing of a movement table = Opening + Increases − Decreases (fixed assets, depreciation, provisions).
    • Net cash in the TFT = the actual change in cash on the balance sheet.

    If even one of these controls fails, the package is wrong — even if each statement “looks fine” in isolation.

    How SynkriaOps generates the package

    SynkriaOps produces the SYSCOHADA revised 2019 financial statements from your trial balance, with no re-keying:

    • Balance sheet, income statement, TFT and TVCP generated automatically, with the correct GROSS/DEPR/NET presentation on assets.
    • Notes 1 to 47 driven by a data engine (each note reads the right accounts), with the ability to apply cell overrides, manual lines and editable bilingual note texts (FR/EN).
    • Import of the previous year’s texts so you do not start from scratch each year.
    • Drill-down line → detail: click a balance sheet amount to see the entries that compose it.
    • Versioned generation with history, and exports for filing.

    Because the notes are recomputed from the entries, a last-minute entry updates the whole package — the balance sheet, the affected note and the TFT stay consistent automatically. The year-end marathon becomes a few-minute review.

    Normal system and minimal cash-basis system

    Revised SYSCOHADA does not require the same package from every company. It mainly distinguishes two systems by size:

    • The normal system — the complete package described in this article: balance sheet, income statement, cash flow statement and the notes. It applies to companies above the thresholds of the minimal system.
    • The minimal cash-basis system (SMT) — a lightened arrangement reserved for very small entities whose turnover stays below a threshold set by the framework. Accounting there is kept essentially on a receipts-and-payments basis, with simplified statements.

    The practical point: a company that grows may switch from the SMT to the normal system. It is better to use a tool that produces the full normal-system package from the start, so you do not end up rebuilding the entire history the day the threshold is crossed.

    In summary

    The SYSCOHADA revised 2019 package (balance sheet, income statement, TFT, TVCP and 47 notes) is the summary deliverable that stands as evidence — and the most costly to produce by hand because of the dozens of consistency controls to maintain. Generated from the trial balance, with notes that recompute themselves, it goes from several weeks to one click.

    To generate your package and your 47 notes from your entries, start free on SynkriaOps.

  • Managing multi-warehouse stock with accounting valuation (weighted average cost) in SYSCOHADA

    Managing multi-warehouse stock with accounting valuation means tracking quantities per warehouse while computing, at each movement, the stock value at weighted average cost (WAC) — so that your inventory value on the balance sheet (class 3 accounts) always reflects physical reality. This is what separates simple “quantity tracking” from real commercial management integrated with accounting. Here is the mechanic, and how mobile scanning and accounting hold together.

    WAC: the right valuation method

    When you buy the same item at different prices over time, at what value does it leave stock on a sale? SYSCOHADA favors the weighted average cost (WAC): at each inbound movement, a new average unit cost is recomputed.

    WAC formula after an inbound movement:

    WAC = (value of existing stock + value of the inbound)
      ÷ (existing quantity + inbound quantity)

    Example:

    • Opening stock: 100 units at 1,000 XAF → value 100,000 XAF.
    • Inbound: 50 units at 1,300 XAF → value 65,000 XAF.
    • New stock: 150 units, value 165,000 XAF → WAC = 1,100 XAF/unit.
    • An outbound of 30 units is valued at 30 × 1,100 = 33,000 XAF.

    WAC smooths purchase-price variations and gives a stable and defensible valuation in an audit — unlike an approximate “latest price” valuation.

    Multi-warehouse: quantities per site, consistent value

    A trading SME often has several storage points: central warehouse, shop, secondary depot. The challenge is to track where each unit is, without losing overall accounting consistency.

    The necessary building blocks:

    • Identified warehouses (name, code, address, main warehouse, responsible keeper), enable/disable.
    • Stock per warehouse: quantities and valuation split by site.
    • Typed movements: inbound, outbound, adjustment, inventory — each attached to a warehouse and, ideally, to an accounting document/entry.
    • Per-item thresholds (minimum, reorder point, maximum) to steer replenishment and detect stockouts.

    Inter-warehouse transfers

    Moving stock from one warehouse to another must never be a manual double entry “out here / in there”: that is the door to variances.

    A clean transfer is a single operation with:

    • A source warehouse and a destination warehouse.
    • One or more lines of items with quantities.
    • A workflow (draft → validated), validation by the keeper, a possible return, a cancellation.
    • A transfer note (PDF) for physical traceability.

    Valuation follows the goods: value leaves the source warehouse and arrives at the destination at the same WAC, with no creation or destruction of value.

    Inventory and valued variances

    Periodically, you physically count the stock and compare it to the theoretical stock. The variance must be:

    • Valued in XAF (variance quantity × WAC), not just in units.
    • Booked via an inventory-variance entry (adjustment of the balance sheet stock value and recognition of the corresponding expense/income).

    Without this step, the stock value on the balance sheet diverges from reality — and the inspector notices. Multi-product inventory campaigns (with line-by-line entry and validation) make the exercise manageable even on wide catalogues.

    The bridge with SYSCOHADA accounting

    Stock is not just a quantity table: it is an asset on the balance sheet (class 3). Each physical flow must find its accounting counterpart:

    • Stock inbound → class 3 movement, linked to the purchase (class 6 / supplier 401).
    • Outbound on sale → recognition of the cost of goods sold.
    • Inventory variance → valued adjustment entry.

    It is this stock ↔ accounting integration that distinguishes serious commercial-management software from a mere product-sheet manager.

    Mobile scanning: stock in the field

    The most rigorous valuation is worthless if field entry is painful. Hence the value of barcode scanning (EAN-13, EAN-8, Code 128) on mobile:

    • Scan an item to find or update it instantly.
    • Run a mass inventory by scan during a campaign.
    • Mass-create catalogue products by scanning a list of items.
    • Correct the warehouse of an item from its sheet (traced transfer), manage expiry and thresholds.

    The field scans, the accounting stays correct.

    How SynkriaOps does it

    SynkriaOps embeds ERP-grade multi-warehouse stock management, tied to SYSCOHADA accounting:

    • Warehouses and stock per warehouse (quantities + valuation split), warehouse optional or mandatory depending on your configuration.
    • WAC valuation recomputed at each movement, with total valuation and a stock dashboard (dormant, stockouts, below-minimum).
    • Inter-warehouse transfers with workflow, keeper validation, return and a PDF transfer note.
    • Inventory sessions and campaigns with variance valued in XAF and variance-entry generation.
    • Mobile app: barcode scan, quantity capture, default VAT by regime, mass inventory by scan, transfer from the sheet — currently in internal pilot distribution.
    • Accounting integration: stock movements feed class 3 accounts and link to documents.

    Stock steering indicators

    A correct valuation also serves to steer. A few indicators to track:

    • Value tied up at WAC — how much cash “sleeps” in stock.
    • Dormant items — references with no movement for a long time, candidates for impairment or clearance.
    • Stockouts and below-minimum — items under their threshold, to replenish.
    • Turnover rate — how fast stock moves: a low rate signals overstock, a high rate a stockout risk.
    • Expiry — for dated products, expired or soon-to-expire lots, which weigh on real value.

    These indicators link operational management (what to order, what to clear) to accounting reality (the value on the balance sheet). Without a reliable valuation, they mislead; with WAC recomputed at each movement, they become decision levers.

    In summary

    Well-kept multi-warehouse stock is three things together: quantities per warehouse, a WAC valuation recomputed at each movement, and an accounting bridge to class 3 accounts. Add mobile scanning for field entry, and you get commercial management that never drifts from the accounting.

    To manage your multi-warehouse stock with integrated accounting valuation, start free on SynkriaOps.