COMPLIANCE & SECURITY · NF203 · SYSCOHADA

Immutable accounting, proven by fact.

Chained SHA-256 hash, immutability by database trigger, locked sequential numbering, FEC export, three-layer multi-tenant isolation and a declarative approval engine. We describe real mechanisms, not a certification logo we would not hold.

Start free See all features

Why compliance with SynkriaOps?

Trust is not declared: it is demonstrated through mechanisms you can verify.

Immutable by design

A validated voucher can no longer be changed: chained hash and database triggers block any alteration.

Your data isolated

Three-layer multi-tenant isolation guarantees no company ever sees another's data.

You decide what your firm can see

Module by module, you grant your accountant full management, read-only access, or nothing at all. With no setting, they keep full access: restricting is your choice, never a surprise.

Governance, if you want it

Separation of duties and double validation turn on when you ask; with no configuration, nothing blocks you.

The proof, not the logo

FEC export, audit trail and chain verification: real mechanisms, described as they are.

The proof, not the promise

Most software shows a "secure" label and a logo. SynkriaOps takes the opposite stance: show the mechanisms. Each validated voucher is sealed by a chained cryptographic hash, locked by a database trigger, numbered in sequence with no possible gap. Your data lives behind a three-layer multi-tenant isolation, and you can, if you want, add a separation of duties. These are facts, not adjectives.

Accounting inalterability, mechanism by mechanism

What makes a validated entry impossible to silently rewrite, and why a tax audit is prepared with peace of mind.

Double-pass chained SHA-256 hash

Each validated voucher is sealed by a fingerprint that references the previous one, computed in a double pass. Any substitution breaks the chain.

Immutability by database trigger

A PostgreSQL trigger blocks any change to a validated voucher's amounts, with an explicit allow-list of the few fields still editable.

Locked sequential numbering

Numbers assigned in sequence, under lock, non-reusable. No gap, no duplicate, no re-issue possible.

Correction by reversal

A validated entry is never overwritten. Correction goes through a reversal or a credit note, traced, in line with SYSCOHADA.

Chain verification

A check replays the hash chain and immediately detects any altered or substituted voucher.

Regulatory FEC export

The accounting-entries file exports in regulatory format (TSV), ready for an audit, even on large fiscal years.

Learn more about financial statements and the FEC export

Every validated voucher, sealed.

The "Validated" status is not cosmetic: it triggers the hash, the lock and the voucher's immutability.

SARL Demo Exercice 2026

Pièces comptables

Pièces validées

1 248

En brouillon

7

Total pièces

1 255

N° Pièce	Date	Journal	Libellé	Montant	Statut
FC-2026-000123	12/05/2026	VTE	Vente marchandises Riviera Distribution	1 250 000	Validé
ACH-2026-000088	12/05/2026	ACH	Facture fournisseur Négoce du Littoral	845 000	Validé
OD-2026-000041	11/05/2026	OD	Dotation amortissement matériel	320 500	Validé
BQ-2026-000210	11/05/2026	BQ	Règlement Orange Money frais	18 200	Brouillon
FC-2026-000122	10/05/2026	VTE	Vente prestations Client BTP	2 100 000	Validé

Accounting vouchers: validated vouchers sealed, drafts still editable.

Governance, isolation and security

The internal control you choose, on an isolated and encrypted multi-tenant base.

Three-layer multi-tenant isolation

Middleware, application guard, then PostgreSQL row-level security (RLS). With no tenant identified, zero rows returned, never all of them.

Declarative approval engine

Separation of duties, double validation and threshold delegation: the company declares its own rules, like a tax regime.

With no configuration, nothing blocks

By default, a validation stays a direct seal. Internal control is added when you decide, never imposed silently.

Audit trail and traced exceptions

General audit trail and an append-only approval log. Every exception to the separation of duties surfaces in an exportable report.

AES-256-GCM encryption

Sensitive secrets (payment keys, tokens) are encrypted with AES-256-GCM using a versioned envelope, never stored in clear.

Strong authentication (2FA)

Two-factor authentication, multiple revocable sessions and regular backups of the production database.

Learn more about banking and secured Mobile Money

Why trust us

SYSCOHADA notes generated automatically with your financial statements.

SYSCOHADA revised 2019
NF203 standard
Full isolation between files
FEC export
Sealed, tamper-proof entries

Discover other features

Compliance is not a separate module: it runs through the whole SynkriaOps suite.

Inalterability, NF203, isolation: your questions

What directors, accounting firms and auditors ask us about compliance and security.

Are validated entries really immutable?

Yes. A validated voucher is sealed by a chained SHA-256 hash and protected by a PostgreSQL trigger that blocks any change to its amounts, with an explicit allow-list of the few fields still editable. A validated entry is never corrected by overwriting it: correction goes through a reversal or a credit note, both traced.

What is the chained SHA-256 hash, concretely?

Each validated voucher carries a cryptographic fingerprint computed in a double pass, which references the previous voucher's fingerprint. The vouchers thus form a chain: if a single one is modified or substituted, the chain breaks and a check detects it immediately. It is the same inalterability principle expected by the NF203 standard.

Is SynkriaOps NF203 certified?

We implement the technical inalterability mechanisms expected by the NF203 standard: chained SHA-256 hash, immutability by database trigger, locked sequential numbering and regulatory FEC export. We prefer to describe these real, product-verifiable mechanisms rather than display a certification logo we do not hold.

How is my data isolated from other companies?

Through a three-layer defence: a middleware that sets the tenant, an application guard that checks membership, then PostgreSQL row-level security (RLS). If no tenant is identified, the database returns zero rows, never all of them. No query can cross another company's boundary.

Can I require a double validation before an entry is sealed?

Yes, if you want to. The approval engine is declarative: with no configuration, a validation stays a direct seal, with no blocking. You can enable circuits for separation of duties, double validation and threshold delegation; any exception is logged and surfaced in an exportable report.

Is my data encrypted and backed up?

Sensitive secrets are encrypted with AES-256-GCM using a versioned envelope, access is protected by two-factor authentication (2FA) and revocable sessions, and the production database is backed up regularly. The general audit trail keeps a record of sensitive actions.

Ready to keep immutable and provable accounts?

14-day free trial, no credit card, supported by our team. Compliance demonstrated by fact, not by a slogan.

Start free Request a demo