LedgerFlow
Custom accounting and GST software
Invoices, bills, banking, ledger and GST in one place.
For businesses whose accounting does not fit a packaged ledger: multi-entity groups, trade-specific costing, or operations where the books need to be fed by the operational system rather than typed in twice. Built to be correct on GST and honest about the cash position.
Screens
What it looks like
4 screens from the working demo — the same data you will see if you open it.
The problem
Why this gets built
By the time the books are closed, the numbers are history. The useful question is what the cash position is now, and which invoices are quietly ageing past sixty days.
Who it is for
Fit
SMEs and firms who want their own books live rather than reconstructed quarterly.
Capabilities
What the system does.
GST-compliant invoicing
CGST/SGST/IGST handled correctly, with invoice formats that survive scrutiny.
Bills & expenses
Purchases and expenses captured against the right head and the right period.
Bank reconciliation
Statement lines matched against entries, with the unmatched ones surfaced rather than hidden.
General ledger
Double-entry underneath, so the trial balance is a fact rather than an aspiration.
GST returns
GSTR-1 and 3B data assembled from the books with filing status tracked.
Ageing & cash position
Receivables and payables by bucket, and what the bank will look like in three weeks.
See it running
LedgerFlow is a clickable demo — open the modules, browse the tables, see how the screens fit together.
Buying decision
Why off-the-shelf falls short here.
For straightforward businesses, packaged accounting software is the right answer and we will say so. Custom accounting is worth building in three situations: when the operational system already holds the transaction and re-keying it into a ledger is the actual cost; when the business runs several entities that must consolidate; and when the costing that matters is trade-specific and the packaged chart of accounts cannot express it.
The failure mode in all three is the same - a second set of records. Operations run on one system, accounts on another, and a person spends the last week of every month making them agree. The reports that come out are accurate as at a date that has already passed.
A custom build puts the ledger where the transaction already is. An invoice raised in operations posts itself, GST is apportioned at line level as it is raised, and the position is current rather than reconstructed.
Comparison
Packaged product vs a custom build.
The differences that decide it, for this sector specifically.
| Aspect | Packaged product | Custom build |
|---|---|---|
| Data entry | Transactions typed into the ledger | Posted automatically from the system that created them, with the source document linked |
| GST | Returns assembled at filing time | CGST, SGST and IGST resolved at line level as the entry is made, with GSTR-1 and 3B data standing ready |
| Multi-entity | Separate books, manual consolidation | Entities kept separate with consolidation and inter-company elimination as a report |
| Costing | A standard chart of accounts | Cost centres shaped to the trade - per site, per lot, per job - rolling into the same ledger |
| Bank | Manual reconciliation | Statement import with matching, and anything unmatched surfaced rather than quietly ignored |
| Cash position | Accurate at period close | Receivables and payables by ageing bucket plus a forward bank view, current today |
Integrations
What it connects to.
A system that cannot reach the tools already in use becomes another island. These are the connections this sector normally needs.
Tally and Zoho Books
Two-way where you want to keep the statutory books there while operations drive the entries.
E-invoicing
IRN and QR generated at invoice time, not batched at month end.
Banking
Statement import across formats, and payment file generation for bulk transfers.
Payment gateways
Collections reconciled to the invoice, including fees and settlement timing.
Payroll
Salary, statutory deductions and reimbursements posted as one reviewed journal.
How it runs
From first conversation to cutover.
Indicative for a build of this shape. The parallel run is not optional — nothing is retired until the numbers agree.
- 1-2 weeks
Discovery
We review your chart of accounts, your GST profile and where the double entry currently happens.
- 4-7 weeks
Core build
Masters, vouchers, GST treatment and bank reconciliation, with your own historical data loaded.
- 4 weeks
Parallel run
A full month run alongside the existing books, reconciled line by line before anything is retired.
- 1-2 weeks
Cutover
Opening balances locked at a period boundary, with the previous system kept read-only.
After rollout
What changes day to day.
- The month-end reconciliation between operations and accounts stops existing, because there is one set of records.
- GST data is assembled from the books rather than compiled, so filing is a review instead of a rebuild.
- The cash position is current, which is the difference between a report and a decision.
- Unmatched bank lines are visible instead of silently absorbed.
Described qualitatively on purpose. We do not publish percentage improvements we cannot attribute to a named client with their agreement.
Questions
Common questions.
Is it GST compliant?
Yes. CGST, SGST and IGST are handled at the line level, and GSTR-1 and 3B data is assembled from the books with filing status tracked.
Can it reconcile bank statements?
Yes. Statement lines are matched against entries, and anything unmatched is surfaced rather than quietly ignored.
Does it show the current cash position?
Yes. Receivables and payables by ageing bucket, plus a forward view of the bank position, rather than a picture that is only accurate at quarter end.