Promised Dates and the Ones That Slip

Start with what a promise record has to hold. It needs the invoice it refers to, the date somebody committed to, the person who took the commitment, and the moment the commitment was made. It also needs to survive being wrong. A promise record that can only be created when it is true is not a promise record; it is a payment record with extra steps. The whole value of the record is that it can be created for a future date and then be wrong.

Notice what this separates from. It is not the same as the invoice, which is a claim that does not change because somebody intends to pay it. It is not the same as a payment, which is money that arrived, and which in this system is its own record with its own amount, method, received-at time, and an idempotency key so a retried submission cannot create a second receipt. It is not the same as the allocation, which is the link that applies part of a payment to part of an invoice. We model the invoice, the payment, the allocation, and the resulting state as four different things, and that separation is what lets a promise sit alongside an invoice without corrupting it.

The derived state is where the discipline shows. Paid is not a column on the invoice. It is recomputed from the sum of allocations, which is why an invoice that is fully allocated reads as paid and an invoice with a promise recorded against it reads as exactly as unpaid as it was before the phone call. A promise does not move money. It moves a date on your calendar, and the only honest thing a system can do with it is make sure that date is written down where the next person will see it before it passes.

The 18% GST figure used in the worked examples below appears only to keep the arithmetic checkable so you can verify the totals by hand. It is not a statement about the rate that applies to your business, and nothing in this article is tax advice. Confirm your rate, your place of supply, and your invoice treatment with your own chartered accountant.

A slip does not just move one invoice. It consumes attention, and attention is the only collection resource a small business has. Every missed promise triggers a conversation, and every conversation has to be had by somebody who also has work to deliver. The cost is not the amount of the invoice; the cost is the hours, and the fact that those hours come out of delivery rather than out of collection.

Here is a constructed count. Take a month in which fourteen payment promises were recorded across fourteen invoices. Nine were kept. Five were missed. For those five, the slip was this many days past the promised date: 6, 9, 14, 21, and 4. Added together: 6 plus 9 is 15, plus 14 is 29, plus 21 is 50, plus 4 is 54. Divided by the five promises that slipped, that is 54 divided by 5, which is 10.8 days. These are constructed figures for this article, not measurements of anything. The point is not the average. The point is that 54 days of deferral produced zero rupees, and it produced five conversations that somebody had to have.

Now put a number on what the deferral is worth when you are the one waiting. Invoice I-118, constructed: taxable value 40,000, GST at 18 percent used only so the total is checkable, which is 40,000 multiplied by 0.18, giving 7,200. Total on the invoice: 40,000 plus 7,200, which is 47,200. A promise was recorded for 12 September. The payment arrived on 3 October. Days past the promise: from 12 September to 30 September is 18 days, plus 3 more days into October, which is 21 days past what somebody had committed to.

Same invoice, now against a supplier. The business was waiting on that 47,200 to settle a supplier bill dated 5 October for 47,200. If the money had arrived on the promised 12 September, the bill was covered. The promise that slipped to 24 October — the fourth on this invoice, which we come to below — landed 19 days after the supplier bill fell due. Check it: from 5 October to 24 October is 19 days. That 19 days is the actual cost of the slip. It was not the value of the invoice, which eventually arrived intact. It was the 19 days of a supplier relationship that now has a question in it, and the four conversations that produced the 24 October date.

Every business has a collection priority order. Almost none of them have written it down, which means the order is actually determined by whoever happens to open the report first and by how annoyed they are that morning. An unwritten order produces two failures. It produces chasing that stops the moment the day gets busy, because there is no rule that says what must be done today. And it produces the wrong order on the days it does happen, because a large invoice that is nine days past a promise and a live relationship looks less urgent than a small invoice that is twenty-one days past a promise from a customer who has not ordered in a year, and the second one is very often the smaller problem.

Write the rule down. Four clauses, in this order, and no more. One: rank by whether the relationship is still live, meaning whether there is current work or an open quote. Two: within live relationships, rank by how many times the promise has already slipped, not by how many days it is late. Three: within that, rank by the outstanding amount. Four: customers with no current work go into a separate list with a different, slower cadence, because the goal with them is a decision, not a payment.

