When a customer revises a promise-to-pay date, update the operating forecast from the new documented promise, but do not overwrite the earlier promise or its original forecast treatment. Preserve both versions, mark the reason for the change, and measure the eventual receipt against the promise that was active at each snapshot.

Oracle's promise-to-pay workflow allows a promise date to be updated. Oracle also explains that submitted promise information is recorded on the customer account and later reconciled as fulfilled or broken based on the committed date. A revised promise is therefore a change in evidence, not observed payment.

Record the change as a new evidence event

For each promise revision, preserve:

  • Invoice or transaction identifier and current open balance
  • Original promise date, amount, source, and recorded timestamp
  • Revised promise date, amount, source, and recorded timestamp
  • Who recorded the revision and why it changed
  • Forecast snapshot and week before the change
  • Forecast snapshot and week after the change
  • Next review date and eventual payment outcome

If the customer changes only the date, keep the promised amount explicit. If the amount also changes, treat the date and amount as separate fields so a partial commitment is not mistaken for the full invoice balance.

Decide which forecast changes

The live operating forecast may move the supported amount into the week containing the revised date. The frozen prior snapshot must remain unchanged for variance review. This gives management two honest views: the latest timing assumption and the evidence trail showing why the earlier expectation moved.

Use the Week 1 boundary rule before mapping either date into the horizon. A revised date after Week 4 belongs in a later state, not in the last visible week by default. A revised date without current, specific support may require an unconfirmed state rather than another precise week.

Separate revision from breakage

A date revision received before the active promise expires is different from a promise that passed without payment. Keep a clear policy for cutoffs:

| Event | Evidence state | Forecast treatment | | --- | --- | --- | | New dated revision before cutoff | Current promise | Update the operating week and preserve history | | Revision received after the snapshot cutoff | Later evidence | Apply to the next snapshot, not retroactively | | Promise date passes without payment | Broken or unresolved | Remove unsupported timing and escalate review | | Receipt is observed and applied | Actual outcome | Record cash and close or reduce the invoice once |

The broken-promise guide covers the expired state. The rolling-versus-frozen forecast guide explains why current planning and forecast measurement should not share a mutable history.

Avoid a rolling optimism loop

Repeatedly moving an invoice to a new promise date can make every weekly forecast look current while hiding chronic slippage. Track the count of revisions, days moved, promised amount changes, and actual result. Use those facts to adjust the confidence label and internal priority; do not invent a payment probability from a small history.

Decision rule

Use the newest supported promise in the current operating view, preserve every prior promise in the evidence log, and evaluate actual cash against the snapshot that was in force. The promise changes timing evidence; it does not change the accounting balance or guarantee a receipt.

AR Pulse converts an authorized QuickBooks receivables export into a ranked cash-action list and four-week collections range. It does not contact customers or promise a payment outcome. View the example report to see how source facts and timing assumptions remain separate.