Tally-ready by construction

Ask a restaurant accountant where their month goes and a surprising amount of it is typing. Sales summaries arrive as a PDF or a spreadsheet, and the numbers get entered again into Tally by hand — a second chance for every figure to be slightly wrong.

The usual fix is an export button. The useful fix is an export that Tally can import without a human deciding anything.

Keystonne is not your book of record

Worth saying before anything else: this software is operational truth, not books-of-record. It knows what was sold, to whom, at what tax, and when the money arrived. Your statutory filing lives in Tally or Zoho or BUSY, with your accountant, where it belongs.

That is a design decision, not a limitation we are apologising for. It means the export is the product, not an afterthought — the seam has to be good because the seam is the whole relationship.

Vouchers, not a spreadsheet

Sales come out as Tally Sales vouchers: the canonical envelope Tally expects, one voucher per invoice, each carrying the party, the GSTIN, the place of supply and the dates, with one inventory entry per line and accounting entries for the party, every tax head, and round-off.

Which means each voucher balances. Party debit equals the taxable value plus the tax heads plus round-off, following Tally's own sign convention. An import that balances is an import your accountant does not have to reconcile before trusting.

Zoho Books and BUSY get the same treatment in their own shapes — BUSY at line grain, with the party, GSTIN, state code and the CGST/SGST/IGST split repeated per line, because that is what BUSY imports.

"Lossless" is a test, not an adjective

Everyone says their export is complete. Here is what we mean by it.

The exporter has an inverse. Invoices go to XML, the XML is parsed back to invoices, and a test asserts the result is deeply equal to what went in, with every amount still an exact integer number of paise. If a field could be dropped or a rupee could be rounded, that test fails.

The trick for the fields Tally has no native slot for — the rate in basis points, the split, the taxable base per head, the financial year, the document type, the Section 9(5) flag, the source id — is that they ride along as dedicated child elements. Tally ignores tags it does not know on import; our parser reads them. Nothing is thrown away to make the file fit.

Money never becomes a float anywhere on that path. Amounts are bigint paise from the bill to the voucher, and rupee decimals are formatted from the integer at the very edge.

The documents the law asks for

The same engine produces GSTR-1 and GSTR-3B style registers, rate-wise, and it respects two things a generic export tends to flatten:

- Registration type decides the document. A composition or unregistered seller issues a bill of supply, not a tax invoice — see that post for why it is law rather than a template setting. - Section 9(5) orders are tagged, not taxed. Aggregator supplies show as "Sec 9(5)" with nil tax, because the platform is the liable party.

The honest limits

- Export, not two-way sync. Nothing writes back into Tally, and Tally does not drive Keystonne. A one-way seam you can inspect beats a sync you cannot. - Your accountant still files. We produce registers; we do not submit returns. - Mapping is yours to confirm once. Ledger names in your Tally company are yours, not ours to guess. Confirm them on the first import and the rest is repetition.

The measure is simple. If your accountant is still retyping anything, the export has not finished the job.