How Buy-and-Bill Reimbursement Logic Breaks Down Inside General Billing Software

Buy-and-bill reimbursement breaks down in general billing software because submitting a claim is not the same as protecting money already spent on a drug. An infusion-only RCM platform for buy-and-bill practices needs drug-unit logic, authorization tracking, quarterly pricing updates, and checks that payments meet the terms of each contract. Without those capabilities, revenue loss is a predictable result of the system’s design.

What buy-and-bill actually is and why its financial logic is unlike any other billing model

In buy-and-bill, the practice purchases a drug before administering it and collects reimbursement only after the payer adjudicates the claim. The practice also holds the inventory risk until administration. A denied claim therefore does more than delay payment for work performed. It leaves the practice waiting to recover the cost of a product it has already bought and used.

The reimbursement benchmark changes while the practice waits to get that money back. Medicare Part B pays at average sales price, or ASP, plus a statutory 6%, although sequestration reduces the effective rate further. CMS recalculates ASP every calendar quarter using manufacturer-reported sales data. The per-unit payment limit thus changes four times a year, and payment also varies with the terms of each payer’s contract. The same drug cannot be assigned one expected reimbursement value and left there.

That timing puts pressure on cash flow. The gap between purchasing the drug and receiving reimbursement is typically two to six weeks. A prior authorization denial, a downcoded administration CPT, or payment below acquisition cost can turn that gap into a cash-flow emergency. Both the drug line and its paired administration service affect what the practice recovers.

Why general billing platforms are not architected for any of these requirements

General billing platforms start from a different premise. Their central job is to assemble and submit claims, with drug billing treated as one part of a broader billing workload. Buy-and-bill instead makes the drug’s cost, billable units, and expected payment central to the transaction. The mismatch sits beneath the claim form. A platform may accept a drug code without having the logic needed to establish whether that code, its units, and its modifiers describe the treatment correctly.

These platforms lack three layers, a drug-unit logic engine, a quarterly ASP update mechanism, and a payer-contract variance layer. The first links the dose given to the rules for billing it. The second ties expected reimbursement to the right pricing period, and the third checks that payment meets the terms of the payer’s contract. Without those layers, staff must supply the reasoning that the software does not perform. A claim can go through even if that reasoning was wrong.

Even the code set needs active maintenance. The 2026 HCPCS Level II changes included added and deleted codes, so a platform without ongoing updates can keep billing a deleted code or fail to support a new one. Pricing creates a similar problem because a system calibrated to Q1 rates is already out of date by April. Connecting clinical doses, changing codes, current prices, and contract terms requires a different design premise beyond what a general platform gains through a configuration change.

How J-code unit errors become the first and most common revenue leak

The first common leak is the wrong unit count. J-code units come from the code descriptor, with the dose as written in the clinical record and the number of vials opened representing different quantities. That distinction controls how treatment becomes a charge. Without a drug-unit engine, a general platform has no native mechanism to enforce the conversion between the amount administered and the units billed. It can accept a number without establishing that the number represents the right billable quantity.

Weight-based dosing makes that disconnect more expensive. When a patient’s weight changes between authorizations, the billed units must match the dose the patient actually received. If charge capture is disconnected from clinical documentation, the claim can retain a unit count that no longer fits the treatment. Underbilling loses revenue, while overbilling creates a compliance risk. A claim with a valid J-code can still have either of these unit-count errors.

Wastage requires another distinction that a basic quantity field cannot make. CMS requires modifier JW for discarded drug and modifier JZ when there is no wastage on applicable Part B drug claims. A platform without wastage logic tied to vial type cannot reliably determine which scenario applies. The result can be a missing-modifier denial or an incorrect payment even when the administered dose is otherwise documented correctly. ACR practice data identifies substantial annual revenue losses in rheumatology from missing J-code units, incorrect infusion time documentation, and missed billable infusion add-on codes.

Where prior authorization failures are seeded before a single claim is submitted

By submission, the drug may already have been administered under an approval that does not cover every part of the encounter. Specialty biologic authorization may involve separate requirements for the drug, the site of care, and the administration service. Step therapy can require proof that prior treatments failed, while clinical criteria may call for lab values, imaging, or specialist notes in payer-specific formats. A general platform that does not participate in this pre-claim work cannot establish that those requirements have been met.

An authorization may end after a set number of sessions or within a defined time window. If renewal is not requested before expiration, later sessions can take place without valid authorization. The original approval is not enough on its own. Without lifecycle tracking, the billing platform cannot flag that an ongoing course of treatment has outlasted its permission.

