PLB, the segment that takes money back

A remittance arrives. You add up what the payer says it paid on every claim, compare it to the deposit that landed in the bank, and the two numbers disagree by a few hundred dollars. Nothing on any claim accounts for it. Every CLP balances. The arithmetic inside the claims is perfect and the total is still wrong.

The difference is almost always PLB.

What it is

PLB is the provider-level adjustment segment. Everything else in an 835 describes money moving against a specific claim; PLB describes money moving against the provider, for reasons that have nothing to do with any claim on this remittance — and often nothing to do with any claim on any remittance you have ever seen.

That is the conceptual jump. A posting engine naturally thinks in claims, and PLB is not a claim. It is the payer settling up with you as a business.

Typical reasons:

• An overpayment recovered. The payer paid too much three months ago and is taking it back now, out of today's deposit.
• A forwarding balance. An amount carried to or from another remittance, which is how a payer handles a balance it cannot settle today.
• Interest, added for a late payment.
• A withhold, under the terms of a contract.
• A capitation payment, which is not claim-based at all.

The arithmetic

The relationship worth writing down, because it is the one your reconciliation depends on:

The deposit amount in BPR02 equals the sum of the claim payments in CLP04 across the remittance, less the net of the provider-level adjustments in PLB.

Get the sign wrong and your reconciliation is out by exactly twice the adjustment, which is a satisfying number to recognise in a variance report once you know to look for it.

The sign convention is the trap. A positive PLB amount reduces what the payer sends you. It reads backwards to most people the first time, because a positive number looks like money arriving. It is the payer's ledger, not yours: a positive adjustment is an amount the payer is holding back.

A fragment, invented:

BPR*I*4820.00*C*ACH*CCP*...*20260312~
TRN*1*0000012345*1234567890~
...
PLB*1234567890*20261231*WO:CLM0099123*180.00~

One deposit of 4,820.00, with 180.00 withheld to recover an earlier overpayment on a claim that is not otherwise on this remittance. The claims on this file sum to 5,000.00.

Tracing it back

The reference inside the PLB adjustment identifier is the thread back to the original claim, and whether it is usable varies enormously by payer. Sometimes it is your patient control number. Sometimes it is the payer's own claim number. Sometimes it is a batch reference meaning something only the payer's own system understands.

This matters because an overpayment recovery is only intelligible if you can find what was overpaid. Where the reference is usable, link it: the original claim should show that money came back, and the account should not still look paid in full. Where it is not usable, do not guess — surface it as an unexplained recovery with the raw reference attached and let a person chase it.

What bites once it is live

One deposit, several remittances. A single ACH credit can cover multiple 835s, and a single 835 can be paid across more than one credit. Reconciliation is many-to-many, and modelling it one-to-one will hold up for months and then break on a Friday afternoon.

The trace number is your join key. TRN02 carries the reference that should appear against the credit on the bank statement. It is the most reliable link between the two worlds, and it is not always present or always matched exactly by the bank's own description.

A recovery can exceed the payment. If the payer is taking back more than it is paying today, the deposit is zero and you may receive an 835 with no money attached at all. A pipeline that assumes a remittance brings money will do something strange here.

Capitation has no claims. If capitation applies, an 835 may arrive with no CLP segments worth speaking of and a PLB carrying the whole amount.

How to test it

The assertion is the arithmetic above, run on every remittance, every time:

• BPR02 equals the sum of CLP04 net of PLB, to the cent.
• Every PLB adjustment is either linked to an identifiable claim or raised as an exception. Silently absorbing it is not reconciliation.
• The sum of deposits matched to a remittance equals that remittance's BPR02.

If the first of those cannot be made to pass on a file, the file is not understood, and posting it anyway puts a number in the ledger that nobody can defend.

What we do

Reconciliation is a stage of the workflow rather than a report at the end of it: the remittance is matched to the deposit, provider-level adjustments are traced to their original claims where the reference allows it, and anything unexplained becomes a queue somebody works, not a rounding difference somebody absorbs.