Posting ERAs

Posting an ERA means reading an X12 835 remittance file, matching its payment and adjustment lines to your claims and service lines, routing contractual write-offs and patient responsibility to the right buckets, and committing the result to the ledger only after the math balances. Done as a blind import, it corrupts the ledger quietly. Done as a controlled review, every matched and unmatched line is visible, the adjustment codes behind each decision are inspectable, and exceptions get worked before money moves.

CMS describes the 835 as the electronic equivalent of a paper explanation of benefits, which undersells it. One 835 file can carry payment detail for hundreds of claims, provider-level adjustments tied to no specific claim, recoupments from prior cycles, and interest credits or IRS withholding. Posting it correctly takes matching controls, exception routing, and a reconciliation step that validates the totals before anything commits.

Short answer

ERA posting is the billing workflow for reviewing an X12 835 electronic remittance advice file, matching payment and adjustment lines to claims and service lines, applying contractual write-offs and patient responsibility transfers, and deciding what posts automatically versus what needs human review. The 835 carries CARC and RARC adjustment codes, group codes (CO, PR, OA, PI) that determine who is financially responsible, and PLB provider-level adjustment segments that account for recoupments, advances, and interest at the transaction footer. A sound workflow reconciles the BPR payment total against the sum of all CLP claim payments minus PLB adjustments before any money reaches the ledger. The CAQH index found more than one-third of remittance transactions still require human intervention; a system that pretends otherwise quietly creates ledger errors.

The X12 835 in plain English

An 835 file is a structured text file built from fixed-format segments separated by delimiters. X12 maintains the standard under implementation guide 005010X221A1, which is the HIPAA-required version. The file wraps everything in interchange and functional group envelopes before the actual transaction content begins.

ISA and GS — the outer envelopes. The ISA segment opens the interchange and declares the delimiter characters the entire file will use. Because the ISA is fixed-width, billing systems must read the actual delimiter characters from the ISA rather than assuming defaults. The GS segment wraps one or more 835 transaction sets inside a functional group. If a payer sends a single 835 covering multiple provider NPI groups, GS and GE bound each functional group. The IEA and GE segments close the respective envelopes.

ST — transaction set header. ST*835 marks the start of a single remittance advice transaction. The control number in ST02 must match the one in SE02 at the transaction trailer; a mismatch fails validation before any segment-level data can be trusted.

BPR — the payment anchor. BPR appears once per transaction set and carries the total payment amount, payment method (ACH, check, or non-payment), bank routing information for EFT reconciliation, and the payment date. BPR02 is the total the payer sent to the bank, and every other number in the file must reconcile back to it: the sum of all CLP claim payments minus all PLB provider-level adjustments must equal BPR02 exactly. A discrepancy means the file failed the balancing test X12 calls SNIP level 3, and no posting decision from that file can be trusted until the math resolves. The formula:

Sum of all CLP04 (claim paid amounts) — Sum of all PLB adjustment amounts = BPR02 (total payment)

Positive PLB amounts decrease the payment; negative PLB amounts increase it. That sign convention is where teams interpreting PLB by hand mis-reconcile.

TRN — the deposit trace. TRN carries the payer's trace number and the provider's bank identification, and it is the link that connects the ERA to the actual bank deposit. When a payment poster is reconciling a deposited EFT against an ERA file, TRN is the matching key. Without TRN, ERA-to-deposit matching is guesswork.

NM1 loops 1000A and 1000B — payer and payee. The 1000A NM1 identifies the payer sending the ERA. The 1000B NM1 identifies the payee receiving the payment. In multi-practice billing-company environments, the payee NPI or tax identifier in 1000B must be validated against the expected provider group before any claim-level matching begins. An ERA sent to the wrong NPI group can silently land in the wrong practice context if the system does not check this.

CLP — claim payment information. A CLP segment opens a new claim-level payment record. CLP01 is the patient control number, the number the provider put on the original claim. CLP02 is the claim status code: 1 means paid, 2 means adjusted, 3 means denied, 4 means denied but transferred. CLP03 is the total billed amount; CLP04 is what the payer paid; CLP05 is the patient responsibility amount. The sum of CLP04, CLP05, and all claim-level CAS adjustments must equal CLP03. A system that swallows a claim-level imbalance corrupts the ledger.

