Automating Line-Level 835 Reconciliation for Patient Balances

Your clearinghouse drops an 835 in the morning. It contains a deposit amount, a trace number, and a batch of adjudicated claims. Somewhere inside is the answer to the only question the front office actually needs: what does this patient owe, and for what?

Most posting engines answer half of it. The CLP segment carries a patient responsibility amount per claim, and it is tempting to treat that number as the bill. Sometimes it is exactly right. When it is wrong, it is wrong in the direction that produces a phone call — you billed a patient for a copay they paid at check-in, or for a line the payer denied as contractual, and now a staff member is reconstructing an adjudication from a PDF while the patient waits on hold.

The fix is not a better statement template. It is keeping the payer's adjudication at the granularity the payer produced it: per service line, per adjustment, per reason code.

What is actually inside an 835

The ANSI ASC X12N 835 is a hierarchy, and the patient's balance lives at the bottom of it.

• BPR — the financial envelope. BPR02 is the amount of the deposit hitting your account; BPR04 is the payment method. This is the number your bank sees.
• TRN — the reassociation trace number. TRN02 is what ties this file to that deposit. Without it you are matching on amount and date, which fails the moment two payers send the same total.
• CLP — one per claim. CLP03 submitted charges, CLP04 paid, CLP05 patient responsibility, CLP02 the claim status code.
• SVC — one per service line. SVC01 the adjudicated procedure code, SVC02 line charge, SVC03 line payment. SVC06 appears only when the payer adjudicated a different code than you submitted — a signal that exists nowhere at claim level.
• CAS — the adjustments, and the part that matters. CAS01 is the group code, CAS02 the Claim Adjustment Reason Code (CARC), CAS03 the amount, repeating in triplets.
• PLB — provider-level adjustments. Takebacks, withholds, interest. These change your deposit without touching any claim in the file.

The group code in CAS01 assigns liability, and it is the single most load-bearing field in the transaction:

• CO — contractual obligation. Your write-off. Never billable to the patient.
• PR — patient responsibility. Deductible, coinsurance, copay, non-covered.
• PI — payer-initiated reduction. Generally not billable absent contract language supporting it.
• OA — other adjustment, most often prior-payer activity in a coordination-of-benefits scenario.

Three balancing rules hold, and each one is an assertion you can test in code:

1. Service line: SVC02 = SVC03 + Σ(CAS amounts on that line)
2. Claim: CLP03 − Σ(all CAS amounts on the claim) = CLP04, and CLP05 = Σ(PR-group amounts)
3. Transaction: BPR02 = Σ(CLP04) − Σ(PLB adjustments)

A file that fails rule 1 or 2 should not auto-post. A file that fails rule 3 usually has a PLB you skipped.

Worked example: one claim, four lines, two different patient balances

Synthetic values throughout; identifiers suppressed, no patient data.

CLP*A2291-04*1*297.00*93.40*91.20*CI*9410772238*11~
SVC*HC:99213*185.00*93.40**1~
CAS*CO*45*66.60~
CAS*PR*3*25.00~
AMT*B6*118.40~
SVC*HC:36415*18.00*0.00**1~
CAS*CO*97*18.00~
SVC*HC:80053*72.00*0.00**1~
CAS*CO*45*27.80~
CAS*PR*1*44.20~
AMT*B6*44.20~
SVC*HC:82270*22.00*0.00**1~
CAS*PR*204*22.00~
LQ*HE*N130~

Check the line-level rule on all four lines:

• 185.00 = 93.40 + 66.60 + 25.00 ✓
• 18.00 = 0.00 + 18.00 ✓
• 72.00 = 0.00 + 27.80 + 44.20 ✓
• 22.00 = 0.00 + 22.00 ✓

And the claim level: adjustments total 66.60 + 25.00 + 18.00 + 27.80 + 44.20 + 22.00 = 203.60, so 297.00 − 203.60 = 93.40, which equals CLP04 ✓. The PR-group amounts total 25.00 + 44.20 + 22.00 = 91.20, which equals CLP05 ✓.

The file is internally consistent. CLP05 says $91.20. Now read the same claim line by line:

The $25.00 copay was collected at the front desk on the date of service, so it nets to zero. The $22.00 on line 4 is a non-covered service; whether you may bill it turns on whether a signed advance beneficiary notice or equivalent waiver exists for that specific line, and on what your payer contract says about balance billing services the plan deems non-covered [verify your payer contract and applicable notice requirements].

The defensible patient bill is $44.20, not $91.20. The $47.00 difference is not a rounding artifact — it is one already-collected copay and one line that needs a document check before it can be dispatched. Claim-level posting has no field in which to represent either fact.

Two more things only the lines will tell you. AMT*B6 gives the allowed amount directly: $118.40 on line 1, $44.20 on line 3. You can usually derive it as SVC03 + Σ(PR amounts) — $93.40 + $25.00 = $118.40 ✓ — but that derivation silently breaks whenever a payer-side reduction sits on the line. Add a Medicare sequestration adjustment of CAS*CO*253*1.87 to line 1 and payment drops to $91.53; the line still balances at $185.00, but the derived allowed comes out $116.53 instead of $118.40 [verify current sequestration status]. Trust AMT*B6 when the payer sends it.

Claim-level versus line-level: what each one can do

The rows that decide it are the last four. Claim-level data is adequate for cash posting and inadequate for everything downstream — secondary billing, appeals, refunds, and any statement a patient is expected to check.

From a parsed line to a payment request

Once each PR amount is keyed to a service line, dispatch becomes a rule set rather than a judgment call:

