A four-provider cardiology practice showed us their denial report for the first quarter: 31 denials from one commercial payer for echocardiograms billed without a prior authorization number, at roughly $180 each. Every one of those claims had passed through their claim scrubber. When we asked what rules the scrubber was running, the practice manager said "whatever came with the system." The vendor's default edits checked the NPI format, the diagnosis pointer and the date of service. Not one of them knew that this payer requires authorization for CPT 93306.
The opposite failure is just as common. A primary care group we audited had 412 active claim scrubber rules, most of them added by a biller who left in 2023. Sixty-eight rules fired on a typical day. The billing team had learned to click through them in bulk, so the rules that mattered were buried under the ones that did not. Their clean claim rate was no better than the cardiology practice's.
A claim scrubber, for the physicians reading this, is the software step between charge entry and claim submission that checks each claim against a set of rules and stops the ones that will reject or deny. This article is about the rules themselves: which claim scrubber rules are worth adding, how to write one from a denial, who owns the set, and how to review it monthly.
Key takeaways
- Vendor default edits catch format errors; the denials that cost you money need custom rules built from your own remittance data.
- Every rule should trace back to a denial reason, a payer and a dollar amount, and should be written down in a change log with an owner and a date.
- One named person owns the rule set, and every addition goes through a short request form and a 30-day test before it becomes a hard stop.
- Review fire rate and override rate monthly; a rule that staff override more than 80 percent of the time is noise and should be fixed or retired.
- The scrubber is not a substitute for eligibility and authorization work at the front desk; it is the last check that the work was done.
What a claim scrubber checks, and where the layers sit
There are usually three layers of edits between your charge and the payer's adjudication system. The first is inside the practice management system, where rules can see everything: the appointment, the eligibility response, the authorization record, the provider's credentialing status with that payer. The second is the clearinghouse, which validates the 837P claim file format and runs its own library of payer-specific edits; rejections here come back on the 277CA acknowledgment. The third is the payer's own front end, which rejects claims before they reach adjudication. Anything that gets through all three and still fails becomes a denial on the 835 remittance.
The layer you control is the first one, and it is the only one that can use your internal data. A clearinghouse cannot know that Dr. Alvarez is not effective with Humana until June 1. Your system can, if someone writes the rule.
The claim scrubber rules worth adding first
This is the set we build for almost every independent practice, in roughly the order of dollars recovered. Each one exists because of a denial code we see on remittances month after month.
| Rule | What it checks | Denial it prevents |
|---|---|---|
| Eligibility on file | An eligibility response dated within 3 days before the visit exists for the billed payer | CO-27, CO-31, PR-204 (coverage terminated, patient not found) |
| Authorization by payer and CPT | For a maintained list of payer and code pairs (93306, 70553, 20610 with hyaluronic acid, sleep studies), an authorization number is present and covers the date | CO-197, CO-15 |
| Provider effective date | Rendering provider is enrolled and effective with the payer on the date of service | CO-B7, CO-185 |
| Modifier 25 check | E/M billed with a minor procedure on the same day carries modifier 25 and a diagnosis pointer that differs from the procedure | CO-97, CO-4 |
| Laterality | Codes on the bilateral indicator list carry RT, LT or 50, and the ICD-10-CM code's laterality matches | CO-4, CO-16 |
| NDC on drug codes | Every J code carries an 11-digit NDC, unit of measure and quantity; Medicaid and many MA plans reject without it | CO-16 with RARC M119 |
| JW and JZ modifiers | Single-dose vial drugs billed to Medicare carry JW with a wastage line or JZ when nothing was discarded | CO-4, CO-16 |
| Frequency limits | G0439 not within 365 days of the last AWV; 99497 with modifier 33 when billed with an AWV; screening codes against their covered interval | CO-119, CO-96 |
| Excludes1 pairs | Diagnosis codes that ICD-10-CM says cannot be coded together, and Z codes that cannot be primary | CO-11, CO-16 |
| Ordering or referring NPI | Labs, imaging and DME carry an ordering provider NPI that is enrolled in PECOS for Medicare | CO-16 with RARC N265, N286 |
| Secondary claim completeness | Claims to a secondary payer include the primary payer's paid amount and adjustment codes from the 835 | CO-22, CO-23 |
| Timely filing warning | A claim older than 60 days from the date of service is flagged, and hard-stopped at 30 days before the payer's limit | CO-29 |
We deliberately leave NCCI and medically unlikely edits off the list, because every reputable clearinghouse library already runs them and duplicating them doubles the noise. Loading every LCD diagnosis list is how a practice ends up with the 412-rule problem from the opening.
Building a rule from a denial: a worked example
Go back to the cardiology practice. The request form we use has six fields, and the completed one looked like this. Denial code: CO-197, precertification absent. Payer: one commercial plan, with its payer ID. Codes: 93306, 93350, 78452. Volume: 31 denials in Q1, 2026, about $5,580 in allowed amount, of which 19 were eventually paid on appeal with a retro-authorization and 12 were written off. Root cause: the front desk checked authorization for stress tests but nobody had told them echocardiograms were added to the payer's list on January 1, 2026. Proposed rule: if payer ID equals X and CPT is in the list, require an authorization number in the authorization field with a start date on or before the date of service and an end date on or after it.
The rule went live as a warning, not a hard stop, for 30 days. In that month it fired 47 times. Forty-one were genuine misses that the scheduler fixed before submission. Six were false positives: the payer's Medicare Advantage product uses a different payer ID and does not require authorization for 93306, so the rule was narrowed to the commercial payer ID. Then it became a hard stop. That sequence, warn, measure, narrow, enforce, is the whole discipline. A rule that starts as a hard stop and turns out to be wrong teaches the team to distrust the scrubber.
Write the outcome in the change log too. Ours has seven columns: rule name, date added, owner, denial code and payer, dollars at stake when added, warn-or-stop status, and the date of the last review. A practice that inherits 412 unlabeled rules cannot maintain them, and usually turns the whole thing off.
Who owns the rules
One person. In a practice with an in-house billing team, it is normally the billing lead or the senior biller who works denials, because that person sees the remittances first. In a practice that outsources, it is whoever at the billing company owns your account, and the contract should say so. The owner does not need to be technical. What the owner needs is authority to say no to a rule request and about two hours a month to run the review.
Requests come from three places. Denial follow-up staff propose rules from what they are appealing. The front desk proposes rules when a payer changes an authorization list, which is why the front desk needs to be reading payer bulletins or getting a summary of them. And the coder proposes rules after an audit finding. Everyone submits the same six-field form. Nobody adds a rule directly. If the practice uses an outside billing service, ask them to show you their rule change log for your account; if they do not have one, that tells you something.
The monthly review, and the numbers that tell you a rule is dead
The review takes four reports. First, fire count by rule: how many claims each rule stopped or flagged in the month. Second, override rate by rule: of those, how many the biller released without changing anything. Third, denials by reason code for the month, matched against the rule that should have caught each one. Fourth, the change log, to see which rules have not been reviewed in six months.
| Signal | Threshold we use | Action |
|---|---|---|
| Override rate | Above 80 percent for two months | Narrow the rule or retire it; it is noise |
| Zero fires | No fires in 90 days | Check whether the payer policy changed; retire if the code volume is gone |
| Denial leak | Any denial whose reason code maps to an existing rule | The rule has a gap; read the claim and fix the logic |
| Unreviewed | Last review more than 180 days ago | Owner re-reads the rule against the current payer policy |
| Hard stop volume | Hard stops above 8 percent of daily claims | Too many stops; convert the low-dollar ones to warnings |
What surprises practices the first time is that the override rate for the top five rules by fire count is usually above 90 percent. The billing team has been spending its day dismissing the same warnings. Fixing those five does more for morale than anything else in the billing office.
The mistakes we keep seeing
Hard-stopping soft problems. A missing referring provider name on a claim that does not need one should never hold a $90 visit for two days. Not dating the rule to the policy. Payer authorization lists change on January 1 and July 1 more than any other dates; a rule built on a 2024 list is wrong by now. Building rules against the wrong field. If the front desk types authorization numbers into the appointment note rather than the authorization module, the rule fires on every claim, and the fix is a workflow change, not a rule change.
The last mistake is treating the scrubber as the denial prevention program. It is the last line, not the first. If eligibility is not run and authorizations are not obtained, you get a queue of held claims instead of a queue of denials. Better, but not fixed. The denial management work upstream is what makes the rules fire less over time.
Questions we hear
Should the rules live in the practice management system or at the clearinghouse?
Rules that need internal data (eligibility responses, authorizations, provider effective dates) must live in the practice management system, because the clearinghouse never sees that information. Rules that are pure claim-content checks (NDC format, modifier pairs, Excludes1) can live in either, and we prefer the clearinghouse when its library already has them so you are not maintaining two copies.
How many custom rules should a small practice have?
For a one-to-five provider practice, 20 to 40 custom rules is typical when the set is healthy. If you have more than 100, the override rates will tell you which ones to cut. If you have fewer than 10, your denial report almost certainly has patterns that nobody has turned into a rule.
Our billing company says their scrubber is proprietary and they cannot show us the rules. Is that normal?
The engine may be proprietary; the list of rules applied to your claims is your business information. Ask for last month's fire and override reports by rule. A vendor that cannot produce them is not maintaining a rule set for your account.
What to do this week
- Export the list of active scrubber rules from your practice management system and your clearinghouse, and count them.
- Pull last quarter's denials by reason code and payer, and mark each denial reason that a rule could have prevented.
- Name the rule owner and create the six-field request form and the seven-column change log.
- Pick the top three preventable denial patterns by dollars and write each as a warning-level rule with a 30-day test.
- Run the override report for existing rules and retire or narrow anything above 80 percent.
- Put the monthly review on the calendar for the first week of each month, after the prior month's remittances have posted.