CAS — claim and service-line adjustments. CAS segments appear both at the claim level (inside the CLP loop) and at the service line level (inside SVC loops). Each CAS segment carries up to six adjustment reason code and amount pairs. The first field of each pair is the group code: CO for Contractual Obligation, PR for Patient Responsibility, OA for Other Adjustment, PI for Payer Initiated Reduction. The second field is the CARC code. The third is the dollar amount of the adjustment. PR-1 is a deductible the patient owes; PR-2 is coinsurance; PR-3 is copay. CO-45 is a contractual reduction to the fee schedule. CO-97 is a bundling denial. The group code determines the next action: CO adjustments go to contractual write-off, PR adjustments move to the patient statement workflow, OA and PI adjustments require investigation. See the denial management workflow guide for a full CARC-by-CARC routing table.

SVC — service payment information. SVC opens a service-line record under a CLP. SVC01 carries the procedure code (CPT or HCPCS) and any modifier. SVC02 is the submitted charge for that line. SVC03 is the amount paid at the line level. SVC04 carries the revenue code for institutional claims when applicable. The balancing test at the service line is the same as at the claim level: SVC02 must equal SVC03 plus the sum of all CAS adjustments at the line level. When SVC03 is lower than the contracted rate for a given CPT code and payer combination, that line is an underpayment candidate. The comparison requires a loaded fee schedule to be meaningful.

PLB — provider-level adjustment. PLB appears in the transaction summary section, after all CLP and SVC loops, and is covered in detail in the next section. It accounts for adjustments that are not tied to a specific claim.

SE, GE, IEA — trailers. SE closes the transaction set and carries a segment count that must match the actual number of segments between ST and SE. Segment count mismatches are a common cause of ERA file rejection before any content is parsed.

What a good ERA posting workflow does

The controls that matter most are the ones that keep wrong posting decisions from silently reaching the ledger, not the ones that make posting fast.

File intake with payer and practice validation. When an 835 file arrives from the clearinghouse, the system should confirm the payer identifier in NM1 loop 1000A, the payee NPI or tax ID in 1000B, and the practice context before opening any CLP loops. Multi-practice billing companies need this check so an ERA for one client cannot post against another client's claims. Medi routes ERAs to the practice context the payee NPI resolves to and surfaces any NPI mismatch as an exception before matching begins.

Claim and service-line matching. The system needs to find the original submitted claim for each CLP. The primary matching key is the patient control number in CLP01, which should match the claim control number the billing system assigned to the 837 submission. When CLP01 does not match any open claim — because the claim was submitted under a different control number, or because the claim is in a different practice context, or because the payer modified the control number — the line is unmatched and needs human resolution. Service-line matching within a matched CLP uses the procedure code and date combination from SVC to find the specific charge line.

Adjustment code routing. Once a claim matches, every CAS group code and CARC should drive a specific ledger action. CO adjustments post as contractual write-offs, with no patient bill. PR adjustments transfer the amount to the patient balance and trigger the statement workflow. OA and PI adjustments land in a review queue for investigation. Systems that flatten every adjustment into a single "adjustment" bucket lose the routing information that determines what happens next.

BPR reconciliation before ledger commit. Before any posting decision hits the ledger, the system should verify that the sum of all CLP04 payments minus the sum of all PLB adjustments equals BPR02. A file that does not balance has a parsing or transmission problem, and its claim-level numbers cannot be trusted until the root cause is found. Most billing software calls this "SNIP level 3 balancing," per the X12 implementation guide.

Secondary claim generation. When a CLP carries claim status 2 (adjusted by primary payer) and CLP05 carries a patient responsibility amount, the COB data needed to bill the secondary is already in the ERA. A workflow that captures it and queues the secondary at posting time, instead of waiting for staff to notice the balance, cuts the gap between primary payment and secondary submission from weeks to hours. When the secondary is not triggered at posting, it gets delayed or missed. The CAQH index ties secondary billing gaps to administrative cost in the payment cycle.

Audit trail and posting record. Every posting decision, auto-posted or human-reviewed, should record who initiated it, when, what the decision was, and what the ERA line said. Billing companies need this trail to answer payer audits, explain ledger entries to clients, and show that exceptions were reviewed rather than silently dropped.

BPR footer reconciliation — why it matters

BPR reconciliation is the most consistently skipped step in ERA posting, and the one most likely to catch a system or transmission problem before it corrupts the ledger.

