Claims processing software is the engine room of a health plan. Every claim a provider sends lands there, and the system decides within seconds or days whether it is paid, denied, or set aside for a person to review. Members feel the result as an explanation of benefits; providers feel it as cash flow.
This guide looks at the payer side: what a claims system does from intake to remittance, which edits and pricing logic run along the way, which deadlines a plan must meet, and where projects to build, replace or extend a claims platform go wrong.
What is claims processing software?
Modernizing a claims platform?
Agnotic builds claims intake, edit engines, pricing services and pend workflows for health plans and TPAs.
Claims processing software is the system a health plan or third-party administrator uses to receive provider claims, check them against member eligibility, benefits, coding edits and contracts, calculate the allowed amount and member share, and issue payment with a remittance. It is often one module of a core administrative processing system.
The aim is a high rate of claims that pay or deny correctly with no human touch, often called auto-adjudication, while sending the right exceptions to the right people. Both halves matter: a system that auto-adjudicates wrongly creates overpayments and appeals at scale.
How does a claim move through a payer's system?
A claim moves through a fixed sequence of stages, and each stage can stop it. Designing the system means deciding what each stage checks and what happens when a check fails.
- 1. Intake: The plan or its clearinghouse receives the X12 837 file, validates its syntax and returns acknowledgments, including a claim-level acknowledgment that says which claims were accepted for processing.
- 2. Member and provider match: The subscriber ID, name and date of birth match a member, and the billing and rendering NPIs match a provider record with a contract or network status.
- 3. Eligibility and benefits: Coverage was active on the date of service, and the service is a covered benefit under the member's plan.
- 4. Edits: Coding, clinical and policy edits check the claim lines, including duplicate checks against claims already paid.
- 5. Authorization match: Services that need prior authorization are matched to an approved request by member, service and dates.
- 6. Pricing: The allowed amount comes from the provider's contract, a fee schedule or a grouper such as DRG for inpatient stays.
- 7. Adjudication: Deductible, copay, coinsurance and coordination of benefits set the plan's payment and the member's share.
- 8. Payment and remittance: Payment goes out by EFT or check, the provider receives an X12 835 remittance, and the member receives an explanation of benefits.
Any stage can end in a pend: the claim stops and waits for a person or more information. Pend volume by stage is the clearest map of where a claims system needs work.
Which coding edits run before a claim is priced?
Before pricing, most plans run the CMS National Correct Coding Initiative (NCCI) edits plus their own payment policy edits. NCCI has two main edit types: procedure-to-procedure (PTP) edits for code pairs that should not be billed together, and medically unlikely edits (MUEs) that cap units of service.
CMS describes a PTP edit as a Column One and Column Two code pair: when a provider reports both for the same beneficiary on the same date, the Column One code can be paid and the Column Two code is denied unless a clinically appropriate NCCI-associated modifier is reported. CMS posts changes to the PTP files every quarter.
For Medicaid, the rules on timing are strict. The 2026 Medicaid NCCI Technical Guidance Manual says states must use the new quarterly edit files from the first day of each calendar quarter, that the new files fully replace the old ones, and that a state which has not applied them by the start of the quarter's second month must reprocess the claims it paid in the meantime. The same manual describes an MUE as a claim line edit, applied to the units on each line rather than the total for the day.
For engineering, that means the edit engine needs versioned edit tables with effective and deletion dates, a load process that runs before each quarter starts, and a way to rerun claims against a corrected table. Plans that store edits as code rather than data struggle with every quarterly update.
How does a claims system price a claim?
A claims system prices a claim by finding the contract or fee schedule that applies to this provider, this member's product and this service on this date, then applying its method. The lookup is usually harder than the arithmetic.
- Fee schedule: A rate per procedure code, often a percentage of a Medicare fee schedule, with modifiers that adjust it.
- Per diem: A daily rate for inpatient stays, sometimes tiered by day or level of care.
- Case rate or DRG: A payment per admission based on a grouper output, with outlier rules for unusually costly stays.
- Percentage of charges: A share of billed charges, common for out-of-network claims and some carve-outs.
- Bundles and capitation: Payment arrangements where some services are paid outside the claim or not paid per service at all.
Contracts change mid-year, providers move between groups, and rates are backdated after negotiations. A pricing service should store every rate with effective dates, record which rate version priced each claim, and support repricing a batch when a retroactive change arrives.
Which deadlines shape a payer's claims system?
Prompt-pay rules shape claims systems more than any feature request. They decide how fast pends must clear and when interest starts to accrue.
For Medicare Advantage, 42 CFR 422.520 requires the plan's contract with CMS to provide for paying 95 percent of clean claims within 30 days of receipt when the claims come from non-contracted providers or from members of a private fee-for-service plan. The plan must pay interest on clean claims not paid within 30 days, and other claims from non-contracted providers must be paid or denied within 60 calendar days.
Contracted providers are paid under the prompt-payment terms in their contracts, which the same regulation requires those contracts to contain. Commercial and Medicaid managed care plans face state prompt-pay laws with their own clocks and definitions of a clean claim.
The system needs the receipt date stored once and never overwritten, a clean-claim flag with the reason it changed, and aging reports by regulatory clock rather than by calendar month. Interest calculations should come from the same data, not a separate spreadsheet.
What should happen to claims that pend?
Pended claims should land in queues by reason, with the information an examiner needs already on screen. A pend that sends a person to three other systems to find the answer costs more than the claim's administrative budget.
- Routing by reason: Eligibility gaps go to enrollment, missing authorizations to utilization management, pricing gaps to provider contracting.
- Aging by clock: Queues sorted by days left under the applicable prompt-pay rule, not by arrival order.
- Requests for information: Letters or electronic requests for records generated from the pend, with the claim paused and the clock rules applied correctly.
- Medical review: Clinical reviewers see the claim, the policy that triggered review and the attached records together.
- Feedback loop: Every manual decision is recorded with a reason code, so recurring pends become candidates for a new rule.
What should the remittance tell the provider?
The remittance should tell the provider exactly why each line paid what it did. The X12 835 carries claim adjustment group codes, claim adjustment reason codes and remittance advice remark codes for each line, and the quality of those codes decides whether the provider can act without calling the plan.
- Specific reasons: Map each internal edit and pend outcome to the most precise reason and remark code available, not a catch-all.
- Line-level detail: Report adjustments on the line that caused them, so a denied add-on code does not look like a denied claim.
- Consistent EOB text: The member's explanation of benefits should describe the same decision in plain language.
- Reassociation: Make sure the trace number on the 835 matches the EFT, so the provider can match cash to remittance.
Vague remittances generate appeals, resubmissions and phone calls, all of which come back into the claims system as more work. Reviewing the top reason codes each quarter with provider relations is one of the cheapest improvements a plan can make.
Should a plan build, buy or extend its claims system?
Most plans should buy or keep a core claims platform and build around it. Writing a full adjudication engine from scratch is a multi-year commitment that few plans can justify, while the edges of the platform are where plans differ and where custom work pays back.
- Buy or keep the core: Membership, benefits, accumulators and adjudication are well served by established platforms.
- Build at intake: Pre-processing that cleans, enriches or splits incoming 837 files before the core sees them.
- Build edit and policy services: Plan-specific payment policies as a separate rules service, versioned and testable.
- Build pricing extensions: Contract types the platform handles poorly, such as complex bundles.
- Build the work layer: Pend queues, examiner screens and analytics on top of the core's data.
Where payer claims projects go wrong
- Configuration as code: Benefits and edits hard-coded, so every change needs a release.
- No replay: No way to rerun last month's claims through a new rule before turning it on.
- Lost dates: Receipt dates reset when a claim is corrected or resubmitted, breaking prompt-pay reporting.
- Silent edits: Denials that return a generic code, so providers resubmit unchanged and the plan processes the same claim twice.
- Duplicate logic: The same policy checked in intake, the core and a vendor tool, with three slightly different results.
A regression suite built from de-identified production claims, with expected outcomes, protects against most of these. Every rule or configuration change runs through it before release.
How Agnotic can help
Agnotic Technologies builds the custom layers health plans and administrators need around their core claims platform: 837 intake and pre-processing, versioned edit and payment policy services, pricing extensions, pend queues and examiner tools, and claim replay suites for testing rule changes before they go live.
Agnotic designs these services to keep receipt dates, rate versions and edit versions on every claim, so prompt-pay reporting, provider disputes and audits can be answered from the data rather than from memory.
Plan your claims processing work
Explore claims processing automation, or browse more revenue cycle articles.
Related reading on Agnotic
Compare the provider side of claims, Epic's payer platform and how AI and member expectations are changing health plans.
