How to track promises to pay in B2B collections
A customer replies to your reminder: “It's on Friday's payment run.” That sounds like progress. But if nobody writes down which invoices, how much, and which Friday, and nobody checks the bank on that day, the promise is just a delay. Two weeks later the invoice is older and you're back where you started.
To track promises to pay reliably, treat each one as a record, not a note. Capture the amount, the date, the payment method, the person who promised, and the invoices it covers. Confirm it back in writing the same day. Check for the payment on the promised date, and follow up the next business day if it hasn't arrived. Then measure how often each customer keeps their word, because that history is what makes the next promise worth anything.
What counts as a real promise to pay?
A promise to pay is a specific commitment from someone at the customer to pay a specific amount by a specific date. “We'll get to it soon” isn't one. Neither is “it's been approved,” which only tells you the invoice has cleared an internal step. If the reply is vague, your job is to turn it into something you can check.
| Field | What to capture | Why it matters |
|---|---|---|
| Invoices covered | The invoice numbers the payment will clear, not just the customer name. | A payment for two of five invoices is not the same as a payment for the account. |
| Amount | The exact amount promised, and whether it is the full balance or part of it. | Lets you tell a kept promise from a partial one. |
| Promised date | A calendar date. Turn “Friday's run” into the actual date. | This is the day you check the bank. |
| Payment method | ACH, wire, check, card, or a payment portal. | Sets when you should expect to see it and where to look. |
| Who promised | Name, role, and email of the person who made the commitment. | You follow up with the person who promised, not a general inbox. |
| Source | A link to or copy of the email, call note, or portal message. | Settles any later question about what was agreed. |
| Date recorded and owner | When the promise was logged and who on your team owns the follow-up. | Every promise needs someone responsible for checking it. |
| Status | Open, kept, partially kept, broken, or withdrawn. | Drives the next action and your metrics. |
Some systems are stricter than others about this. In SAP Collections Management, for example, each promise to pay is assigned to exactly one invoice, and the record tracks how many promises have not been kept for that invoice. Oracle Advanced Collections lets a collector record a promise for one transaction or a group of them, but not for a transaction that is in dispute. That last rule is worth borrowing: if the customer is disputing the invoice, you have a dispute to resolve, not a promise.
Where should you record promises to pay?
Record them where your team already works each account, and in one place only. If your ERP has a collections module, use its promise-to-pay feature. SAP's S/4HANA process records the promised amount and date against an open invoice and updates the promise as kept or broken based on what happens in accounts receivable. Oracle's collections product checks open promises against payments when a reconciliation program runs and creates a follow-up task for the collector when a promise is broken.
Without a promise feature, a shared tracker works if it holds the fields above and someone reviews it daily. An inbox or a free-text comment doesn't work: it can't be sorted by date, so nobody gets reminded on Friday.
How do you follow up on a promise to pay?
- Pin down the details. If the reply is vague, ask one short question: which invoices, what amount, and what date.
- Confirm it in writing the same day. Reply in the same thread and restate the promise: invoices, amount, date, and method. This gives the customer a chance to correct you and gives you a record of what was agreed.
- Log it and set the check date. Enter the promise in your ERP or tracker with an owner. Set the check for the promised date, and adjust for the payment method. A mailed check, for example, won't be in your account the day it's sent.
- Pause your other reminders. Sending an automated past-due notice two days after someone gave you a date undermines the commitment. Some systems do this for you: Dynamics 365's collections process automation skips invoices with a Promised to pay status and picks them up again if the status changes to Promise to pay broken.
- Check the bank on the promised date. Look at the bank feed or your cash application queue, not just the open invoice list. A payment can arrive without remittance and sit unapplied while the invoice still looks open.
- Close it or follow up the next business day. If the full amount arrived and matches the invoices, mark the promise kept. If not, follow up the next business day with the person who promised. Don't wait for the next scheduled reminder.
- Update the status. Mark it kept, partially kept, or broken. If the customer gives you a new date, record a new promise rather than editing the old one, so the history shows what actually happened.
What should you do when a promise is partial or broken?
Most systems give you a little room before calling a promise broken. SAP lets you set tolerance days after the promised date. If no payment arrives in that window, the promise is evaluated as broken. If part of the amount arrives, it's partially kept. Decide how much grace you allow, write it down, and apply it the same way to everyone.
| What happened | Likely cause | Next action |
|---|---|---|
| Full payment arrived on time | The promise was kept. | Mark it kept, apply the cash, and close the follow-up. |
| Payment arrived but isn't applied | No remittance, or the amount doesn't match one invoice. | Ask for remittance detail and apply it. Don't chase the customer for money they've sent. |
| Partial payment arrived | Short payment, deduction, or only some invoices were on the run. | Ask which invoices were paid and why the rest weren't. If it's a deduction, treat it as a dispute. |
| Nothing arrived, and the customer is silent | The invoice missed the run, or the promise was never real. | Follow up the next business day. If there's no reply, escalate to the next contact by your rules. |
| Nothing arrived, and the customer gives a new date | The run slipped, or approval is still pending. | Mark the first promise broken and record a new one. Ask what changed. |
| Second or third broken promise on the same invoice | Something is blocking payment that nobody has named. | Stop accepting dates alone. Ask what's holding it up: approval, PO, portal rejection, or cash. |
One missed run is usually timing. Three missed promises on the same invoice usually mean something else, such as an invoice stuck in an AP portal or a missing PO. Ask about that, not for another date.
Example: one promise, tracked from start to finish
This example is illustrative. On Monday, an AP specialist replies that invoices 1041 and 1043, totaling $18,400, are on Friday's ACH run. The collector replies in the thread the same morning: “Thanks. Just to confirm, that's $18,400 by ACH on Friday, October 16, covering invoices 1041 and 1043.” She logs the promise against both invoices and sets a check for Friday.
On Friday, an ACH payment of $12,100 arrives with remittance for invoice 1041 only. The promise is partially kept. On Monday, she asks the AP specialist about invoice 1043. The answer: it was held because the receiving team never confirmed delivery. That is now a different problem with a different owner, and a new date would not have fixed it.
What to send when a promise is missed
Keep it short and specific. Restate what was promised, say what you saw, and ask a question that is easy to answer. Here's a message you can adapt:
Subject: Invoice [number]: payment expected [date]
Hi [name], on [date] you let me know that invoice [number] for [amount] would be paid on [promised date] by [method]. I've checked, and I don't see the payment on our side yet.
Could you confirm whether it went out? If it did, a remittance or payment reference would help us find it. If it was held, could you let me know what's holding it up and when we should expect it? Thanks, [name].
Our past-due invoice email templates include a missed-promise template, along with messages for missing POs and new AP contacts.
Which promise-to-pay metrics should you track?
You don't need many. These four, reviewed monthly, show whether promises are a reliable signal on your ledger:
- Promise-kept rate: promises paid in full by the promised date (plus any grace period you allow), divided by all promises that came due in the period. Count partial payments separately rather than as kept.
- Broken promises by customer: the number of broken promises per account. A customer with several in a quarter needs a different approach, not more reminders.
- Repeat promises per invoice: how many promises one invoice collected before it was paid. More than one or two usually means a hidden blocker.
- Days from promise to payment: how long promised cash actually took to arrive. This tells you how much to trust a date when you forecast.
Compare these with your own history. Definitions vary between teams, so write down which promises you count and how much grace you allow.
How do promises to pay affect DSO and cash forecasting?
A promise doesn't lower days sales outstanding. Cash does. The AFP describes DSO as the time between a credit sale and the collection of cash from that sale, and a promise that slips simply keeps that invoice outstanding longer. Tracking promises helps indirectly: you catch missed payments a day later instead of a cycle later. To see what faster follow-up is worth on your ledger, try our DSO calculator.
Promises are also forecasting inputs. SAP's own collections documentation notes that promises to pay can help the cash team work out how much cash is due in, and track where promises are broken. A sensible approach: treat promised cash from customers with a strong kept rate as expected, and discount or push out promises from customers who often miss.
When checking every promise becomes the job
Ten promises a week fit in a tracker. A hundred across email threads and bank deposits is where the Friday check stops happening.
Alder handles this as part of collections. When a customer commits to a payment date, Alder records the promise, checks the bank feed on that day, and follows up in the original thread if the payment hasn't arrived. It escalates broken promises by your rules, and anything a customer will see waits for your approval. If promises to pay are slipping through on your team, book a demo and bring a few examples.