When a member has two health plans, someone has to decide which one pays first. About 43.1 million people in the US (13.1%) held more than one type of coverage in 2021, and most of them had Medicare plus a private plan, according to the Census Bureau. For a payer, each of those members is a small bet. If the plan pays as primary when it should have paid second, it covers a bill it never owed and then has to win the money back.
Federal audit reports show how that bet goes wrong, and the causes turn out to be ordinary ones. Staff overrides an automatic claim hold, Medicare information arrives after a claim is paid, and recovery sometimes starts more than a year late. Each of those is a repeatable, rule-based step, which is where smart RPA earns its place.
- In short: Coordination of benefits (COB) decides which plan pays first when a member has more than one. Payers lose money when the order is wrong, and two federal audits of Blue Cross Blue Shield plans trace that loss mainly to staff overrides of automatic claim holds and Medicare information that arrives after payment, with slow recovery making it worse. Smart RPA, meaning bots that follow fixed steps across claims and eligibility systems plus document reading, can take four jobs in that chain: sweeping paid claims when late data lands, flagging overrides, entering other-coverage records, and tracking recoveries. People keep rule conflicts, member disputes, and recovery negotiations.
What Is Coordination of Benefits?
COB is the process that decides which plan has primary payment responsibility, and how much the other plans contribute, when one person is covered by more than one plan. CMS describes it as the way to identify available benefits, pay claims correctly, and prevent payments that add up to more than 100% of a claim.
The payer carries most of the risk. A provider bills the plan on file, and the plan pays according to the coverage record it holds on that day. If that record is missing a second plan, or lists the wrong order, the claim pays in full when it should have paid partly or not at all. Nobody notices until another source surfaces the other coverage, and by then the plan is chasing a recovery.
That other coverage surfaces late for ordinary reasons. Carelon notes that plan memberships change constantly through marriages, job changes, and other life events, and that members often do not know which plan is primary. For Medicare, CMS collects other-insurance data through employer data-sharing agreements, the COB Agreement (COBA) program, and Section 111 reporting by insurers, so a plan’s own records can lag behind what CMS holds.
How a Plan Decides Who Pays First
State regulators use the order-of-benefit rules in the NAIC Coordination of Benefits Model Regulation as a model for their own COB rules. The rules run top to bottom, and the first one that settles the question wins.
| Rule | Example | NAIC reference |
| The plan that covers the person as a member, not a dependent, pays first | A spouse’s own employer plan pays before the plan she holds as a dependent | Section 6(D)(1) |
| Birthday rule: for a child covered by both parents, the parent whose birthday falls earlier in the calendar year has the primary plan | Parents born in March and August, so the March parent’s plan pays first | Section 6(D)(2)(a) |
| Divorced or separated parents: a court decree comes first, then custody | The decree names one parent responsible for medical costs, so that plan pays first | Section 6(D)(2)(b) |
| Active employee coverage pays before coverage as a retiree or laid-off employee | A person still working has a retiree plan on the side | Section 6(D)(3) |
| Coverage through an employer pays before COBRA or state continuation coverage | A person leaves a job, keeps COBRA, and joins a new employer plan | Section 6(D)(4) |
| If nothing else settles it, the plan that has covered the person longer pays first | Two plans with no other deciding factor | Section 6(D)(5) |
The rules look simple on paper. In practice, each one needs a fact the plan may not hold, such as a parent’s birthday, a court decree, or the date a retiree plan began. Medicare adds its own federal secondary payer rules on top. CMS runs a dedicated recovery center for that work. A plan cannot rely on the NAIC rules alone for members who also have Medicare.
Where COB Overpayments Come From
The clearest public look at COB errors comes from two audits by the Inspector General of the US Office of Personnel Management (OPM). They examined how Blue Cross Blue Shield plans in the Federal Employees Health Benefits Program coordinated claims with Medicare. The scope is narrow: one federal program with Medicare as the other payer, so treat the figures as examples and not as industry averages. The pattern is specific enough to test against your own claims data.
The 2019 audit covered claims reimbursed between October 2017 and June 2018 and identified $3,149,770 in COB overpayments, including $736,653 that the Blue Cross Blue Shield Association had already recovered before the audit began. Its high-dollar review looked at 2,022 claim lines worth $1,185,140 and sorted them by cause:
| Cause | Claim lines | Questioned costs |
| Processor error: staff overrode the system’s automatic hold for Medicare review | 1,073 | $634,046 |
| Retroactive changes: Medicare information arrived after the claim was paid, and earlier claims were not adjusted | 431 | $347,394 |
| System error: the claims system failed to hold a claim for Medicare review | 290 | $110,049 |
| Provider billing error | 60 | $55,070 |
| Non-COB errors, such as pricing | 168 | $38,581 |
53.5%. Share of questioned costs in the 2019 high-dollar review that came from processor errors ($634,046 of $1,185,140, calculated from the report’s cause table).
Source: OPM Inspector General report 1A-99-00-19-001
The 2022 audit looked at 2019 and 2020 and found a smaller problem with a different shape. It identified $107,108 in overcharges across 80 claim lines, all caused by Medicare enrollment information that reached the plans’ claims system after the claims were processed. The plans had paid those claims correctly on what they knew at the time. They recovered $101,025 of the money, but local plans were slow to review the daily report that lists retroactive enrollment changes.
15 of 80. Recoveries in the 2022 audit started more than one year after the updated Medicare information was available. The report warns that Medicare may deny claims received more than a calendar year after the date of service.
Source: OPM Inspector General report 1A-99-00-21-019.
Read together, the two reports show three separate failure points. A system raised the right flag, and a person overrode it. Data changed after payment, and nobody swept back through the paid claims. A report listed the problem claims, and the recovery waited for someone to read it. Each of those is a timing or control failure, not a hard coverage question, and each can be closed by a step that runs on time, every time.
Where the Manual Effort Sits
COB work runs as a chain, and the manual effort piles up at the handoffs between steps. The chain below shows where a bot runs the step and where a person decides.
Step 2 needs a person when the rules conflict. The other steps are sequences of lookups, comparisons, and record updates that a bot can run the same way each time, though disputes and negotiated recoveries still reach a person.
What Smart RPA Does in the COB Chain
Smart RPA here means two things working together. RPA bots follow fixed steps across the plan’s claims, eligibility, and recovery systems, the way a staff member would. Document reading, meaning optical character recognition and classification, lets the same bots handle the PDFs, scans, and forms that carry other-coverage information. What follows is a proposed design built from the audit findings above. It is not a description of a finished Nalashaa deployment.
1. Sweep paid claims when late data lands.
When an updated Medicare record or other-coverage file arrives, the bot reads its effective date, queries every claim paid for that member since then, and lists the ones that should have paid as secondary. This job targets the cause the audit calls retroactive changes. The 2022 audit found that the plan’s system already produced a daily retroactive enrollment report, and recovery waited for someone to review it. A bot can read that report the day it arrives and open the recovery cases from it.
2. Check every override against the coverage record.
The 2019 audit’s largest cause was staff overriding the system’s automatic hold. A bot can pull the log of released holds, compare each claim with the member’s coverage record, and route the mismatches to a supervisor for review. The bot does not take the override decision away from the processor. It makes sure a second reviewer sees the ones that conflict with the record.
3. Turn documents into coverage records.
COB questionnaires, member letters, and employer files reach a plan as PDFs, scans, and spreadsheets. Document reading classifies each one and pulls out the other plan’s name, policy number, effective dates, and the member’s relationship to the subscriber. The bot then writes the record and flags anything incomplete for a person. The goal is a shorter gap between the plan learning about other coverage and the claims system knowing it.
4. Track recovery dates and escalate.
Each recovery case carries dates: when the information became available, when the request went out, when a reply is due, and any timely-filing limit. The 2022 report warns that Medicare may deny claims received more than a calendar year after the date of service, and it found 15 of 80 recoveries that started more than a year after the updated information was available. A bot can watch those dates and escalate cases before they cross the limit.
Where RPA Stops
Bots handle the repeatable steps in COB well. Four parts of the work still belong to people.
Conflicting rules and court decrees. When two plans’ provisions disagree, or a divorce decree decides who is responsible for a child’s medical costs, someone has to read the document and make the call. The NAIC rules for divorced or separated parents turn on exactly that kind of paperwork, and document reading can extract the text but cannot weigh it.
Coverage nobody reported. A bot acts on the data that arrives. If a member never mentions a second plan, nothing triggers the workflow. Carelon notes that members often do not know which plan is primary, so outside data sources and member outreach still matter. The bot’s job starts when that data lands.
Recovery terms that differ by contract. A person with authority has to set the timelines, wording, and escalation rules the bot follows. The bot applies them consistently, but it should never invent them.
Member data and sign-off. Recovery requests carry member coverage details. HIPAA defines payment for a health plan to include coordination of benefits and collection activities, so the work itself is a recognized plan function. The plan’s access controls and audit logs still decide what a bot can see and send, and compliance should approve the letter templates before any bot uses them.
Five Questions to Answer Before Automating
- How many days pass today between other-coverage data arriving and a lookback on paid claims?
- Which systems hold the other-coverage record, and do they agree with each other?
- How often do processors override COB holds, and does anyone review those overrides afterward?
- Which timely-filing and recovery deadlines apply across your contracts and your Medicare work?
- Who approves recovery letters, and which fields can a bot send without a second look?
The answers show which of the four jobs above is worth building first. A plan that sweeps late data within a day but never reviews overrides has a different first project than one with the opposite gap.
Where Nalashaa Fits
Nalashaa Healthcare builds RPA and intelligent document capture for healthcare payers, and pairs the bots with AI validation where fixed rules fall short. For COB, that combination covers the two halves of the work: reading the documents that carry other-coverage information, and running the claim lookbacks, override checks, and recovery tracking that follow. You can see the wider range of healthcare automation services on the Nalashaa Healthcare site or contact us at info@nalashaa.com.
Bottom Line
COB overpayments rarely come from hard coverage questions. In the federal audits cited here, they came from overrides of automatic holds, Medicare data that arrived after payment, and recoveries that started late. Each of those is a step a bot can run on schedule, with people handling the rule conflicts, member disputes, and recovery negotiations. A plan that starts with one of those four jobs, and measures its own gap first, will know what smart RPA is worth in its own claims data. One illustrative way to size that gap (a planning formula, not a Nalashaa result): days between other-coverage data arriving and the first lookback × claims paid per day for the affected members × the average difference between what the plan paid as primary and what it should have paid as secondary.
FAQ
What is coordination of benefits in health insurance?
Coordination of benefits is the process that decides which plan pays first, and how much the other plans contribute, when a person has more than one health plan. CMS describes its purpose as paying claims correctly and preventing payments that add up to more than 100% of the claim.
How does a plan decide which insurance is primary?
The plan applies a fixed order of rules. Under the NAIC model regulation, the plan covering a person as a member pays before the plan covering the same person as a dependent, and further rules cover children of two parents, divorced parents, active versus retired employees, COBRA coverage and length of coverage. Medicare adds federal secondary payer rules on top.
What is the birthday rule?
For a child covered by both parents, the plan of the parent whose birthday falls earlier in the calendar year is primary. If both parents share a birthday, the plan that has covered a parent longer pays first, according to Section 6(D)(2)(a) of the NAIC model. A court decree overrides this rule for divorced parents.
What is Medicare Secondary Payer?
Medicare Secondary Payer (MSP) describes cases where another insurer, such as an employer group health plan, has primary responsibility and Medicare pays second. CMS runs a Benefits Coordination & Recovery Center that investigates other insurance and maintains MSP records.
Why do COB errors show up after a claim is paid?
Other-coverage information often reaches a plan after the claim is processed. In a 2022 OPM audit, the plans had paid the claims correctly on the information they held, and Medicare enrollment data arrived later in their claims system. The error appeared only once the record changed.
How long can a plan wait to recover a COB overpayment?
That depends on the contract and the other payer’s rules, so the plan should confirm its own limits. For Medicare as the other payer, the same 2022 audit warns that claims Medicare receives more than a calendar year after the date of service could be denied for late filing.
Where does a plan learn about other coverage?
Plans learn about other coverage from several sources. For Medicare, CMS collects other-insurance data through employer data-sharing agreements, the COBA program, Section 111 reporting by insurers, and exchanges with pharmacy benefit managers. Plans also rely on member questionnaires and updates, which is why coverage records fall behind when members marry, change jobs or gain a new plan.
Can a bot decide which plan is primary?
For clear-cut cases with complete data, a bot can apply the order-of-benefit rules the same way every time. When the facts conflict, as with a court decree or two plans whose provisions disagree, a person should decide. Document reading can extract the data, but it cannot judge the dispute.
Latest posts by Priti Prabha (see all)
- RPA in Healthcare: 5 Workflows to Automate First - October 6, 2026