One engine. Six areas. No interfaces to fall out of step.

CGST and SGST or IGST is derived from the supplier state, the place of supply and the registration type, evaluated once and stored on the line. Reverse charge, exports and SEZ each take their own path, and each is covered by tests that assert the computed heads and the return figures rather than the printed label. The composition scheme is not one of those paths: you can record the registration type and print a Bill of Supply that suppresses the tax columns and carries the declaration, but choosing it changes nothing the tax engine does, and the dealer’s own turnover tax is not computed.

GSTR-1 and GSTR-3B figures assembled from the postings, broken down so every total can be traced back to the vouchers that produced it. You can hand the working paper to an accountant and they can check it — which is the whole point.

Import the portal’s 2B extract and match it against recorded purchases: matched, matched with a difference, missing in books, missing at the portal. The differences are what matter, so they are what the screen leads with.

The integration is written against a provider interface with a mock implementation. It produces SANDBOX identifiers, the screen says so in as many words, and nothing is transmitted to any government system. When a real provider is connected it will be behind explicit consent, a confirmation screen and an idempotency key — none of which exist to be bypassed.

FIFO or weighted average per item, held as explicit valuation layers. Reversing a movement unwinds the layers it created — which is exactly where systems that store a single running average quietly go wrong.

Track batch numbers and expiry dates through receipt, issue and transfer, with a report on what expires when. Under weighted average there is one pooled layer, so expiry reads from the movement history rather than the layers — a detail that matters and is easy to get wrong.

Reorder level and lead time per item, against real consumption. Slow and non-moving stock is derived from the last movement date, so the report tells you what is genuinely sitting still.

Bills of material with component consumption, work orders that value the issue at the current valuation before posting, and job work sent out and received back. The output is valued from what actually went into it.

Twenty-one rules over the whole ledger: unbalanced vouchers, orphaned allocations, negative stock, control accounts that disagree with their subsidiary, periods that should be closed, gaps in a numbering series. Each returns the rows that failed, not a red light.

Every recorded event is hashed with the hash of the event before it. Change one row in the database and every subsequent hash stops matching — and the Operations screen says so. Verified over 12,050 events in the load test.

Receivables aged into bands from the bill dates, then grouped by customer into a collections view with a stage worked out from how overdue the oldest bill is. The stage is derived on every load, so it cannot be stale.

Trial balance, profit and loss, balance sheet, cash flow and day book, all derived from postings. Forty-one milliseconds for a trial balance over a year of 100,000 vouchers on PostgreSQL — fast enough that there was never a reason to store a second copy.