835 remittance reader
Reads the file, decodes the codes, and tells you whether it balances to the deposit — including the PLB adjustments that usually explain why it does not.
Choose an 835 or ERA file
or drop it here. It is read in your browser and never uploaded.
or paste the remittance text instead
to see what the output looks like.
Every claim posted correctly and the total is still wrong
This is the complaint an 835 generates more than any other, and it is almost never the claims. It is the segment underneath them.
A remittance has a part most software reads and a part a lot of software quietly skips. The part everyone reads is the claims: what was billed, what was paid, which codes explain the difference. The part that gets skipped sits after the last claim and applies to the payment as a whole.
The PLB segment
Provider-level adjustments are amounts moved against the payment rather than against any individual claim: an overpayment being recouped, a balance carried forward from a previous remittance, interest you are owed, tax withheld. The payer guides put them squarely inside the balancing arithmetic — BCBS Illinois writes it as the sum of all claim payments (CLP04) minus the sum of all provider level adjustments, and that is what has to equal BPR02. Read the claims and skip the PLB and there is no arrangement of the claim data that will make the deposit come out.
The failure is quiet by design. Post every claim from an 835 that carries a $2,400 recoupment and each claim will be right, the ledger will look right, and the bank will be $2,400 short with nothing on screen explaining it.
The sign convention that catches everyone
A positive provider adjustment reduces the payment. A negative one increases it. The number describes the adjustment, not the cash: a positive WO is money being taken back, and a negative L6 is interest being added. Every payer guide states it the same way and it still reads backwards the first time, so each row here is labeled with its effect rather than leaving you to infer it.
Three balances, not one
An 835 has to add up at three levels, and a break at any one of them means something was misread:
- The payment
- BPR02 equals the sum of the claim payments minus the net of the provider-level adjustments. This is the one that answers the deposit question.
- Each claim
- The submitted charge equals what was paid plus every adjustment against it.
- Each service line
- The line charge equals what the line paid plus the line's own adjustments.
All three run here, on every claim, and each failure is reported with the amount it is out by and the claim it belongs to.
The group code still decides the money
Every adjustment carries a group code and a reason code, and the reason code is the one with all the words on it. The group code is the one that matters: CO means write it off and PR means bill the patient, whatever the reason code says. Each adjustment here shows both, with the group code's consequence spelled out. The denial code decoder covers the full code lists.
Terminology
- ERA / 835
- Electronic remittance advice. The electronic equivalent of the paper explanation of benefits, and the payer's answer to a claim you submitted on an 837.
- CLP
- Claim payment information. One per claim, carrying the control number, status, charge, payment and patient responsibility.
- CAS
- Claim adjustment. Explains why the payment differs from the charge. Appears at claim level and at service line level, and carries up to six adjustments per segment.
- PLB
- Provider-level balance. Adjustments against the payment as a whole rather than a single claim.
- BPR02
- The total payment amount: what should have arrived in the bank.
- TRN02
- The check number or EFT trace number, for matching the remittance to the deposit.
Questions billers actually ask
My deposit does not match what I posted. Where do I look first?
The PLB segment, almost always. It sits near the end of the transaction, after every claim, and carries adjustments applied to the payment as a whole rather than to any one claim: recoupments of earlier overpayments, forward balances, interest, IRS withholding and payer write-offs.
It is a segment that posting systems routinely skip, and skipping it produces exactly this symptom — every claim posts correctly and the total is still wrong. Paste the file here and the tool tells you whether the shortfall equals the provider-level adjustment total, which is the giveaway.
How does an 835 balance?
Three levels, and all three are checked here.
The payment total: BPR02 equals the sum of every claim payment (CLP04) minus the net of all provider-level adjustments (PLB). A positive PLB amount reduces the payment and a negative one increases it, which catches people out.
Each claim: the submitted charge equals the payment plus the adjustments. Each service line: the line charge equals the line payment plus the line adjustments.
Every check reports the shortfall in dollars and names the claim, so you are not hunting for it.
Why does a positive adjustment reduce my payment?
Because the amount describes the adjustment, not the cash. A positive PLB is money being taken out of this payment — a recoupment, a withholding — so the deposit goes down. A negative PLB is money being added, most commonly interest the payer owes you on a late claim.
It reads backwards the first time and it is stated identically in every payer companion guide. The tool labels each one reduces payment or increases payment so there is nothing to remember.
What do WO, FB, L6 and 72 mean?
WO is overpayment recovery: money being clawed back. FB is a forward balance, carrying an amount to or from another remittance — negative means it is moving to a future one, positive means it arrived from a previous one. L6 is interest owed to you, and appears as a negative because it adds to the check. 72 is an authorized return, acknowledging a refund you sent.
You will often see WO and 72 together with opposite signs, netting to zero: that is the payer acknowledging receipt of a refund check rather than two separate movements of money.
Can I get the claims out as a spreadsheet?
Yes. Download claims as CSV gives one row per service line, with the claim identifiers, charges, payments, and every adjustment decoded to its CARC description. Adjustments that sit on the claim rather than on a line get their own rows, and an adjustment_level column says which is which, so the adjustments in the spreadsheet still add up to the claim. It opens straight in Excel or Sheets.
Values that begin with a symbol a spreadsheet would treat as a formula are escaped, so a control number starting with a dash stays a control number rather than becoming an error. Amounts are left alone, so a negative adjustment arrives as a number you can still total.
Download as JSON gives the whole parsed remittance instead: every claim and service line, the provider-level adjustments, and every balance check with the amount it is out by. The CSV is deliberately claim-shaped and does not carry the PLB rows — the JSON does.
Does my remittance file get uploaded?
No. It is read with the browser File API into memory on your own machine, parsed there, and any download is generated locally. There is no server to send it to; this site is static files.
That matters more here than on most tools. An 835 carries patient names, member identifiers, dates of service and payment detail. Reading one should not require handing it to a stranger.
The output looks wrong or the file will not parse
Most likely delimiters. An 835 declares its own — the element separator, the component separator and the segment terminator all come from the ISA header, and payers do vary them. This parser reads them from the file rather than assuming the usual * and ~, which is a common reason a hand-written EDI parser works on the samples in a companion guide and fails on a real remittance.
If you pasted a fragment with no ISA header, standard delimiters are assumed and the tool says so. If it still looks wrong, send me the file shape — not the file — and the parser gets fixed.
What is the difference between an 835 and an 837?
The 837 is the claim you send. The 835 is the answer you get back: what was paid, what was adjusted, what was denied and why. They pair up through the control number — CLP01 on the 835 is the CLM01 you submitted on the 837.
This tool reads 835s only. Reading an 837 is a different job at a different point in the workflow.
Notes and sources
Segment structure, the provider-adjustment reason codes and the sign conventions are taken from freely published payer and government companion guides: UnitedHealthcare's 835 provider-level adjustments guide, the Blue Cross Blue Shield of Illinois PLB guide, and the Wisconsin ForwardHealth 835 companion guide. The ASC X12 TR3 implementation guide is copyrighted and is not reproduced here; what this tool encodes is structure documented in those free guides.
The provider-adjustment code list is therefore the codes that appear in published companion guides, not the complete X12 set. An unrecognized code is reported as unrecognized rather than guessed at, along with its amount, so it still counts towards the balance.
The adjustment group code check is against the current X12 claim adjustment group code list, which carries CO, OA, PI and PR. CR appears on older published lists and still turns up in files, so it is decoded and flagged rather than reported as an unknown code. No free source states which version of the standard dropped it, so the tool does not claim one.
CARC and RARC descriptions come from the same snapshot as the denial code decoder, taken from x12.org on 2026-08-25. X12 revises those lists three times a year, in March, July and November. Those descriptions are the copyright of X12 Incorporated and are shown here with attribution; the codes themselves are required for the HIPAA 835 transaction.
One honest caveat on the claim-level check: published sources state the claim balancing rule two different ways, differing over whether the patient responsibility field is counted separately from the patient-responsibility adjustments or is a summary of them. Rather than pick one and be quietly wrong on files that follow the other, both readings are evaluated, a claim passes if either balances, and the patient responsibility field is checked against the adjustments separately so you can see which reading applies.
Nothing is uploaded and nothing is stored. If a real remittance fails to parse here, describe the shape of it — never send the file — and the parser gets fixed.