Force-retry & overrides

Outcome

You understand which safety rails the platform installs around denial work, when to override them, and how the audit trail captures the override.

Prerequisites

Scope	What it lets you do
billing.auto-correction.run	Trigger handlers
billing.auto-correction.override	Force-retry past idempotency
billing.receivable.override	Force-match low-confidence pairings
billing.denial.write	State changes including reopen
audit.read	Review all overrides

Most overrides are supervisor-grade; many tenants gate the override scopes behind dual-control approval.

The rails the platform installs

Each rail catches a real failure mode. Overriding is appropriate but expensive — your audit row says you knew.

Force-retry on auto-correction

When to force-retry:

Reason	Example
Prior SUCCESS's rebill itself denied	Rare; usually traces to bad data on the rebill.
Engine ran with a stale rule	Rule has since been corrected; want fresh attempt.
Engine SKIPPED for a stale reason	Auth was attached after; retry now finds it.

When NOT to:

Anti-pattern	Why
"Maybe the engine will work this time"	It won't; same inputs → same outputs.
To suppress an annoying denial	The denial is signal; suppress is the wrong move.

Force-match on receivables

When the matcher's score is wrong (legitimate match below threshold):

Scenario	Move
Numbers off by < 1% (rounding)	Force-match.
Member ID changed mid-flight	Force-match.
Payer split a multi-line claim	Match each line individually; force only where partial-control collides.

The force-match audit row carries MATCHED_FORCED, your name, your reason. Reporting flags MATCHED_FORCED rates by user and payer.

Reopening a written-off denial

When new evidence (or a payer 835) reverses a prior write-off:

1. Open the denial. Click Reopen. Reason required.

2. Confirm. The platform:

   • Reverses the WRITEOFF payment_application.
   • Returns the claim balance.
   • Sets the denial back to OPEN (or RESOLVED if a reversing 835 is the trigger).

Manual flip — last resort

The platform allows billing.denial.write to manually flip statuses (e.g. OPEN → RESOLVED) without an action that causes the flip. Reasons:

Use case	When
Out-of-band resolution	Phone call, paper EOB resolved without 835.
Stale denial due to reversed payment	Old data lingers despite payment reversal.
Migration cleanup	Tenant data import created stale state.

The manual flip writes a prominent audit row with reason. Supervisors should periodically review these.

Override of the COB ladder

The MSP / Medicaid-last-resort logic occasionally produces an unwanted order (e.g. an unusual payer relationship). To override:

1. Open the member's COB tab (Tenant Manual → Members & PHI → COB & dual eligibility).

2. Click Override priority. Set the new ordering with reason.

3. Save. The override flag stays until removed; future COB-driven secondary builds respect it.

Validation

Check	Expected
Every override writes an audit row	Yes.
Reason is required and non-empty	Yes.
Supervisor approval gates fire where configured	Yes.
Reporting widgets surface override rates	Yes.

Troubleshooting

Symptom	Cause	Fix
Override button missing	Scope gate or tenant config	Ask supervisor / admin.
Audit row missing details	Tenant audit config trimmed fields	Audit log has the canonical row; adjust the visible columns.
Manual flip didn't take	State-machine guard refused	The transition isn't allowed from current status; check 9.2 — Status reference.
Override approvals stuck	Supervisor's queue is unattended	Escalate; supervisor scope is required to clear.

Where to next

• 9.2 — Status reference — what transitions are allowed from where.
• 6.5 — Follow-up cadence — managing the work the safety rails surface.