Skip to main content

Manual rebill

Outcome​

A denial that the engine couldn't fix gets a clean manual rebill — you identify the root cause, fix it where it lives, and rebuild + submit under a parent/child relationship.

Prerequisites​

ScopeWhat it lets you do
billing.denial.readRead the denial
billing.claim.writeReverse + rebuild
billing.charge.writeEdit charges if root-cause is a charge

When manual is the right call​

Rule of thumb: the engine is wrong is rare. Most manual rebills are the engine doesn't cover this case. If you're tempted to manually rebill on top of a SUCCESS, stop and ask why the auto-rebill is itself denying.

Steps​

  1. Open the denial. Read the CARC and any RARC. Note the original claim ID.

  2. Click Open in rebill. The platform reverses the original claim:

    • Pricing rows reverse.
    • Auth used_units releases.
    • Charges unlock to VALIDATED.
    • The claim moves to REBILLED (terminal).
  3. Identify the root cause. The CARC + RARC pair tells you most.

    PatternFix where
    Wrong modifierCharge or rule
    Missing authAttach auth (2.5)
    Wrong dxCharge edit (2.6)
    Wrong DOSCharge edit
    Wrong memberCharge edit (or void + re-build under correct member)
    Coverage staleRefresh eligibility (2.4)
  4. Make the fix. Each edit captures a reason.

  5. Re-build the claim from the same charges. The new claim's parent_claim_id points at the original. Submit per 3.1.

  6. Update the denial. The denial flips to RESOLVED once the rebill's 277CA accepts. Until then, set a follow-up date on the denial; the worklist surfaces it red if the date passes.

When the cause is upstream​

Sometimes the root cause is in the EMR (wrong code mapped, wrong DOS sent). The right move:

  1. Tag the denial with mapping-suspect or clinical-error.

  2. Hold the rebill (don't reverse yet). The denial sits at IN_PROGRESS with the tag.

  3. Coordinate: file the upstream fix; once the corrected charge re- ingests, reverse-and-rebuild.

This is slower but keeps your audit trail honest — rebuilding the same data and expecting a different result invites repeat denials.

Mass manual rebill (after a rule fix)​

After admin fixes a configuration error that produced many similar denials:

  1. Filter denials to the affected CARC + payer + date range.

  2. Bulk select, Trigger auto-correction. Many of these will succeed automatically with the new rule.

  3. For the residue (handlers don't cover this case), you can do a Bulk reverse + rebuild (with supervisor scope), but typically you walk these one at a time — it's safer.

Validation​

CheckExpected
Original claim's status is REBILLED after reverseYes.
New claim's parent_claim_id points at originalYes.
Auth used_units net-zero across reverse and rebuildYes.
Denial flips to RESOLVED after 277CA acceptsYes.

Troubleshooting​

SymptomCauseFix
Open in rebill greyedOriginal is WRITE_OFF or already REBILLEDLook at Relationships; act there.
Rebuild fails the same validationEdit didn't address root causeRe-read the CARC; fix again.
Engine ran and you manually rebilledBoth produce children — duplicate of each otherReverse the manual one (your audit row will show it was avoidable).
Rebill submitted but never acceptedNew 277CA rejected for a different reasonTriage as a new denial; the chain depth grows.

Where to next​