The BPR segment appears once per 835 transaction set, near the top of the file, and carries a single dollar amount: the total the payer moved to the bank. Everything else in the file decomposes that amount. When the decomposition does not add up, the file was truncated in transmission, a PLB segment was misread, a CLP record was skipped, or the payer generated a malformed file. All of these happen in practice. A system that skips the BPR check and posts CLP records one by one posts partial data while looking like it succeeded.

The reconciliation formula, from the 835 transaction balancing specification maintained by the X12 community:

Total payment (BPR02) = Sum of all CLP04 claim paid amounts — Sum of all PLB adjustment amounts

The PLB sign convention drives most balance failures. A positive PLB amount reduces the check total: the payer took money back (recoupment, withhold, IRS levy). A negative PLB amount increases the check total: the payer added money outside any specific claim (forwarded balance, interest). Read PLB03 as a plain dollar amount without accounting for sign and you mis-reconcile systematically.

BPR reconciliation also catches the case where a payer sends one ERA covering multiple provider groups under a single BPR total. When the payee NM1 loop applies to only part of the file, the BPR total will not reconcile against that provider group's CLP records alone, and a system that does not model multi-provider-group ERAs fails the check. Payer companion guides specify whether their 835 uses one BPR per provider group or one for the entire file.

The practical test for any billing system: load a real 835 from a commercial payer, confirm the file-level balance check runs and reports pass or fail before any CLP-level decision, and verify a failure surfaces as a human-reviewable exception rather than getting skipped.

PLB segments: the recoupments, advances, and adjustments hidden in the ERA footer

PLB segments appear at the end of the 835 transaction, after all CLP and SVC loops have closed, and carry financial adjustments at the provider level rather than the claim level. A system that parses only the CLP loops posts the claim-level data accurately but reconciles against a BPR total it cannot explain. That unexplained difference, the PLB total, ends up in a suspense account or gets force-balanced in ways that corrupt the ledger.

X12 maintains the full list of PLB provider adjustment reason codes. The codes that billing teams see most often:

The BCBS Illinois PLB segment guide and Fawkes Health's PLB code overview both note WO is the most common recoupment code across commercial payers. WO means the payer already decided money was owed back; the billing team identifies which original claim or encounter the recoupment applies to, verifies the amount, and applies it to the correct ledger entry. When WO arrives without a reference claim number (which happens regularly, per Claim.MD's recoupment documentation), staff must call the payer for the original claim identifier before applying the adjustment.

FB matters most in multi-cycle ERA environments. When a payer uses FB to carry an overpayment recovery across several remittance cycles instead of collecting it at once, a system that does not model FB as a multi-cycle liability fails BPR reconciliation on every subsequent ERA until the forwarded balance clears. Tracking outstanding FBs and matching them to later clearance entries takes PLB-aware state in the posting system.

Held lines and exception handling

Even a well-matched ERA will produce lines that should not auto-post. The categories that need human review before the ledger sees them:

Write-off variance over tolerance. When a CO-45 adjustment matches the expected contractual rate within a small tolerance (typically a few dollars), auto-posting is fine. When the paid amount is materially below the contracted rate for that CPT code and payer, the line is an underpayment candidate, not an immediate write-off. The tolerance threshold is a business decision, configurable per payer. A billing company that writes off CO-45 adjustments without checking the loaded fee schedule under-recovers on contract underpayments. See the medical billing software FAQ for underpayment detection at posting time.

Secondary not yet posted. When a CLP record indicates a secondary-payer ERA but the primary payment has not posted yet, the secondary line cannot be verified without the primary posting context. Hold the line and notify the user rather than posting against an incomplete ledger entry.

Recoupment lines. Any WO or FB PLB entry without an identifiable reference claim should be held for review. A recoupment applied to the wrong original claim creates ledger distortions that are painful to unwind. The review step: identify the original claim from the payer reference number, confirm the recoupment amount against the original payment, apply the WO to that claim entry, and document the recovery reason.

PLB adjustments with no matching claim. PLB entries do not attach to a specific CLP record by definition. A system that cannot account for PLB in the ledger leaves BPR reconciliation permanently unbalanced. Surface each PLB entry as a named exception, with the reason code, reference number if present, and dollar amount, and route it to the right ledger bucket (interest income, overpayment recovery, tax withholding) after human confirmation.

