Bringing in vouchers
Import payments, receipts, contra, journals, credit/debit notes and sale/purchase returns from a spreadsheet — the same easy, guided way as transactions.
Vouchers move in just like transactions. Open Transactions → Import/Export, choose Voucher Imports, pick the voucher kind, and upload your sheet. Columns are matched for you, and the same calm, grouped messages tell you if anything needs a look. On a return, a blank or a dash (-) in a quantity or money cell is read as 0; on the other kinds, a dash in an amount cell is a row to fix.
Bringing a voucher file in again works the same way too. Each voucher is compared with the vouchers of the same kind in your books, in its financial year (April to March), by its number: the number Kaalchakra gave it, from a Document No column (whole numbers only), or the number your old software printed, from a Voucher No column. The two kinds of number are never compared with each other. One already there and unchanged is not added a second time; one that changed is listed for you to update or leave as it is; and one that can't be updated says why — for example its cheque has been printed, a bank line of it has been reconciled, an automation manages it, its period is locked, or you can't edit vouchers. A voucher with no number can't be recognised: one that exactly repeats a voucher an earlier file created is not added again, and anything else is created. A Voucher No that the file uses for more than one voucher in a year, and that no voucher in your books holds, can't recognise any of them by that number, so each one is matched by what it contains: a voucher identical to one you already have is not imported again, and the rest come in as their own vouchers. When a voucher in your books does hold that number, the file's voucher identical to it is left as it is, and the others are listed under To decide — or Can't update when more than one of yours holds it — with Import as new, where it can be imported.
Some matches wait for you under To decide, left as they are unless you choose Update: a voucher found by its Document No whose date or accounts differ, one found by its old Voucher No whose date or accounts (on a return, its items) differ, whatever its amount, and a return, credit note or debit note dated in a period whose GST return file has already been made. A voucher found by its old Voucher No also offers Import as new, where it can be imported, which brings the file's voucher in beside the one in your books — for example a later instalment that reused the same bill number in your old software, even for the same amount, or the same bill number paid to another party. One found by its old Voucher No with the same date and accounts but another amount is a correction, listed as changed. A return, credit note or debit note keeps the number from your file, and your GST returns file it under that number — which may be used only once in a financial year. So if a file brings a second return whose number another return already has in the same financial year (after Import as new, for example), both carry that number, and the GST Audit Report names the clash before you file. Correct the number in Busy, then delete the second return here and import it again.
Names that are not in your masters are listed for you to decide, as on the transaction page — accounts on payments, receipts, contra, journals and notes; the party, items and charges on a return. A return never creates a party or an item: answer Same as one you have, or leave those documents out. An account you answer Create new is created in Suspense Accounts; move it to its proper group in Masters afterwards. Your Same as answers are remembered when you import, and you can see them under Remembered names on the Transactions Import/Export page.
Vouchers in a locked period
A voucher dated inside a period you have locked is neither added nor updated from the file: one already in your books is listed with the locked date, and new ones are counted. Someone who manages the period lock can tick Include documents up to ‹date›; the vouchers it covers are written when you press Import, up to that date only.
The kinds you can bring in
| Voucher | What it records | Essential columns |
|---|---|---|
| Payment | Money paid out (bank or cash). | Date, the paying account, the account paid, Amount |
| Receipt | Money received (bank or cash). | Date, the receiving account, the account received from, Amount |
| Contra | Moving money between your own bank and cash. | Date, from account, to account, Amount |
| Journal | An adjustment between accounts. | Date, each account with its Debit or Credit amount |
| Credit Note / Debit Note | An account adjustment for a party. | Date, each account with its Debit or Credit amount |
| Sale Return / Purchase Return | Goods returned (moves stock). | Date, Party, and on each line the Item, Quantity and Rate |
Each voucher must balance
For payments, receipts, contra, journals, and notes, every voucher's total debit must equal its total credit — that's simply double-entry. Put each side on its own row: one row for the debit, one for the credit. If they don't add up, you'll get a clear, friendly note pointing at the voucher.
One voucher can span several rows
A voucher with several lines uses one row per line. Put the date, the numbers and the narration on the first row and leave them blank on the rows just below — a row that fills none of the voucher's own cells, or repeats the same Voucher No, belongs to the voucher above it. The downloadable template shows the layout.
Returns move stock; notes adjust accounts
Sale and Purchase Returns bring back goods and move your stock, so they need item lines. Credit and Debit Notes only adjust account balances, so they use debit/credit lines — no items.
Bringing in Sale and Purchase Returns
A returns sheet looks like an invoice sheet: one row per item, with the party, the return's own number and its date on the first row of each return and those cells left blank on the rows below. Quantity and rate are what matter — the rest is optional.
| Column | Needed? | What it should hold |
|---|---|---|
| Party | Yes | The customer who returned the goods, or the supplier you returned them to. |
| Date | Yes | The date of the return. |
| Item | With each item | One row per item coming back. |
| Quantity | With each item | How many units are being returned. |
| Rate / Price | With each item | The rate actually charged — the price after any discount. |
| Tax %, CGST, SGST, IGST | Optional | Carried through exactly as your sheet has them. |
| Rounding and other charges | Optional | Put each on its own row with its name and amount. |
| Total | Optional | When filled, it is taken as the return's total, even where the lines add up differently — so map it only when it is right. |
The taxable value on a return's lines
A returns file exported with the default columns carries Item Taxable Value (after Tax %) and Cess Amount (after IGST Amount) on every line, so you can change a line's quantity, rate and amounts in that file and import it to update the return. A Sale Return or Purchase Return layout you saved in Column setup earlier carries neither until you add them: open Column setup, pick the return, and add both with Add or remove columns. When you change a line's amount, change its taxable value with it — a line whose taxable value and GST do not add up to its amount is refused, and named. A sheet from Busy does not need either column: the return's taxable total is worked out from the amounts and tax in your file. If your own sheet holds a taxable value per line, take care before you map it: a per-unit rate is not a taxable value, and pointing one at it will understate the return. Fill it on every line of a return that carries money, or leave it blank on all of them — a return whose lines give a taxable value on some and not on others is named as one whose tax can't be worked out from the file: a new one is not imported, and one already in your books is left as it is. A return already in your books has its amounts updated from a file only when the file carries a taxable value and every GST and cess column its lines use; without them, a changed amount is listed as one the file can't change.
Dates that cannot be misread
A date like 05/04/2026 can mean 5 April or 4 May depending on where the file came from, and nothing in the cell says which. So the import page asks how the dates in your file are written — Day/Month/Year, Month/Day/Year or Year-Month-Day — shows a date from your file read that way, and keeps your choice for the next file. If your sheet can write the month as a name — 05-Apr-2026 — that can never be misread at all. Any date that can't be read the way you chose is reported against the return it belongs to, so nothing is guessed silently.
Bringing the same file in twice
Re-running a file is safe. Each return in the file is compared with your books first. One that is already there and unchanged is left exactly as it is and not created again. One that has changed is listed for you — update it from the file, and it keeps its number with the columns your file maps brought up to date, or leave it as it is. One that can't be updated says why. A return linked to the sale or purchase it was made against keeps its party: a file that names another party can't change it. A return without a number can't be recognised: an exact repeat of one an earlier file created is skipped, and anything else is created. A single return that cannot be brought in never stops the others.
If the file has no whole-number Document No for a return, a whole-number Voucher No becomes its own number in Kaalchakra too — unless another return in the file uses the same Voucher No, or the return is brought in with Import as new. If that number is already taken in the year, the return is not imported and says why.
Returns are numbered separately from invoices
Your returns carry their own numbering, independent of your sales and purchases — so a return numbered 1 and an invoice numbered 1 are two different documents and never collide.
Was this page helpful?