Why an edited Tally voucher becomes a duplicate GRN

The symptom

Month end. Stock doesn't tie out. Somebody spends a day and a half tracing it and eventually finds two goods-receipt records for the same physical delivery — same party, same items, two different voucher numbers, a few days apart.

Nobody entered it twice. The godown received one delivery and confirmed one delivery. And yet there are two records.

You correct it, you move on, and it happens again next month with a different party.

The cause

In Tally, vouchers get edited. This is not a bad habit — it is how the software is meant to be used. Someone corrects a quantity that was keyed wrong. Someone renumbers an invoice because a series was wrong. Someone cancels and re-enters after the party revises a bill. At financial year end, companies get split or renamed and numbering restarts.

Now think about how a connected system finds the Tally record it already knows about. The obvious way — the way almost everything does it — is to match on the voucher number, because that is the number a human sees, quotes on the phone, and writes on the paper.

So the sync does exactly what it was told to do. It looks for voucher GRN/0412, doesn't find it, concludes this must be a new record it has never seen, and creates one. Meanwhile the original row is still sitting in your system, orphaned, pointing at a number that no longer exists.

One delivery. Two records. No error message anywhere, because from the software's point of view nothing went wrong.

The fix

Tally keeps its own internal identifier for every voucher, separate from the number people see. That identifier does not change when the voucher is edited, renumbered, or re-entered against a corrected bill. It is the stable thing in a system where the visible number is deliberately not stable.

Match on that, not on the voucher number.

Once you do, an edited voucher arrives, matches the record you already have, and updates it. A renumbered voucher fixes its own number in your system instead of spawning a twin. A cancellation cancels the row it actually belongs to.

It is one line of matching logic. It is also the difference between a Tally integration that quietly corrupts your stock figures and one that doesn't.

The question to ask any vendor

If you are evaluating software that claims a Tally integration — ours or anyone's — this is the single most useful question you can ask, and it takes ten seconds:

If the answer is the voucher number, or if the answer is vague, you will be finding duplicates within a month or two of going live. If they know exactly what you're asking and answer with Tally's internal identifier, they have hit this problem themselves and solved it.

The second question, less obvious and worth asking too: what happens at financial year end, when the company is split or renamed and numbering restarts? A system that hard-codes a Tally company name will simply stop syncing on the day that changes, and — depending on how it is written — may not tell anyone it has stopped.

Why I know this

I distribute Red Bull, Cadbury, Wipro and a few other brands across North Bengal and Sikkim, and I run a tissue converting unit with Premier Tissues India. For years the receiving side of that business ran on Google Sheets next to Tally, and I lost two full days every month to reconciling what the godown said had happened against what the books said had happened.

A meaningful share of those two days was this exact bug, and I spent a long time believing it was my team being careless. It wasn't. It was a matching rule.

Related notes

• Tally integrations: what can and cannot be automated — the wider map this bug sits inside.
• What a distribution business actually loses on Google Sheets — the five stages, in the order they fail.
• Proof of delivery: what the photo actually needs to show
• Choosing distribution software as a 20-person distributor — competitors named, and where I'd tell you not to buy from us.