The accounting firm problem

A firm following several dozen SMEs has a unique operational challenge: keeping data strictly separate between clients while letting the internal team move from one file to another in a few clicks.

Traditional solutions impose either one instance per client (cost and maintenance burden) or fragile application-layer isolation (risk of cross-tenant leakage).

The SynkriaOps approach

SynkriaOps uses a strongly-isolated multi-tenant architecture: a single PostgreSQL schema, but each row carries a tenant_id and PostgreSQL Row Level Security filters access at the database engine level.

Concretely, this means:

  • A firm accountant has a single SynkriaOps user account.
  • They belong to several user_tenant records (one per active client file).
  • When switching files, the session exposes app.current_tenant_id to the engine; any subsequent SQL query returns 0 rows if the context is not set — this is a fail-safe, not a best-effort.

The visible effect: the internal team switches clients in two clicks, but no data leak is physically possible on the server side, even in case of an application bug.

The pilot firm workflow

The Yaoundé-based firm we have been following since February 2026 manages 47 active files on SynkriaOps. Their typical workflow:

  1. Monday morning — client entry review. Client SMEs enter throughout the week; the internal team audits the 47 dashboards in 1h30, spotting anomalies (imbalances, suspicious adjustments, FEC variance).
  2. Tuesday-Thursday — accounting production. Complementary entry, reconciliation, bank matching, adjustment journals for files in monthly closing.
  3. Friday morning — exports and reporting. PDF generation (Balance Sheet, P&L, General Ledger) for ongoing closings.

Not a single cross-file leak identified in 3 months — the internal auditor of one of the clients (an industrial group) explicitly validated isolation after a technical review of the RLS architecture.

Identified limits

Three honest limits after 3 months of use:

  • No client portal for SMEs on the firm side (Phase 4 roadmap).
  • No integrated payroll — the firm uses a third-party tool for Cameroon DIPE filings and payslips, then re-imports social charges as monthly adjustments.
  • No automated DSF export for the Cameroon statistical-fiscal declaration (manual CSV for now).

These 3 modules are on the roadmap. The SYSCOHADA FEC export is already operational and tested on 6 files in May 2026.

Case study anonymized at the firm’s request. The practices described are observable in apps/api/src/modules/cabinet/ and apps/api/src/common/middleware/tenant.middleware.ts.