Will this claim be paid?
Bundling, unit ceilings, add-on rules, site of service, medical necessity and who may assist — answered against your codes. The claim below is already filled in; press Check claim.
The claim — extensive sinus and nasal surgery
| Line | Code | Procedure | Allowable |
|---|---|---|---|
| L1 | 31256-50 | Exploration, maxillary sinus — bilateralendoscopic family | $158.8 |
| L2 | 31254-RT | Nasal/sinus endoscopy, partial ethmoidectomy — rightendoscopic family | $214.07 |
| L3 | 30520- | Repair of nasal septum | $625.29 |
Nothing on this claim denies. Every line is payable and every modifier is used correctly. The only question is what it should pay — and four rules apply to it in an order that changes the answer. The endoscopic family's diagnostic base code is 31231 at $56.23.
Correct adjudication
CorrectBundling, then bilateral, then EMPR within the family, then MSR between groups. Each rule sees the output of the one before it.
1Resolve bundling
Nothing bundles here. There is no procedure-to-procedure edit between any pair on this claim, so no modifier is needed and none would help — a distinct-service modifier on a pair that carries no edit is inert. Every line stays payable, which is where the interesting part starts.
- L1no PTP pair — payable$158.8
- L2no PTP pair — payable$214.07
- L3no PTP pair — payable$625.29
2Resolve bilateral value
Modifier 50 pays one line at 150% — but only where the code's bilateral indicator allows it. 31256 is indicator 1, so it does. 30520 is indicator 0, so appending 50 to it buys nothing. This resolves BEFORE any reduction, because every later rule ranks against the value of the service actually performed.
- L1$158.8 × 1.5$238.2
- L2unilateral (RT) — no bilateral uplift$214.07
- L3bilateral indicator 0 — no 150% adjustment$625.29
3Resolve endoscopic multiple-procedure reduction
Endoscopies in one family are grouped. The highest-valued pays in full; every other line in the family subtracts the family's diagnostic base code (31231, $56.23). It is a subtraction, not a percentage — that distinction is what scenario B gets wrong.
- L1highest in family — pays 100%$238.2
- L2$214.07 − $56.23 base$157.84
- familyendoscopic family total$396.04
4Resolve standard multiple-surgery reduction
The endoscopic family is ranked as a single group against the non-endoscopic procedure — but the group is NOT then cut. A live vendor-pricer run settles this: 30520 ranked first and paid its full $625.29, and 31254 stayed at $157.84 rather than dropping to $78.92. The endoscopic reduction is the family's reduction; the standard 50% does not apply on top of it. This model halved the family until that run proved otherwise.
- L3ranks first — pays 100%$625.29
- familyendoscopic family — ranked, not reduced again$396.04
Total $1,021.33
RT/LT split on an endoscopic code
Overpaid $23.17The provider bills the bilateral endoscopy as two lines, 31256-RT and 31256-LT, instead of one line with modifier 50.
1Two lines, same code, opposite sides
The engine never merges RT and LT of the same code into one bilateral unit, so the bilateral indicator is never enforced.
- L1a31256-RT — treated as a standalone endoscopy$158.8
- L1b31256-LT — treated as a standalone endoscopy$158.8
2EMPR runs against two lines instead of one
Having two endoscopies where there should be one bilateral service, the second takes the base-code subtraction as though it were a different procedure.
- L1ahighest in family — pays 100%$158.8
- L1b$158.8 − $56.23 base$102.57
- codepaid for 31256$261.37
Where it breaks — $261.37 for a service worth $238.2 as a bilateral line. Splitting a bilateral procedure across two lines pays MORE than billing it correctly, which is the wrong incentive to leave in an engine.
Total $1,044.5
Correct
$1,021.33
Scenario A
$1,044.5
Difference
+$23.17
paid above the correct amount
| Line | Correct | Scenario A | Difference |
|---|---|---|---|
| L1 31256 | $238.2 | $261.37 | +$23.17 |
| L2 31254 | $157.84 | $157.84 | — |
| L3 30520 | $625.29 | $625.29 | — |
25 checks per day, free and without an account. Need more, or want to call this from your own system? Request an API key — keyed access is unlimited.
An edit is a decision. It should be legible to both sides.
A remit arrives with a code and a terse description. It names the outcome, not the reasoning — and by then the claim has already been adjudicated.
Staff reverse-engineer the rule from experience, resubmit, and hope. The same edit fires again next month on a different claim, and the cycle repeats.
Both sides spend real money arguing about a rule that was published all along. Neither side benefits from the ambiguity.
The rules governing most of these decisions are public. The problem has never been secrecy — it is that the logic is scattered across tables, policies and configuration layers that almost nobody reads end to end.
How it works
Every engine can tell you a line was denied. The difference here is that the reason comes back with it — the rule, the indicator it read, and why a modifier did or did not change the answer.
Point it at the claim
Enter the service lines as they appear on the claim — codes, modifiers, units, place of service, dates and diagnosis pointers. No integration required to start.
See every edit that fires
Bundling conflicts, unit ceilings, modifier validity, site of service and medical necessity — evaluated together against the whole claim, not one rule at a time.
Read the reasoning, not just the code
Each result cites the rule it came from and the source that publishes it, so the finding can be defended rather than guessed at.
Fix it before submission
See what would clear the edit — a supporting modifier, a corrected unit count, a documentation requirement — while the claim can still be changed.
Same rules. Two directions.
Payers ask whether an edit is configured correctly. Providers ask why it fired. Both questions run on the same published logic.
For payers
Configuration, payment integrity, and clinical editing teams
- Test configuration changes against real claim patterns before they reach production.
- Compare how your edit set behaves against published CMS baselines.
- Give configuration and payment integrity teams a shared, explainable reference.
- Cut the appeal volume that traces back to edits providers never understood.
For providers
Revenue cycle, denials management, and coding teams
- Catch edits pre-submission instead of learning about them on a remit.
- Understand the actual rule behind a denial, with its published source.
- Build appeals on cited policy rather than trial and error.
- Spot the recurring edits driving the most rework across your book.
Questions
- What does it cover?
- Bundling conflicts and unit ceilings for practitioner, outpatient hospital and DME, under both Medicare and Medicaid rules. Add-on code requirements, medical necessity against local and national coverage policy, the inpatient-only list, site-of-service limits, and assistant-at-surgery eligibility. All of it built on publicly published policy, refreshed every quarter, and every result carries the rule it fired on.
- What is actually covered?
- Bundling and unit limits for practitioner, outpatient hospital and DME; add-on code rules; the inpatient-only list; coverage policy with diagnosis lists resolved to your state, plus national coverage rules; site of service; and assistant-at-surgery. Every dataset is versioned to the quarter it takes effect and refreshed as new policy publishes.
- Is this a clearinghouse or a scrubber replacement?
- No. Scrubbers tell you a claim failed. ClaimEdits tells you which rule fired, why it fired, and what the published source actually says — the explanation layer most tools leave out. It also reaches past bundling into coverage policy and site of service, which most edit tools do not touch. It does not check eligibility, prior authorization, timely filing or coordination of benefits, and says so on every result.
- Do you need access to our claims system?
- Not to start. You can evaluate individual claim lines without any integration. Deeper workflows are a conversation once the basics prove useful.
- Does it work for both payers and providers?
- Yes, and deliberately so. Both sides are reasoning about the same published rules from opposite directions. The underlying logic is identical — what differs is the question being asked.
See it against your own claims
The fastest way to judge whether this is useful is to run it on edits you already argue about. Tell us what you're seeing and we'll set that up.