A single-item invoice at one tax rate is straightforward, and almost anything will import it. The moment an invoice carries several items at different rates, the number of things that have to line up multiplies, and tools that looked fine on simple data start producing vouchers Tally refuses or, worse, accepts wrongly.
The failures are not random. They cluster in a small number of places, and most of them come down to arithmetic that was done in the wrong order.
What has to exist before the invoice can post
Multistock invoices fail at import far more often than simple ones for a reason that has nothing to do with the invoice: they depend on more masters being correct first.
- Every stock item on the invoice has to exist, with the right unit of measure. An item that does not exist stops the whole voucher, not just its own line.
- Each item needs its GST rate set on the item master or inherited correctly from its group. An item with no rate does not fail loudly; it posts at nothing.
- The tax ledgers need the correct type of duty configured, or amounts post but never reach the returns.
- The party ledger needs the right registration type and state, because that is what decides whether the invoice is intra-state or inter-state.
Important
An item whose rate is missing from the master will not usually announce itself. The line posts with no tax and the invoice total is simply lower than the document. It is found at filing, not at import, which is the most expensive time to find it.
Where the arithmetic goes wrong
This is the heart of it. On a mixed-rate invoice, tax has to be computed per rate group, not on the invoice as a whole, and the order of operations decides whether the total matches the supplier’s document.
The correct sequence is: group the lines by rate, total the taxable value within each group, compute tax on each group total, then round. What tools get wrong is computing tax line by line and rounding each line, then adding up. On an invoice with a dozen lines those two approaches disagree by a rupee or two, and the voucher no longer equals the paper invoice.
A rupee sounds trivial. It is not, because the invoice will not tie to the supplier’s figure, it will not tie to 2B, and someone will spend an afternoon on it.
Pro tip
When a multistock invoice is off by a very small amount, do not look for a missing line. Look at whether tax was computed per line or per rate group. A difference of one or two rupees on a many-line invoice is almost always rounding order, not a lost item.
Discounts, freight and the order they apply in
The second common break is anything that is not a plain item line.
A discount given before tax reduces the taxable value and therefore the tax. A discount applied after tax does not. Both appear on invoices, they look similar on paper, and applying one as the other changes the tax on every affected line.
Freight and other charges have to be apportioned across the rate groups, not dumped onto one line or added at the bottom as an untaxed extra, because the charge inherits the treatment of what it relates to. On a mixed-rate invoice that means splitting it, which is exactly the step that gets skipped.
Round-off is the third. Tally will maintain a round-off ledger and it should be carrying pennies, not rupees. A round-off line that is growing is a symptom of the rounding-order problem above, not a solution to it.
Checking the result rather than trusting it
Because several of these failures are silent, the only reliable check is comparing the posted voucher against the source document.
- Does the invoice total in Tally equal the total on the supplier’s invoice, exactly?
- Does the taxable value in each rate group match, group by group rather than in aggregate? Two groups can be individually wrong and still sum correctly.
- Is the round-off carrying pennies or rupees?
- Did every line get a tax rate, or is one sitting at zero?
- Is it intra-state or inter-state, and does that match the party’s state rather than the branch you dealt with?
What this has to do with bank statements
Most of what arrives from a bank statement is a payment or a receipt, not an invoice, so multistock does not enter into it. Where the two meet is the supplier side: the payment you booked from the statement has to settle against an invoice that was entered correctly, and if the invoice total is a rupee out, the settlement leaves a rupee behind that nobody can clear.
So the tidiest bank ledger in the world will still show unexplained residuals if the invoices behind it were posted with the wrong rounding order. It is worth knowing that the residual is coming from the invoice rather than assuming the payment was mis-keyed.
Greenote builds all seven voucher types including multistock invoicing with GST, and computes tax per rate group rather than per line, which is the specific thing that keeps the total equal to the document.
Conclusion
Multistock invoices break in a small number of predictable places: a master that does not exist, a rate that was never set, and above all tax computed in the wrong order and rounded too early.
Group by rate, total, then compute, then round. Apportion freight across the groups. Treat a growing round-off as a symptom rather than a fix. And check the posted voucher against the paper rather than assuming a successful import means a correct one, which is a habit worth having generally: see what each Tally import error actually means.
Start a free trial and compare a real invoice against what lands.
Turn bank statements into Tally vouchers offline
Greenote reads 100+ Indian banks and posts clean vouchers straight into Tally, fully on your PC. No uploads, no cloud, no manual entry.
7-day free trial, no card required. Works with Tally Prime & ERP 9.
