Promise to pay dates that collectors trust
How to set grace days, promise horizons and tolerance for promise to pay dates, and how broken promises reach a named collector for follow-up.
Make promise to pay dates trustworthy by setting three rules before a collector records the first one: how many grace or tolerance days pass before a promise counts as broken, how far out a promise date may be set, and who follows up when a promise breaks. Then let a scheduled job flag broken promises into a work queue, not a spreadsheet. This rests on the Oracle Advanced Collections User Guide, Implementing Receivables Credit to Cash, Setting Up Promise Date Options for a Customer and PeopleSoft Order to Cash Common Information.
Why is promised cash hard to trust?
A customer on the phone says the check goes out Friday. The collector types it into a comment field or a shared spreadsheet. Nobody has decided when Friday becomes late, so the promise stays in the cash forecast until someone notices. Across a large ledger of open items, the expected-cash line then means little.
The documentation describes a stricter record. The Oracle Advanced Collections User Guide says you record the customer’s promise to pay specific amounts at specific times, for a single transaction or a group of transactions. In PeopleSoft Receivables, Setting Up Promise Date Options for a Customer states that once a conversation is marked as a promise of payment, the collections analyst must enter a promise date and the amount to save it. A saved promise conversation cannot be reverted to a regular conversation.
What happens after a promise is recorded?
The Oracle Advanced Collections User Guide says the product tracks the expected payment automatically, and tells you to run the IEX: Promise Reconciliation concurrent program daily. When payment is made, the promise status changes from Collectible to Closed. When it is not, the status changes to Broken when that program runs, and Advanced Collections adds a broken promise task on the Task node of the Collector’s Work Queue. The optional callback program needs to run every day after reconciliation. If a callback date passes without that run, the callback will not be created. This means a broken flag is only as current as the last job run.
Which promises count, and when do they break?
The Oracle Advanced Collections User Guide also says you cannot enter a promise if all or part of a transaction is in dispute. For Oracle Fusion Advanced Collections, Implementing Receivables Credit to Cash lists a number of grace days before a promise is broken, and a maximum number of days to make a promise, which controls the latest due date a collector can set.
In PeopleSoft Receivables, Setting Up Promise Date Options for a Customer describes Tolerance Days, a Payment Tolerance percentage you are willing to deduct from the promised amount and a Broken Promise Action. These apply to a setid, or a setid with a customer or customer group, and each can allow a user override. PeopleSoft Order to Cash Common Information says an override needs an override reason, and that a history of status changes is not collected or reported, including manual overrides from Broken to Kept. If Broken can become Kept without history, the approval has to live somewhere else.
Who sets the rules, and who may override them?
The decision is how much discretion collectors keep over promise dates and broken status.
| Option | We would choose it when | What we would check first |
|---|---|---|
| One default set, no overrides | Customers pay in similar patterns | How often promises slip by a day or two |
| Defaults by customer group, overrides allowed | Large retailers and small accounts pay differently | Who approves an override and where the reason is kept |
| Collector sets each promise freely | Promise volume is low and one team owns it | Whether the forecast should include these promises at all |
The underlying design question, one owner and one record per status, is not unique to finance. Project teams face it with revisions, as in capturing changes as one record per change and tool features versus a connected project record.
What to do this quarter
- Pull every open promise and check that each has a date, an amount and named transactions.
- Set grace or tolerance days and a maximum promise horizon, and write down why.
- Name one owner for broken promise follow-up per customer group.
- Confirm the reconciliation and callback jobs run daily, and alert someone when a run is missed.
- Measure kept, broken and open promises per customer each month, and log every override with its approver.
What this means for a bottleneck worth $1M or more
If promised cash drives credit holds, forecasts and working capital decisions across business units, promise handling is worth redesigning together with deductions and cash application as one domain. Rules handle the predictable: grace days, horizons, daily reconciliation runs. AI reads the messy part, such as remittance emails and call notes that hint at a promise. People approve overrides and write-offs, and AI never decides alone. See how we approach customer-to-cash as one domain.
Limits of this evidence
These documents describe configuration and behavior in Oracle Advanced Collections, Oracle Fusion Advanced Collections and PeopleSoft Receivables. They do not show how often promises break, or whether any setting changes collection results. They give no benchmark for grace or tolerance days. Implementing Receivables Credit to Cash lists the preferences but does not describe how a broken promise is surfaced to a collector. Other ERP products are not covered.
Questions buyers ask
Can a collector record a promise to pay on a disputed invoice?
The Oracle Advanced Collections User Guide says you cannot enter a promise if all or part of a transaction is in dispute. We would work the dispute first, then take the promise on the undisputed transactions.
What is the difference between grace days and tolerance days?
In Oracle Fusion Advanced Collections, grace days are the extra days allowed after the promised payment date before the system considers a promise broken. In PeopleSoft Receivables, Tolerance Days are the days past the promise to pay date you are willing to wait before taking further action, set for a setid, customer or customer group.
Does PeopleSoft keep a history of promise status overrides?
PeopleSoft Order to Cash Common Information states that a history of status changes is not collected or reported, including manual overrides from Broken to Kept. If overrides matter for your forecast, keep the approval and reason in a separate log.
Sources
Sources give context. Dates show when each was last checked.