Zero-dollar ERAs. A BPR02 of zero usually signals a fully denied remittance: every CLP line denied, no money transferred. These files still carry adjustment codes and patient responsibility amounts and still need to be matched and worked. Drop a zero-dollar ERA without processing its CLP records and the denied claims go unworked.

Duplicate ERA detection. When the same TRN trace number arrives twice, through clearinghouse re-delivery or payer retransmission, a system without duplicate detection double-posts every CLP record in the file. Detection should key on TRN trace number, payer identifier, payment date, and BPR02 amount together.

The CAQH 2023 index found that more than one-third of remittance advice transactions require human intervention. A posting workflow should make those interventions visible, owned, and traceable rather than letting them accumulate in an unworked exceptions queue.

Where does Medi fit?

Medi presents ERA posting as a structured review workflow inside the billing-company operating queue. When an 835 arrives through Stedi, Medi parses it to the segment level, validates BPR balance before opening any CLP records, routes each ERA to the practice context the payee NPI resolves to, and makes the matching and exception state visible to the payment poster assigned to that batch.

What that means in practice for a billing company:

• Payment posters see matched and unmatched lines in the same view, with the CLP claim status, paid amount, patient responsibility, and CARC codes translated to plain English alongside the raw codes
• PLB segments are shown as named line items (WO recoupment, L6 interest, FB forward balance) rather than raw segment strings, with the dollar impact on the BPR reconciliation shown alongside
• Lines that exceed the write-off tolerance, carry secondary-not-posted status, or have PLB entries without reference claims are surfaced as held exceptions in a review queue, not silently posted
• Posting decisions are logged with user, timestamp, decision type, and the source ERA line, so any posted amount can be traced back to the remittance data that drove it
• ERAs with BPR reconciliation failures are flagged before any CLP-level posting begins

Medi does not claim ERA posting is easy or that everything auto-posts cleanly. The claim is narrower: the workflow surfaces what needs review, keeps exceptions actionable, and leaves an audit trail that holds up under scrutiny. See billing-company operations for how ERA posting fits the broader revenue-cycle operating model.

What Medi does not claim:

• That all ERA lines will auto-post without human review
• That PLB recoupments will always carry enough information to identify the original claim without payer contact
• That underpayment detection replaces a loaded and maintained fee schedule for each payer contract
• That ERA posting replaces the denial workflow for claims that come back partially or fully denied

What should buyers verify in an ERA posting demo?

Billing-company buyers should ask for a live demo with a real 835 file, not a sanitized sample, and verify the following before forming a conclusion.

• Does the system run a BPR-level reconciliation check before opening any CLP records, and does it surface a BPR failure as a visible exception rather than silently continuing to post?
• Can the demo operator show a PLB segment being parsed, with each PLB reason code (WO, FB, L6, IR, AP) displayed as a named item and its impact on the BPR footer explained?
• When a CLP claim does not match any open claim in the system, does the unmatched line appear in an actionable exception queue, or does it disappear?
• Can the write-off tolerance threshold be configured per payer, and does the system hold lines that exceed the threshold rather than auto-posting them?
• When a secondary ERA arrives before the primary has posted, does the system hold the line or post it against an incomplete primary ledger entry?
• Is patient responsibility (PR-1 deductible, PR-2 coinsurance, PR-3 copay) automatically transferred to the patient statement workflow, or does the payment poster need to manually trigger that transfer?
• Can a payment poster see the full audit trail for a posted ERA line — user, timestamp, original ERA segment data — without leaving the ERA review screen?
• Does duplicate ERA detection use TRN trace number as part of the composite key, or can the same ERA be imported twice?
• For a multi-practice billing company, can the demo operator show that an ERA for Practice A cannot post against claims in Practice B's context?

If any of these get a canned walkthrough instead of a live file, press for a live run. The difference between a system that handles these cases and one that does not stays invisible until an edge case hits the ledger.

Frequently asked questions

What is the difference between an ERA and an EOB?

An ERA is the electronic equivalent of a paper Explanation of Benefits, delivered as an X12 835 transaction file. An EOB is the paper document a payer mails to a provider or patient explaining claim adjudication. CMS describes the 835 as the electronic equivalent of the paper EOB. Both carry the same core data (paid amounts, adjustments, CARC codes, patient responsibility), but billing software can parse an ERA and post clean matches automatically, while an EOB needs manual re-entry. Most commercial payers and Medicare have supported ERA enrollment for years; the 2022 CAQH index put ERA adoption at 83 percent, up from 43 percent a decade earlier.

