Open-source GST billing and accounting software with a double-entry ledger: how Rechvix works

Short answer: Rechvix is a self-hosted billing, inventory, accounting and GST platform for Indian businesses. Every sale, purchase and adjustment is posted to a double-entry ledger, and finalising an invoice is a single database transaction. It is open source under AGPL-3.0, and I am its lead developer.

What problem does it solve?

Billing tools for small and mid-size businesses tend to fall into two groups. Some are spreadsheets that cannot produce a GST e-Invoice. Others are subscriptions that keep every invoice, ledger and customer record on a vendor's servers, often without real double-entry accounting underneath.

A billing system fails quietly when its numbers drift: stock that no longer matches movements, a ledger that does not balance, an invoice edited after it was filed. Rechvix is designed so those failures are structurally hard to produce, not just discouraged.

What does Rechvix include?

• Billing: quotations, proforma invoices, tax and cash invoices, credit and debit notes, returns, and a fast point-of-sale screen with live stock and price.
• Inventory: product catalogues across several warehouses, with stock valuation per product and warehouse.
• Accounting: a double-entry ledger with a trial balance and receivables.
• GST: e-Invoice and e-Way Bill support, with a structure that lets another country's tax rules be added without rewriting the core.
• Scale: multiple companies and multiple branches in one installation.

How does one invoice change stock, tax and accounts together?

Drafts can be edited freely. Finalising a document is one transaction that takes stock, posts the ledger entries, applies tax and allocates the document number. If any part fails, none of it persists. That requirement shaped almost every other decision in the project.

This is also why Rechvix is a modular monolith and not a set of microservices. Splitting invoice finalisation across network boundaries would trade correctness for an architectural style the scale does not need. Dependencies point one way, from HTTP handlers to application services to pure domain rules to repository interfaces implemented on PostgreSQL.

How are businesses kept apart in a multi-company setup?

Tenant boundaries are enforced in two places: an organisation filter in the SQL query and PostgreSQL row-level security. The runtime database role is different from the migrator role, so the application cannot quietly bypass the policies. When I reviewed every repository I found thirteen lookups that relied on row-level security alone and added an explicit organisation filter to each. The reasoning is in Row-level security is not your only tenant boundary.

Why self-hosted?

A self-hosted system gives its owner control of the records and the deployment. It also moves backups and upgrades onto the operator. I treat that as a design obligation: the backup guidance includes a restore drill that checks the restored database for drift between stock balances and the movement ledger, described in Restore drills for PostgreSQL business software.

What are the trade-offs?

Stock balances are maintained in application code, not a database trigger. That keeps the costing rule in one language but leaves no database-level backstop if someone inserts movements by hand. The full reasoning is in Stock balances belong in application code.

Who should use it?

Owners and accountants of small and mid-size businesses, billing-counter operators, and distributors or multi-branch retailers with large catalogues across several warehouses, who want their ledger on infrastructure they control. The Rechvix case study covers the data model, security boundaries and what I personally built.