Coordination of Benefits Automation for RCM Systems

Coordination of benefits automation decides who owes the money a payer did not pay. When it is missing, revenue cycle systems bill patients for balances that belong to a secondary payer, and the code that causes it passes review every time. This guide is for engineering and product leaders at revenue cycle, EHR and practice management platforms: the three failures that show up in production, why single-claim logic cannot catch them, and five checks you can run against your own data this week.

What coordination of benefits automation actually decides

Coordination of benefits automation answers one question: given this remittance and the patient's other coverage on this date of service, who owes what is left. Everything else in the feature follows from that answer.

When a payer pays part of a claim it leaves a remainder. The 835 tells you the size of that remainder and, through its adjustment codes, whose it is. What it does not tell you is what to do next, and that decision is where most systems stop. The remainder then lands on the patient by default, not because anyone decided it should, but because the patient is the only party left in the data model once the primary payer has answered.

Three separate failures follow from that single default.

Failure one: the balance that never moves

A stranded remainder is a balance posted to the patient while a secondary payer sits on file, active on the date of service, never told the claim exists. Staff see a balance they cannot collect, no control sends it anywhere, and it ages until somebody writes it off or calls the patient.

Most of the answer is already in the remittance. The adjustment group code on each service line says whether an amount travels onward or stops with the provider.

Getting this backwards is the most expensive single mistake in coordination of benefits, and it costs in both directions. Treat CO as billable and you are balance billing a patient for a contractual write down. Treat PR as absorbed and you write off money a secondary payer would have paid.

The outbound side is specified in detail and worth reading rather than inferring. Prior payer adjudication goes in loop 2320, the other subscriber and payer in 2330A and 2330B, line level detail in 2430, and the whole thing has to balance: line payments less claim level adjustments must equal the claim payment amount. The CMS 837P companion guide and the WPS secondary claims guidance both set this out. If you want to read your own files segment by segment while working through this, the X12 EDI developer guide covers the surrounding transaction set.

Check where the adjustments actually live

Adjustments in an 835 sit at the service line, in the 2110 loop, not on the claim row. Parsers that read the claim level only find nothing and conclude there is nothing to route. A routing rule that never fires looks identical to a rule that correctly finds no work, which is why this survives testing. Sum the lines, and fall back to the claim row rather than the other way round.

Failure two: the write off that becomes a patient bill

A resurrected balance happens when a secondary claim is raised and then written off, usually because the filing window closed, and the ledger decides the original balance is unresolved again and puts it back in front of the patient. The practice missed the deadline. The patient did not.

Whatever logic suppresses the original claim while a follow on is open has to keep suppressing it once that follow on is paid or written off, and lift only when the follow on is deactivated with nothing standing in its place. That distinction sounds like an edge case. It is the difference between an internal cost and a bill somebody has to defend on the phone.

The same code usually hides a second problem. Secondary filing windows run from the date the prior payer adjudicated, carried on the 835 as the check or remittance date, not from the date of service.

A system counting from date of service reports a deadline that has already passed on claims with weeks left, and staff learn to ignore the number entirely. Once they ignore it, the real deadlines pass too.

Failure three: the card charged while a payer still holds the claim

The third failure is an automated collection run charging a card for a balance that a payer is about to pay. The primary has answered, a secondary claim has been raised and sits unanswered, and the overnight job reads a balance above zero and charges the card on file.

This is the one with legal exposure, and the one most likely to be live right now, because the guard that should stop it usually looks correct. Collection guards are written per claim. They ask whether this claim is adjudicated, whether this claim is denied, whether this patient's coverage prohibits collection. Once the primary answers, this claim is adjudicated, not denied, and its balance looks settled. The claim carrying the open question is a different row, and nothing in the check looks at it.

A Medicaid rule catches part of this by accident. If the next payer is Medicaid, the no collection rule blocks the charge for its own reasons. If the next payer is commercial, nothing does, and the money comes off the patient's card two weeks before the payer pays the same amount.

Why this is not only a service problem

Where the patient is a Medicaid beneficiary, billing them for a covered service is prohibited rather than merely awkward. Participating providers must accept the Medicaid payment as payment in full under 42 CFR 447.15, and the balance billing protections for Qualified Medicare Beneficiaries carry civil monetary penalties. Retroactive eligibility makes it worse. A patient can pay in March, be approved in May with coverage backdated to February, and the provider is holding money taken from somebody who was a member throughout. Almost no system looks for that, so it surfaces when the patient or the state asks.

Why correct code produces all three

All three failures come from reasoning about one claim at a time. That is the natural way to write the code, it is how the data is shaped, and it is how the tests get written. A claim knows its own status, its own remit and its own balance. It does not know another claim was raised behind it, and no single claim assertion will ever catch it.

Coordination of benefits is a chain, and the unit of truth is not the claim. It is the visit, across every claim raised for it, in sequence. Until the ledger, the collection guard and the statement run all reason about that chain, each will be independently correct and collectively wrong.

There is a second reason these survive testing, and it is more uncomfortable. Test fixtures set fields that production data does not, and omit fields production always has. A fixture written by the developer who wrote the query will satisfy that query. The only way to find this class of defect is to run the logic against a real remittance corpus and count how often it fires. A rule that fires zero times across thousands of real claims is telling you something.

Five checks you can run this week

Each of these is one query against your own data, and each returns either an empty set or a problem. None of them needs a project.

1. Stranded remainders. Claims with a payer payment, a remaining balance, and another coverage active on the date of service, where no follow on claim exists. Every row is money sitting on a patient that belongs to a payer.
2. Misattributed contractual amounts. Balances presented as patient responsibility where the adjustment group on the remaining amount is CO or PI. Every row is a potential balance billing exposure.
3. Resurrected write offs. Patient balances where a follow on claim exists and has been written off or paid. If the original is visible to the patient, the suppression logic is wrong.
4. Collections racing a payer. Anything in the auto charge or statement queue where the visit has a follow on claim with no payer response on file. Run this one first.
5. Retroactive coverage. Patients who paid for a date of service that a plan later turned out to cover, where the plan start date precedes the visit. This is a refund list, and it is usually not empty.

If checks one and four come back clean, your coordination of benefits is in better shape than most systems. If check four returns rows, treat it as the priority regardless of what else is in the backlog.

Where automation actually helps

Automation helps at the routing decision, not at the screen. A system that classifies every remainder the moment a remittance posts, names the payer that owes it, and offers one action to raise the follow on claim removes the queue that staff cannot clear. The screens matter less than the decision behind them.

The parts worth building, in order: the routing decision over the full coverage chain, the outbound COB loops on the 837, a filing clock counted from the prior payer response, and a collection guard that reasons about the chain rather than the claim. The first and the last are where the money is.

If you are working through coordination of benefits in an existing platform, our revenue cycle management software development team builds this path end to end, and our X12 EDI integration services cover the 837 and 835 work underneath it. Talk to our team about running the five checks against your own data.