Payment Promise Tracking: How to Turn 'We'll Pay Thursday' Into Data
A promise to pay is the only forward-looking information in the whole receivables process, and in most finance teams it is written on a notepad and gone by Thursday. Here is how to capture it, resolve it, and use what it tells you.
On this page
Key takeaways
- A promise to pay is the only forward-looking data in receivables — everything else, including the aging report, describes the past.
- Capture four fields or it is not trackable: customer, amount, date, and who took the call. A sentence in a notes column cannot be reported on.
- Every promise must resolve — kept or broken. An unresolved promise is worse than no promise, because it looks like progress.
- A promise-kept rate per customer is the cheapest credit signal available to you, and no external data provider can sell it.
- Do not add up open promises and call it a forecast. Weight each one by the promiser's own track record, and treat a thin history as unknown rather than as good.
Ask a collections team how much cash is coming in next week and you will usually get one of two answers. Either a number from the aging report, which describes what customers were contractually supposed to do and says nothing about what they will do. Or a number from memory: "Al Fahad said Thursday, the contractor said end of month, and I think someone promised something on the Sharjah account."
The second answer is closer to the truth and completely unusable, because it exists only in one person's head. That is the gap payment promise tracking closes — and it is a bigger gap than it looks, because a promise is the single piece of genuinely predictive information the receivables process generates.
This guide covers what to capture, how to resolve a promise, what the resulting record is worth, and the mistake almost everyone makes when they first try to forecast from it.
Why a promise is different from a due date
An invoice due date is an assertion by you. A promise to pay is an assertion by the customer — and it is made after they have looked at their own cash position, their approval queue and their payment run. That makes it a materially better predictor, even from customers who break promises, because a broken promise still tells you something a due date never can.
| Signal | Who asserts it | Points | What it predicts |
|---|---|---|---|
| Invoice due date | You | Backwards | When payment was contractually required |
| Days overdue / aging bucket | Neither — it is arithmetic | Backwards | How long the failure has persisted |
| Average days to pay | Derived from history | Backwards | Typical behaviour, not this invoice |
| Promise to pay | The customer | Forwards | When this specific money is intended to move |
What to capture
The difference between a promise you can track and a note you cannot is structure. Four fields are the minimum, and the fourth is the one most often dropped.
- Which customer, at the level your ledger is organised — and if the same group trades through several branches, which branch's balance the promise refers to.
- How much. "They'll pay something this week" is not a promise; it is a mood. If the customer will not name an amount, that is itself worth recording.
- By what date. A specific date, not "next week". The date is what makes the promise resolvable.
- Who took it. Attribution serves two purposes: the follow-up survives that person's annual leave, and promise reliability becomes measurable per collector as well as per customer.
Resolving the promise: the step everyone skips
Capturing promises is the easy half. The half that produces all the value is closing them out, because an open promise with a date in the past is the worst state in the system — it looks like the account is under control while nothing is happening.
Every promise ends in exactly one of three states, and the third is a trap.
| State | Condition | What it should trigger |
|---|---|---|
| Kept | Payment landed by the promised date | Nothing — record it and move on. This is the numerator of the kept rate. |
| Broken | The date passed and the payment did not arrive | Immediate escalation, and a credit review event on the customer |
| Unresolved | Nobody checked | Nothing, which is the problem — it silently inflates your forecast |
Kept and broken are both good outcomes for the process. Unresolved is the only real failure, and it is the default state unless something is watching the date.
This is the argument for the date being monitored by a system rather than by a person. A collector with sixty accounts cannot hold sixty dates, and the promises that slip are disproportionately the ones from difficult customers — the accounts where slippage matters most.
In CollectFlows the resolution is derived rather than entered: the promised amount and date are compared against the invoice balances imported from the accounting system, so a promise resolves as kept or broken without anyone remembering to close it. That distinction matters more than it sounds — a process that depends on somebody ticking a box gets partially completed, and partially completed data is what produces a confidently wrong kept rate.
The promise-kept rate, and what to do with it
Once promises resolve, each customer accumulates a ratio: promises kept over promises resolved. It is a deceptively powerful number, for a reason that has nothing to do with collections analytics — it measures intent, and every other credit signal available to you measures capacity.
A credit report tells you whether a customer could pay. Their kept rate tells you whether they will. Those come apart constantly in practice: the well-capitalised customer who pays everyone at 90 days regardless of terms has capacity and no intent, and no bureau product will tell you that about your own relationship with them.
Uses for a kept rate, in rough order of value
- Escalating on evidence — a second broken promise is a fact, not an accusation
- Prioritising the chase list: two accounts of equal value are not equally likely to pay
- Credit reviews, as a behavioural input alongside the financial ones
- Deciding which customers can be trusted with longer terms
- Coaching: a collector whose promises mostly break may be accepting commitments too easily
- Cash forecasting — with the weighting caveat below
What a promise is actually worth: the weighting rule
The obvious next step after tracking promises is to total the open ones and treat it as a forecast. This reliably overstates cash, because it treats every promise as equally good — and the customers who make the most promises are, unsurprisingly, not the ones who pay on time.
Weighting fixes the direction of the error, but it introduces a second problem: a customer with two resolved promises has a kept rate of 0%, 50% or 100%, and none of those is information. A single late payment would swing their entire weighting. So a usable rule needs a fallback chain, and the interesting design decision is what to do when there is no evidence at all.
| Evidence available | Rate applied | Why |
|---|---|---|
| 3 or more resolved promises for this customer | Their own kept rate | Enough history to be about them rather than about luck |
| Fewer than 3 resolved promises | The portfolio-wide kept rate | Their personal sample is noise; the book's behaviour is the better estimator |
| No resolved promises anywhere yet | 100% — counted in full | With no evidence that promises get broken, a discount would be an invented number presented as a calculation |
Three is the threshold used in lib/intelligence/forecast.ts. The last row is the one worth arguing about, and the reasoning is that a conservative-looking guess is still a guess — it is more honest to count the promise in full and label the forecast as low-confidence.
Two further disciplines make the resulting number usable rather than merely defensible. Present it as a range, not a point: a conservative end counting only committed money discounted by track record, and an expected end that adds a run-rate baseline for accounts which pay reliably without ever making a promise. And label it as a model, visibly, wherever it appears — because the failure mode of a good forecast is that it gets quoted in a board pack as a fact.
Getting started without changing anything else
Promise tracking is unusually cheap to adopt, because it does not require a new process — collectors already extract promises from customers. It only requires that the promise be written down in the same shape every time.
- Add the four fields to however you currently log follow-ups. Even a spreadsheet column each for amount and date is enough to begin.
- Agree the wording collectors use on the call, so a promise is either obtained or explicitly not obtained. "When can you confirm payment, and for how much?" gets a date; "can you pay soon?" gets a mood.
- Check the promises falling due each morning. This is the single habit the whole practice depends on.
- After a quarter, compute kept rates. This is the point at which the data starts telling you things you did not already know.
- Only then start weighting a forecast. Doing it earlier produces a number built on kept rates that are still noise.
The wider workflow this sits inside — assignment, follow-up history and escalation — is covered under collections management software, and the credit side of what a kept rate feeds into under the credit control process. For where promises fit in the receivables cycle as a whole, see what accounts receivable management covers.