How to record a credit sale versus a cash sale

A cash sale and a credit sale are the same commercial event with one difference: whether payment happens at the same moment as the supply or later. That single difference changes the number of entries, the accounts involved, and what the books can tell you.

In a cash sale, supply and payment coincide. There is one moment and one entry, touching two accounts: money comes in and revenue is earned.

In a credit sale, they separate. At the point of supply the sale has been made and nothing has been paid, so the books must record revenue earned and simultaneously record that a specific customer owes you a specific amount. Later, when the customer pays, money arrives and the amount owed disappears. That is two entries, at two dates, involving three accounts in total.

The reason this matters beyond bookkeeping mechanics is that the second entry is where businesses lose track. The first entry is easy to remember because it coincides with the pleasant part of the transaction. The second happens weeks later, often via a bank credit that arrives with a name and no invoice reference, and the person entering it has to work out which sale it settles. Getting that wrong does not break any total; it simply leaves the wrong invoice marked as unpaid, which is how a business ends up chasing customers who have already paid.

For a cash sale of ten thousand rupees, ignoring tax for a moment, the entry is a debit to cash or bank of ten thousand and a credit to sales of ten thousand. An asset increases and revenue is recognised. That is the whole transaction and nothing further is outstanding.

Tax makes it slightly longer without changing the shape. If the sale is ten thousand plus tax, the amount received is the total, the revenue recognised is the taxable value, and the tax collected is a liability, because it is not yours. So the entry becomes a debit to bank for the full amount received, a credit to sales for the taxable value, and a credit to a tax payable account for the tax. Splitting the tax out at the moment of the entry is what makes the return preparable later, and recording the gross figure as revenue is a common error that overstates sales and hides a liability.

One complication deserves flagging because it looks like a cash sale and is not. Card, wallet and gateway payments are settled net: the processor deducts its charges before remitting, so the money arriving is less than the sale. The correct treatment records the full sale, the fee as an expense and the net amount received, taking the detail from the settlement report. Recording only the net understates both revenue and costs, and it makes the bank reconciliation fail in a way that is tedious to trace.

At the point of supply, the entry is a debit to accounts receivable and a credit to sales. Revenue is recognised because it has been earned by delivering, and receivable records that a specific customer owes you. Where tax applies, the tax liability generally arises at this point too rather than on collection, so it is credited to tax payable here.

This is the entry that surprises people: the sale is in your profit figure and no money has moved. That is correct under accrual accounting and it is the mechanism behind a profitable month with a falling bank balance.

When the customer pays, the entry is a debit to bank and a credit to accounts receivable. Note what this entry is not: it is not revenue. The revenue was recognised at supply. Recording it again on payment would double-count the sale, which is one of the more common errors in books kept by someone who learned on cash transactions.

Two details make this work in practice. The receivable has to be tracked per customer and per invoice, not as a single lump, because otherwise a payment cannot be matched to what it settles. And partial payments have to reduce the specific invoice rather than floating loose, since a customer paying most of an invoice and withholding a disputed balance is a common and entirely ordinary situation that a lump-sum receivable cannot represent.

The gap between the two entries is the reason a business can be profitable and short of money at the same time, and the mechanism is worth following precisely.

Revenue is recognised at the first entry. Cash arrives at the second. Between them sits the receivable, which is a number on your balance sheet and not spendable. Meanwhile the costs of making that sale, the stock and the labour, were generally paid before the sale happened. So the business funds the gap out of its own resources for as long as the gap lasts.

Now scale it. Double the sales and, if terms are unchanged, the amount held in receivables roughly doubles too. Growth therefore increases the funding requirement rather than relieving it, which is why fast-growing businesses run out of money while reporting record profits. Nothing has gone wrong; the profit is real and it is currently sitting in other people's accounts.

This is what makes the receivable a management figure rather than a bookkeeping artefact. Two questions matter about it: how large is it relative to sales, and how old is it. The first, computed as receivables divided by sales for a period and scaled to days, gives roughly how long collection takes, and a rising trend is cash arriving later. The second requires splitting the balance by age, because a single total conceals whether the money is recent or stale, and an old receivable is both less likely to be collected and more likely to need writing off.

Some credit sales are never collected, and the books have to be able to say so, otherwise receivables accumulate amounts that will never become cash and the balance sheet overstates what the business has.

There are two distinct situations. A receivable that is doubtful is one you expect may not be collected but have not given up on. A receivable that is bad is one you have decided is not collectible. The first is dealt with by a provision, which reduces the reported value without removing the invoice, and the second by writing it off, which removes it.

The mechanics are straightforward: a write-off debits bad debts expense and credits receivables, so the cost lands in the profit-and-loss statement for the period in which you accepted the loss, and the receivable disappears. Where tax was charged on the original sale there may be separate consequences, and whether and when a write-off is deductible, along with the treatment of any tax already paid, depends on provisions and on facts. That is a question for your accountant rather than an entry to make on your own judgement.

What matters from the bookkeeping side is that the decision gets made rather than avoided. A receivable ledger that has never had anything written off is not evidence of excellent collection; it is usually evidence that nobody has looked. Leaving uncollectible amounts in place inflates working capital, inflates assets, and delays the loss into a period that did not cause it.

The two-entry structure of a credit sale records, with complete precision, that a sale was made and that an amount is owed. It carries no information about whether the amount will arrive.

A receivable from a customer who has stopped answering the phone sits in the books at full value, identical in every respect to one from a customer who pays reliably on the thirtieth day. Nothing in the accounting distinguishes them. Age is a proxy and a weak one: an invoice can be sixty days old because the customer's approval process is slow and healthy, or because they have run out of money. Those look the same in a report and require opposite responses.

The entries also cannot tell you whether the sale should have been made on credit at all. That is a judgement about the customer made before the invoice was raised, and it is where most bad debt is actually created.

This is the boundary for any system handling receivables, and it is worth stating exactly because the reports look authoritative. Software can record both entries, enforce that a payment reduces a receivable rather than creating revenue twice, hold the balance per customer and per invoice, split it by age, apply partial payments, and flag an invoice that has passed its due date. All of that is real and it is most of the labour. What it cannot do is know that a customer is in trouble, decide that an amount has become uncollectible, or tell the difference between a slow approval chain and a warning. Those judgements come from people who talk to customers, and the value of the ledger is that it puts the right invoices in front of them.