The collections file for the month is usually already a spreadsheet. It comes off the bank portal, or the payment gateway settlement report, or a sheet the sales team maintains, and it has three hundred lines on it: date, party, amount, reference.
Somebody then opens TallyPrime and types those three hundred receipts, one at a time, because the outstanding report has to be right before the follow-up calls start on Monday.
You can import receipts from Excel to Tally, and doing so is not hard. What is hard, and what decides whether the exercise helps or hurts, is what happens on the bill-wise screen that appears with every receipt. Get that wrong at scale and you will have a ledger that balances perfectly and an outstanding report that is useless.
The receipt data almost always exists already
Very few businesses type receipts from paper. The information arrives digitally: a bank statement export, a UPI or card settlement file, a cheque deposit list, a sheet the field team fills in.
Each of those carries the same core facts a TallyPrime receipt needs. Date, amount, which account the money landed in, and some hint of who paid. The retyping exists because the hint of who paid is not a Tally ledger name, and because nobody has decided how the payment maps onto open bills.
That is an ordinary data-mapping problem, not an accounting one, which is why it is worth solving once rather than three hundred times a month.
Why you can import receipts from Excel to Tally and still be wrong
When you record a receipt against a party for whom bill-wise details are maintained, TallyPrime asks how to allocate the amount. The options include allocating it against a specific existing bill, and posting it On Account, which means the money is credited to the party without being tied to any invoice.
On Account is a legitimate choice. It is also the default that most bulk imports fall back to, because the spreadsheet does not say which invoice the customer was paying.
The result looks fine at a summary level. The party balance is correct, the bank is correct, the trial balance is correct. But the receivables ageing is now wrong, because the invoices those payments settled are still sitting there as open bills, and an equal pile of unallocated credits sits alongside them.
Two months of that and nobody trusts the outstanding report any more. If that already sounds familiar, it is one of the usual causes behind outstanding not matching the ledger.
What your file needs before you import receipts from Excel to Tally
The mechanics are the ordinary ones. TallyPrime takes vouchers from outside through the Import Data option on the Gateway of Tally, and depending on your release that means a spreadsheet layout or an XML file. Every ledger the voucher names has to exist first, or the entry lands in the exceptions queue.
What matters more is the columns.
| Column | Why it has to be there |
|---|---|
| Receipt date | The voucher date. Use the value date from the bank, not the day you are entering it. |
| Party name | The ledger to credit, or the name to match against. |
| Amount | The receipt value. |
| Bank or cash ledger | Which account the money actually landed in. A single default here is how UPI collections end up in the cash book. |
| Instrument or UTR reference | Your audit trail, and often the only way to trace a disputed entry later. |
| Invoice number or numbers | The bill reference to allocate against. This is the column people leave out. |
| Amount per invoice | Needed when one payment settles several bills, or part of one. |
| Narration | Optional, but a good place to carry the raw bank description. |
Keep one row per bill allocation rather than one row per payment. A customer clearing four invoices with one transfer is four rows sharing a voucher reference, which is exactly how TallyPrime wants to see it.
When the customer does not tell you which invoice they paid
Often they do not, and this is the genuinely difficult part.
There are three workable approaches, and it is worth choosing one deliberately rather than letting each operator improvise. Allocate oldest-bill-first up to the amount received, which suits businesses with steady terms. Match on exact amount where the payment equals one open invoice, which catches most cases cleanly and leaves the rest for a human. Or hold anything ambiguous On Account intentionally, in a reviewed queue, rather than by accident.
The wrong approach is the fourth one, which is to let the import decide silently.
Where a built import is different from a converter
Free Excel-to-Tally converters generally handle the voucher and stop at the allocation, because allocation depends on the state of your books at that moment rather than on the file.
That is the piece we build at Plug & Play Computers: the receipt import reads your open bills for that party, applies the matching rule you chose, and puts anything it cannot resolve into a list for someone to look at instead of guessing. Because we support the TallyPrime licence as well, the same team adjusts the mapping when your bank changes its export format. The walkthrough above shows the flow on live data.
Checks worth running before and after
Import into a copy first. Always, and especially the first time. Receipts are harder to unpick than sales because of the allocations attached to them.
Reconcile three totals. The file total, the bank ledger movement in TallyPrime, and the reduction in total receivables. If the third does not move by the same amount as the first, allocations went astray.
Look at the On Account figure. Run the receivables report and check how much sits unallocated. A number that grows every month is the early warning.
Check the bank ledger split. Confirm that UPI, NEFT, cheque and cash rows landed in different ledgers if that is how your books are structured.
Watch for duplicates. Bank exports often overlap at the month boundary. Import the same week twice and you have double receipts against real bills, which is worse than missing them.
Frequently asked questions
Can you import receipt entries from Excel into TallyPrime?
Yes. TallyPrime accepts vouchers from an external file through its Import Data option, and receipts are one of the supported voucher types. The part that needs planning is bill-wise allocation: unless your file carries the invoice references each payment settles, the receipts import as On Account and your outstanding report stops being accurate.
What does On Account mean on a TallyPrime receipt?
It means the amount is credited to the party without being linked to any specific invoice. The party balance is right, but the original invoices stay open in the receivables report, and the credit sits separately. It is appropriate for advances, and inappropriate as a bulk default.
Do the party ledgers need to exist before importing receipts?
Yes. TallyPrime will not create a ledger implicitly from a voucher; anything missing is logged as an exception for you to resolve. Practically, that means either importing masters first, or using an import that creates missing parties deliberately, with the right group and details.
Can one imported receipt settle several invoices?
Yes, and this is the normal case for wholesale customers. Represent it as one row per invoice being settled, all carrying the same voucher reference, with the amount split across the rows.
Can bank statements be imported as receipts directly?
They can be the source, but a bank statement is not a receipt file yet. It has no party ledger and no bill reference, only a description. Turning a statement into receipts means adding a mapping from the description or the UTR to a party, which is a one-time setup that then runs monthly.
What about receipts that come in as UPI payments during billing?
That is a slightly different problem, because the receipt can be created at the moment of the sale rather than imported later. It is covered in creating the receipt automatically when a customer pays by UPI.
Working out whether it is worth it
Count your monthly receipt lines and be honest about the allocation. If you are entering under fifty receipts a month and allocating each one properly as you go, an import will not save you much.
If you are entering several hundred, or if you are entering them quickly and leaving the allocation for later, the import is worth building, and the allocation rule is worth agreeing on before anything is automated. The saving is in the entry; the value is in an outstanding report your collections team can actually work from.
If you want to see what your own collections file would produce, send us one month of it and we will run it against a copy of your company. You can also see the other TallyPrime work we do on the solutions page.