Skip to content
All writing

September 8, 2026

Building an audit-grade ERP: the architecture behind Sentro

An ERP is easy to demo and hard to trust. The demo is a few forms and a dashboard; the trust is whether, two years and ten thousand transactions later, the numbers still reconcile and you can prove how they got there.

Sentro is a multi-site manufacturing ERP I built solo — procurement, manufacturing, inventory, sales, receivables, treasury, and a full general-ledger engine. This is how it is architected to stay correct.

Multi-site is a data-layer concern, not a filter

Every transactional record carries a site scope, and that scope is enforced at the data layer — automatically injected and validated on every read and write — rather than remembered in application code.

A developer cannot accidentally leak one site into another site’s report, because the isolation does not depend on anyone remembering to add a WHERE clause. The safe path is the only path.

An event-driven general ledger

Operational actions — receiving goods, posting an invoice, recording a payment — do not write journal entries inline. They emit events, and a dedicated ledger engine translates those into balanced journal entries asynchronously.

This keeps the operational modules simple and the accounting rules in one place. The ledger becomes a projection of what happened, not a side effect scattered across dozens of controllers.

The ledger is append-only

Posted journal entries are never edited or deleted. A correction is a reversing entry that links back to the original, and closing an accounting period locks it.

The history is the record. You can reconstruct the state of the books at any point in time — which is exactly what an audit asks you to do.

An immutable audit trail on everything financial

Every financial create, update, and delete writes an audit record: who did it, when, from what IP, and the before and after values. Nothing is hard-deleted, and an admin viewer sits over the log, so a question like "who changed this vendor’s terms?" has a definitive answer.

Three-way match, enforced

Accounts payable cannot post a bill without reconciling it against the purchase order and the goods receipt, within a configured tolerance. The control is not a report someone runs after the fact — it is a gate the transaction has to pass to exist at all.

Approvals as data, authorization through one seam

  • Approval rules — per module, per role, with monetary thresholds — are configuration, not hard-coded conditionals, so the business can change them without a deploy
  • Every authorization decision routes through a single policy service instead of scattered inline role checks, which keeps the rules auditable and leaves a clean path to attribute-based access control

Why this matters

Correctness in accounting software is not a feature you add; it is a property of the architecture. Event-driven posting, an append-only ledger, immutable audit trails, and enforced matching are what let a solo-built ERP be something a business can actually close its books on.