Here is what that rule does to a constructed set of three customers. Customer A: one invoice outstanding, total 47,200 as worked above, promise held once and not missed, no current project, 3 days past the promise. Customer B: three invoices outstanding, 47,200 each, which is 141,600, promise missed once, a current project with a quoted value of 94,400, 2 days past the promise. Customer C: one invoice outstanding, 47,200, promise missed twice, no current project, 21 days past the promise.

A mood picks C first, because 21 days looks like a crisis. The written rule picks B first, because B has a live relationship and one miss rather than two, and B is 2 days past. The rule picks C second, because two misses is the trigger for a phone call regardless of the amount. It picks A third, because A kept the only promise they made and has nothing else from you, so the right move is one message and no escalation. The rule is not more correct than instinct in every case. It is correct in the same case every time, which is the only property that makes a priority order worth having.

Three promises slip and the customer is embarrassed. The fourth one is different, and the difference is not about them. The first promise is a plan. The second is a setback. The third is a pattern the customer is now aware of, and the fourth converts that awareness into a belief about you, specifically the belief that your dates are not real. That belief does not stay on this invoice. It moves onto the next quote, where it shows up as a request for payment in advance, and onto the retainer conversation, where it becomes the argument for a discount.

The arithmetic of the fourth promise, constructed. One invoice, four promises recorded: 12 September, 26 September, 10 October, 24 October. The spacing is identical each time, which is what a person does when they are embarrassed and picking a round number. Check the spacing: 26 September minus 12 September is 14 days. 10 October minus 26 September is 4 days to the end of September plus 10 days, which is 14. 24 October minus 10 October is 14. Every gap is the same. Total deferral across the four promises: from 12 September to 24 October, which is 19 days to 1 October and then 23 more days to the 24th, so 42 days.

Forty-two days of deferral on a 47,200 invoice, and the money eventually arrived in full. The invoice was never the problem. What changed over 42 days is that you stopped being a supplier whose dates mean something, and became a supplier whose dates have to be negotiated. That is a permanent change to the terms, and it is invisible on every report you own, because reports measure invoices and not the belief a customer now holds about your invoices.

There is a second thing the fourth promise destroys, which is the ability to write off a bad debt cleanly later. If the fourth promise is followed by silence, you have no new information: you do not know whether they cannot pay, will not pay, or have stopped replying. The promise was supposed to be the information. Each new promise replaces a hard answer with a soft one, and a soft answer is not worth less than a hard one for the rest of the chase, it is worth more, because a hard one lets you decide and a soft one only lets you wait.

A system cannot make a promise keep. It can only make a missed one visible, and that is a much smaller claim than the marketing around collections software usually implies. Any product that tells you it will chase your invoices for you is describing a feature this system does not have and does not plan to imply.

So be clear about the four things that do not exist here. There is no dunning sequence: no escalating ladder of reminders that fires on day seven, day fourteen and day thirty without a person deciding anything. There is no automated escalation: nothing raises an invoice to a manager, a director or an external party by itself. There is no card on file and there is no auto-debit: we do not hold a stored instrument and pull money from it. Each of those is a real product decision with real consequences, and each of them takes a decision away from a person who ought to keep it. A dunning sequence that fires at a customer who has a good reason and a human who would have known that is worse than no reminder at all.

What exists instead is narrower. A payment promise is a record: invoice, date, person, moment. It sits in a queue with an owner, so the overdue work is visible as work rather than as a feeling. The Today surface is built for exactly this shape of problem, role-scoped queues of things that are overdue and assigned, rather than a report you have to remember to open. And there is no rule engine behind it either — no trigger, condition, action to configure — so the reminder is a decision somebody has made and written down, not a habit baked into somebody else's product.

The consequence is that the chase is a person's job, and it has to be somebody's job on a named day. That is a less pleasant product story than automatic escalation, and it is the honest one. What the record gives you is that the job is short: you are not reconstructing what was promised from memory, you are reading a row that says what was promised and whether it held.