A Cheque We Only Understand Going Out
In several Gulf markets a customer settles an invoice by handing you a cheque dated six weeks out. The invoice is closed as far as they are concerned, the money is not yours yet, and our receivables model has no state for that.
Receivables software almost universally models an invoice as having two interesting states: owed, and paid. Everything else — aging buckets, credit holds, collection reminders, the cash-flow forecast — is derived from which side of that line a document sits on. It is a clean model and it is a reasonable one in markets where payment means a transfer that either has or has not happened.
It breaks in markets where a substantial share of business-to-business settlement happens by cheque written for a future date. The customer hands over paper. In their mind, and frequently in the commercial relationship, the invoice is settled — they have paid you, and they will be annoyed to receive a reminder. In your bank account nothing has occurred and nothing will occur for weeks. And the paper itself may or may not clear when its date arrives.
The finding, stated plainly, and narrower than it first appears
There is no cheque instrument anywhere in our schema — no cheque number, no cheque date, no drawee bank, no clearing state — in either direction. What exists going out is the word: "cheque" is one of the payment-method labels on a vendor payment. A label on a completed payment is not cheque handling, so this is not a case of supporting one direction and not the other. We support neither, and going out we merely name it.
Three states, not two
A post-dated cheque puts a receivable into a state that has to be tracked separately from both of the states we model, because it behaves like neither.
What each party believes, on the same invoice, on the same day
Read the last row of that table as an operational problem rather than a modelling one. Marking it paid corrupts the thing receivables software exists to protect — the correspondence between the ledger and the bank. Leaving it outstanding produces aging buckets full of invoices nobody intends to pay again, credit holds triggered on customers who are current, and dunning letters to people holding your receipt. Both failures are visible to the customer, which is the worst place for an accounting compromise to surface.
And the paper has its own life
What makes this a genuine instrument rather than a timing annotation is that the cheque is an object with attributes and a history that the invoice does not have and cannot carry.
- It has an identity. A cheque number, a drawee bank, an amount and a date on its face. Those are how it is discussed on the phone and how it is found again when something goes wrong.
- It is physically somewhere. In a drawer, at the bank, presented, returned. Where the paper is at any moment is a real question with operational consequences and no field to answer it.
- It can be replaced. A customer who knows the funds will not be there asks you to hold it and hands over a new one with a later date. That is a routine conversation, and it means a receivable can be covered by a succession of cheques over months.
- It can bounce. Then the invoice was never settled, the customer's standing has changed materially, and both facts need to be true in the record at once — which requires having known the cheque existed in the first place.
- It may not be one to one. One cheque can cover several invoices; several cheques can settle one. A single payment-reference field on an invoice cannot express either.
That last point is what rules out the tempting shortcut. It is easy to imagine adding a couple of fields to an invoice — a cheque number and an expected date — and calling the gap closed. It would work for the simplest case and fail immediately on a cheque covering four invoices, on a replaced cheque, and on any attempt to answer "what paper are we holding, and when does it turn into money?" — which is the actual question a finance team in this position asks every week.
The general version, which is not about cheques
Whenever settlement is a process rather than an event, a two-state model of payment will fail. The same shape appears in letters of credit, in escrow, in instalment plans on delivered goods, in card settlement that lands days after authorisation, and in any transfer that clears in batches. If money can be committed, identified and dated but not yet yours, that is a third state and something has to hold it.
Why we are publishing a gap instead of a feature
Because the alternative is that somebody discovers it in week three of a rollout, having chosen us partly on the strength of a receivables module that does genuinely work well for transfer-settled and card-settled business.
It is also a piece of work rather than a patch, and saying so is more honest than a roadmap date. Doing it properly means an instrument that exists in its own right, that can be linked to more than one invoice and be superseded by a replacement, that carries a state through presentation and clearance or dishonour, that contributes to a cash-flow view without contributing to the paid balance, and that does all of this on the money-out side too — because a business writing post-dated cheques to its own suppliers has the mirror-image problem and today gets only a label for it.
What we will not do is add a cheque-number field to an invoice, ship it, and describe the gap as addressed. That produces a product that appears to handle the instrument until the first replacement cheque, and appearing to handle it is worse than the current honest silence.
The question to ask anybody, including us
A demonstration will not surface this, because demonstrations settle invoices with a transfer. If post-dated cheques are a meaningful part of how you get paid, these four questions separate real support from a field.
- "Show me an invoice the customer considers settled where the money has not arrived." Ask to see the aging report and the cash-flow view at the same moment. Those two screens disagreeing correctly is the whole feature.
- "One cheque, four invoices — where does it live?" If the answer is a reference typed on each invoice, there is no instrument, only a note.
- "The customer asks you to hold it and sends a replacement. What happens to the first one?" Replacement is the routine case, not the exception, and it is the fastest way to find out whether a cheque is an object or a text field.
- "It bounces. What changes?" The invoice reverts, and the customer's credit standing should have changed. Ask whether the second half happens by itself.
Our answers today are no, nowhere, nothing, and nothing — because the instrument does not exist to have answers about. If your settlement is bank transfer, card or cash, the payments and collections module does what it says and the aging and credit-hold work is real. If a meaningful share of your collections is paper dated into the future, you would be holding that information outside AWRA for now, and you should know that before signing rather than after.
One thing this finding is not is a currency problem, and the two get confused because both surface in the same report. The Total That Added Dollars To Shillings is about a receivable whose amount is expressed in a unit the total ignored. This one is about a receivable whose amount is fine and whose timing and certainty have nowhere to live. A report can be wrong about what a figure is worth, or wrong about whether it is money yet, and those need separate fixes.
