Blog · May 8, 2026 · 8 min read

How to Test 835 Remittance Reconciliation Before Go-Live

Most EDI go-live failures happen at the 835 — not the 837. Here is a practical guide to testing remittance reconciliation before you ever touch production.

Fig. 1 — 835 remittance payment flow
837 Claim CLM · SV1 · HI submit Payer Adjudication CLP · CAS · AMT 835 ERA 835 Segments BPR — payment amt CLP — claim level CAS — adjustments SVC — service line AMT — allowed amt PLB — provider adj post Reconciliation 837 charge = paid + adj + PR
The 835 must balance: BPR payment + CAS adjustments + PR patient responsibility = original CLM charge amount

Why the 835 breaks go-lives

Most teams test the 837 thoroughly — they validate the claim structure, run it through a clearinghouse sandbox, check the 277A acknowledgment. Then they go live and the 835 breaks everything.

The 835 is harder to test because it requires the full payment cycle to complete: you need a valid 837 first, then payer adjudication, then a realistic ERA response. In a test environment that usually means waiting days for a sandbox response — or worse, fabricating a 835 by hand and hoping it matches what the payer will actually send.

The most common failure modes at go-live:

  • CAS segment mismatches — the billing system expects CO-45 contractual adjustments but the payer sends PR-2 patient responsibility. The math balances but the posting logic breaks.
  • PLB (Provider-level adjustment) not handled — the payer nets a prior overpayment against the current payment. The 835 balances but the AR system doesn't know how to post the PLB loop.
  • NPI/TIN mismatch on NM1*PE — the rendering provider in the 835 doesn't match what's in the billing system. Auto-posting fails silently.
  • SVC line level vs CLP claim level posting confusion — the billing system posts at the CLP level but the payer sends adjustments at the SVC line level. Partial payments get misapplied.
  • Zero-pay 835s not handled — a full denial comes back as a $0.00 CLP with CAS CO-97. Many systems skip the posting step for zero-pay claims, leaving them in limbo.

The anatomy of an 835

Before you can test it, you need to understand what a valid 835 contains. The key segments in order:

ISA*00* *00* *ZZ*PAYER *ZZ*PROVIDER *260510*1000*^*00501*000000001*0*P*:~
GS*HP*RECEIVERAPP*SENDERAPP*20260510*1000*1*X*005010X221A1~
ST*835*0001~
BPR*I*285.00*C*ACH*CTX*01*123456789*DA*12345678*987654321***DA*87654321*20260524~
TRN*1*ICN2026041800001*1234567890~
DTM*405*20260524~
NM1*PR*2*BLUE CROSS BLUE SHIELD*****XV*00590~
NM1*PE*2*NORTHSIDE MEDICAL GROUP*****XX*1234567890~
CLP*CLM-2026-00481*1*285.00*228.00*57.00*CI*ICN2026041800001*11*1~
CAS*CO*45*57.00~
NM1*QC*1*SMITH*JANE****MI*MBR00291001~
SVC*HC:99214*285.00*228.00**1~
DTP*472*D8*20260415~
CAS*CO*45*57.00~
AMT*B6*285.00~

Reading the math: BPR says $285.00 was paid. CLP says charge was $285.00, paid $228.00, patient responsibility $57.00. CAS says CO-45 contractual adjustment of $57.00. So: $228.00 + $57.00 = $285.00. ✓

This balance check — paid + all CAS adjustments + PR patient responsibility = original charge — is what your billing system's auto-poster runs on every single CLP loop. If it doesn't balance, the claim suspends.

The eight 835 scenarios you must test before go-live

Full payment
BPR = CLP charge. No CAS adjustments. Simple pay. Most systems handle this — but verify the NM1*PE TIN matches your billing system.
Contractual adjustment (CO-45)
The most common. Payer pays contracted rate, adjusts off the rest as CO-45. Your billing system should write off CO-45 automatically.
Patient deductible (PR-1)
Payer applies deductible. PR-1 in CAS means patient owes the balance. Billing system should create a patient balance, not write it off.
Full denial (CO-97 or CO-4)
Zero-pay CLP. The 835 still arrives — it just has $0 in the payment field. Most systems skip auto-posting on zero-pay, leaving the claim in suspense.
Partial payment — multiple service lines
SVC loops with different payment ratios per CPT code. The sum of all SVC payments must equal the CLP payment amount.
COB — primary paid, secondary 835
CLP has both CO and OA adjustment reason codes. The secondary payer 835 cross-references the primary payment. Most billing systems struggle here.
PLB — provider-level adjustment
Payer nets a prior overpayment or withhold against this check. PLB appears at the end of the 835, outside the CLP loops. Many systems ignore PLB entirely.
Reversal / void
CLP*ICN*22*... — reason code 22 means this is a reversal of a prior payment. The billing system must find and reverse the original posted payment.

How to generate synthetic 835s for testing

The challenge with 835 testing is that a realistic 835 requires matching data from the original 837: the same ICN, same member ID, same CPT codes, same provider NPI. If those don't match what's in your billing system's pending claims file, the auto-poster rejects or suspends the transaction.

There are three approaches:

Option 1 — Wait for the clearinghouse sandbox to respond. Most clearinghouses have a test environment that will generate a synthetic 835 in response to a test 837. The problem: sandbox response times are slow (24–72 hours), the scenarios are limited to what the sandbox supports, and you can't easily generate edge cases like PLB adjustments or full denials.

Option 2 — Hand-build the 835. Faster but error-prone. Getting the CAS math right, the SVC line level detail matching the 837, and the PLB loops correct requires deep EDI knowledge and takes hours per scenario.

Option 3 — Generate the 835 from the same member record that generated the 837. This is what Synthibase does. Because the 837 and 835 are generated from the same encounter and member registry, the ICN, member ID, provider NPI, and CPT codes all match automatically. You get a coherent 837/835 pair for every test scenario — including full denials, COB, and PLB — without waiting for a sandbox response or building segments by hand.

A practical pre-go-live 835 checklist

Before you go live with a new billing system, clearinghouse, or payer connection, verify each of these:

01 BPR payment amount posts correctly to the correct provider account
02 CO-45 contractual adjustments are written off automatically without creating patient balance
03 PR-1 and PR-2 patient responsibility creates a patient statement balance
04 Zero-pay CLP (full denial) suspends the claim with the correct reason code — not silently ignored
05 SVC line level adjustments reconcile to the CLP total
06 PLB provider-level adjustments are captured and visible in the AR system
07 NM1*PE NPI/TIN matches the billing system provider master
08 COB secondary 835 cross-references primary payment correctly
09 Reversal/void (CLP reason code 22) finds and reverses the original posting
10 835 file is acknowledged with a 999 functional acknowledgment

Synthibase generates 835s paired with their originating 837 — same ICN, same member, same provider, same CPT codes — so the reconciliation math works end to end. Every scenario in the checklist above is testable before you touch production. Start a free trial →

← Back to blog