Split billing is where a compliant 340B program either proves itself or starts to come apart. Software can flag a claim as eligible, but that alone doesn't make the replenishment supportable. If accumulations don't trace cleanly from the encounter to the dispense and then to the purchase record, you aren't running a 340B inventory process. You're creating audit exposure.
That matters even more in a program this large. Drug Channels reported that discounted purchases under the 340B program reached $100 billion in 2025, with hospitals accounting for 87% of purchases. At that scale, pressure for transparency and accountability doesn't show up in the abstract. It shows up in the accumulator, the replenishment file, and the records your team has to produce when someone asks why a particular NDC was bought on the 340B account.
Before replenishment logic matters, claim eligibility has to be right
Covered entities sometimes talk about split billing as if the difficult part is the software build. It isn't. The difficult part is making sure the claim feeding the accumulator was actually eligible under the entity's policy and backed by the underlying record.
In practice, the mapping starts with a basic question: what event is the system treating as the qualifying use of the drug? For an in-house pharmacy claim, that usually means the dispense record plus the encounter data supporting patient and provider eligibility under the covered entity's rules. For administered drugs, it can mean a documented administration tied to the encounter and charge detail. If that underlying event isn't clean, the replenishment transaction doesn't become defensible just because the software moved it into a virtual 340B bucket.
Administrators know the real-world version of this problem: the claim that is technically matched but operationally wrong. The patient had a visit. The prescription adjudicated. The system found the prescriber and the location. Then someone discovers later that the encounter record wasn't finalized, the provider record wasn't mapped the way policy requires, or the dispense was reversed and rebilled in a way the accumulator didn't unwind correctly.
The software can still show an eligible unit count. An auditor won't care that the queue looked normal on the day of dispense.
That is why the split billing build has to reflect actual policy decisions, not assumptions buried in vendor logic. If your team can't explain in plain language which data elements make a claim eligible and which exceptions force it out, then you don't have enough control over replenishment.
On replenishment, this is inventory accounting, not retroactive justification
Replenishment works only when the covered entity can show that eligible utilization accumulated and then triggered a purchase on the correct account. The key word is show. Not infer. Not reconstruct from memory.
In a replenishment model, the physical bottle on the shelf isn't the point. What matters is whether the records support a virtual segregation of inventory, so the entity can demonstrate that eligible dispenses or administrations were offset by 340B purchases while non-eligible use was offset by non-340B purchases. When this falls apart, the same mistake usually sits underneath it: people treat the purchasing side as the proof.
It isn't. A 340B wholesaler invoice proves product was bought at the 340B price. It doesn't prove the entity was entitled to buy that quantity on the 340B account.
The auditable chain usually runs the other way. Start with the patient-level event. Confirm it met the covered entity's eligibility standards. Verify that the claim or administration was captured by the accumulator the way it was supposed to be. Confirm any carve-in or carve-out treatment was applied consistently under entity policy. Then trace how that accumulated use turned into a replenishment purchase.
If a reversal, return, transfer, wastage adjustment, or late charge changed the utilization record, the inventory record should show the correction. If it doesn't, the covered entity is relying on luck.
This is where virtual inventory records actually do the work. An auditable system should let the entity trace why a particular replenishment occurred, what eligible utilization supported it, and what later adjustments changed that support. If the record tells you only that "the system ordered it," the record is too thin.
Once contract pharmacies are involved, clean mapping gets harder
The same logic applies in contract pharmacy, except the operational risk is higher because more parties touch the data. Drug Channels reported in its 2026 analysis that nearly two-thirds of the U.S. pharmacy industry participates as contract pharmacies for 340B hospitals and federal grantees, and that five large chains and PBMs account for 77% of all relationships. The practical takeaway is straightforward: a covered entity can't assume that a large network or a large administrator creates clean accumulations by default.
Contract pharmacy replenishment depends on claim feeds, data transformations, reversal handling, inventory assignment rules, and settlement logic that often sit outside the covered entity's direct control. If the entity doesn't know how the administrator handles timing mismatches, claim edits, resubmissions, and prescriber or location crosswalks, it can't really attest that replenishment is accurate. It can only hope the black box is right.
Not a compliance strategy.
One common scenario is the claim that qualifies on the first pass but changes after downstream adjudication activity. The pharmacy reverses and rebills. The third-party administrator updates one file but not another. The replenishment has already posted. Months later, the covered entity is staring at a purchase record supported by stale claim logic.
If contract pharmacy oversight stops at monthly savings reports, it misses the part that matters. A covered entity needs to know which party owns each control and which report proves that control worked. That includes claim capture, exclusion logic, replenishment timing, duplicate prevention, and adjustment handling. If a vendor performs the function, the covered entity still owns the compliance risk.
What an auditor actually wants to see
Auditable inventory records don't have to be fancy. They have to be complete, consistent, and reproducible. The standard is practical: can the covered entity take a questioned purchase or questioned claim and walk it back through the record set without gaps?
The documents and data that matter usually include the covered entity's written policy for eligibility, accumulation, and replenishment; encounter, dispense, or administration records supporting the qualifying use; crosswalks for providers, locations, and product mapping used by the split billing system; accumulator and adjustment reports showing how eligible utilization was built and corrected; and purchase records tying replenishment to accumulated eligible use.
What gets entities into trouble is the gap between policy and actual system behavior. A policy says one thing, the pharmacy build does another, and no one tests edge cases until there's a problem. That gap gets bigger after system conversions, clinic restructures, wholesaler changes, or contract pharmacy administrator transitions. Every one of those changes can quietly alter the claim-to-purchase mapping logic.
There is a broader compliance point here too. MedLearn's reporting on federal enforcement activity outside 340B shows how aggressively billing and documentation failures can be pursued when records don't support what was claimed. The article cites an HHS OIG semiannual report highlighting more than $5.5 billion in monetary impact from enforcement actions. 340B is its own regulatory framework, but the lesson carries over cleanly: if the record set doesn't support the transaction, the explanation that "the system did it" won't save anyone.
The safest posture is boring discipline. Freeze your eligibility rules in writing. Test the accumulator against actual claims. Reconcile reversals and adjustments. Review whether replenishment outputs still match policy after operational changes. Make sure the records tell the story without oral explanation, because someday they may have to.
