Claims Payment Integrity Software: Why Post-Pay Recovery Costs You More Than the Errors Did

Every dollar you recover after payment costs more than the dollar was worth

A claim for a bilateral procedure comes in with a modifier that should have halved the second unit. Your core system prices it, the check goes out on Friday, and eleven weeks later a post-pay vendor flags it. Now the recovery path begins: a letter to the provider, an offset against a future remittance, a phone call from that provider's billing manager to your network director, and a note in the next joint operating committee meeting about payment accuracy. You recovered the money. You also spent staff time, consumed goodwill with a contracted provider, and paid a contingency fee on a dollar you already had.

That sequence is the single strongest argument for prepay, and every payment integrity leader already knows it. The reason plans stay in post-pay is not ignorance, it is architecture. Prepay intervention means inserting logic into an adjudication pipeline that is measured in cycle time and constrained by prompt payment statutes, inside a core administration system like Facets, QNXT or HealthRules that was not designed to have a third party reach into its pricing step. Post-pay is easy because it happens after the hard part. Prepay is where the value is because it happens before the abrasion.

The second thing every payment integrity leader knows is that the vendor stack has become its own problem. Two, three, sometimes four vendors each running edits against overlapping claim populations, each paid a percentage of what they find, each claiming savings on the same underpriced line. Attribution disputes at quarter end consume analyst time, and nobody inside the plan can independently reproduce the savings figures because the logic belongs to the vendors.

Your edits are somebody else's policy, and your policies are not in them

Start with what commercial editing does well. NCCI procedure-to-procedure edits, medically unlikely edits, standard bundling, modifier logic and coding relationship libraries are enormous bodies of maintained content, updated quarterly, and no plan should build them. Cotiviti and Optum maintain that content properly and it would be foolish to try to replicate it.

The gap is everything specific to you. Your medical policy says a particular imaging study requires a documented prior conservative therapy period. Your contract with a specific health system carves out an implant reimbursement above an invoice threshold. Your state Medicaid contract has a rate floor that overrides your standard fee schedule for a set of codes. Your plan made a network exception for a facility during a capacity crisis and it should have expired. None of that is in a rule library, because none of it is standard, and it is precisely where a plan's own money leaks.

Today those rules live in three places: a policy document a medical director wrote, a configuration in the core system that somebody set up years ago, and a set of manual review queues staffed by nurses and coders reading claims. The result is that a policy change takes a quarter to reach adjudication, and nobody can tell you which claims paid incorrectly during the lag.

What a custom build does: give the plan a rule authoring environment it actually owns. Rules are expressed against claim, member, provider, contract and authorisation data, they are effective-dated so a policy change applies from a real date and not retroactively by accident, and they can be simulated against a historical claim population before they go live. That simulation step is the feature that changes behaviour. A payment integrity analyst can write a rule, run it across last quarter's claims, see the hit count, the dollar impact and a sample of affected claims with their providers, and decide whether it goes prepay, post-pay or nowhere. Without simulation, every new rule is a gamble on provider relations.

Prepay has a latency budget and a legal clock, and both are unforgiving

The constraint that kills naive prepay designs is time. Your adjudication pipeline has a cycle time your operations team defends, auto-adjudication rate is a board-level metric, and prompt payment statutes in most states set a hard clock from receipt of a clean claim. A prepay integrity layer that adds seconds per claim at volume, or that routes too many claims to manual review, converts a savings programme into a claims backlog and a regulatory finding.

What a custom build must include: a hard latency budget enforced in the design, with rules classified by whether they can execute synchronously in the adjudication path or must run asynchronously in a pended queue. Synchronous rules are deterministic and fast: coding relationships, contract term lookups, fee schedule comparisons, duplicate detection against an in-memory window. Anything requiring clinical review, document retrieval or an external call goes asynchronous with a pend reason and a service level that respects the prompt payment clock rather than ignoring it. The system must also fail open in a defined way, because an integrity layer that stalls when a dependency is slow will hold the entire claim flow, and that is a far worse outcome than paying a claim you would have edited.

The other half is the pend queue itself. Every pended claim is a decision waiting on a human, and the queue needs prioritisation by expected value and days remaining on the statutory clock, not first in first out. Plans that run prepay well watch two numbers together: dollars saved and the age distribution of pends. Watching only the first is how you end up with a compliance problem.

Contract-aware pricing is where the real money is, and rule vendors do not have your contracts

The largest dollars in payment integrity are usually not coding edits, they are contract application: a claim priced against the wrong fee schedule version, an outlier calculated on a stale cost-to-charge ratio, a carve-out not applied, a percent-of-Medicare arrangement using a superseded rate, an implant or drug pass-through paid without the invoice validation the contract requires. These are not coding errors. They are the plan paying something other than what it agreed to pay.

HealthEdge Source is genuinely positioned here and pricing transparency against reference-based schedules is its strength, so if your gap is purely Medicare-referenced pricing accuracy, look there first. What still tends to be left to the plan is the messy middle: negotiated language that does not fit a standard pricing model, letters of agreement, single case agreements, and the drift between what the contract document says and what the core system was configured to do.

