The vendor payment ledger: knowing what you owe before the supplier tells you
Ask most shop owners what they owe their suppliers and the answer is a rough number from memory. Ask which invoices are overdue and the answer is usually whichever supplier called last. The data to answer properly is already in the purchase records.
What is missing is the structure that ages it, and that structure is a ledger built invoice by invoice.
On this page
Age by invoice, never by supplier
A running balance per supplier tells you the total and nothing else. Two shops owing the same supplier eighty thousand rupees can be in completely different positions.
One owes it on four recent invoices, all within terms. The other owes it on eleven invoices, three of them four months old. The total is identical and the situations are not.
So the ledger has to hold each invoice as its own line, with its own date and its own due date. Everything useful follows from that.
The columns a vendor payment ledger needs
Five columns carry the weight. More than that is usually somebody’s reporting preference rather than a working requirement.
The goods receipt reference is the one that prevents the expensive mistake. An invoice with no matching receipt is a bill for goods nobody can confirm arrived.
Credit days belong on the supplier record, with an override where a particular order was agreed differently. Typing a due date by hand on each invoice guarantees inconsistency.
Three ways to read the same position
A payables position is not one number. Three readings describe it, and the differences between them tell you what kind of problem you have.
A large total with almost nothing overdue is a business using its credit terms properly. A small total that is mostly overdue is a cash problem dressed up as a small number.
The third reading is the operational one. What has to be paid in the next seven days decides what you can spend this week, and it is the only one most owners actually need daily.
Paying the same bill twice
Duplicate payment is quiet, common and almost never detected by the shop that makes it. It happens when the same invoice enters the system twice, or when a payment is made against a statement rather than an invoice.
| How it happens | What it looks like | The control |
|---|---|---|
| Invoice entered twice | Two identical lines, same number | Block duplicate invoice numbers |
| Paid against a statement | Payment matches no single invoice | Pay invoices, never statements |
| Advance then full payment | Advance never applied | Link advances to the invoice |
| Debit note ignored | Full amount paid despite a claim | Apply notes before payment |
| Two people paying | Same bill, two tenders | One approver per supplier |
The simplest control is the first one. A system that refuses a second invoice carrying the same number from the same supplier removes most of the risk at no cost.
Three-way matching, in a shop-sized version
Large companies match the purchase order, the goods receipt and the invoice before paying. A shop can do the same thing in a lighter form.
- What you ordered, even if the order was a phone call written down
- What actually arrived, recorded at the gate on the day
- What was billed, entered from the invoice itself
- Any debit note raised against that invoice
- What has already been paid against it
Where all five agree, pay. Where they do not, the ledger shows exactly which of them disagrees, and the conversation with the supplier takes two minutes rather than an afternoon.
Paying in the right order
When cash is tight, shops pay whoever shouts loudest. That is understandable and it is also how a shop loses its best credit terms.
Pay the suppliers whose terms you need most, first and on time. The one who supplies your fastest-moving stock is worth more than the one whose invoice is oldest.
Keep a note against each supplier of what the relationship is worth. A ledger that shows only money misses the reason some invoices matter more than others, and the back office is where that note belongs.
Building it from what you already have
- Enter every purchase invoice as its own line, with its number and date
- Attach the goods receipt reference at entry, not later
- Set credit days on the supplier, with per-order overrides where needed
- Apply debit notes to the invoice before any payment is made
- Run the ageing weekly, and the due-this-week list every working day
A vendor payment ledger built this way takes an hour to set up and a few minutes a day to maintain. In exchange, the question of what you owe stops being a matter of memory, and your purchase records finally agree with your bank.
Frequently asked questions
Why age payables by invoice rather than by supplier?
Because a running balance tells you the total and nothing else. Eighty thousand rupees owed on four recent invoices within terms is a different situation from the same sum spread across eleven invoices, three of them four months old.
What columns does a payables ledger actually need?
The invoice number and date, the goods receipt reference, the agreed credit days, any debit notes applied, and a single status of paid, part paid or open. The receipt reference is what stops you paying for goods nobody can confirm arrived.
How do shops end up paying the same bill twice?
An invoice entered twice, a payment made against a statement rather than an invoice, an advance never applied, a debit note ignored, or two people paying the same bill. Blocking duplicate invoice numbers from the same supplier removes most of the risk.
What is three-way matching for a small shop?
Check what was ordered, what arrived, and what was billed, plus any debit note and anything already paid. Where all five agree, pay. Where they do not, the ledger shows which one disagrees, so the supplier call takes two minutes.
Which suppliers should be paid first when cash is tight?
The ones whose terms you most need, not the ones who shout loudest. The supplier of your fastest-moving stock is usually worth more than the one holding your oldest invoice, so keep a note of what each relationship is worth.
Sources, method and author
A working payables procedure rather than an accounting treatment. It covers ageing by invoice, the five-column minimum, duplicate-payment controls and a shop-sized version of three-way matching. Each is standard practice compressed to what one business can maintain in a few minutes a day. The three readings are a way of looking at one dataset, not three separate reports. It is not accounting advice.
- Investopedia on accounts payable — the general structure of what a shop owes
- CBIC GST — input credit matching, which depends on invoice-level records
- Reserve Bank of India — payment and settlement context for supplier transfers
Clotouch is a point of sale product built by Clonet Technologies Pvt Ltd. The procedure works in any system that records purchases at invoice level, including ours. It is not accounting or tax advice.
Author. Aman Raj. Published 26 October 2026 for Clonet Technologies Pvt Ltd, Bengaluru.
