Choose the symptom you can observe
Open the matching case. Check the existing state before changing a record or repeating an action.
The run fails before creating the expected invoices.
Check first
- Read the run's exact error and compare it with the prepared preview and readiness result.
- Check whether a required rule, destination, source period, or assignment changed after approval.
- Confirm the run scope and reporting context are still valid for the current period.
Next action
Hold a second submission, correct the named prerequisite, and create a new preview or run only through the approved recovery path. Preserve the failed run and its error so the retry does not erase the original evidence.
Confirm the result
The recovery run references the corrected prerequisite and its result clearly separates created, deferred, and failed records.
Some records complete while others remain deferred or failed.
Check first
- Compare each outcome group with the preview's eligible, deferred, and blocked rows.
- Open the row-level errors and identify whether they share a rule, source, or destination cause.
- Check that completed invoices are not included in the proposed recovery scope.
Next action
Leave completed records unchanged, route each failed or deferred group to its actual owner, and prepare a narrowly scoped recovery after the cause is resolved. Do not rerun the entire original scope by default.
Confirm the result
The recovery record lists only unresolved rows and links each completed, deferred, or failed outcome to the original run.
The team is about to submit the same run twice.
Check first
- Search for an existing run with the same rule, scope, period, and preview identifier.
- Check whether the first run is queued, processing, completed, or awaiting a provider response.
- Compare the prepared preview timestamp with the run that was already submitted.
Next action
Pause the second submission and follow the existing run's status until its outcome is known. If recovery is needed, use a new scope or explicitly approved retry that excludes records already created.
Confirm the result
One run is designated as the original attempt, and any recovery scope excludes completed records and names its relationship to that attempt.
The run says complete, but invoices or notices remain in an earlier state.
Check first
- Compare the run completion time with the latest invoice and notification record times.
- Check whether completion refers to submitting work or to every downstream record being delivered.
- Open a representative invoice and notice to identify the remaining state transition.
Next action
Treat the run as operationally incomplete until its downstream states are understood, then route the remaining transition to the invoice or delivery owner. Do not declare the business process complete from the run header alone.
Confirm the result
The run note links its completion state to the resulting invoice and notification states, including any remaining follow-up owner.
Prepare a useful escalation
- Include the run identifier, preview identifier, scope, period, approval time, status, row-level errors, and resulting records.
- Keep completed records out of any recovery request unless the owner explicitly explains why.
- Ask the processing owner to approve a new scope or retry after the original run is understood.
Reference the relevant record instead of copying credentials or unrelated personal information into the handoff.