Payer Contract Audit for Infusion Fee Schedule Accuracy

A payer contract audit for infusion practices has to catch something a denial report never will: claims that get paid, close out clean in the patient accounting system, and are still wrong. Infusion billing teams recover more denied and underpaid revenue when they stop treating every variance as one problem and instead build detection around three separate categories (denials, underpayments, write-offs) and around the specific payer rules, J-code logic, and modifier combinations that drive each one. The rest of this piece explains why standard revenue cycle workflows miss that gap, how it forms inside payer systems without a single word of the contract changing, and what a line-level audit built for infusion has to check.

Why standard RCM workflows miss infusion revenue loss

A denied claim is loud. It throws a flag, lands in a worklist, and someone on staff has to open it, read the reason code, and decide what to do next. A paid-but-short claim does the opposite. It posts, the balance zeros out, and the account closes as resolved. Nobody opens it again. No one reads a reason code, because there isn't one. The claim simply looks finished, and finished claims don't get a second look in most billing offices.

That's the core issue: the 835 remittance tells a practice what the payer decided to pay, not what the payer was contractually obligated to pay. Those are two different numbers, and the remittance only ever shows one of them. Both read as collected. Both close. Only one of them actually left money on the table.

So you need to treat underpayments, denials, and write-offs as three distinct categories, because each one needs its own way to catch it. Denials get caught by a claims-status workflow. Write-offs get caught by an aging and adjustment review. Even experienced RCM staff tend to fold underpayments into the write-off bucket, so they get adjusted off the books.

Infusion billing makes this gap far more expensive than it would be in general medical billing. Because infusion operates on buy-and-bill, the practice has already spent money on the drug before a payer ever adjudicates the claim, so an underpayment here is a direct loss against a purchase the practice already made, not an accounting footnote.

General-purpose RCM platforms were not built to catch any of this. They reconcile payments against expected totals in a broad sense, but most were never designed to check J-code unit counts against administered dose, validate modifier stacking on administration codes, or compare drug cost to reimbursement at the line level. Without that specific comparison running, the underpayment stays invisible indefinitely.

Fee schedule drift and contract language

Fee schedule drift is the gap that opens between the rate written into a signed payer contract and the rate a payer's claims system actually applies to a submitted claim, a gap that tends to widen over time without anyone updating a single clause, and it's the upstream source of most of the underpayments described above.

Payers have two separate ways to hold onto money that should belong to the provider. One is reimbursing below the contracted rate. The other is writing contract terms that favor the payer's position from the start. Both work quietly, and drift usually involves the first one: a rate that was correct on the day the contract was signed slowly stops matching what the payer's system applies, through mechanisms that never touch the contract document itself. An escalator the contract promised for year two never gets triggered.

Rate increases themselves can mask the same problem. Payers often concentrate increases on lower-volume codes, where the headline percentage looks generous but the dollar impact barely registers. A provider sees an increase announced and assumes reimbursement is improving, but the high-volume infusion codes that drive revenue stay flat or quietly decline.

The coding system layered on top of this adds its own source of drift. The same thing happens with ASP-NDC mismatches: CMS publishes a quarterly pricing crosswalk that links National Drug Codes to HCPCS billing codes, and if the NDC on a claim doesn't align with that crosswalk, pricing validation fails before reimbursement is even calculated correctly.

Modifiers compound the problem further. If you bill the same CPT or J-code with a different modifier combination, it can produce a materially different allowed amount under the same contract. If a payer's adjudication system applies bundling logic the contract never authorized, that underpayment sits buried inside a modifier combination nobody is checking line by line.

You need continuous monitoring of claim adjudication against an organized, payer-specific contract repository to catch this kind of drift, not a periodic audit that catches it months after the fact. That's a discipline infusion RCM platforms have to build into their core workflow, because without automated validation of each payer's rates and modifiers at the moment of adjudication, drift compounds quarter after quarter until it becomes structural and, eventually, unrecoverable. Most practices have no such repository, because contracts live scattered across filing cabinets, old email threads, and the institutional memory of whoever has worked there the longest, leaving drift no mechanism standing in its way.

Infusion fee schedule audits versus general physician fee schedule audits

A general physician fee schedule audit checks one relationship: does the allowed amount on each CPT code match the contracted rate. That comparison, run consistently, catches most of the underpayment risk in general medical billing. But infusion billing carries several additional layers that a CPT-level comparison alone cannot see, so when you apply the same audit framework to infusion claims, real money goes undetected.

J-code billing requires the number of units billed to match the exact administered dose, and that calculation depends on the specific drug, its concentration, the dose ordered, and the unit definition written into the HCPCS descriptor for that code.

Administration CPT codes carry their own complexity on top of this. Codes like 96413, 96415, and 96417, along with their add-on codes, are both modifier-dependent and time-dependent. The allowed amount shifts based on how long the infusion ran, how many drugs were administered, and whether administration was sequential or concurrent. None of that can be validated against a generic fee schedule. It has to be checked against the specific payer's contract language governing that combination of circumstances, because two payers can treat the identical clinical scenario differently.

Infusion stacks J-code unit logic and drug cost exposure on top of that existing complexity, so the software gap that already exists for general billing gets wider, not narrower, when you apply it to infusion claims.

