
A customer settles fifty thousand rupees. Ten in cash across the counter, fifteen by UPI, and a cheque for the balance. One conversation, one payment, one moment.
In a lot of offices that becomes three receipt vouchers. One for the cash, one for the UPI, one for the cheque, each with its own trip through the bill-wise allocation screen, each allocated against the same set of invoices, and each numbered separately.
It works. The ledger is right. It is also three times the keystrokes, and it leaves a record that nobody looking at it in six months will be able to reassemble into the single payment it actually was.
What three separate receipts cost you
The obvious cost is time, and it is not trivial. Every receipt voucher is a party selection, an amount, a ledger, and then the allocation screen where open bills have to be picked. Doing that three times for one payment, forty times a day, is most of an afternoon.
The less obvious cost is traceability. Split across three vouchers, the payment is no longer visible as one event. If the customer later disputes the amount, or if the cheque bounces, the person investigating has to find three entries that are related only by date and party.
Then there is the allocation arithmetic. Fifty thousand against four open invoices is one decision. The same thing done as three receipts means splitting each invoice across three vouchers, or arbitrarily assigning whole invoices to whichever mode happens to fit. Neither reflects what the customer did, and the second quietly makes your ageing report wrong.
TallyPrime can already split a receipt across ledgers
This is worth being clear about, because a lot of pages selling add-ons for this skip it.
A receipt voucher in TallyPrime is an ordinary double-entry voucher. You credit the party, and you can debit more than one ledger in the same voucher. Cash, the bank account the UPI settles into, and the bank account the cheque is deposited to can all appear as separate debit lines on one receipt, with the total matching what the customer paid.
TallyPrime also supports multi-mode payment on POS invoices for exactly this reason, where a single sale is settled partly in cash and partly by card or wallet.
So the capability is there. The reason offices still pass three vouchers is usually one of two things: nobody showed the operators that a receipt can carry multiple debit lines, or the entry is slow enough in practice that three simple vouchers feel faster than one complicated one.
The first is a training fix and costs nothing. The second is the real problem.
Where one-click receipt entry in TallyPrime saves real time
The saving is not in the concept of a split receipt. It is in the number of screens between the operator and a saved voucher.
In a plain multi-ledger receipt, the operator picks the party, then works down the ledger lines one at a time, then handles the bill-wise allocation, then checks the total. If the customer changes their mind about the split halfway through, the ledger lines have to be edited and the allocation revisited.
What a one-click receipt entry setup does is collapse that into a single screen: the amounts against each mode, the invoices being settled, and the total, all visible together, entered once, saved once. The voucher that comes out the other side is the same ordinary TallyPrime receipt. What changes is how many times somebody has to press Enter to produce it.
That matters most where the split is common rather than occasional. A wholesaler collecting from route salesmen, a showroom taking part-cash part-card, a distributor whose customers pay half by NEFT and settle the rest in cash, all deal with this several times a day.
Setting it up so the books stay clean
Whether you use the built-in split or a faster entry screen, three things decide whether the result is useful.
A distinct ledger per mode. Cash, each bank account, and each digital collection channel need to be separate. If UPI and cheque both post to one generic bank ledger, the split you just recorded tells you nothing and reconciliation is no easier than before.
Allocation against the actual bills. The point of a single receipt is one allocation decision, made properly. If the entry saves time by defaulting everything to On Account, it has traded three correct vouchers for one wrong one.
A shared reference on the voucher. Whatever ties the payment together, a collection slip number or the customer’s own reference, should be on the entry. That is what makes the event reconstructable later.
Fitting that to how a specific counter or collection desk works is the sort of TDL work we do at Plug & Play Computers, and it is usually a small job because it is shaping an existing voucher rather than inventing a new one. The video above shows a single-screen cash, UPI and bank receipt being entered on a live company.
Mistakes worth avoiding
A single catch-all bank ledger. The most common one, and it undoes the whole benefit.
Rounding the split to make it fit. If the cash counted does not match, that is a real difference and it needs to be visible, not absorbed into the UPI line.
Post-dated cheques treated as received. A cheque in hand is not money in the bank. How your books treat the gap between receiving and clearing should be a deliberate choice, not an accident of which ledger the operator picked.
Leaving the allocation for later. The allocation is easiest at the moment of entry, when the customer is standing there and can tell you which bills they are clearing. Later, nobody knows. This is one of the routine causes behind outstanding not matching the ledger.
Frequently asked questions
Can one receipt voucher in TallyPrime include cash, UPI and bank together?
Yes. A receipt voucher can debit several ledgers in a single entry, so cash, the bank account a UPI payment settles into, and the bank the cheque is deposited to can all appear as separate lines on one receipt, credited to the same party. TallyPrime also offers multi-mode payment on POS invoices for the same situation at the point of sale.
Is a split receipt better than separate vouchers?
For a single payment made in several modes, yes. It reflects what actually happened, it needs one bill-wise allocation instead of several, and it keeps the event traceable. Separate vouchers are appropriate when the payments genuinely arrived at different times.
Does a multi-mode receipt affect bank reconciliation?
Only helpfully, provided each mode has its own ledger. The cheque line reconciles when the cheque clears, the UPI line when the settlement lands, and the cash line does not touch the bank at all. Posting them all to one ledger is what makes reconciliation hard.
How should the bill-wise allocation work on a split receipt?
Allocate the total against the invoices the customer is settling, not each mode separately. The customer paid fifty thousand against four bills; how that fifty thousand was tendered is a separate fact, recorded on the debit side.
Can this be combined with creating the receipt from the sales invoice?
Yes, and the two fit together naturally at a counter. Creating the receipt at the moment of billing is covered in auto receipt entry for UPI payments.
What if the receipt data comes from a spreadsheet instead?
Then it is an import problem rather than an entry problem, and the same allocation rules apply. See importing receipt entries from Excel.
Whether to change anything
Start by checking whether your team knows that a receipt can carry several debit lines. If they do not, that alone may be the fix, and it costs a conversation.
If they do know and still pass separate vouchers, the entry is too slow, and that is worth measuring rather than guessing at. Count how many payments in a typical week arrive in more than one mode. If it is a handful, leave it. If it is most of them, the operators have already told you where the friction is by working around it.
If you want a second pair of eyes on how your receipts are currently being entered, we are happy to look at it with you on a screen share. The other TallyPrime work we do is on the solutions page.