What a completed review should leave you with
A pre-run blocker register listing scope, blocker owner, linked resolution path, decision, and final readiness time.
Evidence to collect
- Readiness check timestamp and organization, franchise, and period scope.
- Each blocker, severity, owner, and linked resolution path.
- Final ready or not-ready result immediately before the run decision.
What to do when the review finds a problem
A readiness check identifies a missing prerequisite.
Assign the blocker to the team that owns the linked configuration or source record.
The readiness result contains mixed severity states.
Separate a warning that can be accepted from a blocker that prevents the run.
All surfaced blockers have a disposition.
Confirm the organization, franchise, period, and destination scope before declaring the run ready.
Configuration or source data has changed.
Recheck readiness after each resolution and record the final result before approval.
A common mistake to avoid
Treating an empty or failed readiness response as proof that a billing run is ready.
How can teams check billing readiness?
Open billing readiness before processing, review each surfaced blocker, follow its linked setup path, resolve the applicable issue, and recheck the page. This creates a clear handoff from configuration work to an approved billing run.
Manage the work in Granite
Granite's billing readiness view links each surfaced blocker to the setup path that owns its resolution.
Open dashboard ↗