TL;DR
Coordination of benefits determines which health plan pays first when a patient has more than one. It exists to prevent duplicate payment and to establish a clear order of liability. COB denials are unusual among claim denials because the claim itself is typically correct. Nothing was miscoded and nothing was missing. It simply went to the wrong payer first, and the information needed to get that right does not live in your systems.
Key Takeaways: COB establishes primary, secondary, and tertiary payer order. Determination follows defined rules including employment status, the birthday rule for dependent children, and Medicare Secondary Payer provisions. COB issues are consistently cited among the leading causes of denial. The underlying difficulty is that coverage facts are external, patient-held, and change without notice, so there is no expiry date to monitor.
What is coordination of benefits?
Coordination of benefits is the process of determining, when a patient holds more than one health plan, which plan pays first, which pays second, and which pays any remaining balance.
It exists for two reasons. It prevents the same service being paid twice across multiple policies, and it establishes an unambiguous order of liability so payers and providers know who is responsible for what portion.
The mechanics are straightforward once the order is known. The primary payer adjudicates the claim under its own terms. The secondary then considers the remaining balance under its terms, often covering some or all of what the primary did not. A tertiary payer follows if one exists.
The difficulty is never the mechanics. It is establishing the order.
How primary payer is determined
COB order follows defined rules rather than preference, and they are worth knowing because most COB errors are failures to apply a rule correctly rather than failures to have one.
Employment status. For an individual covered by their own employer’s plan and also as a dependent under a spouse’s plan, the plan where they are the subscriber is generally primary and the spouse’s plan secondary.
The birthday rule. For dependent children covered under both parents, the plan of the parent whose birthday falls earlier in the calendar year is primary. It is the month and day that matter, not the year, which is a common misunderstanding. Where both parents share a birthday, the plan that has been in effect longer is primary.
Custody arrangements override the birthday rule where a court order assigns responsibility for healthcare coverage.
Medicare Secondary Payer rules determine when Medicare pays second rather than first, commonly where a patient is covered by an active employer group plan, or where liability, no-fault, or workers’ compensation coverage applies to the specific incident.
Active versus retiree coverage. An active employee’s plan is generally primary over a retiree plan.
Why COB denials are different
Here is the property that makes COB worth treating as its own discipline rather than a subset of eligibility.
Most denials indicate something was wrong with the claim. A COB denial usually indicates the claim was right and went to the wrong place.
A coding denial means the code was incorrect. A medical necessity denial means the documentation did not support the service. A timely filing denial means the deadline passed. In each case something about the claim or its handling was deficient, and correcting it is a matter of fixing what you controlled.
A COB denial typically means the service was rendered, correctly documented, correctly coded, and submitted within the window, to a payer who was not primary. The claim was not defective. The sequencing was.
That distinction matters operationally because the correction is not a resubmission with a fix. It requires establishing the correct order, obtaining any required denial from the payer that should have gone first, and resubmitting in sequence, which takes longer and frequently pushes against timely filing limits on the second attempt.
Industry analyses of denial root causes consistently place COB among the leading categories, alongside eligibility, authorization, and payer-specific guideline adherence.
The structural problem
Why does this keep happening in organizations that know the rules?
Because the information required to sequence correctly is not yours, and it has no expiry date.
Consider what actually changes a patient’s COB position. They start a new job and gain employer coverage. Their spouse changes jobs and their dependent coverage moves. They turn 65 and Medicare enters the picture, though whether it becomes primary depends on whether they remain actively employed. A divorce reassigns responsibility for a child’s coverage. An accident brings liability or no-fault coverage into play for that incident only.
None of these events generate a notification to you. The patient may not mention them, may not realize they are relevant, or may genuinely not know which of their plans is primary. Coverage is held by the patient and changes according to events in their life, not according to your registration schedule.
This is what separates COB from other data quality problems in the revenue cycle. A credential has a renewal date you can monitor. A contract has an effective date and an amendment history. Coverage has neither. It changes silently, externally, and without a clock.
The consequence is that COB accuracy degrades continuously between encounters, and the only reliable detection mechanism is asking again, which is why intake scripts and structured coverage questioning at registration matter more than most downstream fixes.
Where the work actually goes
The operational shape of COB work is specific.
Someone asks the coverage questions at registration and records the answers, which requires asking explicitly about secondary insurance, spouse coverage, Medicare status and employment, and whether the visit relates to an accident. Someone verifies the responses against payer eligibility systems, which return their own view of coverage and sometimes disagree with each other. Someone applies the sequencing rules to the verified facts. Someone updates the patient record so the next encounter starts from the current position rather than a stale one.
And when a COB denial arrives, someone reads the remittance, establishes what the payer believes the correct order to be, obtains any primary denial required to substantiate the secondary claim, and resubmits in sequence before the filing window closes.
Almost none of this is clinical or coding judgment. It is gathering facts from several sources that do not agree, applying defined rules to them, and keeping the result current. Its volume scales with patient encounters rather than with the number of people available to do it.
Where automation fits
Because the rules are well defined and the difficulty lies in assembling and reconciling facts, the constraint is data gathering rather than decision logic.
Automation that can read unstructured responses and reason across sources addresses that directly: interpreting eligibility responses from multiple payers including where they conflict, applying the sequencing rules to the verified position, identifying when a patient’s recorded COB status is inconsistent with what payers now report, and reading COB denial remittances to determine what order the payer believes applies and what documentation the resubmission requires.
The prevention side matters more than the recovery side here. A COB error caught before submission costs a verification. The same error caught after denial costs a rework cycle, a primary denial to obtain, and a resubmission racing a filing deadline.
Because sequencing determines who is billed and patients are affected by the outcome, each determination needs to be traceable to the eligibility responses and rules it rests on. A payer disputing your sequencing will ask what you relied on.
To be clear about scope, Kognitos is not a clearinghouse, an eligibility vendor, or a practice management system. It does not replace the systems that transmit eligibility inquiries or hold the patient record. What it addresses is the reconciliation layer between them: reading responses that disagree, applying the sequencing rules, and producing a current COB position with a record of how it was reached.
For related processes, see our guides on revenue cycle management, payer contract management, provider credentialing, healthcare automation, and AI in healthcare. To see how deterministic AI reconciles conflicting coverage data with a full audit trail, book a demo or try the platform.
Getting started
Two checks worth running.
Audit your registration script for the COB questions specifically. Most intake processes ask whether the patient has insurance. Fewer ask explicitly about secondary coverage, spouse coverage, Medicare status combined with current employment, and whether the visit relates to an accident. Those four questions prevent a disproportionate share of COB denials, and their absence is the most common root cause.
Take your last quarter’s COB denials and check how many involved a patient whose coverage had changed since their previous encounter. If that proportion is high, the problem is not rule knowledge, it is that your recorded position was accurate when captured and had since gone stale. Those require a re-verification cadence rather than more training.
