Claim Scrubbing in Medical Billing: What Scrubbers Catch, and What They Miss

Direct answer: Claim scrubbing is the automated process of reviewing a medical claim for errors before it is submitted to a payer. A claim scrubber runs the claim through validation rules and flags errors: it checks coding accuracy, patient demographics, modifier usage, and payer-specific rules so the claim is clean, complete, and ready to be paid on first submission. Scrubbing detects errors; editing fixes them. Think of the scrubber as a spell-checker for claims, not a coverage expert: it confirms fields are filled, formats are valid, and codes exist, but it never reads the clinical note, so it cannot catch a documentation gap that makes the level of service unsupported. A clean scrubbed claim still needs a human eye and a coverage check before it leaves the practice.

WHAT A CLAIM SCRUBBER CATCHES

A scrubber checks the claim against a library of validation rules, and the errors it catches fall into a few clear groups. First, coding errors: CPT and ICD pairing mismatches where the diagnosis does not support the procedure, unbundling errors where services that should be billed together are split apart, and upcoding or undercoding where the code does not match the service. Second, modifier errors: a missing or incorrect modifier, such as an office visit billed at 99213 without modifier 25 when a separate evaluation and management service was provided, telehealth claims missing modifier -95 or -GT, or a bilateral procedure missing modifier -50. Third, demographic and identity errors: a wrong date of birth or policy number, a name that does not match the payer's file, or a missing or invalid NPI. Fourth, place-of-service errors: the wrong place of service, such as POS 11 for an office visit when the service was telehealth and should be POS 02 or POS 10. Fifth, authorization and limit errors: a missing prior authorization reference number, services billed beyond a unit limit, and duplicate claims for the same service. Sixth, filing and formatting errors: timely filing alerts, typically a 90 to 180 day window depending on the payer, payer-specific rules, and X12 837 formatting errors that would stop the claim from being accepted at all. Every one of these is a defect in the claim form itself, and that is exactly what a scrubber is built to see.

WHAT THE SCRUBBER CANNOT SEE

This is the lead point, and the part most practices miss: a scrubber confirms fields are filled, formats are valid, and codes exist, but it does not test the CPT and ICD combination against a payer's coverage policy, it does not track each plan's rules as they change, and it cannot see a documentation gap because it reads the claim form, not the note. A diagnosis and procedure pair can be a valid combination in general and still be uncovered for that payer, that plan, or that patient, and the scrubber will pass it without a word. A payer can change a coverage rule, a prior authorization requirement, or a medical necessity policy, and the scrubber's rule set will not know until someone updates it. And because the scrubber never sees the clinical note, it cannot tell whether the documentation supports the level of service billed: a visit coded at a higher level with a thin note passes the scrub and can still be denied, or audited, after payment. A claim that passes the scrub is not a claim that will be paid; it is a claim with no form errors. Treating a clean scrub as a clean bill is the mistake that turns pre-submission prevention into post-payment denials.

THE FOUR-LAYER FIX

One layer is not enough, because each layer catches what the one before it cannot. Layer one is the automated scrub: run every claim through the scrubber before submission, and clear every flag, not just the errors, because warnings that are routinely ignored become the denials that are routinely worked. Layer two is a human scrub on high-volume codes: a person reviews a sample, or all claims, for the codes the practice bills most, checking the diagnosis and procedure pairing and the modifier against what was actually done. Layer three is coverage lookups on flagged combinations: when a code pair is unusual, new, or has been denied before, look up the payer's coverage policy for that combination before submitting, rather than trusting the scrubber's silence. Layer four is a denial-pattern log feeding charge entry: track which errors keep coming back as denials, and feed that pattern back to the people entering charges, so the same mistake stops being entered in the first place. The scrubber is layer one; the other three layers are what make it work.

CLAIM SCRUBBING VS DENIAL MANAGEMENT

Scrubbing and denial management are two halves of the same loop, and they sit on opposite sides of submission. Claim scrubbing is pre-submission prevention: it catches errors before the claim reaches the payer, so the claim never becomes a denial. Denial management is the weekly routine for working denials after they happen: reading the remittance, finding the root cause, correcting or appealing, and tracking the pattern. A practice that only scrubs will still get denials, because of the coverage and documentation gaps the scrubber cannot see; a practice that only works denials will keep getting the same ones, because nothing is stopping the errors at the front door. The two work together when the denial log feeds the scrub: every denial that traces back to a preventable entry error should become a new scrub rule, a new charge-entry check, or a new coverage lookup, so the next claim does not repeat it.

WORKED EXAMPLE

An illustrative example, not a real claim. A practice bills an office visit at 99213 with a separate minor procedure on the same day, and the claim passes the automated scrub with no flags. The biller notices during the human scrub that the visit was billed without modifier 25, even though a separate evaluation and management service was provided alongside the procedure, and adds the modifier before submission. The same week, a different claim passes the scrub cleanly but the human reviewer flags the diagnosis and procedure combination and looks up the payer's coverage policy, which shows that combination is not covered for that plan; the claim is held and the documentation is reviewed rather than submitted to be denied. The first claim was saved by the human layer catching a modifier the scrubber's rules did not flag; the second was saved by the coverage lookup catching something no scrubber can see.

PREVENTION CHECKLIST

FREQUENTLY ASKED QUESTIONS

A note on codes and coverage: This article is educational information about billing and claim validation, not legal or compliance advice. Coding rules, coverage policies, and filing limits vary by payer, plan, and state, so always verify them against the payer's guidance and the specific remittance before acting.

Related reading: Claim Denial Management Workflow · How to Reduce Claim Denials · Common Medical Coding Errors · Timely Filing Limit in Medical Billing · Claim Denial Codes: Complete Guide

Part of the complete guide: Claim Denial Codes: The Complete Guide for Medical Billing — every code in this article, explained in one place.