Posting ERAs

ERA posting is where revenue cycle work either closes cleanly or starts bleeding. A remittance file arrives, claims get matched to service lines, adjustments land in the right buckets, and money moves to the ledger — or it does not, and someone has to find out why. Medi treats ERA posting as a controlled money workflow, not a blind import. Payment posters can see every matched and unmatched line, inspect the adjustment codes that drove each decision, and work exceptions without leaving the queue.

CMS describes the 835 transaction as the electronic equivalent of a paper explanation of benefits. That description undersells the complexity. A single 835 file can carry payment detail for hundreds of claims, provider-level adjustments that have nothing to do with any specific claim, recoupment entries from prior payment cycles, and interest credits or IRS withholding amounts. Getting all of that right requires a workflow with matching controls, exception routing, and a reconciliation step that validates the math before anything posts.

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, CARC 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 posting 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 that more than one-third of remittance advice transactions still require human intervention; a posting system that pretends otherwise will quietly create 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. Every other number in the file must reconcile back to this single figure — the sum of all CLP claim payments minus all PLB provider-level adjustments must equal BPR02 exactly. Any discrepancy means the file failed the balancing test that X12 calls SNIP level 3, and no posting decision based on that file can be trusted until the math is resolved. This is the reconciliation 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 counterintuitive sign convention is a frequent source of reconciliation errors when billing teams interpret PLB manually.

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 CAS adjustment amounts at the claim level must equal CLP03. When the math does not balance at the claim level, a posting system that swallows the discrepancy will corrupt 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 in an ERA posting workflow are not the ones that make posting fast. They are the ones that prevent the wrong posting decisions from silently reaching the ledger.

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 to prevent an ERA file for one client from posting 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 (no patient bill, no appeal queue). PR adjustments transfer the amount to the patient balance (statement workflow trigger). OA and PI adjustments land in a review queue for investigation. Posting systems that flatten all adjustments 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 is a file with a parsing or transmission problem, and individual claim-level decisions should not be trusted until the root cause is identified. This check is what most billing software calls "SNIP level 3 balancing," per the X12 implementation guide.

Secondary claim generation. When a CLP carries a claim status of 2 (adjusted by primary payer) and CLP05 carries a patient responsibility amount, the COB information needed to submit a secondary claim is available in the ERA. A posting workflow that captures this data and queues the secondary claim immediately — rather than waiting for staff to notice the balance — reduces the delay between primary payment and secondary submission from weeks to hours. When secondary claims are not triggered at posting time, secondary billing gets delayed or missed entirely. Per the CAQH index, secondary billing gaps are one of the primary causes of administrative cost in the payment cycle.

Audit trail and posting record. Every posting decision — auto-posted or human-reviewed — should record who initiated the action, 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 document that exception decisions were reviewed rather than silently dropped.

BPR footer reconciliation — why it matters

BPR reconciliation is the most consistently skipped step in ERA posting, and it is the step most likely to surface 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. It carries a single dollar amount: the total the payer moved to the bank. Everything else in the file is a decomposition of that amount. When the decomposition does not add up, something is wrong — either 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 posting system that skips the BPR check and posts CLP records individually will post partial data while looking like it completed successfully.

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 sign convention on PLB catches a lot of teams off guard. A positive PLB amount reduces the check total — it means the payer took money back (recoupment, withhold, IRS levy). A negative PLB amount increases the check total — it means the payer added money outside any specific claim (forwarded balance, interest). A billing team reading PLB03 as a straightforward dollar amount without accounting for sign will mis-reconcile systematically.

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

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

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. They carry financial adjustments at the provider level rather than the claim level. A billing system that parses only the CLP loops and ignores PLB will post the claim-level data accurately but will reconcile against a BPR total that it cannot explain. That unreconciled difference — the PLB total — often sits 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 that WO is the most common recoupment code across commercial payers. WO means the payer already made a decision that money was owed back; the billing team's job is to identify which original claim or encounter the recoupment applies to, verify that the amount is accurate, and apply it to the correct ledger entry. When WO appears without a reference claim number (which happens regularly, per Claim.MD's recoupment documentation), billing staff must call the payer to get the original claim identifier before they can apply the adjustment accurately.

FB deserves special attention in multi-cycle ERA environments. When a payer uses FB to carry forward an overpayment recovery across multiple remittance cycles rather than collecting it all at once, billing systems that do not model FB as a multi-cycle liability will repeatedly fail BPR reconciliation on subsequent ERAs until the forwarded balance clears. Tracking which FBs are outstanding and matching them to subsequent clearance entries requires PLB-aware state management 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 CO-45 adjustments match the expected contractual rate within a small tolerance (typically a few dollars), auto-posting is appropriate. When the variance is larger — paid amount is materially lower than the contracted rate for that CPT code and payer — the line is a candidate for underpayment investigation rather than immediate write-off. The tolerance threshold is a business decision, not a technical one, and it should be configurable per payer. A billing company that writes off CO-45 adjustments without checking against the loaded fee schedule will systematically under-recover on contract underpayments. See the medical billing software FAQ for more on underpayment detection at posting time.

Secondary not yet posted. When a CLP record shows a claim status that indicates this is a secondary payer ERA, but the primary payment has not yet posted in the billing system, the secondary ERA line cannot be verified without the primary posting context. The right behavior is to hold the line and notify the user, not to post it against an incomplete ledger entry.

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

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

Zero-dollar ERAs. When a payer sends an 835 with a BPR02 of zero, it typically signals a fully denied remittance — every CLP line is denied and no money was transferred. These files still carry adjustment codes and patient responsibility amounts, and they still need to be matched and worked. Dropping a zero-dollar ERA without processing the CLP records means denied claims go unworked.

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

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 file arrives through Stedi, Medi parses the file 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 then makes the matching and exception state visible to the payment poster assigned to that ERA 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's honest claim is not that ERA posting is easy or that everything auto-posts cleanly. The honest claim is that 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 into 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 evaluating ERA posting capabilities 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 are demoed with a canned walkthrough rather than a live file, press for a live run. The difference between a system that handles these cases correctly and one that does not is 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 information — paid amounts, adjustments, CARC codes, patient responsibility — but an ERA can be parsed by billing software and posted automatically for clean matches, while an EOB requires manual re-entry. Most commercial payers and Medicare have supported ERA enrollment for years; the 2022 CAQH index showed 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 in the file carried a denial code and no payment, so no money was transferred. Zero-dollar ERAs 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 zero-dollar ERAs will leave every denied claim in that batch unworked and untracked. Another cause of a zero-dollar ERA is a recoupment that exactly offsets a new payment — the PLB WO amount equals the CLP total, netting 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 does not appear in any CLP loop — it is purely a provider-level adjustment, which means systems that only parse CLP records will 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. The ERA file itself should always be reviewed first — most of the information a payment poster needs for standard adjustment routing is in the CAS group codes and CARC codes. Payer contact is most productive when the ERA data is 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-05-17. 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.