What a completed review should leave you with
A delivery recovery log naming the notice, latest failure, permitted action, retry outcome, and linked invoice or report state.
Evidence to collect
- Delivery identifier, notice type, recipient context, and current status.
- Latest provider-facing failure detail and retry or resolution time.
- Linked invoice or report state after the recovery action.
What to do when the review finds a problem
Notification history contains mixed statuses and business consequences.
Prioritize a failed delivery with an active invoice or report dependency over an informational history item.
A notice is failed or queued.
Read the latest delivery detail before retrying so the action addresses the current failure.
A recovery action is available.
Use retry, resolve, restore, or suppression only when that action is allowed for the notice state and role.
A recovery attempt has completed.
Follow the linked invoice or report and close the item only after its follow-up state changes.
A common mistake to avoid
Retrying every failed notice without checking whether the recipient, status, or linked record has changed.
How can teams recover a failed billing notice?
Filter notification history for failed or queued records, open delivery detail, use the permitted retry or resolve action, and follow the linked invoice or report. The delivery record shows whether the next step succeeded or still needs review.
Manage the work in Granite
Granite's billing notifications history connects failed or queued deliveries to permitted recovery actions.
Open dashboard ↗