How it works
Five mechanisms, and what each one prevents.
Every diagram below is of something the software actually does. They are animated because each one is a sequence - a thing happening over time - and a still picture of a sequence leaves out the part that matters.
One
Stock is summed, never stored.
The correction is another row.Nothing above it was edited, so the history still explains the number.
What this prevents
A stored quantity has to be written by somebody. Two tills writing it at once lose a sale. A crash halfway through writing it leaves a number that matches nothing. And when it is wrong, there is no way to find out why, because the thing that made it wrong was overwritten.
Summing the movements has none of those failures. Every number is reproducible from rows that are still there, and a stock-take correction is another movement - so next month you can still see that two were damaged, rather than only that the count changed.
Party balances, what an invoice still owes, profit for a period: all derived the same way, from the same discipline.
Two
Offline billing, without two shops minting the same number.
What this prevents
A duplicate invoice number is a compliance problem, not a display bug. The usual fix - ask the server for the next number - is exactly what stops working when the line drops.
So a device reserves a block in advance, while it still has a connection, and bills from that block offline. Two blocks can never overlap: allocation happens under a database row lock, and a unique index refuses a second block starting where one already does.
A device that hands back a partly used block leaves a gap in the sequence. That is the right trade - an accountant can explain a missing number, and cannot explain the same number twice.
Three
The database itself refuses an unbalanced voucher.
A voucher whose lines do not balance is refused.By the database, at the moment it is declared complete - not by the application.
What this prevents
Most billing software checks its own arithmetic. That works until the day a code path forgets - and then the books are wrong and nothing reports it, because the thing that was supposed to notice is the thing that failed.
Here the rule lives below the application. A trigger sums the lines when a voucher is declared complete and refuses it if the two sides disagree, or if they disagree with the total the voucher declares for itself.
So the trial balance cannot be out. Not "is not, at present" - cannot be, because an unbalanced voucher has no way of existing.
Four
The tax split is decided, not typed.
Both at once is refused by the database.A document carrying CGST and IGST together is always a bug, so it cannot be stored.
What this prevents
Whether a sale is CGST plus SGST or a single IGST is not a preference. It follows from where the goods are supplied, and getting it wrong is the sort of mistake nobody notices until a return is being filed.
The rate is looked up per item, the split is decided from place of supply, and a document carrying both at once cannot be stored - a constraint in the database refuses it.
Rule sets are versioned. A document keeps the version it was taxed under for ever, so a rate change next year does not quietly restate last year's invoices.
Five
The recurring work happens whether anyone logs in or not.
What this prevents
Rent on the first, the retainer every quarter, the reminder to a customer who has not paid. A shop that has to remember these will eventually forget one, and nothing anywhere will say so.
Two servers both reaching the same job would bill every customer twice, so exactly one takes a lock and runs it. The lock is held by the connection - a machine that dies mid-run releases it, where a status flag in a table would block the job for ever and need a person to clear it.
Every attempt is recorded, including the ones that did nothing. "Ran and found no work" and "did not run" have to be tellable apart, or a job that quietly stopped looks exactly like a quiet month.
The honest part
What it refuses to do.
Software that overstates itself costs you more than software that does less. These are the things this one will not claim.
It cannot take a card payment
It prints a UPI QR code, which is how most Indian counters actually take money - the rupees go straight to your bank with nobody in the middle and no percentage taken. But no webhook tells this software the money arrived, so a QR can never mark a bill paid. It asks for money; it does not record it. Recording is a keystroke, and it is yours.
It does not file your GST return
It computes GSTR-1 and GSTR-3B, keeps every generation as a revision you can produce later, reconciles against GSTR-2B, and exports in the portal's own format. Filing needs an account with a GST Suvidha Provider. The acknowledgement number is recorded from what you were given, never produced.
It will not invent a number
Where a figure cannot be derived it is left out and said so, rather than estimated. A currency with no closing rate is listed as missing a rate rather than revalued at a guess; a company the scheduler could not act on is named with the reason rather than skipped.
See it doing this.
The counter bills, the office reconciles, and both are the same program.