Claim Scrubbing in Medical Billing: What It Catches Before Submission

Claim scrubbing is the review of a medical claim for errors before it is submitted to a payer. A scrubber, usually software built into billing software, checks coding accuracy, patient and provider information, formatting, and payer-specific rules, and flags problems while the billing team can still fix them. The claim that goes out after scrubbing is meant to be a clean claim: complete, correctly coded, and formatted the way the payer expects.

The reason this step exists is timing. An error caught before submission is a correction inside the practice. The same error caught after submission is a rejection or a denial, and both cost the practice follow-up work, a resubmission or an appeal, and time spent waiting for payment that could have gone out clean the first time. Scrubbing does not make billing error free. It moves the point where errors get found from after submission to before it, when they take the least rework to fix.

For where this step sits in the wider billing cycle, see how medical billing works. The rest of this post covers what a scrubber actually checks, what happens to a flagged claim, how scrubber edits differ from clearinghouse and payer edits, and the limits of what scrubbing can catch.

Where scrubbing sits in the workflow

Scrubbing happens after the claim is built and before it leaves the practice or billing company. In order, the sequence runs roughly like this: patient visit, documentation, charge capture, coding, claim creation, scrubbing, clearinghouse transmission, payer adjudication, payment posting. Scrubbing is the checkpoint between claim creation and transmission.

That position matters because of what the scrubber can see. By the time a claim reaches scrubbing, the encounter has been documented and coded and the claim has been assembled from that work. The scrubber reads the claim itself: the codes, the identifiers, the dates, the charges, the payer information. It does not read the clinical note behind the claim, and that limit shapes what it can and cannot catch, as covered below.

Many practices do not send claims directly to payers. They route them through a medical billing clearinghouse, which standardizes, validates, and transmits claims in the standard electronic format, usually the X12 837 transaction. That creates a second layer of checking, because the clearinghouse runs its own edits on top of whatever the billing software already ran. The two layers are related but they are not the same job, and confusing them is a common source of false confidence.

What a scrubber checks

A scrubber runs a claim through layers of rules. The exact rule set varies by vendor, specialty, and payer mix, but the layers below cover what a competent scrubber checks.

Structure and formatting

The first layer is structural. Required fields must be present, identifiers must be formatted correctly, and dates must be valid and internally consistent. A claim with a missing field, an end date that precedes its start date, or a charge total that does not match its line items will fail here. These are the simplest errors and also the easiest to prevent, because they need no clinical judgment to spot, only a complete claim form.

For electronic submission, this layer also covers the format itself. The claim has to be structured correctly for conversion into the standard electronic transaction, with the right segments in the right order and field lengths the payer system accepts. A claim that is clinically correct but structurally malformed still cannot be processed.

Patient and provider information

The second layer checks the people and identifiers on the claim. Patient demographics must match what the payer has on file: name, date of birth, member ID, and group number, where the payer requires them. Provider information must be present and valid: the rendering provider and the billing entity, with the National Provider Identifier (NPI) for each, and taxonomy and tax ID where the payer requires them. A mismatch here, such as a transposed digit in a member ID or a billing NPI where a rendering NPI belongs, will stall a claim even when the coding is right.

This layer overlaps with eligibility work. A claim built on the wrong payer, an inactive plan, or a member ID that does not match the payer record is a claim headed for trouble, and a scrubber that checks identifiers and coverage details can catch some of that before submission. For the front end check itself, see insurance eligibility verification. Scrubbing is not a substitute for that check, because the scrubber works from the claim as built, and if the claim was built on bad eligibility data, the scrubber may have nothing to compare it against.

Coding logic

The third layer is the coding layer, and scrubbers differ the most here. It checks that the codes on the claim are valid, current, and consistent with each other:

• Diagnosis codes (ICD-10) that are valid for the date of service and specific enough for the payer's requirements.
• Procedure codes (CPT/HCPCS) that are current, not deleted or replaced in the current code year, and appropriate for the place of service and provider type.
• Diagnosis and procedure pairings that make sense together, so the diagnosis supports the procedure billed. A procedure with no supporting diagnosis, or a diagnosis that does not justify the procedure, is a medical necessity problem waiting to happen.
• Modifiers that are present where required and appropriate for the code they modify, and absent where they would change the meaning of a code incorrectly.
• Code combinations that follow bundling rules, including the National Correct Coding Initiative (NCCI) edits that CMS publishes to prevent billing inappropriate code combinations. Billing separately for procedures that belong under one comprehensive code is an unbundling error, and a scrubber with NCCI edits will flag it.
• Units, age and gender conflicts, and place of service consistency, such as a procedure code that conflicts with the patient's age or a place of service code that does not match where the service happened.
• Duplicate claims, where the same service for the same patient on the same date appears twice.

