How to Read an ERA Without Missing the Money

Most billers read an ERA from the top down, claim by claim, and post what they see. That works until the deposit does not match what the remittance said you were paid.

When that happens, the money is almost always in a segment near the bottom that nobody reads. It is called PLB, and it sits outside the claim detail entirely.

Three levels, and only two of them get read.

An 835 carries information at three levels, and understanding which level you are looking at answers most questions before they become problems.

• Check level. One per remittance. Carries the total payment amount and the trace number that matches your bank deposit.
• Claim level. One per claim. Status, charged amount, paid amount, patient responsibility.
• Service line level. One per procedure. Where the adjustment reason codes actually live.

Then there is a fourth thing, which is not a level at all: provider-level adjustments. They belong to you rather than to any claim, and they are why a remittance can be internally consistent and still fail to match the deposit.

The equation that tells you if something is missing

Every 835 balances to a single arithmetic rule. If it does not balance, either the file is wrong, or you have missed something, and it is nearly always the second one.

Total payment  =  sum of all claim payments  minus net of all provider-level adjustments

In segment terms, BPR02 equals the sum of every CLP04 minus the net of every PLB amount.

A positive PLB amount reduces the check. A negative PLB amount increases it. That sign convention catches people out constantly, because intuitively a recoupment feels like it should be negative.

If your claim totals add up correctly and the deposit is short, stop reading claims. The answer is in the PLB.

PLB: where the money hides

Provider-level adjustments sit near the end of the transaction, after every claim has been reported. They cover anything the payer is doing to you rather than to a specific claim: recovering an old overpayment, withholding for the IRS, paying you interest on a late claim, applying a penalty.

This is the most commonly ignored part of an 835, and the most common reason a remittance fails to reconcile against a deposit.

Why forward balance is the hard one

WO is traceable. It usually carries the original claim control number, so you can find what is being recovered.

FB is not. A forward balance does not reference the claim it came from. It operates at the transaction level, and its reference field carries a trace number rather than a claim number.

So when a forward balance shows up on today’s remittance, finding out what it relates to means going back to the earlier remittance carrying that trace number and reading its negative balance detail. That is tedious, and it is the only way.

The practical consequence is that forward balances accumulate unexamined. A practice can carry a balance across several remittances without anyone establishing what caused it, which is exactly the situation where an incorrect recoupment goes unchallenged.

The pair that looks like double counting

When you send a refund, some payers report it twice. A negative 72 acknowledging the refund arrived, and a positive WO offsetting it so the transaction balances.

The net effect on the check is zero. If you post both, you have adjusted the account twice for one refund.

Worth checking how your posting software handles that pair, because it is a silent error. Nothing rejects, nothing flags, and the account balance is simply wrong.

Claim status codes worth recognizing on sight.

The claim status sits in CLP02 and tells you what the payer actually did before you read a single dollar figure.

• 1 Processed as primary. The normal case.
• 2 Processed as secondary.
• 3 Processed as tertiary.
• 4  Denied. Nothing was paid, and the reason is in the adjustment codes.
• 19 Processed as primary and forwarded to another payer. You do not need to bill the secondary yourself.
• 22 Reversal of a previous payment. This one matters most.

A status 22 means the payer is undoing something it already paid. You have to reverse the original posting, not just post the new line, or the account carries both the original payment and its correction.

A reversal usually arrives paired with a corrected claim in the same transaction. If it arrives alone, the recovery is coming through the PLB on this remittance or a later one.

And reversals are not always right. A payer reversing a correctly paid claim is not rare, and a status 22 is worth reading rather than posting automatically.

Allowed, paid, and what the patient owes.

Three different numbers that get treated as interchangeable, usually with expensive results.

• The allowed amount is what the payer agreed the service is worth. Compare this against your contracted rate, not against what was paid.
• The paid amount is what actually moved. It is lower than the allowed amount whenever the patient owes a deductible or coinsurance.
• Patient responsibility appears under the PR group code. Nothing else is billable to the patient.

A claim can be allowed at exactly the right rate and pay almost nothing, because the patient is early in their deductible year. That is a correctly processed claim, not an underpayment. Judging payment accuracy by the paid amount rather than the allowed amount produces a work queue full of claims that were never wrong.

The most common contractual adjustment you will see alongside this is CO-45. That is covered in CO-45 explained, including why you cannot bill the patient for it.

A reconciliation routine that takes ten minutes

Reading every line of every remittance is not realistic. Reconciling is, and it catches the things line reading misses.

1. Match the trace number on the remittance to the deposit in your bank feed
2. Confirm the total payment matches the deposit exactly
3. If it does not, go straight to the PLB before reading any claims
4. List every PLB entry with an amount, and check each one has a reason you understand
5. Anything you cannot explain gets written down and chased, not posted and forgotten

That last step is the one that matters. An unexplained recoupment posted quietly is money gone. The same recoupment written on a list is a question someone can ask the payer.

If you work from a clearinghouse screen rather than the file

Most billers never see raw 835 data. The clearinghouse renders it into something readable, and that rendering is usually good.

The thing worth checking is whether it shows provider-level adjustments at all. Some interfaces display claim detail beautifully and omit the PLB entirely, or bury it on a separate screen nobody visits. If your remittances never seem to include recoupments and yet your deposits are occasionally short, that is the first place to look.

Ask your vendor directly: where do you display PLB segments? If the answer is unclear, that is your answer.

What to do next

1. Take last week’s largest remittance and check the total against the deposit
2. Find the PLB section and list every entry
3. For each one, establish what it relates to. WO entries carry a claim number; FB entries carry a trace number pointing to an earlier remittance
4. Check how your posting software handles a 72 and WO pair, and whether it double posts
5. Confirm your clearinghouse actually displays provider-level adjustments

Reduced payments from payer policy changes also arrive looking like normal adjustments. Modifier 25 in 2026 covers one example where a correctly billed claim now pays half, with nothing to appeal.

Sources

• CMS electronic billing and EDI transactions. Federal guidance on the 835 and remittance advice.
• X12. Publisher of the 835 implementation guide, which is the definitive specification.
• Your payer’s own 835 companion guide. Most large payers publish one, and it documents exactly which PLB codes they use and how.

Reference information only. Not billing advice. Verify against the payer before you file.