Automating Line-Level 835 Remittance Reconciliation for Physician Practices

Most practices post remittances at the claim level: the payer says the claim paid 102.40, someone posts 102.40, the balance moves, the account closes. The file that produced that number contains four to five times more information — every charge line, every adjustment, every reason code, every dollar of patient responsibility split by type — and almost none of it survives the posting step.

That discarded detail is where underpayments, silent bundling denials, and unexplained deposit variances live. This article walks through the structure of an 835, works one claim end to end with real segment arithmetic, and defines the checks a reconciliation engine has to pass before you let it post without a human.

Where claim-level posting loses the money

The 835 (Health Care Claim Payment/Advice, ASC X12N 005010X221A1 under HIPAA) is a nested file. Three levels matter for reconciliation:

Transaction level. BPR carries the total payment amount and method (ACH, FWT, CHK). TRN02 is the reassociation trace number — the value that ties the file to the money, because it also rides in the NACHA CCD+ addenda record on the ACH credit. If your bank feed and your ERA feed are not joined on TRN02, you are reconciling by amount and date, which breaks the first time two payers deposit the same amount on the same day.

Claim level. CLP gives the patient control number, claim status, total submitted charge (CLP03), total paid (CLP04), total patient responsibility (CLP05), and the payer's own claim control number (CLP07) — the ICN you will need for any appeal.

Service line level. One SVC per charge line, each followed by its own CAS adjustments and often an AMT*B6 allowed amount. This is the only level at which you can tell which CPT lost money and why.

Post at the claim level and you get one number. Post at the line level and you get a per-CPT ledger you can compare against your contracted fee schedule. Everything below depends on that difference.

Worked example: balancing a three-line claim

Here is a single claim from a commercial payer, reduced to the segments that carry money. The NM1*QC patient loop is deliberately omitted — it carries PHI and has no role in the arithmetic.

CLP*PC-88421*1*560.00*102.40*87.60*12*2026084500123*11*1~

SVC*HC>99214*250.00*102.40**1~
DTM*472*20260610~
CAS*CO*45*122.00~
CAS*PR*2*25.60~
AMT*B6*128.00~
REF*6R*L1~

SVC*HC>92083*180.00*0.00**1~
DTM*472*20260610~
CAS*CO*45*118.00~
CAS*PR*1*62.00~
AMT*B6*62.00~
REF*6R*L2~

SVC*HC>92250*130.00*0.00**1~
DTM*472*20260610~
CAS*CO*97*130.00~
AMT*B6*0.00~
LQ*HE*M15~
REF*6R*L3~

The governing rule at the line level is simple and absolute:

SVC02 (submitted charge) = SVC03 (line paid) + Σ CAS adjustment amounts on that line

Check all three:

Then roll up to the claim. CLP03 (560.00) minus every adjustment on the claim (122.00 + 25.60 + 118.00 + 62.00 + 130.00 = 457.60) must equal CLP04: 560.00 − 457.60 = 102.40 ✓. And CLP05 must equal the sum of PR-group adjustments only: 25.60 + 62.00 = 87.60 ✓.

Now read what the arithmetic tells a practice manager that the $102.40 does not:

• Line 2 paid zero, but it is not a denial. PR-1 is deductible. The full $62.00 allowed amount is collectible from the patient, and it should trigger a request-for-payment the moment the file posts — not 30 days later on a statement cycle.
• Line 3 is a bundling denial. CO-97 with RARC M15 means the payer considers 92250 a component of another adjudicated service. CO is the group code, so it is contractually non-billable to the patient. This is the line worth appealing or fixing upstream through modifier policy — and at the claim level it is invisible, because the claim "paid."
• Patient responsibility is $87.60, split $62.00 deductible / $25.60 coinsurance. Two different collection conversations, and the split only exists in the CAS reason codes.

One more transaction-level trap. If the file contains a PLB segment — say PLB*1234567890*20261231*WO>ACCT-4471*150.00~ — the deposit will be $150.00 less than the sum of CLP04 across the file, because a positive PLB amount reduces the payment. That is a prior-period overpayment recovery, not a shortfall on today's claims. Engines that do not model PLB produce a permanent, growing variance between the bank and the ledger.

The four checks that make automation trustworthy

Automation earns the right to post without review by proving it every file:

