Seven claim problems you can catch before the payer sees them

Tuesday, 4:47 PM. Billing has 126 claims ready to go.

The batch total looks right. Patient demographics are populated. Codes are present. Provider information exists. Nothing looks obviously broken.

Now imagine checking seven things before clicking submit:

1. Does the authorization cover the service?
2. Is the provider information appropriate for the claim?
3. Does the code and modifier combination pass the configured rules?
4. Does the service match the patient's level of care?
5. Is the documentation actually complete?
6. Is the patient and subscriber information consistent?
7. Is the payer information correct?

Eleven claims move from Ready to Review required.

That's not eleven claims you lost. It's eleven problems the payer didn't have to discover for you, and eleven that won't come back in three weeks as a rejection or a denial someone has to reconstruct from memory.

Claim scrubbing should answer more than “Are all the boxes filled in?”

Basic claim validation checks that a claim is well formed:

• required fields
• data formats
• identifiers
• dates
• basic code structure
• electronic transaction requirements

Those checks matter. A claim that fails them may never be accepted for processing at all. But they answer whether the claim is complete. They don't answer whether it's right.

It also helps to be clear about where a given rule comes from, because “the claim should” can mean four different things:

Most of what follows is the third and fourth kind: checks an organization chooses to run, often to catch problems a payer would otherwise find. A claim can be technically complete and still carry one:

Nothing is structurally missing from that claim. The problem is the relationship between the claim and the care workflow behind it: the service date and the authorization disagree. No format check will ever catch that, because both values are perfectly valid on their own.

That gap is where behavioral-health-specific validation earns its keep.

Problem #1: The authorization doesn't cover what you're billing

None of these automatically makes a claim invalid. An extension may have come through and not been entered. The payer may count utilization differently from your tracker. The level-of-care change may already be approved. Each of them is a relationship a person should look at before the claim goes, not after.

Depending on the payer and service, useful authorization checks can include:

• an authorization exists where one is expected
• the date falls within the authorization period
• utilization remains
• the authorized level of care matches
• the authorized service matches
• the authorization number is present where required
• configured limits aren't exceeded

Scrubbing is the last place to catch an authorization problem, not the best one. The best one is the scheduling screen, which is why authorization tracking belongs there. We went through that workflow in The authorization expired yesterday. Who was supposed to know?

Problem #2: The provider information doesn't line up

A claim is also a statement about who delivered the care. Depending on the payer, that can involve:

• rendering provider
• billing provider
• NPI
• taxonomy
• payer enrollment
• credentials
• licensure
• supervision arrangements, where applicable
• which providers can bill which services

A clinician can be appropriately licensed to deliver a service while a separate payer enrollment or claim-configuration issue still affects billing. Those are different questions. Licensure is granted by a state board; enrollment is between the provider and each payer; the claim can depend on both.

Scrubbing can catch the mismatch on the claim. Preventing it means tracking credentials, licensure, and enrollment with expiration dates, so the lapse shows up before anyone is scheduled against it.

Problem #3: The code and modifier combination needs review

Behavioral health claims can carry several layers of coding information:

• CPT codes
• HCPCS codes
• modifiers
• revenue codes, where applicable
• units
• place of service
• other claim information

Which combinations are acceptable depends on the payer, the provider type, the service, and the contract, so there is no universal rule set to list here. Some edits are published: CMS, for example, publishes National Correct Coding Initiative edits for Medicare claims, covering code pairs and units of service. Others come from individual payer policies, and some are rules an organization configures for its own programs.

That points to a distinction worth building into any validation:

• Error: a known, configured condition that prevents the claim from being ready.
• Warning: a potential issue that needs a person to review it.

Nothing in that claim is known to be wrong. Two things in it are worth a look. Those should read differently on the screen, and they should route differently too.

Problem #4: The claim says one level of care. The patient record says another.

In an organization running several levels of care, the patient's program, the authorization, the documentation, and the claim should tell one coherent story. Here they don't:

Three records agree and the claim doesn't. The usual cause is mundane. The patient stepped down from PHP to IOP last week. The clinical record was updated, the authorization was updated, and the service configuration the claim is built from was not.

Transitions are where this happens: residential to PHP and IOP, IOP to outpatient, and patients who add or leave MAT or OTP services. A check that compares the claim's level of care with the patient's current program catches it in seconds. Finding it from a denial can take a week.

Problem #5: The service happened, but the documentation isn't ready

Service delivered ≠ documentation complete ≠ claim ready. They happen at different times, often by different people, and a claim built from the first one alone is a guess about the other two.

The payer should not be the workflow that tells the organization its documentation was incomplete. Depending on the configured requirements, claim readiness may need visibility into:

• note status
• signature status
• required forms
• treatment-plan status
• attendance
• individualized group documentation
• other required clinical records

What counts as “complete” varies by payer and service; the scrubber's job is to know whether the record meets what your organization has configured, not to define it. A documentation clock shrinks the list of held claims by getting notes signed the same day. And when twelve individual responses in one group read the same, that's a different problem, covered in Cloned notes and medical necessity.

