The promise register
How should promised payment dates be tracked? As a dated commitment.
Record every payment promise as its own dated entry: which invoices it covers, the amount, the date promised, who said it and in what role, when and where they said it, any condition attached, the date it comes back for checking, and who is checking. A promise held anywhere else is a memory with a deadline attached.
The register can be a spreadsheet. What matters is that a commitment made on a Tuesday phone call is still visible — in the same place, to whoever works the list — on the morning it falls due.
What a promise actually contains.
“We’ll sort that out this week” is not a promise. It is a sentence that sounds like one. A promise you can act on has parts, and each part earns its place by making a specific mistake impossible.
| What you record | Why it earns a column | What goes wrong without it |
|---|---|---|
| Which invoices it covers | A customer with four open invoices who promises “payment this week” has either committed to something specific or to nothing. | Money arrives and nobody can say whether the promise was kept, or which balance it settled. |
| The amount promised | Part payments are ordinary and are not failures. They only look like failures when the expectation was never written down. | A part payment reads as a broken promise, or a broken promise reads as a settled account. |
| The promised date | A promise without a date cannot be checked, so it can never be kept or broken — only forgotten. | The invoice simply ages, and the most useful fact about the account never becomes visible. |
| Who said it, and in what role | A clerk relaying a payment run and a finance director committing to one are different facts with different weight. | The next contact goes to whoever answered last time and the conversation restarts from the beginning. |
| When and where it was said | A promise on a recorded call, an email and a message in a group chat carry different levels of certainty and different levels of retrievability. | The one person who heard it is on leave, and the commitment effectively no longer exists. |
| Any condition attached | “Once the signed scope comes back” is a real and reasonable condition — and it is your side of it. | You chase a promise the customer never made, and they are right to be annoyed. |
| The check date and the owner | A commitment with nobody watching it is a note. The date is what turns it into a task that appears on its own. | Nothing surfaces on the day, and the account rejoins the general pile of things that are late. |
An unrecorded promise costs you twice.
The cost is not the promise you forget. It is that without a recorded date, every subsequent contact is timed by guesswork, and both ways of guessing are expensive.
Chase too early and you have contacted a customer who is doing exactly what they said they would do. It reads as though nobody in your business is keeping track of their own conversations, which is precisely the impression you cannot afford while asking someone to prioritise your invoice. It also devalues the next reminder, because the customer has learned that yours arrive on a timer rather than for a reason.
Chase too late and the thread has gone cold. The person who made the commitment has moved on to their next month, the context has to be rebuilt, and the request has quietly become a new one rather than a follow-through on something already agreed. Two weeks of silence after a missed date does not read as patience. It reads as permission.
There is a third cost, slower and larger. Without a record you cannot tell a customer who is habitually slow from one who is becoming unreliable, because both look identical on an ageing report. That distinction is the difference between a payment-terms conversation and a credit decision, and it only appears once promises have been tracked for long enough to form a pattern.
What a promise register should show.
The register is not a log to be read. It is a working list, and it earns its keep by producing four views without anybody assembling them.
- Due today. Every promise whose date has arrived, with the invoice, the amount and who to contact. This is the morning list.
- Passed without payment. Promises whose date went by and where nothing has been reconciled since. This is the queue that matters most, and it should be shorter than the ageing report and far more actionable.
- Open and forward-dated. What has been committed and when, so expected receipts can be read against what you have committed to pay. This is the view finance actually wants.
- Conditional and waiting on you. Promises held up by something your side owes — a credit note, a breakdown, a purchase-order number, a signed scope. These are the fastest balances in the whole ledger to unblock, and the easiest to leave sitting.
- By customer, over time. How many promises this customer has made, and how many arrived on the date given. This is the view that changes commercial decisions.
The last view is the one that repays the discipline. After two or three quarters the register stops being an operational aid and starts being evidence: a short, factual history of which customers do what they say. That is worth having in front of you at renewal, at a terms conversation, and before you take on a large piece of work.
The version you can build in a spreadsheet this week.
None of this needs new software. One sheet, one row per promise, the columns from the table above, and four habits.
- Write it while you are still on the call, or within the hour. A promise reconstructed from memory in the afternoon loses the two details that matter: the exact wording and the condition.
- Record only what was actually said. If the customer said “probably next week”, that is an intention and should be logged as one, with a check date. Recording it as a commitment to a specific date manufactures a broken promise later and makes your own register unreliable.
- Sort by check date and open it every morning. Five minutes. If the register is only opened when someone is worried about cash, it is not a register.
- Keep it next to the invoice list, not inside an inbox. Anything that lives in one person’s mail is not held by the business, and it disappears the week they are away.
The date passing without payment is where this stops being an administrative exercise. What that means, and the order of actions that follows, is a separate matter: what should happen when a customer breaks a payment promise. And when a customer responds to the check by sending a transfer receipt, that is not the end of it either — a payment screenshot is not settled cash.
A register only works if somebody owns the morning list. If nobody does, the sheet becomes a second place not to look — which is a question of who owns invoice follow-up, not of tooling.
Where At Par fits — and the limits.
At Par runs the promise register as part of ordinary receivables operations for owner-led service businesses. Every commitment lands against the invoice it belongs to, captured with its date and any condition attached, the check happens on the day rather than when someone remembers, and a promise that passes without payment is surfaced as its own event rather than absorbed into the ageing. It sits alongside bookkeeping and month-end close, so expected receipts and reconciled cash are read from the same records.
Where the wider receivables process starts and stops is set out in accounts receivable outsourcing. If your ledger already lives in QuickBooks or Xero, the file stays yours.
Asked by people building the register.
What counts as a payment promise? +
A specific commitment to pay a stated amount, on or by a stated date, made by someone at the customer with the standing to say it. "We will release it in Friday’s payment run" qualifies. "We are looking at it" does not — that is an intention, and it should be logged as one with a check date rather than recorded as a commitment. Treating a vague answer as a promise creates a broken promise that never existed.
Where should payment promises be recorded? +
Somewhere attached to the invoice and visible to more than one person — a receivables system, or a single shared sheet kept beside the open invoice list. Email threads and messaging apps are where promises are made, not where they should be held: nothing surfaces on the due date, and the record disappears when the person who heard it is on leave.
Should a verbal payment promise be confirmed in writing? +
A short factual note back is good practice and costs nothing: the amount, the date given, and any condition, in one or two lines. It is not a demand and should not read like one. It gives both sides the same version, gives the customer a chance to correct a detail, and means the commitment survives a change of contact on either side.
What should be recorded when a customer promises to pay part of an invoice? +
The amount promised and the balance left behind it, as two separate facts. Part payments are ordinary and often reflect an internal approval limit rather than a problem. Recorded properly, the payment arrives and closes the promise cleanly. Recorded as "will pay the invoice", the same event looks like a failure and the remaining balance loses its own follow-up date.
How do you track a promise that covers several invoices? +
Record one promise entry and list every invoice inside it, with the total committed. When the money arrives, it can be checked against the set rather than guessed at line by line. Where the customer has not said which invoices are included, that is worth asking at the time — the answer takes one sentence then and can take weeks to reconstruct afterwards.
Should a promised payment date replace the invoice due date? +
No. They are different facts and both should stay visible. The due date is what was agreed when the invoice was issued and does not change because a customer has given a new date. The promised date is what the customer has said will happen. Overwriting one with the other hides how far past terms an account has drifted and quietly rewrites the history.
Can accounting software track promised payment dates? +
Ledgers are built to record what has happened, not what has been said. Some receivables tools carry a promise field and a follow-up trigger; many general ledgers do not, which is why a separate register beside the invoice list remains common and perfectly workable. The requirement is not a particular product — it is that the date, the condition and the owner are held somewhere that surfaces them on the day.
How long should a promise stay open before it is checked? +
Until the date given, plus whatever clearing time the payment route genuinely needs — then it should surface on its own. Inventing a general waiting period is how accounts drift; the customer chose the date, so that date is the trigger. Where a promise is conditional on something from your side, the check date belongs to that condition, not to the payment.
Send us what your customers have promised. We’ll show you what is actually expected.
Bring your open invoice list and whatever record exists of what customers have said — a sheet, a thread, or nothing at all. We will show you what a working promise register would tell you that the ageing report does not.
Prefer to reach us directly? Tell us a little and we'll come back with a time.
Build the register with usWe use your details only to prepare for and hold this call. No spam, ever.
Reviewed by an ACCA on the At Par team · Last updated 29 July 2026 · Tracking a promise records what a customer said; it does not make the payment arrive. See what we actually do.