Cheques, bank transfers and the money you have not been paid yet
A closed bill is not collected money. How to record a post-dated cheque or a transfer that has not cleared, why marking it paid corrupts your books, and what a due-date list is actually for.
A corporate customer takes eighty covers for a staff party, signs for the lot, and hands you a cheque dated the end of next month. A supplier delivers and agrees to wait thirty days. In both cases something has definitely happened, and in neither case has any money moved.
Most restaurant systems handle this badly, and they handle it badly in the same way: they offer you paid or unpaid, and neither is true.
Why “paid” is the wrong word
If you close that party bill as paid in cash, three things break at once.
Your takings for the day now include eighty covers of money that is not in the drawer, so the shift will not reconcile and whoever counts the till will spend twenty minutes hunting a discrepancy that does not exist.
Your revenue is right — the party did happen, the food did leave the kitchen — but your cash position is wrong, and cash position is the number that decides whether you can pay staff on Friday.
And when the cheque bounces, you have no record that says what to chase, who signed it, or which bill it was meant to settle.
Marking it unpaid is no better: the bill is settled as far as the guest is concerned, and leaving it open will have somebody chasing a customer who already paid.
The honest answer is a third state. The bill is closed, the revenue is booked, and the money is owed on a date.
What a deferred instrument actually records
Whatever the system calls it, a usable record has to carry these things:
| Field | Why it matters |
|---|---|
| Type | A cheque today; a bank transfer or a promissory note tomorrow |
| Direction | Whether you hold it or issued it |
| Number | The cheque number, which is what the bank will ask for |
| Bank | Which bank it is drawn on |
| Party | The customer or supplier, by name |
| Amount and currency | Both, because a group may take foreign currency |
| Issue date | When you accepted it |
| Due date | When it can be presented — the field the whole feature exists for |
| Status | Pending, cleared or bounced |
| Branch | Or none at all, for a head-office instrument |
| Notes | Where the awkward context goes |
The one people leave out is branch, and it matters more than it looks. A cheque taken at one location is that location’s receivable, and its manager should see it. A cheque covering a group contract belongs to nobody in particular and should sit at head office, visible to all of them and counted against none.
Direction: receivable and payable
Two things get called “a cheque in the system” and they are opposites.
A receivable is a cheque you are holding, written by a customer. It is an asset, it is your risk, and if it bounces you are chasing somebody.
A payable is a cheque you wrote to a supplier. It is a liability, it is their asset, and what you owe on it is a date you must not miss — the supplier who does not get paid on the day agreed is the supplier who stops delivering in the middle of a service.
Keeping both in one list with a direction on each is what lets you ask the only question that matters: on any given week, what comes in and what goes out?
Three states, and the one that justifies them
Pending is where an instrument starts. Then one of two things happens.
Cleared means the bank honoured it and the money is actually yours. This is the moment the cash moves, not the day you accepted the cheque, and it should be recorded with a timestamp and the person who confirmed it — so that “who marked this cleared?” has an answer six months later.
Bounced is the whole reason the feature exists. A returned cheque is not just money that did not arrive: it is a bill that is once again unpaid, a customer relationship that needs a conversation, and often a bank charge of its own. A system that only knows paid and unpaid has nowhere to put any of that.
Both should be irreversible-by-default and reversible-by-manager, because both get pressed by mistake.
The due-date list is the point
Everything above is bookkeeping. This is the part that is actually useful on a Tuesday.
Sorted by due date, the instrument list answers questions nobody can answer from a ledger:
- What is due to clear this week, and is it enough to cover the payroll run?
- Which customer has two cheques pending and is asking for a third party booking?
- Is anything overdue that nobody has chased?
- How much of this month’s “revenue” is still a promise?
That last one is the honest version of a question owners ask constantly. A strong month on paper that is forty percent cheques is a strong month you cannot spend yet, and knowing the difference is most of cash-flow management in a business with thin margins.
Practical rules that save arguments
Never accept a cheque without recording it the same day. The one in the drawer that nobody entered is the one that bounces.
Photograph it. The number and the bank are usually enough, but a picture settles a dispute about a date or a signature instantly.
Give it a due date, not a vague month. “End of the month” is not a date and cannot be sorted.
Reconcile it against the bank, not against hope. An instrument is cleared when the bank says so, not when the due date passes.
Keep post-dated cheques out of the day’s takings, always. If your reports cannot separate collected money from promised money, they are not reports — they are optimism with a header row.
The short version
A closed bill and collected money are different facts, and a system that only has one word for both will misstate your cash every time somebody pays by cheque. Record the instrument, give it a direction and a due date, let it clear or bounce on its own evidence, and read the list by date. It is not sophisticated accounting. It is just refusing to count money you do not have yet.
Run all of this from one system
POS, kitchen, inventory, recipe costing, staff and accounting — connected, and free to start.
Create your free account