Claims system configuration is the set of provider, fee schedule, pricing and benefit rules a health plan's claims platform applies to every claim, and its accuracy is a different question from whether a claim is valid. Edits test whether a claim is complete and coded consistently; they do not test whether the rate the system used is the rate the contract sets for that date of service. A claims system configured with last year's schedule, an amendment never loaded or a reduction the contract waives will pay thousands of clean claims wrong without a single edit firing. Botminds' Provider Contract Management closes that gap by reading every setup row against the signed contract terms and every paid claim against the rate the contract sets, each night, and handing each difference to the configuration lead as an exact, test-priced change.
Examples from the solution are sample data on a fictional health plan. The research findings are from HHS's Office of Inspector General and CMS, linked where they appear.
A valid claim and a correctly paid claim are different tests
Valid: what claim edits test: Is the claim complete, coded consistently and payable under the member's benefits?
Right: what a configuration audit tests: Is the allowed amount the amount the governing contract sets for this provider, code and date of service?
Valid: what claim edits test: Coding rules, eligibility, authorizations, benefit design
Right: what a configuration audit tests: The signed agreement, its amendments, the schedule year and the payment policies the contract applies
Valid: what claim edits test: A rejection or a denial the provider sees at once
Right: what a configuration audit tests: A payment that looks normal and is short or over by a few percent
Valid: what claim edits test: The plan, at adjudication
Right: what a configuration audit tests: Usually the provider's revenue cycle team, weeks later
Valid: what claim edits test: Often one claim at a time
Right: what a configuration audit tests: Every claim priced from the wrong row since it went wrong
What is claims system configuration?
Claims system configuration is the translation of a health plan's contracts and benefit documents into the tables its claims platform reads: provider records and their links to pricing arrangements, fee schedules, rate methods, effective dates, payment policies and benefit rules. When it is right, claims price and pay without a person. When it is wrong, the platform repeats the mistake as reliably as it would repeat the right answer.
Provider pricing is the part of configuration this guide is about. Benefit configuration (deductibles, copays, coverage) has its own failure modes and its own audits. The two meet on the claim, but they come from different documents and different owners, and a plan that audits only benefits will not find a missed rate amendment.
Valid is not the same as right: why edits pass a wrong price
Claim edits are designed to reject what cannot be paid, not to recompute what should be paid. A claim for a covered service, billed with valid codes by a contracted provider for an eligible member, passes. If the rate row is stale, the edit has nothing to compare it with: the stale rate was a valid rate the day before the amendment took effect, and it still looks like one.
That is why configuration errors surface through disputes rather than through the claims operation. The provider's revenue cycle team compares the remittance with its own copy of the contract; the plan, in most cases, does not. The provider becomes the plan's audit, and the plan learns about each error at the speed of the provider's follow-up.
How do configuration errors cause wrong payments?
A configuration error turns one wrong decision into a rule. The HHS Office of Inspector General found that of 160,378 payment denials issued by 15 Medicare Advantage organizations in the first week of June 2019, an estimated 18 percent met Medicare coverage rules and the plans' own billing rules, and it attributed most of those to manual review errors and to "system processing errors (e.g., the MAO's system was not programmed or updated correctly)" (HHS-OIG, OEI-09-18-00260, 2022). It explained why the second kind matters more.
"system errors can cause greater harm because they automatically generate a potentially larger volume of incorrect denials until the MAO notices the error and fixes it."
HHS Office of Inspector General, OEI-09-18-00260 (April 2022)
The OIG's examples were denials, and its sample is from 2019, so they say nothing about how often contracted rates are configured wrong. They show the mechanism. In one case a plan's system picked the wrong tax ID for an in-network provider, making it look out-of-network; the plan told the OIG that "the same error may have affected 163 additional provider payment requests." In others, providers' disputes prompted plans to acknowledge errors "such as incorrect configuration of provider coverage details."
CMS draws the same lesson from its own 2025 audits of Medicare Advantage and Part D sponsors, listing among its examples that "Claims and provider payment systems used incorrect payment methodologies, benefit configurations, or provider information, resulting in inaccurate payments", and noting that such issues "often impact large numbers of enrollees before they are detected" (CMS, CY 2025 Part C and Part D program audit and enforcement report).
What are common claims configuration errors?
Most provider pricing errors fall into a handful of patterns, and each has a signature in the paid claims. The useful taxonomy is not by system screen but by what changed in the contract and failed to change in the setup.
Eight claims configuration errors, and the signature each leaves in paid claims
| Error | What happened | Signature in paid claims | Sample plan: claims, amount |
|---|---|---|---|
| Amendment signed, never loaded | A rate increase took effect; the row kept the old percentage | Every claim since the effective date short by the same percentage | 47 claims, $8,249.62 under |
| Per diem not updated | A facility amendment raised the daily rate | Every inpatient day short by a fixed dollar amount | 112 claims, $41,745.00 under |
| Last year's schedule still in setup | A "current-year" term was keyed to a fixed year | Short from 1 January, by however much the schedule moved | 57 claims, $27,311.55 under |
| Reduction the contract waives | A default multiple-procedure reduction applied to units 2 and up | Second and later units at half rate | 138 claims, $6,375.60 under |
| Payment policy revision missed | A modifier policy changed; the row did not | Lines with that modifier paid at the old percentage | 91 claims, $4,822.09 under |
| Rate decrease not loaded | A negotiated decrease took effect; the row kept the higher rate | Overpaid from the effective date: a recovery, not a dispute | 64 claims, $7,132.16 over |
| Percentage keyed wrong | A typing error at load | A constant ratio between paid and contract on every claim | 26 claims, $1,073.80 over |
| Telehealth term not applied | A reduced rate for video visits was never set up | Telehealth lines paid at the in-person rate | 38 claims, $1,018.02 over |
Two features of the list matter for an audit plan. First, errors run in both directions: on the sample plan, 445 claims were paid under the contract and 128 over it. A program that only hunts underpayments, or only overpayments, finds half the problem. Second, the signature tells the auditor where to look. A constant percentage gap points to a keyed percentage; a gap that starts on 1 January points to a schedule year; a gap that starts on an amendment's effective date points to a load.
Where the money paid off contract came from, by cause
One error, many claims: how far back to look
When a configuration error is found, the look-back should run to the date the error began, not to the date it was found. For a missed amendment that is the amendment's effective date; for a schedule-year error it is 1 January; for a keyed percentage it is the date the row went live. A finding that fixes the claim in front of the analyst and stops there leaves the rest of the error in place.
The look-back is also where the plan's exposure is set. Underpayments found by the plan before the provider complains can be reprocessed with interest on the plan's own timetable. Overpayments have their own limits: in Virginia, for example, a carrier may not retroactively deny or recover a previously paid claim unless one of the statute's conditions applies, the commonest being that no more than 12 months have passed since the payment (Va. Code § 38.2-3407.15(B)(8)). An overpayment that sits in the setup for 13 months may be one the plan cannot recover.
Every paid claim against its contract: under and over by provider, with the cause named
How do you audit a claims system configuration?
A claims system configuration is audited against the contract, not against itself. Comparing the live setup with last month's setup only finds changes; comparing it with the signed terms finds errors. The strongest audits combine three tests, because each catches what the others miss.
A configuration audit in three tests, and the questions behind each
- Row against contract
For every pricing row: does the method, percentage, schedule year, locality, effective date and end date match the latest signed term that governs it? This catches loads that were never made or were keyed wrong.
- Test-price the change before it goes live
Price five or more claim shapes through any new row: a code at each end of a range, two procedures together, a modifier, a service date the day before and the day of the effective date. CMS's own advice to sponsors is to "Validate cost-sharing calculations and payment methodologies before implementation."
- Paid against contract, every claim
Recompute each paid claim from the contract and compare. This catches what row audits miss: payment policy interactions, provider links that send a claim to the wrong arrangement, and contracts that changed without any row changing.
- Name the cause, not just the claim
Every gap should end with the row behind it and the date it began, so one fix and one look-back close the whole error.
- Check both directions
Overpayments are configuration errors too, and some can only be recovered for a limited time.
- Separate the auditor from the loader
The person or tool that finds a difference should not be the one that changes the setup; a named configuration lead approves each change.
What is a rate load audit?
A rate load audit is a check of newly loaded or changed pricing rows against the contract that required them, usually before the rows are released or shortly after. It answers "was this load done right," and it is the cheapest point at which to catch an error, because no claims have yet paid from it.
Its blind spot is everything that was never loaded. A rate load audit reviews the rows someone changed; an amendment that never reached the configuration queue produces no row to audit. That is why the row-against-contract test should start from the contract repository, not the change log, and why the paid-against-contract test is needed behind both.
How often should claims configuration be tested?
Claims configuration should be tested at every load, at every 1 January for terms tied to a current-year Medicare schedule, at every payment policy revision, and continuously against paid claims. Annual or quarterly sample audits find error rates; they are poor at finding errors, because a sample of a few hundred claims will rarely include the one provider whose amendment was missed.
The economics favour frequency. An error found the night after the first wrong claim costs one reprocessed claim; the same error found by the provider after a quarter costs every claim in between, the interest on each, a dispute response and, for overpayments, recoveries that strain the relationship. The interest arithmetic is in the prompt pay interest guide.
Who is responsible for claims configuration accuracy?
The health plan is accountable to the provider and the regulator; inside the plan, accuracy needs three named owners. The network contract manager owns what was signed. The configuration lead owns what is live. Someone, a payment integrity team or an independent check, owns the comparison between them, and reports differences to both.
The OIG asked CMS to "direct MAOs to take steps to identify and address vulnerabilities that can lead to manual review errors and system errors," and CMS concurred. For a configuration team that means a control that does not depend on the provider noticing first. The day-to-day work of the people who make the loads is described in the claims configuration analyst guide.
What Provider Contract Management checks each night, and what it leaves to people
Botminds' Provider Contract Management runs the three tests above as a matter of course. Its rate setup auditor reads each setup row against the signed terms; on the sample plan it read 14,880 rows against 2,418 agreements and found eight that differed. Its paid-claims checker compares every paid claim with the rate the contract sets for its date of service, each night; its design target is every paid claim checked against its contract every night. Each finding names the row, the change, the source page and the claims it corrects, test-priced on five sample claims.
Money found against the contract, by cause, and how fast people got a cited rate
It does not replace the claims system, the configuration team or the plan's coding edits. It never changes setup, never adjusts or reprocesses a claim and never applies an unsigned draft; the configuration lead approves every change and a person releases every reprocessing batch. The setup export and paid-claims file it reads are the plan's own, so the first step of any trial is connecting them. To see the screens together, start from Provider Contract Management.
Questions people ask
Can claim edits catch a wrong contract rate?
Generally not. Edits check whether a claim can be paid, using coding, eligibility and benefit rules; a stale rate is still a valid rate to the edit. Catching it requires recomputing the price from the contract and comparing, which is a separate control.
What is the difference between a rate load audit and a payment integrity review?
A rate load audit checks configuration rows against the contract before or shortly after release. A payment integrity review typically examines paid claims for overpayment, often on coding, medical necessity or billing grounds. Configuration accuracy needs a third check that most programs lack: every paid claim against its contract rate, in both directions.
How do you find claims paid under a missed amendment?
Start from the amendment's effective date and the codes it governs, select every paid claim for the provider's identifiers with service on or after that date, and recompute each one under the amendment. The OIG's review shows why the search must be systematic: one routing error at one plan may have affected 163 further payment requests.
What tolerance should a paid-versus-contract check use?
Enough to ignore rounding, and no more. The solution's sample plan uses $5.00 or 1%, whichever is greater. A wide tolerance hides keyed-percentage errors, which produce small, constant gaps on every claim.
Should the configuration team audit its own loads?
It should test them, and someone else should audit them. Separating the person who finds a difference from the person who changes the setup is the same separation of duties a plan applies to payments, and it keeps the audit from inheriting the loader's reading of the contract.