SKIP TO CONTENT
A/L
SYS_002SYSTEM

VS Accounts

Shared Accounting Engine

One double-entry engine that every business system posts into, instead of each product growing its own half-built ledger.

TYPE
ACCOUNTING ENGINE
STATUS
SYSTEM
YEAR
2026
ROLE
Architecture and implementation
PLATFORM
Node.js service consumed by every product
STACK
Node.js · TypeScript · MySQL · PostgreSQL · REST
Products on one engine
4+
Private ledgers per product
0
Entry to source-document trace
1:1
01

PROBLEM

Every business system eventually needs accounting. A hotel needs it, a gas agency needs it, a contractor needs it, a dairy needs it. The usual outcome is that each product grows its own partial ledger — a sales table here, an outstanding column there — and each one gets the hard parts slightly wrong in a different way.

The cost compounds. The same bugs get fixed four times, reports disagree between products, and no owner running two businesses can see a consolidated position.

02

SYSTEM

VS Accounts treats accounting as infrastructure. It owns the chart of accounts, journals, vouchers, allocation and reporting, and exposes posting as a service that any product can call.

Business systems do not write journal entries by hand. They describe a business event — a sale, a receipt, a stock consumption, a trip cost — and a mapping layer turns it into a balanced set of entries. The product knows its domain; the engine knows accounting.

Every posting is idempotent and traceable back to the source document in the originating system, so a figure in a report can always be walked back to the operation that caused it.

03

CORE FLOW

How the operation moves through the system.

ARCH_01 / ONE ENGINE, MANY SYSTEMS
  • Room and restaurant sales, folios, purchase, stock consumption
  • Cylinder sales, deposits as liability, receipts and allocation
  • Project cost, labour, supplier bills, running-account billing
  • Collection payable to farmers, deductions, cycle payouts
  • A new product integrates by mapping its events, not by rebuilding a ledger
Chart of accounts, posting rules, vouchers, allocation, period control.
  • LEDGERS
  • JOURNALS
  • OUTSTANDING
  • TRIAL BALANCE
  • REPORTS
SELECT OR HOVER A NODE FOR DETAIL

Sceneway, GasMitra, Contractor ERP, Dairy and future products all post into a single shared accounting engine, which produces ledgers, journals, outstanding balances, trial balance and reports.

04

KEY MODULES

M01Chart of accounts
Group and ledger hierarchy, per tenant, with opening balances.
M02Posting rules
Business event to journal mapping, versioned so old postings stay reproducible.
M03Vouchers
Sale, purchase, receipt, payment, journal, contra and stock-consequence entries.
M04Allocation
Receipts and payments allocated against documents; ageing reads allocation.
M05Period control
Business-date posting with closable periods and a re-runnable close.
M06Reporting
Day book, ledger, trial balance, outstanding, tax register, consolidation.
05

ARCHITECTURE

Boundary
Products call a posting API with a business event and a source document reference.
Balance rule
A posting either balances and commits in full, or it is rejected. There is no partial state.
Idempotency
Each posting carries a source key, so a retried request cannot double-post.
Tenancy
Tenant is resolved from the caller credentials; a chart of accounts never crosses tenants.
Traceability
Every entry links back to the operational document that produced it.
Storage
MySQL and PostgreSQL deployments; entries are append-only, corrections are reversals.
06

ENGINEERING

The parts that were not obvious, and what the system does about them.

  1. 01 / 04

    Reversals instead of edits

    Operational software lets users correct mistakes, and accounting does not let history change. Corrections post a reversal plus a fresh entry, which keeps an audited trail while still giving the operator a working undo.

  2. 02 / 04

    Mapping business events without leaking accounting into the product

    If a POS screen has to know which ledger to debit, accounting has escaped into the UI. Products emit domain events; a versioned mapping layer decides the accounts, which means a rule change does not mean a release of five products.

  3. 03 / 04

    Consolidation across systems

    An owner with a hotel and a gas agency wants one position. Because both post into the same engine under the same tenant, consolidation is a query rather than an export-and-merge exercise.

  4. 04 / 04

    Reproducing last year figures

    Tax rates, posting rules and account structures change. Rules are versioned and stamped onto the posting, so a report for a closed period reproduces the numbers that were correct then.

07

SCREENS

  1. SCREEN_01Ledger view with source-document trace
  2. SCREEN_02Outstanding and ageing by party
  3. SCREEN_03Trial balance and period close
08

RESULT

Four operational products share one accounting core. An accounting fix or a new report is written once and every product gets it.

New systems start with working accounting on day one, because integrating means mapping events rather than building a ledger.