A promise to pay is a record with an expiry, not a note in a CRM
In short
A promise to pay is a customer's dated commitment to pay a stated amount against named invoices. It only works as a record — amount, date, invoices, channel, evidence, state — because free text has no expiry: nothing fires when the date passes, reminders keep going to someone who already committed, and kept rate cannot be measured.
Key takeaways
- 6 fields: amount, date, invoices covered, channel, evidence, state. Fewer, and it cannot expire on its own.
- Part-kept is a real fifth state. Two-state designs record a customer who paid 80% as having broken their word.
- A live promise suppresses the chase but never the statement, a record of position rather than a demand.
- It may only turn broken after unapplied cash has been searched for the promised amount in the window.
A promise to pay is a customer's dated commitment to pay a stated amount against named invoices. As an object it carries 6 fields and 5 states, and the follow-up runs off it without anyone remembering anything. As a line in a call note it is a memory aid, and the system behaves as though the call never happened.
The tell is familiar. A collector agrees a date on Tuesday, logs it, and on Thursday the automated reminder goes out anyway. The customer, who committed 48 hours earlier, now has proof nobody at your end reads anything. The commitment was never stored where the reminder logic could see it.
Six fields, and what fails when each is missing
| Field | What breaks without it |
|---|---|
| Amount promised | A part payment cannot be judged, so every shortfall lands as a break |
| Promised date, plus explicit grace | Nothing expires; it stays open until a human closes it |
| Invoices covered | Cash arrives, matches nothing in particular, the promise ages anyway |
| Channel and who captured it | No way to compare an agent's promises with a person's |
| Evidence: call reference, message id, submission id | A disputed commitment is one person's word against another's |
| State, timestamped at every move | No kept rate, and no next action derivable from the last outcome |
Invoices covered is the field teams skip and then regret. A customer promising 4 invoices out of 11 has said something precise about the other 7 — queried, waiting on a purchase order reference, or with another approver. No list throws that away.
Five states, and the one recorded as a broken word
- Open. Captured, still in the future, suppressing outreach until date plus grace elapses.
- Kept. Cash applied to the covered invoices, at or above the amount, inside the window.
- Part-kept. Applied but short, or late beyond grace. A distinct outcome, counted as one.
- Broken. Date plus grace passed, nothing applied, and the receipt search below already ran empty.
- Superseded. A later promise replaces it; the original keeps its own outcome rather than being edited into the new figure.
Kept and broken alone is the common design, and it is wrong in one specific way: a customer who promised a large sum and paid most of it 3 days late looks identical to one who paid nothing and never called back. The follow-up chosen is then wrong in both directions.
A live promise is a suppression rule with a deadline
- The chase pauses until date plus grace. That rule stops Thursday's email undoing Tuesday's call; the addressing faults behind reminder emails nobody answers are separate and still need fixing.
- Worklist position drops. A live promise means the account is not actionable today.
- The escalation clock restarts on the outcome. A broken promise is a stronger trigger than another week of aging.
- The statement still goes. It is a record of position, not a demand, and withholding it leaves the payer's accounts team without the document they reconcile against.
A commitment that cannot switch off an automated message is not a promise your system knows about.
Money arrived, nobody could name it, and the promise expired
The most damaging false break has nothing to do with the customer. They paid on the day they said. The receipt landed as a round sum covering several invoices, no remittance detail, and sat in suspense while the promise aged out. The collector then opens an escalation call chasing money you hold.
So: a promise may only turn broken after a receipt search on the promised amount across the promised window, unapplied and on-account balances included. That is the same subset logic as a lump sum with no remittance advice, and if the matching cascade behind cash application exists, a known payer, amount, window and invoice list is the easiest problem you will hand it.
Direct debit promises need the same care in reverse. A collection taken and later returned is not kept, and the state should follow the return reason rather than the initial credit — a technical return is a retry, a cancelled instruction is a different conversation. Telling those apart is what payment return codes and what they oblige you to do covers; store the code beside the outcome.
Kept rate, weighted by money, and what it may decide
| Measure | What it should be allowed to change |
|---|---|
| Capture rate: contacts ending in a recorded promise | Call structure. A low rate means calls end without anyone asking |
| Kept rate, value-weighted, part-kept at cash applied | Whether this customer's promise suppresses outreach at all |
| Median days from promised date to applied cash | The grace period, reviewed rather than guessed |
| Consecutive promises with no cash between | Routing. Three in a row is an escalation, not a cadence |
Weight by value or the number misleads: 19 small promises kept and 1 large one broken is a 95% count-based kept rate and a bad month. How accounts get ordered once promises exist is answered elsewhere in the receivables and cash application topic. Making the object behave across a real ledger is scope we take under MVP and product builds for finance operations teams.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is the difference between a promise to pay and a payment plan?
A promise to pay is one dated commitment; a payment plan is an ordered set of them. The difference that matters is break behaviour: missing one instalment usually carries consequences agreed in advance for the whole plan, while a standalone promise breaking affects only itself. Model the plan as a parent record holding individual promises.
Should a partial payment against a promise count as kept or broken?
Neither — record it as part-kept, at the amount actually applied. Forcing it into kept overstates performance and buries the shortfall; forcing it into broken tells a customer who paid most of what they owed that you treat them as a defaulter. Only a third state keeps the next action proportionate.
Can a voice or email agent record a promise to pay on its own?
Yes, if it captures an amount, a date and an invoice list and confirms all three back in the same interaction. The risk is not an agent taking a promise; it is an agent taking a vague one — an agreement to pay soon, with no figure, that suppresses outreach without committing anyone. Require all three before the record can be written.
- collections
- receivables
- promise to pay
- workflow design
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- One payment, forty invoices, no remittance adviceA bank credit that matches no invoice total is rarely a mystery. It is a payer you have not resolved and a subset of open items nobody has enumerated — and when 2 subsets fit, the correct answer is to apply neither.diagnostic
- Your reminder emails are read by nobody: where the sequence actually breaksBefore rewriting the copy, prove the message reached a human who is allowed to act on it. Most silent dunning sequences are failing at the address, the queue or the missing reference — not at the wording.diagnostic
- Payments arrive short by small amounts and break every auto-matchChronic small shortfalls have 4 causes with 4 different owners, and the shape of the delta tells you which one you have long before anyone picks up the phone.diagnostic
- Unapplied cash: money you have, against invoices you cannot nameMoney in the bank that no open item has been matched to. The balance is not an accounting curiosity — it overstates aging, misdirects collections, and hides disputes inside a number nobody owns.definition
- Decline reason codes: what to record at the moment of the decisionA reason recomputed from today's data is not the reason the applicant received. Bureau values, balances and documents move, so the reason belongs in the same transaction as the decision.definition
- First-payment default is an origination defect, not a collections eventA borrower who never makes payment one is rarely a credit decision that aged badly. The instrument was never lodged, the date was wrong, the payment went unattributed, or the income was never there.definition
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation