If your business runs on Tally — as most Indian trading, distribution and manufacturing businesses do — the first question anyone asks about a warehouse system is not about bins or scanners. It is: "How does what happens in the warehouse end up in Tally?" It is the right question, because the value of a WMS collapses the moment it forces your accounts team to re-key everything the warehouse already recorded.
Fast WMS answers it directly. Warehouse transactions post to Tally as the matching vouchers through a store-to-godown mapping: a goods receipt becomes a purchase receipt, a dispatch becomes a sales voucher, and internal transfers and adjustments become stock journals. Once the mapping is set up, the accounting entry follows the physical movement automatically. This guide walks through how that mapping is built and what flows across it.
Why Tally alone isn't enough — and why it stays
Tally is superb at accounts. It tracks stock totals by godown, values inventory, and produces the statutory reports Indian businesses depend on. What it cannot do is run the warehouse floor: it does not track which bin a pallet sits in, does not enforce FIFO or FEFO at a barcode scanner, and does not generate directed pick lists. That execution layer is exactly what a WMS provides.
So the goal is never to replace Tally — it is to stop entering the same transaction twice. The warehouse should record a movement once, at the point and moment it physically happens, and Tally should receive the corresponding voucher without a human retyping it. That is what the integration delivers, and it is why Tally stays right where it is.
Godown mapping — the foundation
Everything rests on one idea: both systems must agree on what a location is. In Fast WMS, stock lives in stores and bins; in Tally, it lives in godowns. Godown mapping links each Fast WMS store or warehouse to its matching Tally godown, so that when a voucher posts, it knows exactly which godown to hit.
This is a one-time configuration, and it is worth doing carefully because it is the anchor for everything after it. A store in the WMS that has no godown counterpart in Tally has nowhere to post; a store mapped to the wrong godown posts correctly-shaped vouchers to the wrong place. Get the map right once, and every future posting lands where it should with no manual selection.
Ledger and master linking
Locations are only half the picture. The other half is making sure the two systems name the same items and the same parties identically, and that the right ledgers are linked so a posted voucher balances. Three alignments matter:
- Item master alignment. The item codes in Fast WMS must correspond to Tally's stock items, so a receipt of a given item posts against the right stock item in Tally.
- Party master alignment. Suppliers and customers must match across both systems, so a purchase or sales voucher hits the correct party ledger.
- Ledger linking. The purchase, sales and stock ledgers a voucher should touch are defined up front, so each posting is a complete, balanced entry rather than a half-formed one.
With masters aligned and ledgers linked, a warehouse transaction carries everything Tally needs to record it properly. Nothing is inferred at posting time; it is all decided during setup.
What syncs to Tally — the voucher map
Once mapping and linking are in place, each type of warehouse document maps to a specific Tally voucher. This is the heart of the integration, and it is simplest to read as a table.
| Fast WMS transaction | Posts to Tally as | Effect |
|---|---|---|
| Goods receipt (GRN) | Purchase receipt against the mapped godown | Stock in, supplier ledger updated |
| Dispatch / gate-out | Sales voucher | Stock out, customer ledger updated |
| Bin / store transfer | Stock journal | Stock moves between godowns, no value change |
| Stock adjustment ± | Stock journal | Book quantity reconciled to physical |
Because a goods receipt in Fast WMS is a real, structured document — you can see how the inbound flow is built on our GRN & inbound feature — it carries the supplier, item, quantity and godown a purchase receipt needs. Likewise a dispatch, covered on the dispatch & invoicing feature, carries what a sales voucher needs. The voucher is not reconstructed later; it is generated from the document that already exists.
The setup sequence
Putting it together follows a clear order. Each step depends on the one before it, which is why doing them in sequence saves rework:
- Confirm the Tally target. Note the company, godowns, stock items and party ledgers the WMS will post into. This is the shape the mapping must match.
- Map stores to godowns. Link every Fast WMS store or warehouse to its Tally godown counterpart.
- Align item and party masters. Ensure items and parties correspond across both systems so vouchers hit the right stock item and ledger.
- Link the ledgers. Define the purchase, sales and stock ledgers each voucher type should touch.
- Test with one document of each type. Post a single GRN, a single dispatch and a single transfer, and confirm each appears as the correct voucher in Tally before going live.
Before integration, a distributor's accountant spent the last three days of every month re-entering warehouse receipts and dispatches into Tally from a stack of printouts — and reconciling the gaps that inevitably appeared. With store-to-godown mapping in place, each GRN posted as a purchase receipt the day it happened and each dispatch as a sales voucher, so month-end became a review instead of a re-keying marathon.