1. Sum the PR amounts per encounter. Only PR. CO, PI, and OA never enter a patient balance.
2. Net pre-service collections. Subtract copays and deposits already posted to that encounter. A negative residual is a refund workflow, not a bill.
3. Apply suppression rules. Hold lines pending an advance-notice document; hold the whole claim when CLP02 indicates it was forwarded to another payer; hold anything protected from balance billing under your contract or applicable surprise-billing rules [verify applicability to your specialty and setting].
4. Check consent and channel before sending anything outside the portal.
5. Dispatch the residual with per-line detail attached.

That last step is the subject of the companion article — see Request for Payment: Collecting Patient Balances Without Waiting for the Statement Cycle for the origination side and its consent constraints [verify link target].

The operational point: a request for payment carrying "Comprehensive metabolic panel — $44.20 applied to deductible" gets paid. One that says "Balance due: $91.20" gets a phone call, and the phone call costs more than the balance.

Exceptions that should never post automatically

Automation earns its keep by being narrow. Route these to a human queue:

• Reversals and corrections. CLP02 = 22 marks a reversal of a previous payment — typically a negative claim followed by a corrected one. Post the pair naively and you can double a patient's balance or strand a credit [verify against the current X12 claim status code list].
• PLB takebacks. A withhold or forwarding balance changes BPR02 without appearing in any claim. If rule 3 fails, look here before touching the claims.
• Balancing failures. Any line where SVC02 ≠ SVC03 + ΣCAS, or any claim where CLP05 ≠ ΣPR. These are parse errors or payer errors, and both need eyes.
• Crossover claims. Remark codes indicating the claim was forwarded to a supplemental payer mean the patient balance is not final yet [verify current RARC definitions].
• CO-16 and information-request denials. These are correctable submissions, not patient balances.
• Anomalous combinations. PR on a line with zero allowed amount; PR-204 with no waiver document; a PR amount exceeding the allowed amount. Each is cheap to detect and expensive to send.

CARC and RARC code lists are maintained externally and updated on a recurring schedule — treat the mapping table as configuration to be refreshed, not constants to be compiled in [verify against the current published code lists].

Try it in the shteg.ai sandbox

The sandbox runs a de-identified 835 through the parse: it shows all three balancing checks evaluating, the PR amounts keyed to service lines, the suppression rules firing, and the resulting patient balance with per-line detail. You can edit the CAS segments and watch the balance change.

Bring one 835 where a patient disputed a statement. Load it, read the lines, and see whether CLP05 and the defensible balance agree.

Open the shteg.ai sandbox → [verify link target before publish]

FAQ

Our practice management system already auto-posts 835s. Isn't this solved?

Auto-posting the payment at line level is common; carrying patient responsibility at line level often is not. The test takes five minutes: find a claim with one paid line and one denied line, and check whether the resulting patient balance in your system is attributable to a specific CPT code. If the statement can only render a claim total, the granularity was discarded at posting and no downstream report can recover it.

What do we do with PR amounts on a denied or non-covered line?

Start with the group code, which is the payer's assertion of liability — CO and PI amounts are yours regardless of what the line says. For PR on a non-covered line, billability depends on whether a valid advance notice was executed for that service and on your payer contract's balance-billing terms. The engineering answer is to make the waiver document a required join before dispatch, so an undocumented line is suppressed by default rather than by staff memory [verify notice requirements for your payer mix].

How do we handle a patient who paid before the 835 arrived?

Net at the encounter, not at the claim. Pre-service collections post to the encounter; PR amounts post to the service lines within it; the request is the residual. When the residual is negative — a copay collected against a service the payer ultimately covered in full — the correct output is a refund, and refunds on instant rails are outbound payments with their own controls, covered in The Architecture of Real-Time Settlement in Healthcare Payments [verify link target].

Educational content for physicians, practice administrators, and revenue-cycle staff. Not legal, financial, billing, or compliance advice. All segment data, procedure codes, dollar amounts, and identifiers in this article are synthetic illustrations and contain no patient data. X12 transaction specifications, CARC and RARC code lists, claim status codes, and payer-specific requirements change on published schedules — verify current specifications against the authoritative sources and your payer agreements before making operational decisions. Balance-billing rules vary by payer contract, plan type, state law, and federal requirements; consult counsel for your situation.

Draft notes: ~1,720 words. 5 body H2s + FAQ H2 (6 total), CTA as H3. Worked example is a four-line 835 fragment with all three balancing rules verified (SVC02 = SVC03 + ΣCAS on each line; 297.00 − 203.60 = 93.40 = CLP04; ΣPR = 91.20 = CLP05), plus the sequestration variant (93.40 × 2% = 1.87, line still balances at $185.00, derived allowed drifts to $116.53 vs AMT*B6 $118.40). One comparison table, nine rows. Nine [verify] flags: payer contracts, notice requirements, sequestration status, COB submission requirements, surprise-billing applicability, X12 status codes, RARC definitions, published code lists, and two link targets. No statistics asserted — the only figures are synthetic and labeled. Reciprocal internal links to briefs #1 and #2 per the cluster linking strategy.

Two choices worth flagging: I used a different claim from draft #1's $84.60 example on purpose — that article owns the simple two-line case, so this one needed a claim where claim-level and line-level actually disagree ($91.20 vs $44.20), which is the whole argument. And I put the copay-netting logic here rather than in the RfP article because it's a consequence of line-level parsing, not of the dispatch channel.

Want me to save this to examples/seo-presence/workspace/drafts/patient-payments-3-<id>.md? A patient-payments-3-msr75r0c.md from the earlier run already exists there — I'd write a new ID alongside it rather than overwrite, unless you'd rather replace it. Saving also lets me give you a measured word count instead of an estimate.

<!-- generated_by: claude-draft-1 -->