Est.

Why General-Purpose RCM Platforms Underperform on Infusion Billing at the Platform Level

Infusion billing's drug-cost and authorization complexity breaks general-purpose platforms.

· 8 min read
Cover illustration for “Why General-Purpose RCM Platforms Underperform on Infusion Billing at the Platform Level”
Platform & MSO Finance · October 25, 2026 · 8 min read · 1,776 words

An infusion-only RCM platform for buy-and-bill practices must connect drug cost, J-code units, recurring authorizations, and payer rules from scheduling through payment. General-purpose platforms underperform when their core data models treat those reimbursement relationships as billing details.

Why infusion billing breaks the assumptions built into general-purpose RCM platforms

General-purpose RCM platforms were built for the claims that make up most of the volume, including E/M visits, surgical procedures, and standard diagnostics. For those claims, reimbursement is mainly at risk when coding is wrong or filing is late, with less risk from drug-unit conversion or authorization across recurring treatment cycles. Infusion breaks that design assumption at its foundation. A claim can have valid codes and arrive on time yet still fail because the units, drug, or treatment date do not match the authorization.

Infusion requires benefits verification, authorization tracking, J-code calculation, drug-line payment reconciliation, and payer-specific denial management to work as one connected process. If the data model does not represent drug cost, J-code descriptors, and authorization-to-claim matching as core records, downstream rules cannot reliably use them. Scrubbing logic, work queues, and accounts receivable structures inherit the same omissions. Adding a field does not establish the relationships needed to detect a problem before treatment or trace it after payment.

How the 2026 payer environment raised the cost of architectural gaps

The 2026 payer environment makes it more important to match authorizations, keep coding edits up to date, and check claims against their documentation. CMS's Interoperability and Prior Authorization Final Rule places operational provisions, including decision timeframes, denial reasons, and public metrics, generally in January 1, 2026, while API requirements generally begin January 1, 2027. In practice, payer systems match authorizations against claims at the data-field level, including the exact CPT code, modifier, and site of service. An authorization for the wrong place of service can therefore produce an automatic denial.

NCCI bundling edit updates place a separate burden on static claim-scrubbing rules. A rule set that does not use current edits can miss conflicts before a claim is sent. Payment is no longer the last checkpoint, either. Sift Healthcare's Fourth Annual Denials Insights Report, published February 2026, identifies denial activity moving upstream and becoming fragmented across workflows, with growth in automated takebacks, post-payment recoupments, and AI-assisted payer adjudication.

Why J-code unit calculation is the most consequential task general-purpose platforms do not perform

J-code billing units come from the J-code descriptor. The conversion is the financially sensitive step. A general-purpose platform without drug-level validation can accept the resulting charge without recognizing that the unit calculation is wrong. When that error sits in the charge master, it is not confined to one entry. The same conversion can repeat across months of recurring treatment before a denial or audit exposes it.

Buy-and-bill makes that repetition especially costly because the practice has already paid for the drug. A denied J-code claim leaves the practice holding the full acquisition cost, typically $3,000 to $40,000 per infusion encounter depending on the drug, without reimbursement unless the denial is recovered through appeal. Many non-governmental payers use bundling methodologies and payment policies that differ from AMA and CMS interpretations for infusion and injection charges. A static scrubber cannot anticipate those payer-specific J-code denial patterns.

Even a correctly calculated claim can leave a drug margin problem that generic payment posting does not show. Average sales price, or ASP, reimbursement updates quarterly. When acquisition costs rise faster than the reimbursement rate, payment can fall below acquisition cost for up to two quarters. That gap requires drug-level margin tracking. Without it, the platform cannot distinguish accurate reimbursement from reimbursement that still fails to cover the drug.

Why recurring prior authorization creates a lifecycle management problem that general-purpose workflow structures are not designed to handle

An infusion authorization is permission for defined treatment. It may cover a limited number of sessions or a specific treatment window. Recurring therapy can outlast either limit without a renewal. If reauthorization is not submitted before expiration, later sessions in the same course can proceed with no valid authorization on file. An intake checkbox cannot show how that status changes.

The authorization is also specific to the drug. Approval for one biologic does not cover a second biologic when a physician changes treatment mid-cycle. A new authorization must be obtained before the next infusion, so the treatment change needs to trigger work before billing begins. For specialty medications, pharmacy and medical benefits also have different authorization rules, timelines, and criteria for approval. A single authorization queue does not adequately separate those paths.

At each submission, CPT/HCPCS codes, units billed, and dates of service need to match the authorization, while treatment modifications require a new authorization submission. Adding staff does not change what the platform represents. If it cannot model an authorization as time-bound, drug-specific, and cycle-aware, it cannot generate the needed renewal alerts or escalations from that record. Staff must compensate for a missing relationship.

How payer-specific denial patterns expose the limits of a single denial workflow

A denial reason code is not a complete explanation of what happened or what deadline applies. General-purpose systems group denials at the claim adjustment reason code, or CARC, level rather than mapping them to payer-specific adjudication logic and drug category. That grouping strips away distinctions needed for follow-up. A UHC modifier denial and a BCBS medical necessity denial do not represent the same problem, even if both arrive in the same general work queue. The platform needs to expose the payer and root cause together.

UHC's peer-to-peer review window runs from denial for a shorter period, while BCBS windows vary by state across a wider range. Applying the wrong timeline can turn a recoverable claim into a permanent write-off. The architectural gap is the failure to surface the claim's payer-specific route and deadline when the denial enters the system, before a reviewer has to reconstruct them.

How silent underpayments accumulate when payment posting has no drug-line reconciliation logic

A paid claim can still be an underpaid claim. General-purpose payment-posting modules confirm that money came in and post it to the ledger, but that does not show whether each drug line paid correctly. A payment below ASP plus the standard add-on percentage, or below the payer's contracted rate, can be recorded as paid without an exception. The missing comparison is expected payment against actual payment at the line level. Without it, the shortfall has no denial status to draw attention.

The expected amount also has to remain current. If the fee schedule does not reflect the current quarter's ASP, the platform benchmarks drug payments against a stale rate. Without the same comparison, a downcoded or bundled administration charge can look fully paid while the difference goes unseen. Many non-governmental payers use bundling policies that differ from CMS standards, so the applicable contract and payment policy must inform the comparison.

Payment posting cannot be treated as final closure, either. The same report shows growth in post-payment recoupments and automated takebacks, through which payers can recover money they have already paid. Without reconciliation, repeated shortfalls can accumulate across recurring drug payments while each claim appears settled. Once the remittance window closes, an unnoticed underpayment can become a permanent write-off. A proactive audit function is needed to reopen what ordinary posting has already treated as finished.

How flat AR aging structures obscure the highest-dollar infusion claims in the queue

A flat accounts receivable aging structure sorts claims by elapsed time without adequately distinguishing their financial exposure. A denied biologic claim can sit in the same bucket as a dispute over a low-dollar administration-code payment. Their ages may match, but their risks do not. Losing the administration payment is a smaller loss, while losing reimbursement for an acquired biologic can create a cash-flow emergency.

The claims also need different kinds of follow-up. Authorization and infusion-product classification discrepancies, medical necessity denials on continuing medications, modifier errors, and late follow-up on high-dollar unpaid claims are separate problems. A uniform queue obscures which one needs resolution. If priority does not depend on drug category, dollar value, and the issue behind the claim, the highest-dollar claims can stay buried until recovery windows close. The defect is not simply an inconvenient view of AR but a structure that fails to direct attention according to what the practice stands to lose.

Why these failures compound: the revenue cycle starts at scheduling, not at billing

These gaps share one mistaken starting point, which is treating claim submission as the beginning of the revenue cycle. For infusion, the conditions for reimbursement are already being set at scheduling, benefits verification, and treatment-plan modification. The claim arrives after those decisions have been made. A platform without authorization lifecycle tracking, drug-unit validation, or payer-specific rules gives no warning when there is still time to catch an avoidable problem before treatment.

A lapsed authorization can seed a denial, and a generic denial queue can hide the payer-specific deadline needed to recover it. Other claims in the patient's series may pay but be checked against stale ASP rates, allowing underpayments to close unnoticed. Meanwhile, unpaid high-dollar claims can age beside minor disputes without gaining priority.

Reimbursement has to be the organizing principle. That requires the authorization, drug, and payer to remain distinct, connected, time-aware records from intake forward. Without those connections, downstream teams must rediscover upstream conditions after the practice has incurred the drug cost. Sending a claim faster cannot fix an authorization that was already invalid when treatment took place.

What billing software must infusion centers use to handle buy-and-bill reimbursement?

An infusion-purpose-built platform must represent authorization as a time-bound, drug-specific, cycle-aware record. Expiration windows, changes in treatment, and the requirements of pharmacy-versus-medical benefits must set work in motion before anyone touches a claim. The platform must also validate J-code units at charge entry so that a charge master conversion error is caught before it repeats through a treatment series. Scrubbing after charge creation is too late to serve as the only control.

The same specificity must extend to denial handling and payment. Payer-specific denial logic must extend generic CARC grouping to connect root cause to the appropriate workflow and timeline. Payment posting must compare every drug-line remittance against the current quarter's ASP rate and the payer's contracted schedule. Exceptions need to remain visible even when a claim is paid. AR priority must then reflect drug category and dollar value alongside the claim's age.

A platform may have screens for authorization, billing, payment posting, and AR without linking the records that each needs. Information from intake must govern each later step. An infusion-purpose-built system must handle benefits verification, authorization lifecycle management, J-code billing, payer-specific denials, drug-line reconciliation, and AR prioritization as an integrated workflow.

More in Platform & MSO Finance