Coding errors are also the layer where a scrubber's limits show most clearly. The scrubber checks whether the codes are consistent with each other and with the payer's rules. It cannot check whether the codes match the documentation, because it reads the claim, not the note. A code that is valid, well paired, and correctly modified can still be wrong for the visit if the documentation does not support it. That gap is what coding audits are for, and it is covered in medical coding audits.

Payer-specific rules

The fourth layer is payer-specific, and it is the layer that separates a generic scrubber from a useful one. Each payer has its own requirements: which modifiers it wants, what authorization or referral reference it expects on the claim, what place of service rules it applies, what frequency limits it enforces, and what field formats its system requires. A claim that passes generic edits can still fail a payer-specific edit, because the generic rule set never knew about that payer's rule.

Payer-specific rules also change. Payers update coverage policies and submission requirements on their own schedules, and a rule that was correct last quarter may be out of date this quarter. That is why a scrubber is not a set-and-forget tool. Its rule set needs regular review, and a direct source for new rules is the practice's own experience: recurring rejections and denials point directly at rules the scrubber should have caught.

What happens to a flagged claim

A scrubber does not usually fix errors on its own. It flags them, and the claim goes back to a work queue for a person to correct. The typical loop looks like this:

1. The scrubber runs and returns a list of flagged claims, each with the edit or edits it failed.
2. A biller or coder reviews each flag, decides whether it is a real error or a false flag, and corrects the claim where needed. Some flags need a coding correction, some need a demographic fix, and some need information from the practice, such as an authorization number that was never entered.
3. The corrected claim runs through the scrubber again. Only claims that pass, or whose flags have been reviewed and cleared with a reason, move on to the clearinghouse.
4. Claims that cannot be corrected, because the information is missing or the coding question needs a clinician, stay in the queue with a note about what is needed, rather than going out with a known error.

Two habits make this loop work. The first is clearing flags the same day they appear, while the encounter is still fresh and the information is still easy to get. A flagged claim left in a queue goes stale: staff forget the context, the patient record moves on, and timely filing pressure builds. The second is tracking which flags repeat. A single flag is a task. The same flag on claim after claim is a workflow problem upstream, at charge entry, coding, or intake, and fixing it there saves more time than clearing each instance by hand.

Scrubber edits, clearinghouse edits, and payer edits are three gates

These three terms get used as if they were one check, and that causes real mistakes. They are three gates, run by different parties, at different points, and passing one says nothing about the next.

The key point is the last column. Clearinghouse acceptance means the claim was accepted for transmission to the payer. It does not mean the payer will pay it. The payer's own edits, applied during adjudication, are the only ones that decide payment, and they include coverage policy and medical necessity judgments that no pre-submission check can fully replicate. A claim can pass the scrubber, pass the clearinghouse, and still be denied, and that is not a sign the scrubber failed. It is a sign the scrubber's job ends where the payer's judgment begins.

After the payer receives a claim, it sends back electronic acknowledgments. The X12 999 acknowledgment confirms the file was received and structurally valid. The X12 277CA acknowledgment reports acceptance or rejection at the individual claim level. A clean 999 followed by a 277CA showing accepted claims means the claims passed the payer's front end edits and entered adjudication. It is still not a payment decision.

Rejections and denials are different problems

Because scrubbing sits before submission, it mostly prevents rejections, and it prevents some denials. The distinction matters for what happens next.

A rejection happens before adjudication. The claim never entered the payer's payment decision process, usually because of a formatting or data problem, and it can be corrected and resubmitted without an appeal. Many rejections are exactly the problems a scrubber is built to catch: a missing field, a mismatched identifier, an invalid code.

A denial happens after adjudication. The payer considered the claim and refused to pay a line, with a reason code explaining why, and fixing it usually means a corrected claim or an appeal. Scrubbing prevents the denials whose cause is visible on the claim form, such as a missing modifier or a diagnosis that does not support the procedure. It cannot prevent denials whose cause is not on the claim form, such as a coverage policy the scrubber did not encode or documentation that does not support the code billed. For the denial side in full, see claim denials in medical billing: common causes and fixes and common claim denial codes.

Manual scrubbing versus automated scrubbing