Clinical changes can invalidate approval before its scheduled expiration. A mid-cycle drug switch or dose change requires a new authorization, but a platform that does not connect clinical orders to authorization status cannot alert the team to that change. The consequences reach patients as well as accounts receivable. Denied requests can delay treatment by days to weeks, with documented risk of increased glucocorticoid exposure during delays. Taylor et al.’s 2025 study found that centralizing financial coordinator workflow substantially reduced authorization-related denials and produced millions in cost savings. That finding places revenue cycle control at scheduling and authorization as well as claim submission.

How authorization mismatches — not missing auths — drive the hardest-to-recover infusion denials

An authorization can exist and still fail the claim. The hardest-to-recover infusion denials involve approval for the wrong site, formulation, or dose, or an approved unit count that has already been exhausted. These are not simple missing-document problems. The practice has an approval, but it does not match the treatment being billed. Resolving the denial requires correction of upstream documentation that a billing-layer tool cannot reach.

An authorization may be on file even though the clinical record does not consistently establish that required prior therapy was tried and failed. The payer can then deny on medical necessity grounds despite the approval. The documentation repair spans several records, including the referring physician’s notes, the infusion center’s intake record, and the prior authorization submission. Resubmitting the claim alone does not close that gap.

Payers have cut appeal windows from weeks to days. A center reviewing denials weekly or biweekly can miss the opportunity to appeal a winnable denial. That turns a correctable problem into a permanent write-off before the underlying documentation issue is resolved.

Labels such as “authorization,” “medical necessity,” and “coding” do not identify the specific payer policy, drug and administration code combination, or documentation gap involved. As a result, the practice can work individual denials without seeing the pattern that keeps producing them. Infusion denial management requires root-cause categorization at both payer and code level.

Why underpayments are invisible in general platforms and how they become permanent

A paid claim can still lose money. In buy-and-bill, payment posting must distinguish between the amount received and the amount owed under the applicable contract. General platforms post remittances as received without comparing each line against the expected rate for the drug, the quarter, and the payer’s contracted percentage. An underpayment can therefore enter the account as paid in full without drawing attention.

A payment that matched last quarter’s ASP may fall below the current expected rate, while a pricing change in the other direction can reverse that comparison. Without quarterly updates, the platform has no current rate to use to check whether payment is correct. Even a comparison against a stored rate is unreliable when that rate belongs to the wrong period.

Contract variance adds a separate requirement beyond current ASP. The platform must apply the terms of the specific payer’s contract rather than treat the pricing benchmark as the complete payment rule. Without that layer, even when drug coding is right and the claim is sent on time, the platform cannot tell whether the remittance covers what is owed. The claim can pass every earlier stage and still close with revenue missing. Because no denial arrives, the shortfall does not enter the denial workflow that might otherwise draw staff attention.

High per-unit drug costs amplify small percentage errors. A small underpayment on a single biologic claim can represent thousands of dollars, and the same error can repeat on later claims for that drug from that payer. Each remittance appears to be another completed payment, concealing another instance of the same shortfall. Until someone detects the pattern, the loss grows with claim volume and becomes a recurring drain on money already spent.

What billing software built for buy-and-bill actually handles that a general platform does not

A purpose-built infusion RCM system connects the clinical encounter to the financial checks that follow it. Its drug-unit logic translates administered doses into J-code units using the code descriptor and flags weight-based dosing discrepancies before submission. Wastage is part of that logic. The system applies JW and JZ rules by vial type and administered volume while maintaining modifier rules that reflect current CMS policy. This addresses the point at which a documented treatment can otherwise become an incorrect charge.

Authorization management follows the treatment across encounters. The system tracks both session limits and time windows, surfaces renewal deadlines before expiration, and links drug switches, dose adjustments, and frequency changes to authorization status. Approval is checked at every encounter. That connection gives the pre-claim workflow visibility into changes that would otherwise emerge as denials after administration.

The payment side needs equally specific controls. Expected reimbursement updates with each CMS ASP file release, and each payment is checked against the contracted rate for the drug, quarter, and payer before posting. Denial reporting then shows patterns for each payer and code, including specific combinations of J-code and administration code. A recurring denial becomes evidence of a specific upstream problem.

Software still does not make every judgment call. An infusion-focused RCM model combines these controls with hands-on operators across benefits verification, prior authorization, claims submission, denial management, payment posting, and accounts receivable management. Operators handle payer-specific escalation, documentation gaps, and appeal strategy that rules engines alone cannot resolve. The relevant comparison is therefore not simply which platform submits claims, but which one connects treatment, authorization, coding, and payment. Practices running buy-and-bill on general software are not merely making a vendor choice. They are making a revenue decision.