TallyPrime vs Tally ERP 9: What Actually Changes When You Import

Here is the thing that matters most, and it is counter-intuitive.

An older Tally does not reject an element it has never heard of. It accepts the voucher and drops the element.

So a voucher built for TallyPrime 3 and posted into Tally.ERP 9 comes back reporting success. The voucher is created. The date is right, the amount is right, and something inside it, possibly the GST registration details or the bank allocation block, was quietly discarded on the way in.

Nothing in the response tells you. There is no warning, no partial-success flag, no count that differs. Every version incompatibility in this area is silent, which means you find it weeks later when a return does not tie, and by then it looks like a data problem rather than an import problem.

Rather than assume, we tested it: send a deliberately maximal voucher carrying every element we could attach, export it straight back out of Tally, and diff the two. Whatever went missing is what that version silently discarded.

Across 47 elements, three versions measured in August 2026:

If you are debugging an import that "worked" but produced something wrong, these are the elements where the families genuinely diverge, and they are worth knowing by name.

The UDF namespace declaration. The bank allocations block, which carries cheque and transfer detail. The persisted view and voucher entry mode elements. Old audit entry references. And the two that cause the most confusion in practice: GST registration details, which newer versions expect as a nested block and older ones expect as a flat party GSTIN field, and unit-of-measure reporting, which is a full reporting-UQC block in TallyPrime and a bare UQC name in older releases.

GST and UQC are the ones that hurt, because they are the elements most likely to be wrong in a way that surfaces at filing rather than at import.

A short confession, because it is the useful part of this article.

Before measuring, we predicted which elements each version would accept. Across the two older families, six of twelve predicted flags were wrong. TallyPrime 3 was the only family where every guess happened to be right, which in hindsight is unsurprising: it was the version being developed against.

There was also a caveat in our own notes warning that one element behaved non-monotonically across versions and must never be "tidied up" to look ordered. When it was finally measured, that turned out to be untrue. It had never been tested; it just sounded plausible.

The lesson generalises past Tally: a confident-sounding caveat is still a guess unless it cites a measurement. In this particular area guesses are especially expensive, because the failure is silent and you will not be told you were wrong.

If a practice runs more than one Tally version, and many do because clients run what they run, then version handling is not a footnote.

Questions worth asking any vendor:

Greenote detects which family it is talking to and builds the voucher for that family, rather than sending one maximal shape and hoping. Elements a version cannot take are not sent to it, so nothing is discarded on arrival and what you review is what lands.

The capability table behind that is derived from the round-trip measurements above rather than from documentation, which is the only reason it is trustworthy. Where a family has not been measured, it is marked as unmeasured rather than assumed, and the pre-ERP generation is currently in that category. We would rather say so than claim coverage we have not proved.

That is also why re-running an import is safe: Greenote sets a stable identifier per voucher, so a second run updates the existing voucher rather than creating a twin. More on that in what each Tally import error means.