What does it mean when an ERA fails to balance?

An ERA fails to balance when the sum of all CLP04 claim paid amounts minus the sum of all PLB provider-level adjustment amounts does not equal the BPR02 payment total. This is the SNIP level 3 balance check defined by the X12 835 implementation guide. Common causes include a truncated or partially transmitted file, a PLB segment that was parsed incorrectly (especially sign-convention errors on FB entries), a CLP record the parser skipped, or a malformed payer file. A posting system should surface the balance failure before any CLP-level decisions are made, because individual claim-level numbers from a file that does not balance cannot be trusted.

Why do some ERAs show a net payment of zero?

A zero-dollar ERA (BPR02 = 0) means the payer sent a remittance with no net payment transfer. The most common cause is a fully denied batch: every CLP line carried a denial code and no payment, so no money moved. These files still carry adjustment codes, patient responsibility amounts, and CARC codes for every denied claim, and they still need to be worked. A billing system that skips them leaves every denied claim in that batch unworked and untracked. The other cause is a recoupment that exactly offsets a new payment, where the PLB WO amount equals the CLP total and nets to zero.

What is a recoupment and how does it appear in an 835?

A recoupment is a payer-initiated recovery of a prior overpayment. In the 835, recoupments appear in PLB segments near the end of the transaction, using the WO (Overpayment Recovery) reason code for completed recoupments or FB (Forward Balance) for partial recoveries carried across multiple remittance cycles. The PLB segment should carry a reference number linking the recoupment to the original claim or payment, but Claim.MD notes that not all payers include sufficient information for providers to identify the original claim without calling the payer. A recoupment never appears in a CLP loop; it is purely a provider-level adjustment, so systems that parse only CLP records miss it entirely. See the section on PLB segments above for the full list of codes and their meanings.

How should write-off tolerances be set for auto-posting?

Write-off tolerance is the maximum variance between the expected contractual rate and the CO-45 adjusted amount that the system will auto-post without human review. Setting tolerance too tight creates a large exception queue full of penny-rounding differences. Setting tolerance too loose lets genuine underpayments auto-post as contractual write-offs, permanently losing recoverable revenue. Most billing companies set a dollar-value threshold (for example, five to ten dollars) rather than a percentage, and apply it per service line rather than per claim. The threshold should be reviewed when a new payer contract is loaded and adjusted based on how consistently that payer's fee schedule data aligns with the contracted rates in the system. Tolerance settings have no meaning unless the fee schedule loaded in the billing system is current; a stale fee schedule makes every CO-45 comparison unreliable regardless of the tolerance.

When should a payment poster call the payer versus working the ERA in the system?

Payer contact is the right next step when a PLB recoupment (WO or FB) arrives without a reference claim number, when a CLP carries a claim status code the billing system does not recognize, when a denial CARC requires documentation the system cannot retrieve (like a prior authorization reference that was never recorded), or when the BPR balance fails and the source of the discrepancy is not evident from the parsed segments. Review the ERA file first; most of what a payment poster needs for standard adjustment routing is in the CAS group codes and CARC codes. Payer contact pays off when the ERA data is genuinely insufficient, not when it has not been read carefully yet.

How does Medi handle ERAs that come from multiple payers in one file batch?

Medi parses the GS/GE functional group boundaries to separate ERA transaction sets from different payers within a single clearinghouse batch. Each ST-SE transaction set is processed independently, validated against its own BPR total, and routed to the practice context the payee NPI in its 1000B NM1 loop resolves to. A payment poster working a specific payer's ERA sees only the claims and PLB entries relevant to that transaction set. Cross-payer or cross-practice posting is not possible within a single ERA posting session. For more on how the multi-practice model works, see the medical billing software FAQ or request a demo.

How current is this guide?

Last reviewed 2026-06-07. X12 835 segment definitions and PLB provider adjustment reason codes are maintained by X12. CMS remittance guidance is at Health Care Payment and Remittance Advice. CAQH administrative efficiency statistics are from the CAQH Index Report. 835 balancing specifications are covered by the X12 EDI Academy. CARC and RARC code definitions are at x12.org/codes.