Why Your RCM Platform Is the Root Cause of Infusion Reimbursement Leakage

Infusion reimbursement leakage is a platform design problem when billing software cannot track treatment-linked authorizations, protect buy-and-bill drug costs, or detect line-level underpayments. An infusion-only RCM platform for buy-and-bill practices needs to handle those dependencies before claims become recovery work. Ruby is an infusion-specific platform built around that model, with claim controls and hands-on operators so staff do not have to fill the gaps by hand.

Why infusion billing leakage is a platform design problem, not a people problem

More billing staff may clear one backlog but fail to stop the next. That is the diagnostic error behind treating infusion leakage as a staffing problem. A general-purpose platform built for office visits models billing as episodic, relatively low-dollar, and light on authorization dependencies. Infusion is recurring, high-dollar, authorization-dependent, and exposed to drug acquisition costs. When the platform cannot represent those differences, more staff can work the resulting errors without removing their cause.

The failure often starts before billing begins. When benefit verification is left unfinished, authorization requirements are missed, or payer-specific rules go unnoticed before treatment, the resulting problems are visible later in accounts receivable. By then, the team is trying to recover payment for care already delivered. A denial may look like someone missed a task at submission, even when a check was needed at scheduling or authorization intake.

Payer restrictions still add work, and staff still need to make sound calls. But neither explains why the same preventable error keeps reaching the claim. If staff must keep separate records to link treatment schedules, authorization limits, and billing requirements, they are doing work the platform lacks the logic to do. That distinction changes the diagnosis from poor execution to a workflow design that depends on people to compensate for it.

How infusion's authorization structure creates risk that generic platforms are not designed to track

An authorization is not a standing permission to treat. Approval for month one does not automatically cover month six, because authorized visit counts are fixed in advance. Claims beyond that count are denied for the overage. A platform that records approval without tracking the remaining visits against the treatment schedule can show an authorization as obtained while later encounters fall outside it.

An authorization for an outpatient setting does not cover the same service delivered at a different site. Commercial payers have tightened site-of-care restrictions by directing nonurgent infusions away from hospital-based settings. The date window is equally exact. Care given even one day outside the effective window is treated as unauthorized care, though the usual standard internal appeal rights still apply in most cases.

Continuing treatment can also trigger stricter medical necessity reviews, mandatory biosimilar substitution, step therapy enforcement, shorter expiration timelines, and more peer-to-peer reviews. These requirements make approval an ongoing lifecycle. The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) adds rules to follow, with some rules for day-to-day work generally taking effect on January 1, 2026. Staff who handle authorization by hand and fax must keep up with these changing rules as well as the treatment calendar.

A competent team can track these dependencies manually. Tracking these dependencies manually strains bandwidth at a mid-size infusion center’s volume and payer-rule complexity. An infusion platform instead needs expiration dates tied to scheduled treatment, authorized counts tracked against submitted claims, site-specific coverage, and escalation before a lapse.

Where buy-and-bill drug exposure turns a platform gap into a cash-flow emergency

In buy-and-bill infusion, the practice pays for the drug before submitting the claim. That changes what a billing failure puts at risk. An authorization or coding error can leave the practice unable to recover an acquisition cost it has already paid.

J-code billing requires both a CPT code for the infusion service and a J-code for the drug, correctly coded and aligned. Without that pairing, the claim is incomplete and can deny or underpay. A generic platform that does not enforce the pairing at charge entry allows the problem to leave the practice. The money has already gone out the door. Claim validation comes too late if it begins only when the denial returns.

Among J-code failures, errors in the unit count put the most money at risk. A high-dose biologic billed with the wrong unit count can underpay substantially on each claim. If the same error runs through a week’s infusion claims, the losses can add up to a large amount of revenue over a year. The check must confirm both that a drug code is present and that the billed units match the dose record.

New biologics add another timing problem. A drug can reach the market before CMS assigns a permanent J-code, so it must be billed with not-otherwise-classified (NOC) codes or temporary Q-codes. Even after a permanent code is assigned, reimbursement runs on wholesale acquisition cost until ASP data catches up, typically two to three quarters later. Biosimilars add a separate coding hazard because billing the reference product’s J-code for a biosimilar, or the reverse, creates compliance and audit risk. Crosswalk tables that lag those changes cannot protect charge accuracy.

In its Q4 2025 earnings release, InfuSystem Holdings said work on a new revenue cycle management platform had moved forward and that claims cost less to process and billing ran more smoothly. The publicly traded provider of infusion pumps and related healthcare services offers a concrete example of the operational stakes. Its report does not establish a particular solution for independent buy-and-bill practices.

Why paid claims hide as much leakage as denied ones — and generic platforms never look

A denied claim stays in view because it has not been paid. A paid claim can disappear from active work even when the amount is wrong. Generic platforms that close the workflow at payment posting treat receipt as completion. In infusion, that can turn an undetected variance into a permanent write-off, because the drug line may have paid less than the practice was owed.

The NDC-to-J-code crosswalk is a concrete example. An outdated mapping, a wrong conversion factor, or a mapping to a cheaper equivalent NDC can result in fewer milligrams being reimbursed than were administered. When drug database maintenance falls behind infusion billing cadence, that error can affect every claim using the same mapping. The remittance still shows a payment for the drug. Without line-level review of the mapping and expected payment, the shortfall stays hidden.

Other errors can survive payment posting for the same reason. Infusion hierarchy misapplications, truncated time-based units, drug wastage coding gaps under JW/JZ modifier rules, and incidental supply bundling require more than a check that payment arrived.

Audits done from time to time can find some of those losses. But they identify money already missed, potentially after the claim has been written off, while reconciliation at posting can flag the variance before the recovery window closes. The distinction is architectural. A platform built around episodic claims has little reason to include infusion’s detailed remittance logic, while one built for infusion needs payment verification at the line level as part of the claim’s normal path.

How AR aging in infusion reflects platform failures that happened weeks before a claim was submitted

Aged accounts receivable shows how earlier flaws in the design leave money unpaid. The authorization lapse began against a treatment schedule, and the unit error began at charge entry. Neither originated in the collections queue. Treating the resulting aging balance only as a follow-up problem obscures the point at which the platform could have prevented it.

Infusion’s recurring pattern makes that delay more damaging. The same patient may get the same drug under the same payer, often each month. An unresolved denial cause or systematic underpayment can therefore affect subsequent encounters until the cause is corrected. More effort on the oldest claim does not stop that repetition.

High-dollar biologics need to remain distinguishable from routine infusion claims, with denials visible by drug category and payer and priorities tied to dollar exposure. AI-assisted prioritization can help sort this work. It cannot fix a design that keeps letting flawed claims age, so AR aging shows how well upstream controls work as well as how well collections are going.

What billing software do infusion centers need at each failure point?

At authorization, infusion-appropriate software holds the treatment plan in view with the authorized visit count, effective dates, place of service, and expiration timeline. It alerts before coverage lapses.

At charge entry, the design shifts to drug and unit integrity. The platform enforces CPT-plus-J-code pairing, maintains NDC-to-J-code crosswalks at infusion billing cadence, and checks billed units against dose records. It also flags NOC/Q-code situations when a permanent J-code does not yet exist, with all these checks performed before submission. Their purpose is to stop incomplete or inconsistent charges while the claim is still within the practice’s control.

At remittance, the platform compares each payment line with the contracted rate as part of posting. A paid claim is still subject to review. Underpayments are flagged on each claim without waiting for a monthly audit, so there is still time to act before the recovery window closes.

Denial management then preserves the information needed to prevent recurrence. Root cause and payer are each shown on their own instead of being lumped into one overall denial rate. A payer-specific policy change and a systematic coding error need to be distinguishable because they point to different corrections. AR prioritization follows the same principle. Claims are segmented by drug category and dollar exposure, with high-dollar aged biologics surfaced separately and supported by escalation workflows.

Ruby is built specifically for this operating model, combining infusion-specific workflows with hands-on operators. It checks claim integrity before submission and looks for underpayments at remittance, without waiting for a quarterly audit to find losses. But software alone is not the complete specification. Automation handles volume and flags exceptions, while operators address payer-policy nuance, peer-to-peer review escalation, and appeal construction. Operators without infusion-specific platform support must bridge the same gaps manually, just as a platform without operators leaves judgment calls unresolved.

The diagnostic question infusion practices should ask about their current platform

A vendor’s claim that its platform is good at RCM needs to be tested against its ability to demonstrate the controls infusion billing requires without a parallel manual system. A conversation with the current vendor should put four questions to that claim.

For authorization, can the platform show any active patient’s remaining authorized visits, expiration date, and advance alert threshold without a spreadsheet that staff have to keep up to date? For charge entry, does it enforce CPT-plus-J-code pairing and validate units against dose records before submission, or catch errors only after a denial returns?

For remittance, does it compare every line with contracted rates and flag underpayments before completing payment posting, or post the payment and close the claim? For denials, can it report rates separately by root cause and payer, or provide only an aggregate rate that hides recurring patterns?

A “no” or an answer that staff handle the control manually identifies a design gap. The next step is a focused evaluation. For a practice that finds one or more of those gaps, evaluating Ruby against these same questions is a natural way to test whether a different platform and operator model can address the source of its leakage.