Problem #6: The patient data is internally inconsistent

The least interesting problem on this list is also one of the most common to slip through:

• patient name
• date of birth
• subscriber information
• member ID
• relationship to subscriber
• address, where relevant
• insurance information
• other required demographics

One transposed digit. The care, the documentation, the authorization, and the coding can all be correct, and the claim still won't match a member.

The durable fix isn't a better typist. It's one authoritative patient and insurance record, captured once at intake and verified through eligibility, that every downstream workflow reads from instead of retyping. Every time a member ID is copied by hand, there's another chance to transpose it.

Problem #7: You're sending the claim to the wrong payer configuration

Payer configuration is its own layer:

• payer selection
• electronic payer identifier
• plan
• primary and secondary sequencing
• claim destination
• other configured payer information

The claim can be clinically perfect and still go nowhere useful. That's why validation has to cover administrative data as well as the clinical and authorization relationships above. The seven problems are not ranked by importance; a wrong payer ID stops a claim as surely as a missing signature.

Errors and warnings should not mean the same thing

If every alert blocks the claim, users learn to hate the system. If every alert can be ignored, users learn to ignore the system.

Good validation keeps three lists separate: what must be fixed, what should be reviewed, and what is useful context. Getting the categories right is most of the design work. A rule that belongs in “warning” but is set to “blocking” will be worked around within a week, usually by someone who has stopped trusting the other rules too.

The claim scrubber should tell you what is wrong, not just that something is wrong

The person working the claim should not need a technical dictionary to understand why it stopped. The second message names the field, the two values that disagree, and what to do about it. The first one sends someone to a lookup table, a portal, or the person who configured the system three years ago.

The fix should happen where the bad data came from

Billing notices incorrect insurance information. Billing fixes the claim. The claim goes out and gets paid. The patient record is still wrong.

Where it's appropriate, a correction should fix the source of the problem, not just the claim in front of you. That sometimes means the biller can't make the fix themselves; the patient record belongs to intake or the front desk. Then the validation result should say so, and route there.

A clean claim rate can hide upstream work

A billing team can correct a large share of claims by hand before submission, and the claims that finally go out can perform well. The downstream number looks excellent. The operational problem is still there.

A metric measured at submission might score that month perfectly. Operationally, nearly a quarter of the claims needed someone's time before they could go. Metrics worth tracking alongside the downstream ones:

• claims passing validation the first time
• claims needing manual correction
• errors by category
• warnings by category
• errors by program
• errors by payer
• errors by provider
• time spent correcting claims

What should happen when a claim fails?

The important part is that a failed validation becomes work with a clear reason and an owner. The category matters because it decides the owner: a documentation hold goes to the clinician, a payer configuration error to whoever maintains payer setup, and neither should sit in the biller's queue waiting for someone to notice it isn't theirs.

The same error happening 200 times is not 200 billing problems

This month, 87 claims were flagged for the same payer configuration. Billing corrected all 87. Next month, 92 more.

The team is working efficiently. The system is failing efficiently.

Recurring errors usually trace to one of a handful of causes:

• a configuration problem
• a training problem
• a workflow problem
• a source-data problem
• a payer change
• a provider setup problem
• a documentation workflow problem

Which one should leadership fix first? Probably the repeated, systemic one: 92 claims from one payer setup is almost certainly one fix, while seven demographic errors may be seven different typos. A queue sorted by the oldest claim would never tell you that. A trend sorted by category does.

Claim scrubbing should get smarter from your own failure patterns

Rules don't write themselves, and no scrubber ships knowing every payer's quirks. What an organization can do is close the loop: analyze recurring rejection and denial reasons, and turn the patterns into upstream checks where that's feasible.

If one payer repeatedly rejects a known configuration issue, that pattern may justify a validation rule for that payer. The goal isn't to work payer responses faster. It's to stop sending the same avoidable problem over and over. The denials queue is where those patterns show up; the scrubber is where they should end.

A practical pre-submission behavioral health claim checklist

How ProbityCare approaches claim scrubbing

ProbityCare validates behavioral health claims before submission, using information already connected to the patient's workflow: the authorization, the program, the note, the provider, and the insurance on file. A pre-submission result can read like this:

Behavioral health rules are included, covering configured relationships across:

• authorization matching
• credential and taxonomy information
• code and modifier combinations
• level-of-care consistency
• documentation state
• patient demographic information
• payer information

Validation highlights the exact field and says why in plain language, and unsigned encounters don't leave as claims. It checks what has been configured. It doesn't claim to know every rule every payer applies, and passing it doesn't guarantee payment.

The takeaway

A claim doesn't become clean because every required field contains something. The information has to agree:

• the patient
• the payer
• the provider
• the authorization
• the level of care
• the documentation
• the service being billed

The best time to discover that they disagree is while the claim is still inside your building.

Behavioral health claim scrubbing questions