837 to 835 Reconciliation: Closing the Loop Between Claim and Payment

The matching keys that matter

Most reconciliation failures trace back to relying on the wrong identifier. The reliable hierarchy:

• CLP01 — your patient control number, echoed back; the primary join key
• CLP07 — the payer claim control number; required for any follow-up or appeal
• SVC01 through SVC06 — service-line procedure, charge, paid amount, and units
• TRN02 — the check or EFT trace number that ties the remittance to a deposit
• BPR16 — the effective payment date used for cash posting

Split, partial, and reversed payments

A single 837 claim routinely produces multiple 835 events: a partial payment, a later adjustment, and sometimes a full reversal followed by a corrected payment. A reconciliation model that assumes one claim maps to one remittance will silently overstate collections. Model the relationship as one-to-many, keyed on the payer claim control number, with a running balance per claim and per service line.

Adjustment codes are the actual signal

CAS segments carry the claim adjustment group code plus CARC and RARC codes that explain every dollar of difference between charged and paid. Treated as noise, they become a write-off. Treated as data, they are the highest-value denial-management dataset a revenue cycle has — they tell you which payers deny which procedures for which stated reason, at what volume.

Control totals that catch leakage

Run these on every file, every day, and alert on variance rather than reviewing dashboards:

• Sum of CLP04 paid amounts equals BPR02 total payment amount
• Every 837 claim submitted more than N days ago has at least one remittance event
• Service-line paid plus adjustments equals submitted charge for every line
• Every 835 trace number reconciles to a bank deposit
• Claims with reversals have a matching corrected payment within the expected window

Why this breaks in practice

Clearinghouse reformatting drops or rewrites the patient control number. Multiple systems submit claims with overlapping control-number ranges. Secondary and tertiary payer sequences create claims that legitimately have no direct remittance. Paper and portal payments never produce an 835 at all. Every one of these is a data-model problem, not an EDI parsing problem.

How BCP helps

BCP builds the reconciliation as a transaction layer: we parse 837 and 835 in flight, normalize them into a claim-lifecycle model, publish exceptions and control-total breaks to the revenue cycle team, and retain no PHI at rest. Clients keep their existing clearinghouse and practice management systems; the layer supplies the truth about what happened between them.

What field links an 837 claim to its 835 remittance?

CLP01 in the 835 carries back the patient control number you sent in CLM01 of the 837 — that is the primary join. CLP07 carries the payer's own claim control number, which you need for appeals, corrected claims, and matching subsequent adjustments to the same claim.

Why do some claims never receive an 835?

Common causes: the claim was rejected at the clearinghouse before reaching the payer and only appears on a 277CA; the payment was made by paper check or through a portal that does not generate electronic remittance; the claim is in a secondary or tertiary sequence still waiting on the primary; or the patient control number was rewritten in transit and the remittance cannot be matched back.

How often should reconciliation run?

Daily, on file arrival. Weekly or monthly batch reconciliation means denial trends surface after the timely-filing window on some payers has already closed, which converts a fixable denial into a write-off.