The Reconciliation Problem in Two Streams

Most healthcare practices run two reconciliation workflows. One handles electronic remits, the ANSI X12 835 files that hit your clearinghouse a few minutes after a payer cuts the check. The other handles paper EOBs, the printed explanations that arrive in envelopes a week later, sometimes with the check, sometimes without.

The two workflows are owned by two people. They use different software. They reconcile on different cadences. And they almost never talk to each other.

That gap is where money goes missing. Claims sit unposted because nobody notices the 835 arrived without a matching EOB. Patient statements go out for balances that were already paid. Billers spend their afternoons chasing remits across three portals and a stack of mail.

It does not have to work this way. The architecture for merging both streams into one canonical pipeline is not particularly complicated. It just needs someone to design it on purpose.

What an 835 Actually Tells You

An ERA 835 is a structured ANSI X12 file. It contains claim-level adjudication data: which claim was paid, how much, which line items were denied or adjusted, and the reason code for each adjustment.

The good parts of an 835: it is machine-readable, it arrives fast (usually within 24 hours of payment), and it includes every code your posting system needs to apply line-by-line. CARC and RARC fields tell you exactly why something was adjusted.

The hard parts of an 835: it is not always complete, especially for secondaries. It does not include the kind of payer-specific narrative your biller needs to explain a $43.18 underpayment. And a small, stubborn fraction of payers (most state Medicaid programs, a few workers comp carriers, parts of TRICARE) still send paper for everything no matter what your clearinghouse promises.

What a Paper EOB Carries That an 835 Doesn't

Paper EOBs do four things that electronic remits often do not.

First, they carry the timely-filing proof for everything received by mail. If a payer disputes the date of your claim, the postmarked envelope is your evidence.

Second, they include payer-specific narrative notes. A handwritten "Patient ineligible after 3/15, recoupment to follow" tells your biller something the 835 will not flag for another two weeks.

Third, they pair physically with paper checks. For payers that still cut paper, the EOB and the check arrive together, and your matching logic depends on tracking both.

Fourth, they are often the only record for the lower-volume payers you do not have ERA enrollment with. State Medicaid programs, school district plans, and smaller auto and workers comp carriers are common offenders.

Where Most Practices Break

Three failure modes show up over and over when we audit reconciliation workflows.

The first is dangling 835s. The remit posted, the cash arrived, but the EOB for one or two patient encounters never showed up by mail. Two weeks later, the biller cannot reconcile a $182 line and writes it off. Multiply by a year and that is a real number.

The second is duplicate posting. The 835 hit on Monday. The paper EOB arrived on Friday. Different person, different queue, posted twice. By the time month-end closes, you have a phantom $4,200 in receivables that does not actually exist.

The third is patient confusion. A patient calls about a balance from a service eight weeks ago. Your front desk pulls up the encounter, sees an open balance, and asks them to pay. The paper EOB sitting in the unprocessed mail bin shows the payer already paid that line in full.

All three get worse as you scale. A solo practice can muddle through. A 20-location group with seven billers cannot.

The Architecture: One Pipeline, Two Inputs

A merged reconciliation pipeline has four layers.

Layer one is ingestion. Your clearinghouse drops 835s into an sftp folder or pushes them to a webhook. Your lockbox digitizes paper EOBs and emits structured fields (payer, payment date, claim references, line items, adjustment codes, check number) on the same schedule.

Layer two is normalization. Both streams get converted into the same canonical schema: encounter ID, payer ID, claim ID, service date, paid amount, adjustment amount, and a list of CARC or narrative codes. The 835 fields and the OCR'd EOB fields map onto the same data model.

Layer three is matching. Every normalized remit gets matched against the open claim ledger. Most match cleanly on encounter ID. The ones that do not go into a small exception queue with the most likely matches surfaced for human review.

Layer four is posting and adjustment. Matched remits post to the encounter, adjust where indicated, and trip a patient-responsibility transition if there is a remaining balance.

The Three-Step Reconciliation Loop

The loop runs in three steps every morning.

Step one: the system pulls all overnight 835s and OCRs the previous business day's lockbox EOBs. Both streams enter the same normalized pipeline.

Step two: matched items post automatically. The 95+ percent of remits that match cleanly on encounter ID are posted by the system without human review.

Step three: exceptions get human eyes. A biller works the exception queue. Each item shows the proposed match, the data on the remit, and the open balance on the encounter. One click confirms and posts. One click escalates.

What gets removed: the parallel workflow. Your team is no longer reconciling 835s in one tool and EOBs in another. Both live in the same queue, sorted by exception type and aging.

What This Frees Up for Your Billers

The numbers from practices we benchmark:

• Average remit processing time drops from 3-5 minutes per item to 30 seconds for exceptions and zero for clean matches

• DSO improves by 3-7 days, mostly from faster patient-responsibility transitions

• Posting error rate falls from 1-3 percent to under 0.2 percent

• Month-end reconciliation backlog shrinks from 5-12 hours to under 1 hour

• Write-offs from unmatched remits drop by 60-80 percent in the first quarter

The biggest unlock is qualitative. Your billers stop being clerks and start being analysts. They look at denial trends, payer underpayment patterns, and authorization gaps instead of stamping the same posting form for the four hundredth time. That work compounds.

A 14-Day Deployment Sequence

Most practices can stand this up in two weeks if the inputs are reasonable.

Days 1 through 3: confirm ERA enrollment with your top payers, redirect 835 feeds to the new sftp endpoint, and validate file structure for the top five payers by volume.

Days 4 through 7: redirect your inbound paper to the new lockbox PO box, run a parallel posting workflow for one week to compare outputs, and onboard your billers to the exception queue.

Days 8 through 10: enable auto-posting for high-confidence matches, keep exception review on for everything else, and start tracking the four KPIs (match rate, DSO, error rate, backlog hours).

Days 11 through 14: full cutover, retire the legacy workflows, and lock in the new month-end close playbook.

By day 14, you have one pipeline, one queue, and one place to look when a remit is missing.

What to Watch in the First Quarter

Three numbers matter in the first 90 days.

Match rate is the headline. It should sit above 95 percent for high-volume payers within two weeks, climb toward 98 percent by month two, and stay there. Anything under 90 percent for a specific payer means a mapping problem, not a system problem.

Exception aging is the leading indicator of trouble. If exceptions are sitting in the queue for more than 48 hours, your team is not staffed for the new workflow, or the exception UI is missing context they need.

Patient calls about unexplained balances should drop by half in the first 30 days. If they do not, you have a posting timing issue and the patient-responsibility transition is firing too early.

Pull those three numbers into a weekly dashboard. Look at them on Monday before anything else.