Scrubbing can be done by hand or by software, and the tradeoff is the usual one between judgment and scale.

Manual scrubbing means a trained biller reviews each claim against a checklist of coding, demographic, and payer rules. It works at low volume, and a good reviewer catches context the software misses, such as a claim that looks right but contradicts something the reviewer knows about the patient or the payer. Its limits are speed and consistency: a person cannot run a scrubber's full rule set on every claim by hand, and two reviewers will not apply the same checklist the same way every time.

Automated scrubbing runs the same rule set on every claim, and flags the same error the same way each time it appears. Its limits are the rule set itself. An automated scrubber only knows the rules it was given, and a rule it lacks is an error it will not flag. That is why pairing the two is the setup to use: automated scrubbing first, for volume and consistency, and human review on the flagged items, where judgment decides whether a flag is a real error and what the fix should be.

Some vendors describe scrubbing tools with automation or AI features that learn from denial patterns. The useful question to ask about any such tool is not how it is labeled but what it actually does: which rule sets it carries, how often those rules are updated, whether payer-specific rules can be added from the practice's own denial history, and how flagged claims are routed for review. A tool that cannot take a new rule from a recurring denial will keep missing the same error.

What scrubbing cannot catch

A clear view of the limits keeps expectations honest, and it points to the work that still needs doing elsewhere in the revenue cycle.

Scrubbing cannot see documentation. It reads the claim, not the note, so it cannot tell whether the documented service supports the code billed, whether the note justifies the level of service, or whether a required element of the visit is missing from the record. Those are coding accuracy and documentation questions, and they belong to coding review and audit, not to pre-submission edits.

Scrubbing cannot know a payer policy it was never given. Coverage policies, local coverage determinations, and payer-specific medical necessity rules change, and a scrubber whose rule set has not been updated will pass claims the payer will deny. When a clean claim denies on policy grounds, the fix is to learn the policy and add the rule, not to blame the scrubber for missing a rule it never had.

Scrubbing cannot fix front end data it was never given. If eligibility was never verified, if the authorization number was never entered, or if the intake record has the wrong payer, the scrubber can flag the gap only if it has something to check against. Garbage in at intake becomes a flagged claim at scrubbing at best, and a clean-looking claim built on bad data at worst.

Scrubbing cannot guarantee payment. Even a claim that passes every pre-submission check, every clearinghouse edit, and the payer's front end edits still faces adjudication, where coverage, medical necessity, contract terms, and benefit limits decide the outcome. Scrubbing raises the share of claims that reach adjudication in good shape. It does not decide adjudication.

How practices improve scrubbing over time

A scrubber gets better the same way any quality check gets better: by learning from what it missed. The pattern that works is straightforward, and it needs no new technology, only discipline.

Log recurring flags and recurring denials together. When the same edit fires repeatedly, or the same denial reason comes back on claims that passed scrubbing, that is a rule waiting to be written or a workflow waiting to be fixed. Trace it to its source: a charge entry habit, a coding choice, a field that intake leaves blank, or a payer rule the team knows about but has not encoded.

Fix the source, not just the instance. Clearing a flag on one claim helps that claim. Fixing the charge entry habit, adding the payer rule to the scrubber, or changing the intake form so the field gets captured helps every claim that follows. Treating a repeat flag as a workflow ticket, not just a task to clear, is what turns scrubbing from a daily chore into a rule set that improves.

Review the rule set on a schedule. Payer rules change, code sets update annually, and the practice's payer mix and denial patterns shift. A quarterly review of the scrubber's rules against recent rejections and denials, with outdated rules removed and new ones added, keeps the tool current. Without that review, the scrubber slowly drifts away from what payers actually require, and clean claims start denying for reasons the tool used to catch.

Keep the human in the loop where judgment matters. Automated flags still need a person to decide the fix, especially for coding questions and payer-specific edge cases. A queue where flags are reviewed promptly, with the reason for each clearance noted, builds the record that makes the next review easier: the team can see which flags were real errors, which were false flags, and which rules need tuning.

Where this fits, and what to read next

When scrubbing does its job, the claims that reach the clearinghouse are complete, consistently coded, and formatted for the payer they are going to. When a claim still comes back, the next step is understanding whether it was rejected before adjudication or denied after it, and what fixes it. For firms that handle revenue cycle work, including claim preparation and denial follow up, see our revenue cycle outsourcing services. For denial follow up specifically, see our denial management services. Our methodology explains how directory listings are vetted, including the services and scope firms claim.