TL;DR
Posting an interstate sale to a Sales — Local ledger (or vice versa) silently corrupts the GSTR-1 B2B split. TatvaBooks reads the customer's GSTIN state, classifies the chosen ledger, and disables the post button when the two contradict — blocking the mistake at entry instead of catching it on the 11th.
Every CA firm has lived this exact scenario. You will recognise it in the first three lines.
A customer in Pune places an order with your client, who is also in Pune. CGST + SGST applies. The article opens the accounting software, picks the customer, types the amount, and selects "Sales — Interstate" from the sales ledger dropdown by mistake. The system happily posts. CGST + SGST is credited against an interstate sales ledger.
On the 11th, GSTR-1 generates. B2B Interstate inflates. B2B Intrastate understates. Total CGST and SGST collected matches — everything else is wrong. The customer's GSTR-2B doesn't reconcile against your invoice. The customer calls.
Three working days later, you've revised GSTR-1, written an apology email, and lost half a day of partner time.
We've seen this on dozens of client books over the years. The root cause is always the same: the accounting software treats ledger selection as a free choice. It accepts whatever the user types. It has no opinion about whether the choice is internally consistent.
We disagreed with this design. So we changed it.
What the system does now
When a user creates a sale voucher in TatvaBooks:
- The moment a customer is picked, the system reads their GSTIN. The first two digits give the state code.
- The system compares that state code to the company's state. Same → intrastate. Different → interstate.
- The system reads each sales ledger and classifies it: Sales — Local (intrastate), Sales — Interstate, Sales — Export, or "other" for custom-named ledgers that don't fit a standard kind.
- If the chosen sales ledger's kind contradicts the intra-vs-inter determination, the system shows a red banner and disables the submit button.
The banner says, literally:
⚠ Sales ledger mismatch — Intrastate sale (customer same state) — must use a Sales — Local ledger, not Sales — Interstate. Posting blocked.
It is not a warning the user can dismiss. The post button is actually disabled. The voucher cannot enter the books until either the customer is changed or the ledger is corrected.
What this prevents in business terms
- A wrong-ledger sale silently corrupting GSTR-1 reconciliation across a quarter
- The B2B Intrastate / B2B Interstate split being mathematically impossible to derive from the books
- The customer's 2B not matching your GSTR-1, and the resulting phone call
- A revision of GSTR-1 in the next period (which itself can fail if the original is locked)
- The partner's time spent forensically tracing the bad voucher
It also protects audit trail. Posted vouchers are immutable in TatvaBooks — you cancel via a paired cancellation voucher, not by editing. So a wrong-ledger voucher that did post would require a formal cancellation and re-post. The system saves you that step by refusing the bad post in the first place.
What it doesn't do
We want to be specific about the limits.
Custom-named sales ledgers are exempted. If you've named a ledger "Sales — Vendor X" or "Sales — Project A," the system has no opinion. It can't infer whether such a ledger is intended for intrastate or interstate. We skip the check rather than enforce a wrong rule.
Export sales are exempted. Sales to SEZ or against LUT have their own logic (zero-rated, IGST refund). The mismatch detector doesn't apply.
It can't catch every error. If the customer's GSTIN is wrong (typed incorrectly during onboarding, or the customer gave you a wrong number), the intra/inter determination is wrong from the start. We can't catch that — we can only verify against the data we have.
For these reasons, the mismatch detector is one safety net among several. Period-locks, GSTR-1 preview reconciliation, and the balanced-voucher database trigger together form a system. No single feature owns the whole job. It's the same place-of-supply audit that anchors our 60-minute GSTR-1 close — except here the check happens at posting, not on the 11th.
Why this is the feature we're most proud of
Most accounting software design assumes the user is competent and attentive. Most data-entry users are not — not because they're careless, but because they're busy and aren't Chartered Accountants. They're sales executives, office assistants, first-year articles. They don't know that picking the wrong sales ledger corrupts GSTR-1 in a way that takes a partner's afternoon to undo.
We can either expect them to know. Or we can build a product that doesn't need them to know.
We chose the second. It's one of the decisions that sets TatvaBooks apart from the global cloud products — they accept the wrong-ledger post; we refuse it.
— The TatvaBooks team