How to Use Payer Policies to Collect More
Knowing how to use payer policies is the difference between catching a coding or documentation problem before a claim goes out and finding out two months later that the money is gone for good. For medical billing companies and provider organizations handling dozens of payers, hundreds of CPT and diagnosis combinations, and constantly shifting rules, this is not a minor administrative detail. It is a direct hit to collections, A/R aging and staff time, and it compounds every time a denial sits unworked long enough for the chart to go stale.
This matters for coders, charge entry teams, AR staff and the providers themselves, because payer policies touch nearly every stage of the revenue cycle: what gets coded, what gets submitted, what gets authorized in advance, and what happens when a claim comes back denied.
What Payer Policies Actually Control at the Coding Stage
Every payer publishes rules about what it will pay for, and those rules go far beyond a simple fee schedule. Depending on the type of provider, a payer policy can dictate:
- Which CPT codes, revenue codes and procedures are allowed at all
- Which diagnosis codes are covered, sometimes only in specific combinations with a procedure code
- What documentation has to exist to support that combination
The goal of checking this before a claim goes out is simple: avoid the denial in the first place. But there is a second, often overlooked benefit. Confirming the allowed codes and diagnoses against the payer’s actual policy functions as a form of clinical documentation improvement. It forces the note to contain what a payer or an auditor will later expect to see, which protects the practice if that chart is ever pulled for review.
The problem is that even strong coders cannot hold every payer’s code and diagnosis combinations in their head. A coder might be excellent at CPT selection in general and still have no way of knowing that one specific payer requires a particular diagnosis pairing for a particular procedure. Learning how to use payer policies as a living reference, rather than trying to memorize them, is what keeps that gap from turning into a denial.
Mental Health Billing Adds Another Layer of Complexity
Behavioral health billing is a good example of how fast this gets complicated. A few patterns that show up repeatedly:
- Psychiatric testing codes are frequently billed at a higher complexity level than the documentation actually supports, which invites downcoding or denial if the payer’s criteria are not checked first
- Unit-based billing requires calculating the correct number of units for time-based codes, and getting that math wrong either leaves money on the table or creates an overpayment risk
- Some payers are noticeably harder to work with than others when it comes to coding complexity in mental health, which means the “safe” approach for one payer is not safe for the next
- Employee Assistance Program (EAP) billing uses a different code set than standard outpatient mental health billing, so applying the wrong code set is a common and avoidable error
- Some Medicaid plans do not use standard AMA CPT codes at all and require a crosswalk to their own code set, which most coders have never been trained on and have no reason to have memorized
No provider is going to know all of this, and it is genuinely difficult for even an exceptional coder to carry it all in their head across every payer they bill. That is exactly why this information needs to live in a reference instead of in someone’s memory.
Provider-Specific Modifiers Are Not Optional Details
Modifiers that identify the rendering provider’s license level are another place where small errors cause real denials, especially in telehealth and behavioral health billing. In behavioral health specifically, the modifier typically needs to match the provider’s credential type:
| Modifier | Provider Type |
|---|---|
| AF | Psychiatrist (MD or DO) |
| AH or HP | Psychologist (PhD or PsyD) |
| AJ | Licensed Clinical Social Worker (LCSW) |
| HO | Master’s-level clinician (for example LMFT or LPCC) |
These modifier conventions are documented by payers and coding resources, including a Blue Cross Blue Shield of Michigan telehealth billing guide and industry references that walk through common behavioral health modifier use in more detail.
The complication is that these modifiers are not universal. They vary by provider type, and in many cases they also vary by payer, so a modifier that is correct for one plan can be wrong for the next. Even providers who do their own coding typically do not apply modifiers correctly and lean on coders or the charge entry team to catch it. This is one of the clearest examples of why learning how to use payer policies at the point of charge entry, not after the fact, prevents an entirely avoidable category of denial.
Catching Submission Requirements Before the Claim Ever Leaves
Charge entry and claim submission is the last realistic checkpoint before a claim either gets paid, bounces at the clearinghouse, or comes back denied from the payer, which takes considerably longer to resolve. This is where claim scrubbing and code scrubbing matter most, and where checking the payer’s specific submission requirements can prevent a cycle of rework.
Some payers require documentation to be attached at the time of submission for certain procedures to be paid. It is simply not feasible, from a cost and time standpoint, to attach full documentation to every claim, so billing teams have to know which specific policies require it. In practice, a biller might remember one or two of these rules, if they know them at all, but nobody can memorize every attachment requirement across every payer and every procedure.
A real example of how specific these requirements get: Anthem’s medical policy ANC.00009 on cosmetic and reconstructive procedures requires documentation such as three months of conservative management, photographic documentation consistent with the diagnosis, and limb measurements before certain procedures are considered medically necessary. That is a lot of specific, non-obvious detail for one policy, and it is one of hundreds a billing team might need to reference.
Checking claims against the relevant payer policy before submission matters whether the provider is doing their own coding or a dedicated RCM team is handling it, and whether that team is in-house or outsourced. It is the last practical checkpoint before a claim either bounces at the clearinghouse (fast, but still rework) or comes back denied from the payer (slow, and far more expensive in staff time).
How to Use Payer Policies to Catch Prior Authorization Requirements
Prior authorization is a separate but related problem, and the operational cost of getting it wrong is well documented. In the American Medical Association’s most recent physician survey, 93% of physicians reported that prior authorization delays necessary patient care, and physicians reported spending an average of 13 hours a week managing prior authorization requirements for their practices.
A payer policy typically answers three questions for any given procedure:
- Does this payer require prior authorization for this procedure at all
- Are there special conditions or criteria that trigger the requirement, such as a specific lab result, a failed conservative treatment, or another documented clinical finding
- What exactly needs to be submitted to get the authorization approved
Missing any one of these means either an authorization gets denied, or worse, a procedure is performed without authorization at all and the claim is uncollectible from the start. For organizations dealing with payer-specific authorization rules and the broader question of how payers expose this data through their own systems, it is worth understanding what payer APIs actually require for prior authorization data, since the regulatory direction is pushing more of this information online, even if it is not always easy to use in practice.
Why Denials and AR Work Become a Guessing Game Without a Reference
AR teams are typically flooded with denials, and without a reliable way to check the payer’s actual rule, it becomes extremely hard to know what to do with any individual one. Medical necessity denials in particular split into two very different paths:
- The payer made an error, and the claim was correct as submitted, which means it should be resubmitted as billed
- Something genuinely needs to change, such as attaching missing documentation or correcting a code, before resubmission makes sense
Figuring out which path applies means looking up the specific payer’s policy for that denial, and doing that for every denial is far too much manual work for most AR teams to sustain. In practice, that means staff end up hoping they know the right answer, and that is a massively hit-or-miss approach. Resubmissions and appeals that go out without checking the actual policy often fail anyway, which means the team did a full round of extra work and ended up back where it started, with no payment and more hours sunk into the claim.
The Phone Call Problem
A lot of that lookup work ends up happening over the phone with a payer representative. Aside from how time-consuming that is, payer reps are frequently wrong, and in some cases have little incentive to give complete or accurate information. That makes phone verification both slow and unreliable. Written documentation directly from the payer, by contrast, is something a billing team can actually stand behind if a claim needs to be fought later, whether that is in an appeal or an audit.
The operational cost of denials shows up clearly in industry cost data. One analysis found the administrative cost to rework a single denied claim increased from $43.84 in 2022 to $57.23 in 2023, and that is before counting the original cost of submitting the claim and working it the first time. For a deeper look at how denial patterns actually get tracked and where visualization efforts fall short, see this breakdown of denials management challenges.
The Problem You Cannot Undo
The most expensive version of this plays out when a denial sits for a couple of months before anyone gets to it, which is common when AR queues are backed up. By the time a biller finally works that denial, the claim was almost certainly already submitted with every diagnosis code available from the chart at that point. If more information is needed to support the claim, there is often no way to go back and add it after the fact. The payment is lost permanently, on top of all the administrative work already spent submitting the claim, following up, working the denial, and likely appealing and losing anyway.
This is closely related to downcoding, where a claim does not come back as a denial at all. It simply gets paid at a lower level, and keeps getting paid at that lower level, until someone notices the pattern. Because there is no denial code flagging it, downcoding is often invisible without specifically checking claims against payer policy and watching for the pattern over time. Reviewing first pass claim acceptance performance is one way to catch these patterns before they quietly erode collections for months.
Why Billing Teams Can’t Keep This in Their Heads
Every point above leads to the same conclusion: no one, not even the best biller on a team, can know every payer’s rules, codes, diagnosis combinations, modifier requirements, documentation rules, prior authorization criteria and denial logic, across every payer the practice bills. It is simply too much information to hold reliably.
It is also too time-consuming to look each one up individually, every time, for every claim. And the problem gets worse because payer policies change constantly. A rule that was correct for a date of service before a certain date can be entirely wrong for a date of service after it, which means a biller has to track not just the current rule, but the effective date of every change.
| Manual payer policy lookup | Using a maintained payer policy reference |
|---|---|
| Relies on individual staff memory, which varies by biller | Consistent answer regardless of who is working the claim |
| Requires finding, downloading and parsing each policy manually | Information is already extracted and organized |
| Easy to miss effective date changes | Tracks what changed and when |
| Phone verification with payer reps, often unreliable | Backed by the payer’s own written documentation |
| Hard to apply consistently across a team | Same reference used by coding, charge entry, prior auth and AR |
No one on a billing team has time to dedicate every day to finding the right policies, downloading them, parsing out the specific information needed, and keeping track of it for the next claim that comes in tomorrow. Centralizing this kind of reference material is the same logic behind building a payer policy database in the first place, so the information is already organized instead of being rebuilt from scratch every time a claim or a denial raises a question.
What to Look for in a Payer Policy Tool
Given everything above, a useful tool for checking payer policies needs to cover more than a single piece of the workflow. Based on where the problems actually show up, it should be able to answer, for a given payer and provider type:
- Which CPT or revenue codes and diagnosis codes are allowed, including required combinations
- What documentation is required to be attached at submission for specific procedures
- Which procedures require prior authorization, and under what specific clinical conditions
- Which modifiers apply, by provider credential and by payer
- Whether a medical necessity denial should be resubmitted as billed or requires a documentation change first
Teams evaluating options for this should also look at how the information is sourced. Written, payer-published documentation is more defensible in an appeal or an audit than information gathered over the phone, and it holds up better when a claim needs to be fought later.
How Voyant Approaches Payer Policy Data
Voyant is run by operators who built, scaled and sold their own national RCM company, so this problem was lived firsthand rather than studied from the outside. That operational background is also why Voyant regularly publishes original data and findings pulled directly from its own tools and work, information that is not available anywhere else because it comes from actually running billing operations, not from theorizing about them.
That perspective shaped the payer policy database, which was built specifically to deal with the problems described above: coding and diagnosis combinations that vary by payer and provider type, documentation requirements that have to be checked before submission, prior authorization criteria, provider-specific modifier rules, and guidance on whether a medical necessity denial should be resubmitted or corrected first. It pairs with Voyant’s broader payer policy work and its RCM analytics and reporting across systems like Tebra, eClinicalWorks and AdvancedMD, so policy checks and denial patterns can be tied back to the same dashboards a billing team is already using to track collections and A/R.
Conclusion
Learning how to use payer policies consistently, at coding, at charge entry, at prior authorization and at denial management, is what keeps a practice or billing company from losing claims it can never recover once the documentation window closes. The cost of skipping this is not just the occasional denial. It is lost revenue that cannot be reclaimed, plus the administrative hours spent submitting, following up, appealing and still losing the claim.
Wondering how many denials your team is reworking that could have been prevented with the right policy information at the point of submission? Book a quick call to see how Voyant’s payer policy database can help your coding, charge entry and AR teams check requirements before claims go out instead of after they come back denied.
