A scheduled retry after a failed SaaS invoice payment is useful timing evidence, but it is not collected cash and it is not a customer promise. Keep the invoice open, record the failed attempt, and treat the next retry date as a system event whose forecast confidence depends on the failure type and the current payment method.
Stripe's Smart Retries documentation distinguishes attempted retries, scheduled retry dates, and hard declines that cannot execute successfully without a new payment method. Its automatic-collection guidance also shows that retry behavior varies by collection method and account configuration.
Use a status matrix instead of one retry flag
| Invoice evidence | What is known | Four-week treatment | | --- | --- | --- | | Payment failed; no next attempt | A receipt did not occur | Keep open and leave timing unassigned | | Next retry scheduled; retryable failure | A system attempt is planned | Consider the date with an explicit system-evidence label | | Hard decline; old payment method unchanged | The scheduled sequence cannot produce a charge | Do not assign cash from the retry date | | New payment method observed | The blocker may have changed | Reassess before assigning timing | | Payment succeeded and settled | Cash evidence exists | Remove the supported settled amount from future collections |
The distinction matters because a dashboard can display `next_payment_attempt` even when the previous failure requires customer action. A date in the billing system is not automatically a forecastable receipt.
Separate invoice state from subscription state
A subscription can become past due, unpaid, canceled, or paused according to configured recovery rules. The issued invoice still needs its own open amount, payment-attempt history, and cash treatment. Do not infer that a subscription status closed or collected the invoice.
The uncollectible-invoice guide covers the boundary when finance marks an invoice outside ordinary collection expectations. The auto-advance-disabled workflow addresses invoices that never entered the configured collection path.
If a previously paid invoice becomes open because its payment was detached, use the reopened-invoice event bridge before relying on retry timing. Detachment, reversal, refund, and failed retry are different events.
Record the retry evidence
For each failed invoice, preserve invoice identifier, open amount, collection method, last attempt time, attempt count, failure class, next attempt time if present, whether a new payment method was observed, owner, and next review date. If billing automation changes which event carries the next-attempt field, keep the source event name and retrieval time in the review record.
Do not convert a generic retry policy into a claimed collection probability. A team can use retry timing as one input while keeping the expected receipt range conservative and reviewable.
Reconcile the successful attempt
When a retry succeeds, verify the payment applies to the intended invoice and distinguish processor success from bank availability. The pending-payment guide keeps authorized or processing states separate from collected cash. The scheduled-payment framework shows how to carry a system date without presenting it as certainty.
Decision rule
Use a scheduled retry as labeled system evidence only when the failure remains retryable and the payment path is active. Withhold expected cash for hard declines or missing payment-method fixes, and count a receipt only after the supported payment state is observed.
AR Pulse analyzes an authorized receivables export for small B2B SaaS finance teams with invoiced contracts. It does not run retries, change subscriptions, or promise that an invoice will be paid. Apply for an AR Pulse review when retry states need to be separated from the cash forecast.