Claims Processing Software: A US Buyer's Guide

Last updated: 27 May 2026

If you're handling claims at scale in the US — health insurance, P&C, life, retail warranty, chargebacks — the manual way eats hours. Agents keying in details from phone calls, emails and PDFs. Claims sitting in someone's inbox waiting for review. Payments chased separately from the claim record. It's not that it doesn't work; it's that every handoff is a chance for something to go wrong, and the PCI or HIPAA exposure rides along with every re-keyed card or member ID.

This guide walks through what claims management software does (it's the same thing as claims processing software — the names are used interchangeably), what US insurers and self-insured employers should look for when choosing one, and how Paytia's SecureFlow platform fits in when the claim includes a payment step. For the healthcare-specific overlap with PHI, see our companion pieces on HIPAA and payment processing and HIPAA-compliant credit card processing.

What claims management software actually does#

At its simplest, claims processing software is workflow automation dressed up for a specific job: moving a claim from "submitted" to "paid and closed" with as few manual steps as possible. A claim comes in by phone, web form, email, fax, or EDI X12 837 feed. The system validates the details, routes the claim to the right adjuster or examiner (or auto-adjudicates if it fits the rules), handles any payment owed, and records every step for auditors and regulators.

The reason this matters isn't just speed. Manual claims handling is where errors creep in — a wrong member ID, a CPT code that doesn't match the diagnosis, a payment that went to the wrong account, an out-of-network provider miscoded as in-network. Those errors cost money and frustrate members and providers alike. Automated validation catches them at intake, not three weeks later when the provider chases.

Where the payment step changes things#

A lot of US claims involve money moving: an insurance payout to a policyholder, a warranty refund, a medical reimbursement to a provider, a utility credit, a co-pay collection at the front desk. The moment a card, bank account, or ACH detail enters the workflow, two things happen. First, the work becomes regulated — PCI DSS if a card is involved, HIPAA if there's protected health information attached, sometimes TCPA too if you're calling policyholders to collect premium. Second, anywhere that payment data touches your systems becomes part of your compliance scope.

This is where a lot of in-house claims systems go wrong. They get the workflow right but treat the payment as an afterthought — "we'll just take the card at the end and process it through our merchant account." That single decision can drag every system the payment touches into SAQ D, which is 329 PCI DSS requirements versus the 22 in SAQ A. That's the difference between "compliance is a line item" and "compliance is a department."

Good claims processing software handles the payment step as a first-class part of the workflow and keeps card data out of your environment. Paytia sits in this layer: the claim lives in your system, the money moves through ours, and the card number never touches your servers. The architectural pattern is the same one explained in our tokenization explainer.

EDI X12 837 and 835 — the format that runs US healthcare claims#

Healthcare claims in the US move on the ASC X12 standard, mandated by HIPAA's Administrative Simplification provisions. If your claims operation touches any healthcare line, X12 is the rail you're either on or fighting against. Two transaction sets sit at the heart of the workflow.

The 837 is the healthcare claim. A provider sends it to the payer to bill for services rendered. There are three variants — 837P for professional (physician, therapy, lab), 837I for institutional (hospital, skilled nursing, home health), and 837D for dental. The 837 carries the patient demographics, the diagnosis codes (ICD-10), the procedure or service codes (CPT, HCPCS, CDT for dental), the dates of service, the provider identifiers (NPI), the place of service, the charges, and any prior-authorization or referral references.

The 835 is the healthcare claim payment and remittance advice. The payer sends it back to confirm what they're paying, what they're denying, and why. The 835 contains the claim-level adjustments, the line-level adjustments, the patient responsibility (deductible, co-insurance, co-pay), the reason codes for any adjustment, and the payment reference (check number or EFT trace number). The 835 is also the document that drives the matching of payer remittances to the original claim in the provider's accounts receivable — without it, posting payments back into your accounting becomes manual labor.

Beyond those two, the supporting cast is:

• 270/271 — eligibility inquiry and response. "Is this patient covered, and what does the plan look like?"
• 276/277 — claim status request and response. "Where's my payment?"
• 278 — referral certification and authorization request and response.
• 820 — premium payment from employer to payer.
• 834 — benefit enrollment and maintenance.
• 277CA — claim acknowledgement, sent by the payer or clearinghouse to confirm receipt and front-end validation.
• 999 — implementation acknowledgement, confirming that the file was syntactically valid.

The technical detail matters because mismatches between any of these are the single biggest source of friction in US healthcare billing. An 837 that fails the 999 doesn't reach adjudication. An 837 that reaches adjudication but doesn't match the 270/271 eligibility check gets denied. An 835 that doesn't line up with the original 837 leaves the provider chasing the difference. Any claims system that says it "supports EDI" should be able to walk through which of these it produces, consumes, and surfaces in its UI.

Payer adjudication — what actually happens between submission and payment#

Adjudication is the payer's decision process — what they'll pay, what they won't, and why. The mechanics are largely the same across major US payers, though each one has its own quirks in the implementation.

The claim arrives in the payer's intake system, usually via a clearinghouse that does the front-end validation. The first check is eligibility — was the patient covered on the date of service, what plan were they on, are there coordination-of-benefits questions to resolve. The second is provider validation — is the rendering provider in-network, is the NPI valid, is the taxonomy code consistent with the services billed. The third is medical necessity and code validity — do the CPT codes align with the ICD-10 diagnosis codes, are there required modifiers, does the place of service make sense for the procedure.

From there the claim hits the pricing engine, which applies the contracted fee schedule (in-network) or the usual-and-customary rate (out-of-network), then the benefit engine, which applies the patient's deductible, co-insurance, co-pay, and out-of-pocket maximum. The result becomes the allowed amount, the payer's portion, and the patient responsibility — all of which flow out on the 835.

Adjudication can be fully automatic (auto-adjudication, which most payers target at 80-90% of clean claims) or routed to a claims examiner for manual review when something needs human judgment. Pre-authorization status, coordination of benefits, suspected fraud, and missing data all push claims into manual review. The cost difference between auto-adjudicated and manual claims is large — manual review can cost a payer $20-30 per claim in labor and overhead, versus pennies for an auto-adjudicated claim. That's why payer-side claims technology investments tend to be measured in auto-adjudication rate improvements.

Denials management — the work after the no#

Claim denials are a structural feature of US healthcare billing, not a sign that something is broken. Industry data puts the average initial denial rate somewhere between 5% and 15% depending on the specialty and the payer mix, with a substantial portion of those denials being recoverable on appeal. A denials management workflow is what turns recoverable denials into collected revenue.

The 835 carries the reason for any adjustment via two code sets: the Claim Adjustment Group Code (CAGC) — PR (patient responsibility), CO (contractual obligation), OA (other adjustment), PI (payer-initiated reduction), CR (correction or reversal) — and the Claim Adjustment Reason Code (CARC), which is a specific reason like "missing diagnosis code" or "service not covered under this plan." The Remittance Advice Remark Code (RARC) adds context. Together these tell the provider whether the denial is recoverable and what the path back is.

A good claims system surfaces denials by reason, by payer, and by trend so the provider can attack the systemic ones first. The patterns that repeat — wrong place of service, missing modifier, prior auth not on file, eligibility lapsed — are usually fixable upstream by tightening the intake validation rather than re-working denied claims downstream. The ones that genuinely need appeal go into a tracked workflow with the appeal letter, supporting clinical documentation, and a deadline (most payers cap the appeal window at 60-180 days from the original denial).

For provider-side organizations, denials management is often where the ROI of a new claims system shows up first. A 1% reduction in denial rate on a $50M annual billing volume is $500K — usually more than the cost of the software.

Payment flow types you'll need to support#

Most American claims operations have to handle several payment shapes at once. The architecture decisions are different for each.

Inbound card payments. Premium collection, co-pays, deductibles, restocking fees on warranty returns. The classic CNP risk lives here — phone capture exposes agents and call recordings unless you have DTMF masking in front of the gateway. Recurring premium billing also needs a token vault or network tokenization (Visa Token Service, Mastercard Digital Enablement Service) so you're not storing PANs on file.

ACH debit for premium. The dominant rail for monthly premium debits — cheaper than card interchange and predictable. Nacha rules around authorization, return-code handling, and pre-notes apply. Make sure your claims system records the authorization timestamp and source (IVR, web form, signed paper) and surfaces it in the audit trail. Our ACH payments guide covers the rail-level mechanics.

Outbound push payments for claim payouts. The big shift in the last few years. Carriers used to send paper checks; now they push to a debit card via Visa Direct or Mastercard Send, or to a bank account via FedNow (for higher-value, time-sensitive payouts) or same-day ACH. The customer experience win is real — a Geico, Progressive, State Farm, Allstate, Liberty Mutual, USAA, Travelers, Farmers or Nationwide policyholder who gets their auto-claim payout in under an hour is a policyholder who renews.

Provider reimbursements. Healthcare claims pay providers via EDI 835 (electronic remittance advice) paired with ACH or, for high-value reimbursements, wire transfers. The 835 must match the 837 that started the claim — mismatches are the single biggest source of provider-side back-office friction.

Refunds with negative interchange impact. Refunding a premium overpayment to a card costs you the interchange you collected on the original transaction and the refund processing fee on top. The math sometimes favors pushing the refund back via ACH instead. Your claims system should let you choose the rail per refund rather than hard-coding "send it back the way it came."

Push-to-card payouts — Visa Direct, Mastercard Send, FedNow#

The shift from paper checks to push payments is the most visible change in US claims operations of the last five years, and the rail choices each have different economics, settlement times, and limits.

Visa Direct is Visa's push-payment platform, sometimes called OCT (Original Credit Transaction). It lets you push funds to any eligible Visa debit, prepaid, or credit card. Most US debit cards are eligible. Settlement to the recipient's card is typically within 30 minutes, often faster. Per-transaction limits are set by the issuer but typically run $2,500-$10,000 for individual recipients. The fee structure is per-transaction (originator pays), usually a few dollars or a percentage, depending on the originator's volume and contract.

Mastercard Send is the Mastercard equivalent — push to Mastercard, Maestro, and Cirrus cards. Same essential mechanics, similar settlement times, similar per-transaction limits. Most claims platforms that support push-to-card support both rails so the recipient's card brand determines which one fires.

FedNow is the Federal Reserve's instant payment rail, launched in July 2023. It's a 24/7/365 service that settles in seconds between participating bank accounts. Per-transaction limits are set by the participating bank but can run up to $500,000 (Fed-set transfer limit; banks often impose lower limits). For higher-value payouts — a homeowner's insurance claim of $35,000 after a roof loss, a death benefit, a major medical reimbursement — FedNow is the right rail when both sides' banks participate. Adoption is growing; by mid-2025 over 1,000 US financial institutions were on the rail.

Same-day ACH sits underneath as the fallback for any account FedNow doesn't reach. Settlement is end-of-business-day for the originator's processing window. Per-transaction limit raised to $1M in 2022. Cheaper than FedNow per transaction but slower.

A well-designed claims payout flow runs the rails in priority order: check whether the recipient has a card on file (Visa Direct or Mastercard Send for sub-$10K), check whether the recipient's bank is on FedNow (FedNow for higher-value or where instant matters), fall back to same-day ACH otherwise. The policyholder sees "funds in your account in under an hour" without caring which rail did the work. That experience is what insurance carriers actually compete on now for claims service.

Integration with major US TPAs and payers#

For carriers and self-insured employers, the claims platform almost always has to connect to one or more third-party administrators. The major TPAs in US healthcare — Optum, Cigna, Aetna (now CVS Health), Anthem (now Elevance), Humana — each have their own claim submission portals, X12 file formats, and edit rules on top of the X12 standards. "Supports X12 837" is necessary but not sufficient; a TPA-specific connector that knows the local quirks is what makes the integration work without a payments team babysitting every batch.

The TPA relationships matter on the payout side too. When the TPA is adjudicating on behalf of a self-insured employer, the payment instruction can come back as an 835 to the provider plus a separate banking instruction to the employer's depository — or as a consolidated payment from the TPA's account with reconciliation back to the employer. Either pattern works, but your claims system has to handle the reconciliation cleanly. Reporting back to the self-insured employer (utilization, denial rate, average days to pay) is where the value proposition for the TPA gets re-earned every quarter.

On the P&C side, claims processing connects to body shops and contractors via DRP (direct repair programme) networks, to mortgagees on home claims (the bank holding the mortgage usually has to co-endorse a payout above a threshold), and to subrogation vendors who chase recoveries from at-fault parties' insurers. Each integration is another vendor in the data flow, and each needs to be on the right side of your compliance scope.

Reg E and ACH refund mechanics#

When you reverse or refund an ACH transaction, Regulation E governs the consumer-side rights and timelines. Reg E applies to electronic fund transfers from consumer accounts and is implemented by the CFPB. The relevant clocks are tight.

A consumer who notices an unauthorized or erroneous ACH debit has 60 days from the statement on which the error first appeared to notify the financial institution. The institution has 10 business days to investigate, with the option to extend to 45 days if it provisionally credits the consumer's account during the investigation. For new accounts (less than 30 days old), point-of-sale transactions, or foreign-initiated transactions, the extension can run to 90 days.

The practical implication for a claims operation: if you're debiting premiums from policyholders' bank accounts, you need to handle Reg E disputes inside your claims system, not as a separate dispute desk. The system should record the dispute timestamp, the policyholder's claim, the investigation status, the provisional credit if applied, and the final resolution. The 10-business-day clock starts when the consumer notifies you, not when you got around to looking at it. "We were short-staffed" is not a defence.

Nacha return codes also matter. An R01 (insufficient funds) means try again; an R02 (account closed) or R03 (no account/unable to locate account) means stop and fix the file; an R07 (authorization revoked) means stop permanently and treat any further debits as unauthorized. The claims system should auto-stop on revocation returns and surface them to the operations team — re-presenting after an R07 is the kind of mistake that triggers a CFPB complaint.

What to look for#

When you're evaluating claims processing software, the feature list from the vendor is less useful than answers to a few direct questions about how it actually behaves.

Can you configure the workflow without a developer? The workflow is the product. If changing an approval threshold or adding a reviewer requires a support ticket, the software will lock you into its view of how claims should work rather than yours. American carriers each operate differently — your software shouldn't force them into a single template.

What happens to card data? The honest answer is either "it goes through our PCI DSS Level 1 infrastructure and never touches your systems" or "you'll need to handle PCI compliance yourself." There isn't a comfortable middle ground here; ask directly.

Does it speak EDI X12? For health and dental claims this isn't optional — HIPAA mandates standard transaction sets. The system has to ingest 837 (claim), produce 835 (remittance advice), and handle 270/271 (eligibility), 276/277 (status), and 278 (referral/authorization) at a minimum. Ask to see actual transaction samples, not a marketing claim.

How does it handle the messy cases? A claim that splits across multiple payments, a refund that needs to go back to the original card under Visa or Mastercard rules, a dispute that reopens a settled claim, an underpayment that triggers an 835 reversal. These are the everyday realities of US claims work, not edge cases.

What does the audit trail actually record? You want timestamped entries for every status change, every approval, every payment attempt — including failed ones — and the user identity behind each. When a state Department of Insurance examiner or an internal SOX auditor asks about claim 4417 from eleven months ago, the answer has to be in the system, not in someone's memory.

How does it integrate with what you already run? Policy admin, billing, document storage, accounting, EHR (for healthcare). The less double-entry between systems, the fewer reconciliation problems you'll spend your Fridays solving. For carriers running Guidewire, Duck Creek, Majesco, or Salesforce Financial Services Cloud, ask for the connector or integration pattern up front.

Industry contexts#

The shape of a claim varies a lot by sector, even when the underlying workflow is similar. A few examples of where the detail matters for US operations.

Property and casualty insurance — auto, home, commercial, specialty. High document volume (photos, police reports, contractor estimates), multi-party coordination (adjusters, body shops, contractors, mortgagees on home claims), and state-by-state regulatory reporting on top. Claims often split across multiple payments and reviews. Geico, Progressive, State Farm, Allstate, Liberty Mutual, USAA, Travelers, Farmers and Nationwide all run on this shape. The payment is typically outbound to a claimant, increasingly via Visa Direct or Mastercard Send.

Health insurance — medical claims, pre-authorization, reimbursement, member co-pay collection. HIPAA shapes almost every technical decision. The volume is staggering: roughly 5 billion claims a year across the US system, with EDI X12 837 inbound and 835 outbound as the standard. Payment can be inbound (member co-pays at point of service), outbound (provider reimbursement), or both inside the same case. Integration with EHR systems is mandatory rather than optional. For self-insured employers, the same patterns apply via the TPA.

Life and health — the payment side here is dominated by outbound payouts (death benefits, living benefits, disability income) and inbound premium debits. The claim timeline is much longer than P&C, and the per-claim payout is much higher. Wire transfers are common at the top end; same-day ACH or FedNow for everything else.

Financial services — payment disputes, chargebacks, fraud claims, billing corrections. Tight regulatory reporting into Visa, Mastercard, the CFPB, or state banking regulators. The data you're handling is financial and personal in equal measure. Reg E timelines (10 business days for provisional credit, 45 days for final resolution) drive the workflow design.

Utilities — service interruptions, billing disputes, damage claims, refunds. Lots of field coordination — someone physically goes to a site, writes up the damage, and that has to come back into the claim record. Customer expectations are low, which means even a moderately responsive process looks good.

Retail warranty — warranty claims, returns, refunds, shipping damage. The claim volume is high and the per-claim value is often low, so the workflow has to be lean or the margin disappears. E-commerce platform integration matters more than in other sectors.

HIPAA, TCPA and PCI overlap#

The three regimes US claims operations bump into most often are HIPAA, TCPA and PCI DSS, and they overlap in interesting ways.

HIPAA covers protected health information — anything that identifies a patient and relates to their health, treatment, or payment for care. If your claims system stores PHI, the system itself, the people with access, the business associates (your software vendor, your hosting provider, anyone with a BAA) and the technical controls all fall under HIPAA. Encryption in transit and at rest, role-based access, audit logging, breach notification within 60 days, and minimum necessary access are the headline obligations.

TCPA matters when you call or text policyholders about premium collection, missed payments, or claim updates. Prior express consent is required for autodialed calls or texts to a cell phone. The recent FCC clarifications around revocation of consent (a policyholder can revoke in "any reasonable manner") make it important that your claims system records consent state and surfaces it before an outbound dialer fires. Damages start at $500 per call and can run to $1,500 per call for willful violations — TCPA class actions are a real line item for US carriers. Our TCPA compliance for payment calls guide walks through the consent and revocation rules in detail.

TCPA particularly bites on premium collection calls. A monthly auto-policy premium that fails on ACH triggers a follow-up call. If that call is autodialed to a cell phone and prior express consent isn't on file or has been revoked, every call is a $500-$1,500 statutory damages exposure. Class actions multiply that across the affected customer base — a 2020 settlement against a major retailer over autodialed reminders ran to $76M, and similar cases against insurers run in the seven figures regularly.

PCI DSS covers cardholder data, as discussed above. The interaction with HIPAA matters: if a member pays a co-pay by card during a healthcare interaction, you've got PHI and cardholder data in the same transaction. The cleanest architecture is to separate the two — let the claims system handle the PHI and have a PCI Level 1 provider take card payments over the phone, with the two systems communicating via tokens rather than raw PANs.

How Paytia fits in#

We build claims processing software on Paytia SecureFlow. The difference between this and an off-the-shelf product is that SecureFlow is a platform, not a shrink-wrapped application — we configure it to your claims process rather than asking you to adapt yours to ours. For most US customers, that means a phased delivery: the critical path live in weeks, the harder integrations following in agile cycles.

The other thing SecureFlow brings is that the payment step is already inside the platform. When a claim is approved and needs to pay out, the payment runs through Paytia's PCI DSS Level 1 infrastructure — no separate merchant integration, no extra PCI scope for you to manage. When a claim includes an inbound payment (a co-pay, a deductible, a retailer return that came with a restocking fee), the same applies in reverse: the card data goes to us, the claim record stays with you. Push-to-card via Visa Direct or Mastercard Send is built in for outbound claim payouts; ACH and FedNow for higher-value bank-to-bank disbursements.

Paytia has held PCI DSS Level 1 certification since 2016 and has processed $500M+ in card payments across retail, healthcare, financial services, insurance and government. Our New York office (447 Broadway, 2nd Floor) runs implementations across North America.

Frequently asked questions#

What's the difference between claims processing and claims management?

Claims processing is the nuts and bolts — intake, validation, adjudication, payment, closure. Claims management is the wider picture: reporting, analytics, performance review, process improvement, regulatory filings to state DOIs. They sit one on top of the other. You need both, and they should share a database so your reporting isn't fighting your operations for ground truth.

How long does implementation take?

It depends on how much of your process needs building. Simple workflows live in 1-2 weeks; more involved systems with multiple integrations (EHR, policy admin, billing, EDI gateway) run 4-8 weeks or more. We work in weekly release cycles, so the essentials go live first and the rest follows without a big-bang go-live.

Does it integrate with our existing systems?

Yes — the platform exposes APIs and webhooks, plus pre-built connectors for the common CRM, ERP, accounting and EHR tools used by US carriers and TPAs. Most customers keep the systems they already have and let SecureFlow sit between them, pulling and pushing data as the claim moves through the workflow. For EDI X12 we either integrate with your existing clearinghouse or stand up the connection directly.

Is it HIPAA-compliant?

The payment side is PCI DSS Level 1 certified — that's Paytia's core. For the surrounding claim data we use encryption in transit and at rest, role-based access, and a detailed audit trail on every action. For healthcare deployments we'll sign a BAA, follow the HIPAA minimum-necessary principle, and walk through the technical controls that apply to your specific data flows rather than ticking a generic compliance box.

What about TCPA when calling policyholders?

The platform records consent state per policyholder per channel and surfaces it before an outbound call or text fires. Revocations propagate immediately. If you're using an autodialer for premium collection, the consent record is the document the platform produces in a TCPA dispute — and it's why detailed audit logging matters as much as the workflow itself.

What industries use it?

P&C insurance, health insurance, life insurance, financial services, utilities, retail warranty — any US business where a claim or dispute has to move from "submitted" to "settled" through multiple steps and people. If you're processing more than a few hundred claims a month manually and hitting the limits of spreadsheets, shared inboxes and paper trails, it's the right conversation.

If you'd like to talk through how a claims workflow might look for your business, get in touch. We can walk through the steps and where the payment layer fits.

The audit trail — what state DOI examiners and internal auditors actually ask for#

State Departments of Insurance run market conduct examinations on carriers. Self-insured employers run their own audits on TPAs. Internal audit, external SOX auditors, and OCR investigators all run their own variants. The audit trail is what answers their questions, and the gaps in audit trails are where examinations turn from routine into painful.

A working claims-system audit trail captures, per claim and per event, the timestamp (with timezone), the user identity (with role), the action taken (status change, document upload, payment attempt, approval), the before-and-after values for any data change, the IP address and session ID where applicable, and the reason or note attached to the action. "Status changed to approved" is necessary but insufficient — the auditor wants "changed to approved by Jane Doe (Senior Adjuster) at 14:32:07 EST on 12 March 2026 with note 'Coverage confirmed via 271, no prior auth required for this CPT code.'"

The audit trail also has to cover the payment side. Every payment attempt — successful, declined, reversed, refunded — needs to be linked back to the claim, the user who initiated it, the rail used, the amount, the fee, and any return code. State DOIs increasingly look at average days to pay and payment accuracy as part of their consumer-protection reviews, and the data has to be there to answer the questions.

Retention is the other half. HIPAA requires audit log retention for at least six years from the date of creation or the date last in effect, whichever is later. Most state insurance regulations require similar or longer retention on claim records. SOX requires seven years on financial records that touch material reporting. The claims system should retain the audit trail at least to the longest applicable standard, with secure deletion (not just logical deletion) when retention expires.

Build vs. buy vs. configure — choosing the right delivery model#

The decision to build a claims system in-house, buy a packaged product, or configure a platform isn't usually a single choice — it's a stack of choices about which parts to build, which to buy, and which to assemble.

Building everything in-house is a multi-year project that typically delivers a system perfectly fitted to current operations and badly fitted to whatever operations look like in three years. The maintenance burden is heavy — every regulatory change (PCI DSS version bumps, HIPAA security rule updates, state TCPA precedents, Nacha rule changes, new X12 transaction codes) has to be tracked and implemented by the in-house team. For carriers with very unusual workflows or very specific regulatory positioning, this can still be the right call; for most, it ends up being more expensive than the alternatives.

Buying a packaged product — Guidewire ClaimCenter, Duck Creek Claims, Majesco Claims, Sapiens IDIT — gets you a working system fast but locks you into the vendor's view of how claims should run. Configuration is available within limits; customization usually requires the vendor's professional services or a certified partner. For a P&C carrier looking to consolidate from older legacy systems, this is often the most direct path.

Configuring a platform — workflow-and-integration tools that aren't claims-specific out of the box, fitted to the claims workflow during implementation — is the middle path. The platform brings the technical infrastructure (workflow engine, audit logging, integration framework, identity and access management); the implementation brings the claim-specific logic, integrations, and screens. The trade-off is more implementation effort upfront in exchange for a system that fits the carrier's actual operations rather than the vendor's reference customer's operations.

The right choice depends on volume, regulatory complexity, integration count, and how unusual the workflow actually is. The wrong choice is usually "buy a product because it has the most logos on the vendor's customer page" — those logos tell you the product can run a claims operation, not that it can run yours.

Implementation pitfalls — the ones that turn 8-week projects into 8-month ones#

A few patterns we see repeatedly across US claims system rollouts.

Underestimating data migration. Moving 5 years of open and closed claims out of a legacy system, cleaning the data, mapping it to the new schema, and validating that nothing was lost is almost always more work than the original estimate. The right approach is a phased migration: start with new claims on the new system, leave open claims on the legacy system for a defined run-off period, archive closed claims for reporting.

Skipping the parallel run. Running the new system alongside the old one for a few weeks catches the integration mismatches and data-conversion issues before they become operational fires. Skipping the parallel to save time saves nothing.

Treating training as a one-time event. Adjusters and examiners learning a new system need practice, refreshers, and a feedback loop into the implementation team. "We did the training week" is the wrong end-state.

Letting integrations slip out of scope. Policy admin, billing, EHR, accounting, document management, EDI clearinghouse, banking, identity provider — each one is a project of its own. The bill of materials should be locked at the start, with clear criteria for what's in the first release and what's in subsequent ones.

Skipping the compliance review before go-live. A privacy officer or compliance lead should walk through the production system with the implementation team, sign off the data flows match what the BAA assumes, and confirm the audit trail meets the regulatory requirements. Doing this after go-live is twice the work.

Related reading#

• HIPAA-Compliant Payment Processing: A US Guide
• HIPAA-Compliant Credit Card Processing: The Honest Guide
• TCPA Compliance for Payment Calls
• ACH Payments for B2B: A Practical Guide
• PCI DSS v4 for US Contact Centers