What a custom build does: treat the contract as data with an owner and a version, and make repricing verification a routine rather than an audit. Every paid claim can be independently repriced against the contract terms of record and compared to what adjudication actually paid, with variances above a threshold surfaced daily. That single control catches configuration drift within days instead of at the next contract renegotiation, and it works in both directions, which matters because overpayments and underpayments both damage a provider relationship.

Vendor stacking, attribution and the contingency trap

Contingency pricing aligns a vendor with finding savings, and it aligns them against telling you how. When three vendors run overlapping edits, the plan pays for duplicated work, absorbs multiplied provider abrasion from repeated inquiries on the same claims, and cannot arbitrate attribution disputes without the logic.

What a custom build does: become the traffic controller even where vendors remain in the stack. Claims are routed to vendors by population with explicit suppression so two vendors do not touch the same claim for the same concept. Every vendor finding is recorded with the concept, the claim and the timestamp, so first-touch attribution is a fact rather than a negotiation. Findings that your own rules would have caught prepay get flagged, and over a couple of quarters that report is the objective basis for renegotiating or retiring a vendor. Most plans that build this do not eliminate vendors, they shrink the stack to the ones providing content they genuinely cannot maintain and move the rest in-house where the marginal cost per claim is near zero.

The dispute loop is your best source of rule quality

Every provider dispute on an edited claim is free feedback about your rules. A rule producing a high overturn rate on appeal is not saving money, it is generating work and damaging relationships while eventually paying anyway. Most plans cannot compute overturn rate by rule because disputes live in a different system than the edits.

What a custom build does: close the loop. Each edit that reduces or denies payment carries its rule identity into the remittance, the provider portal explanation and the dispute record. Overturn rate by rule, by provider and by concept becomes a standing report, and rules above a threshold are automatically flagged for review and can be suspended by an analyst without a release. That governance is what separates a payment integrity programme from a friction generator, and it is also what your network team will ask for first when they hear you are expanding prepay.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A first release covering a rule authoring and simulation workspace, a contract-aware rule engine, synchronous and asynchronous execution paths integrated into your adjudication flow, and a pend queue with statutory clock awareness runs $100,000 to $200,000 over 14 to 20 weeks. A full platform adding independent repricing verification, vendor routing and suppression, savings attribution, provider dispute integration with overturn analytics, and post-pay recovery orchestration runs $280,000 to $650,000 phased over 9 to 15 months.

Cost drivers specific to payment integrity: which core administration system you run and how it exposes an intervention point, because Facets, QNXT and HealthRules each present a different integration problem and some plans have more than one. The number of lines of business, since Medicare Advantage, Medicaid and commercial carry different rules and different clocks. Contract data quality, which is the most underestimated item on every proposal we have seen, because if your contract terms exist only as PDFs and tribal knowledge then structuring them is a real workstream. And whether clinical review is in scope, which brings clinician workflow and documentation retrieval with it.

What holds cost down: starting with repricing verification against contracts. It requires no adjudication intervention, it runs on claims you already paid, and it usually finds enough to fund the next phase.

Build versus buy

Buy if you are under roughly 1 million claim lines a year. The fixed cost of running a payment integrity engine does not amortise, and a vendor on contingency is genuinely the efficient answer at that scale.

Keep buying the content libraries regardless of size. Coding relationship content, NCCI-derived edits and clinical coding rules are maintained bodies of work updated quarterly by teams of coders, and rebuilding them would be a category error. What you build is the layer that holds your policies, your contracts and your control.

Build when two of these are true. You pay contingency fees large enough that the annual figure exceeds a build budget, which happens surprisingly early. Your own medical and payment policies take a quarter or more to reach adjudication. You cannot independently reproduce your vendors' savings claims. Or your network team has escalated provider abrasion from post-pay recovery to the point where the CFO and the Chief Network Officer are having a recurring argument. That last one is often the real trigger, and it is a legitimate one, because the fix is structural rather than diplomatic.

How to choose a developer for payment integrity software

Ask where in your adjudication flow they would intervene and what latency budget they would commit to. If they cannot name a specific hook in your core system and a millisecond target, they are going to build a batch process and call it prepay.

Ask what happens when their service is slow or unavailable during a claim run. Fail-open behaviour with alerting is the correct answer. Anything that holds claims is worse than the problem being solved.

Ask how an analyst tests a rule before it goes live. Simulation against a historical claim population with dollar impact and a claim sample is the feature that decides whether the system gets used. Without it, every rule change requires an engineer and a leap of faith.

Ask how rule identity reaches the remittance and the dispute record, because if it does not, you can never compute overturn rate by rule and your governance is guesswork. Then settle ownership: you should own the repository, the cloud environment, the rule content you author and all historical decisions, in writing before kickoff. At Digital Heroes the client owns the lot from the first commit, and in a category where vendors have historically kept the logic, that ownership is most of the point.