Buy-and-bill changes the financial stakes of all this. A practice holds the drug's acquisition cost as a real liability from the moment it's purchased until reimbursement clears, so an underpayment on a biologic claim is a direct cash loss, not a timing issue that resolves itself later. ASP-based reimbursement adds a second layer of exposure beyond the contract itself: when a practice's acquisition costs rise faster than the CMS quarterly ASP update reflects, margin erodes even on claims paid at the fully correct contracted rate. Auditing against the contract is necessary, but it isn't sufficient on its own. The ASP benchmark has to be checked separately.

The "lesser of" clause, common in UnitedHealthcare agreements and present in other commercial payer contracts, is one more structural trap in infusion contracts, causing adjudication to default to whichever is lower, billed charges or the contracted rate. Standard claim-scrubbing software tends to accept that lower figure, leaving the lesser-of condition unchecked.

The pre-audit foundation: inventorying contracts, fee schedules, and amendments before comparing a single claim

No contract audit can begin at the claim level if the contract itself isn't fully accounted for first. Most infusion practices aren't actually ready to run the comparison this article is building toward, because the inputs, current fee schedules, signed amendments, and modifier-specific rate exhibits, were never assembled in one place to begin with.

Contracts in many practices live across filing cabinets, scattered email inboxes, and whatever a long-tenured billing manager happens to remember about a rate negotiated five years ago. Until every agreement is pulled into one central inventory, no systematic claim-level comparison is possible, because there's nothing fixed to compare against. If a contract can't be located at all, the practice is currently being paid whatever rate the payer's system chooses to apply, with no document on hand to hold them to anything different, and that absence is itself a finding the practice needs to act on.

The common gaps look similar across practices: contracts that technically exist somewhere but can't be produced on request, amendments that were signed but never filed anywhere searchable, rate increases a payer representative mentioned verbally that were never put in writing, and network participation the practice entered through an intermediary entity it has since forgotten about.

For an infusion practice, the inventory has to go further than pulling the master service agreement. It needs to surface the specific fee schedule exhibits that govern J-code and administration code reimbursement, frequently housed in separate attachments from the body of the contract itself. At the CPT, modifier, and place-of-service level, the inventory should capture effective and termination dates, renewal terms, required notice periods, the rate methodology (whether it's a percentage of Medicare, a fixed dollar amount, or a case rate), and any carve-outs tied to specific services or sites of care.

Infusion contracts need additional fields layered on top of that baseline: J-code unit rate exhibits, drug-specific carve-out provisions, references to ASP-based pricing, prior authorization requirements that are written directly into the contract rather than just the payer's separate medical policy, and any lesser-of or bundling language that affects how administration codes stack. These often exist only as an email thread negotiated for one out-of-network biologic claim, and once that thread is buried in an inbox, the terms are effectively lost by the time the remittance comes back for comparison.

Once contracts are fully inventoried, you need to digitize them at a level of detail that actually supports claim-level comparison, not simply scan and file them as PDFs that can't be queried against remittance data. A contract analysis system built for healthcare needs to extract allowable rates by CPT code, modifier rules, timely filing windows, and prior authorization triggers directly, organized into a payer-specific rule library. The loaded fee schedule becomes the benchmark, so you measure every future posted payment against it. If that loaded schedule is incomplete, or built from an outdated amendment, every variance you calculate downstream inherits that same error.

Running the line-level contract-against-remit comparison that surfaces infusion underpayments

The only approach that reliably surfaces infusion underpayments is a line-level comparison: every posted payment measured against the independently loaded contract rate, checked against more than one benchmark at the same time. The comparison itself becomes the ongoing work queue, not a report someone reviews when there's time.

For recovery work, you re-price every claim line against several reference points. The loaded payer contract fee schedule comes first, because it's the primary, legally binding figure. Alongside it, the CMS CY2026 allowed amount for that code and setting gives you a second reference. The No Surprises Act qualifying payment amount offers a third, but its calculation methodology was partially vacated by the Fifth Circuit in August 2026, so it currently remains unsettled. The provider's own historical paid rate for that payer rounds out the fourth. The contract rate carries the most weight, but when contract language is ambiguous, or a payer disputes the interpretation, CMS data and the provider's own payment history give the appeal something independent to stand on.

For infusion claims specifically, the comparison has to validate several things a general RCM reconciliation would never check. Unit validation confirms the number of units billed actually matches the administered dose, and that the payer reimbursed the correct number of units at the correct per-unit rate, since a unit-count discrepancy at adjudication is an underpayment, not a denial, and will never generate a flag on its own. Modifier stacking validation confirms that add-on administration codes, covering sequential infusion, concurrent infusion, or injection, were reimbursed at the rate the contract specifies, rather than bundled away by payer logic the contract never authorized. ASP crosswalk validation confirms the J-code paid rate lines up with the CMS quarterly ASP pricing file for that period, since a mismatch between the billed NDC and the crosswalk creates a source of underpayment that recurs every single quarter until someone catches it. And a lesser-of clause check confirms whether that provision was triggered correctly, because standard scrubbing software tends to accept the lower of the two rates without testing whether the underlying condition was met.

General-purpose RCM platforms are not built to run this comparison, so infusion underpayments close as permanent write-offs that never surface as recoverable claims. Platforms built specifically for infusion, including Ruby RCM, are designed to validate J-code unit counts, modifier combinations, and drug-cost-to-reimbursement ratios at the claim line level, because that validation is the only method that catches a paid claim quietly running short against its contracted allowable. If infusion practices want to recover underpaid revenue, rather than discover it years later during a payer audit, they need a methodology built around these specific variables, not a general contract review borrowed from physician fee schedule work it was never designed to handle.