1. Line balancing. SVC02 = SVC03 + Σ CAS on every line, and CLP03 − Σ CAS = CLP04, and CLP05 = Σ PR adjustments. A file that fails is quarantined, never partially posted.
2. Deposit tie-out. Σ CLP04 − Σ PLB = BPR02, and BPR02 matched to a real bank credit via TRN02. Money posted with no matching deposit is an accounting fiction.
3. Reason-code routing. Every CARC/RARC pair maps to an owner and an action: CO-45 → expected contractual, no work; PR-1/2/3 → patient balance, generate payment request; CO-97/B15/59 → bundling review; CO-16 + RARC → missing-information rework; CO-197 → prior auth, and a feedback loop to front-desk workflow. Codes are maintained externally and revised on a published schedule, so the mapping needs versioning, not a hard-coded switch statement [verify current CARC/RARC release cadence].
4. Contract comparison. Compare AMT*B6 (allowed) against your contracted rate for that CPT + modifier + place of service. Line 1 above allowed $128.00; whether that is correct is a question only your fee schedule can answer, and only at the line level.

Checks 1 and 2 are pass/fail. Checks 3 and 4 are what turn a posting job into revenue recovery.

Manual posting vs. line-level reconciliation

The row that matters most is the last one. Manual claim-level posting fails quietly — the difference disappears into contractual adjustment. Automated line-level posting fails loudly, into a queue someone owns.

What to measure after you automate

Skip the vanity metrics. Four numbers tell you whether the reconciliation layer is working:

• First-pass auto-post rate — percentage of service lines posted with zero human touch. This is your throughput ceiling.
• Posting lag — hours between file receipt and posted-and-tied-out. Historically this is measured in days, and it is pure latency: the adjudication already happened.
• Exception aging — days outstanding per exception category. A queue nobody works is the same as a silent write-off, just with better documentation.
• Days in A/R — total A/R ÷ average daily charges. Reconciliation automation moves this by compressing posting lag and by converting patient responsibility into a payment request on day zero rather than statement-cycle day 30.

Two adjacent levers compound with this one. Faster posting resolves the accounting backlog, but the cash still lands on the payer's settlement schedule — see implementing FedNow and RTP for instant payer settlement for the treasury side. And once the 835 processor isolates the PR-group balance per line, the next step is triggering a secure, no-login HIPAA-compliant request-for-payment link automatically instead of queuing a statement.

FAQ

Do we have to replace our clearinghouse or PM system to do line-level reconciliation? No. The 835 is a standard file, and you can route a copy to a reconciliation engine in parallel with your existing flow. The integration work is on the write-back side — how posted line detail and exception dispositions return to your practice management system (API, HL7, or flat-file batch). Confirm write-back support with your specific PM vendor before committing to a cutover [verify per vendor].

What do we do when a file does not balance? Quarantine it; do not partially post. The usual causes are legitimate and identifiable: a PLB recoupment or forwarding balance (FB), interest (PLB with L6), a claim reversal (CLP02 = 22, with negative amounts paired against the original), or a split payment across two files. A true imbalance after those are modeled is a payer file defect and should go back to the payer with the TRN02 and ICN attached.

Does an 835 contain PHI? Yes. Member IDs, patient names in the NM1*QC loop, dates of service, and procedure codes are all present. Any system parsing 835s needs a BAA, encryption in transit and at rest, minimum-necessary access controls, and an audit log at the file and segment level. Treat "we email ERAs around" as a finding, not a workflow.

Try it against your own arithmetic

The shteg.ai sandbox ships with synthetic 835 files — including unbalanced ones, PLB recoupments, and reversal pairs — so you can watch the balancing checks pass and fail before any real remittance touches the system. You will see the line-level output, the CARC/RARC routing, and the deposit tie-out exactly as they run in production.

[Open the shteg.ai sandbox →](https://shteg.ai/sandbox) Use the provided synthetic files; do not upload live PHI to a sandbox environment.

This article is provided for educational purposes and describes general X12 835 transaction mechanics. It is not legal, compliance, coding, or financial advice. Segment examples are synthetic and simplified; CARC/RARC descriptions are abbreviated. Validate all balancing logic, code mappings, and payment expectations against the current ASC X12N 005010X221A1 Technical Report Type 3, the current external code lists, and your own executed payer contracts.

Draft notes for you (not part of the article): ~1,540 words. H1 + 6 H2. Two tables appear — the line-balancing check table inside the worked example is arithmetic display; if you want strictly one table, I can convert it to inline prose. Internal-link slugs are placeholders matching briefs #2 and #3. Want me to save it to workspace/drafts/ as revenue-cycle-1-<id>.md? Reads of that directory came back permission-denied, so a write will likely prompt for approval.

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