ERA Enrollment: Collect 835s From Every Clearinghouse

ERA enrollment points a provider's electronic remittance advice (the 835 file) at one receiver, so a third party cannot ask the payer for its own copy. To track reimbursements and denials across many practices, you collect the 835 from wherever each practice already receives it, then parse and normalize every file into one denial model.

This guide is for teams that serve many independent practices, each on its own practice management system (PMS) and clearinghouse. It covers why the 835 goes to one place, the ways to get a copy, the pipeline and data model we build, and the traps that make denial numbers wrong.

Nirmitee builds this for you. Our clearinghouse integration services and X12 EDI integration services cover the connectors to each clearinghouse and PMS. Our healthcare data engineering services cover the 835 parser, code normalization, claim matching and the central denial dashboard. To scope yours, get a denial data integration plan.

Why ERA enrollment sends each 835 to one receiver

An ERA enrollment tells a payer which trading partner receives the 835 for a given provider identifier, and payers set it up for one receiver at a time. Changing the receiver replaces the old one, which is why a new party cannot add itself as a second recipient.

The rule shows up in the payers' own documents:

• Medicare. The CMS Medicare Learning Network remittance advice fact sheet states: "MACs allow only one receiver of an ERA per National Provider Identifier. Your MAC will contact you if you are set up on its files for multiple receivers of the ERA." A MAC is the contractor that processes Medicare claims for a region. Availity's enrollment guide for Noridian, a MAC, says the same thing in practice: Noridian's system "will only allow you to link your NPI to one receiver ID for 835 ERAs."
• Blue Cross and Blue Shield of Alabama. Its 835 enrollment instructions say it "allows set-up of ERA (835) for only one Trading Partner ID at a time." A "Change Enrollment" moves the 835 from the existing trading partner to a new one.
• Blue Cross and Blue Shield of Louisiana. Its ERA form says the same, and adds that "the existing Trading Partner will be terminated 30 days from the enrollment date of your new Trading Partner."

ERA enrollment is a separate form from claim submission, so how a practice sends its claims (the 837) tells you nothing about where its 835s go. The national operating rule for ERA enrollment, the CAQH CORE Payment and Remittance ERA Enrollment Data Rule, requires a health plan to give providers instructions for changing or cancelling an enrollment. That makes a change possible, and it also confirms that a change is a formal step with the payer.

The Alabama and Louisiana forms also carry a field named "Preference for Aggregation of Remittance Data", with the provider's TIN (tax ID) and NPI beside it. In practice that choice decides whether remittance is grouped by NPI or by TIN. That choice decides how many 835s a practice gets and how they are split, and it matters later when you match payments to deposits.

For a central denial program, this means that for every practice, every payer, and every NPI or TIN, the 835 already has a home. Your job is to tap that home without breaking it. That is the first thing we build: a collection route per practice that leaves the payer enrollment and the practice's posting untouched.

Five ways to get a copy of each practice's 835

There are five practical ways to collect 835 data from a practice that already receives it, and the right one depends on what the practice's clearinghouse and PMS allow. Most programs end up using two or three of them across a portfolio.

Start with route 1 or 2 wherever the clearinghouse allows it, because you get the raw 835 without touching the payer enrollment. Use route 3 for practices whose clearinghouse offers neither. Keep route 4 as a cross-check, because the PMS shows what was posted, and the gap between the 835 and the posted data is itself a finding. Reserve route 5 for practices that hand you their billing.

For this layer we build one connector per clearinghouse (API or second delivery), an SFTP intake for the rest, and a PMS export reader for the cross-check. Each connector is built once and reused for every practice on that clearinghouse.

Whatever the route, get the practice's written authorization for the data you collect, and sign a business associate agreement before any file moves. The 835 carries patient names, member IDs and service dates.

Reference architecture for central 835 denial tracking

A central denial pipeline has five stages: ingest raw files, parse X12, normalize adjustment codes, match payments to claims, and serve a dashboard. Each stage keeps its inputs so you can rerun the next stage when a rule changes.

We build all five stages, and you own the code and the data.

1. Ingest: keep every raw file

Store every 835 exactly as received, with its source, practice, arrival time and a content hash. Never edit a raw file. When the parser improves or a mapping changes, you reprocess from this store instead of asking practices to resend files.

The hash also catches duplicates. The same 835 often arrives twice: once from a clearinghouse API and once from a practice's folder, or twice from a retry.

2. Parse: read the 835 into records

The parser turns each 835 into rows: one per payment (BPR and TRN), one per claim (CLP), one per service line (SVC), one per adjustment (CAS), and one per provider-level adjustment (PLB). Read the delimiters from the ISA segment of each file instead of assuming them, because senders differ.

Validate the totals as you go. The payment amount must reconcile against the claim payments and the provider-level adjustments in the same transaction. A file that does not balance is a parse problem or a payer problem, and either way it must not reach the dashboard without a flag.

3. Normalize: one model for CARC, RARC and group codes

Normalization turns each payer's adjustment into the same three-part key: group code, CARC and RARC. Every adjustment in an 835 has a group code and a reason code, and many carry a remark code.

• Group codes say who owns the amount. X12 lists four: CO (Contractual Obligation), OA (Other Adjustment), PI (Payor Initiated Reduction) and PR (Patient Responsibility).
• CARCs (Claim Adjustment Reason Codes) say why the amount was adjusted. A national code committee maintains them and updates the list three times a year.
• RARCs (Remittance Advice Remark Codes) add detail the CARC cannot carry. CMS maintains them and also updates them three times a year.

CAQH CORE operating rules also require standard CARC and RARC combinations for common business scenarios, and CAQH CORE maintains that combination list. Load all three lists as dated reference tables, so a code reported last spring is read with the meaning it had last spring.

On top of the standard codes, add your own denial category (for example eligibility, authorization, coding, timely filing, duplicate, bundling). Keep it as a separate column mapped from the codes. Never overwrite the payer's code with your category, because the category will change and the codes are the evidence.

4. Match: tie payments back to claims and deposits

Matching links each 835 claim to the claim the practice sent and each payment to the money in the bank. The 835's CLP01 carries the patient control number the practice put on the claim, and CLP07 carries the payer's own claim number. The TRN02 trace number ties the 835 to the check or EFT deposit.

Match on CLP01 within a practice first, then use CLP07 to follow the same claim across later 835s (reversals, corrections, appeals). Where you also have PMS data, compare posted amounts with paid amounts per claim. Differences are either posting errors or adjustments the biller changed by hand, and both are worth a report.

5. Serve: the denial dashboard

The dashboard answers a short list of questions for each practice and for the whole portfolio: what share of claims and dollars were denied, which codes drive it, which payers, which CPT codes, and whether it is getting better. Build every chart from the warehouse, never from raw files, so every number traces back to a file and a row.

Add one view people tend to forget: data completeness. For each practice and payer, show the date of the last 835 received. A practice whose files stopped arriving looks exactly like a practice with no denials.

Planning a build like this? In a free 30-minute call we map your practices' clearinghouses and billing systems, show how we would collect every 835 into one denial dashboard, and send you a written plan. Get a denial data integration plan.

A data model for normalized 835 denial data

The model below keeps one row per adjustment, linked up to the claim, the payment and the source file, so any dashboard number can be traced back to the exact segment that produced it. Field names are illustrative.

A synthetic example of one denied line, as it might look in an 835 and then in the model (no real patient, payer or provider data):

CLP*PCN-000123*4*250*0**12*PAYERCLM-9001~
SVC*HC:99214*250*0**1~
CAS*CO*197*250~
LQ*HE*N54~

Look up CARC 197 and RARC N54 in the current X12 and CMS lists before writing your category rule. Code meanings are versioned, and your rule must cite the list date it was written against.

Common traps that make denial numbers wrong

Most wrong denial dashboards come from a handful of 835 details, and each one is easy to test for once you know it. We build a check for every item below into the pipeline, so each one is caught before it reaches the dashboard.

CAS segments carry several adjustments

One CAS segment holds several reason and amount pairs under one group code (X12 describes six "adjustment trios" per segment), and one claim or line can have several CAS segments. Parse every pair. A parser that reads only the first pair undercounts denials and misreads patient responsibility.

Count denials by your counting unit, decided up front: claim, service line or dollars. A claim with three CAS reasons is one denied claim, three adjustments and one sum of dollars. Mixing units across charts is the most common reason two reports disagree.

PLB adjustments are not tied to one claim

The PLB segment reports provider-level adjustments that change the payment without belonging to a single claim. The CMS remittance fact sheet describes PLB reason codes as adjustments made "at the provider level, instead of a specific claim or service line." UnitedHealthcare's 835 guide, for example, uses FB (forward balance) to move a balance to a future remittance and WO (overpayment recovery) when an earlier overpayment is recouped.

If you ignore PLB, deposits will not match payments and recoupments will vanish from your numbers. Store PLB rows in their own table, keep the reference ID, and report them in their own section beside claim-level denials.

Reversals and corrections double count

When a payer changes how it paid a claim, it reverses the original and sends a corrected claim. In the 005010 version of the 835, the reversal uses CLP02 = 22, and X12's published interpretation states that a reversal must also negate the original adjustments (the CAS segments). The corrected claim then follows, in the same 835 or a later one.

Treat the reversal and the correction as events on the same claim, linked by the payer claim number, and report the latest state. A pipeline that adds every CLP row as new will show the same denial twice, or show a denial that the correction already overturned.

Payers use RARCs differently

Two payers can send the same CARC with different RARCs, or one payer can send no RARC where another always does. Do not build your category map on RARCs alone. Map on group code plus CARC first, and use RARC only to refine a category where the payer's usage is consistent. Review the map per payer when a new combination appears, and alert on combinations you have never seen.

Duplicate files from more than one route

When you collect from two routes for the same practice, the same 835 will arrive twice. Identify duplicates by content hash first, then by payer, TRN02 trace number and payment amount, since a resent file may differ in its envelope. Load once and record the second arrival as a duplicate of the first.

Grouping by NPI or TIN changes what a file covers

A practice that asked the payer to group remittance by TIN receives one 835 for many NPIs, and a practice grouped by NPI receives one per NPI. Store both identifiers on the payment row, and take the rendering or billing provider for each claim from the claim data.

Code lists change three times a year

CARC and RARC lists are updated three times a year. A code can be added, changed or stopped. Load each release with its dates, and never reinterpret old adjustments with new descriptions.

What we build: deliverables and engagement steps

Nirmitee builds the full 835 denial pipeline for organizations that serve many practices: the connectors, the parser, the denial model, the matching and the dashboard. You own the code and the data.

What you receive:

• A route inventory: for each practice, its PMS, clearinghouse, payers, NPIs and TINs, and the collection route we will use.
• Connectors to each clearinghouse (API or second delivery), an SFTP intake, and PMS export readers where no 835 route exists.
• A raw file store with hashing and duplicate detection.
• An X12 835 parser with transaction balancing and flags for files that do not balance.
• A normalized denial model with dated CARC, RARC and group code tables, and a denial category map you can edit.
• Claim and deposit matching on CLP01, CLP07 and TRN02, with reversal and PLB handling.
• A denial dashboard by practice, payer, code and CPT, plus completeness alerts for missing files and new code combinations.
• A reconciliation report that compares 835 data with PMS posted data for each pilot practice.

How the engagement runs:

1. Integration plan call (free, 30 minutes). We map your clearinghouses and billing systems and send a written plan.
2. Discovery. We complete the route inventory and the paperwork (business associate agreement, practice authorizations).
3. Pilot. Three to five practices on different routes, built end to end through the dashboard.
4. Reconcile. We compare the pilot's numbers with each practice's PMS and explain every difference.
5. Scale. We add practices in batches by route, and hand over the code, runbooks and alerting.

Step-by-step rollout for a multi-practice portfolio

A rollout works best practice by practice, starting with discovery and a small pilot, so you learn each route's failure modes before you scale. The steps below assume a portfolio of independent practices with mixed systems.

1. Inventory where each 835 lands today. For each practice: PMS, clearinghouse, payers, NPIs, TINs, and whether ERAs are grouped by NPI or TIN. Write down who at the practice can authorize data access.
2. Pick a route per practice. Use the route table above. Prefer the clearinghouse API or a second delivery. Record the route and the reason in the practice's record.
3. Sign the paperwork first. Business associate agreement, the practice's written authorization, and any clearinghouse terms for third-party access.
4. Pilot with three to five practices on different routes. Cover at least one clearinghouse API, one SFTP drop and one PMS export, so the pilot tests the hard cases.
5. Build ingest, raw storage and the parser. Keep every raw file and its hash. Balance every transaction and flag the ones that do not.
6. Load the code lists and write the category map. Group code plus CARC first. Date every mapping rule.
7. Check against the practice's own numbers. For one month per pilot practice, compare total paid, total denied and top denial codes against the PMS. Explain every difference before you trust the dashboard.
8. Turn on completeness alerts. Alert when a practice or payer has no new 835 for longer than its normal gap, and when a new code combination appears.
9. Scale in batches. Add practices in groups, by route. Re-run the step 7 check for each new route or clearinghouse.
10. Review the category map every code release. Three times a year, load the new CARC and RARC lists and review new combinations seen in the data.

Get a denial data integration plan. In a free 30-minute call we map your practices' clearinghouses and billing systems, show how we would collect every 835 into one denial dashboard, and send you a written plan. Book my integration plan.

Related reading

• 835 vs 837: claim and remittance files explained
• What is an 835 file, with a decoded example
• How long EDI and ERA enrollment takes with payers
• Denial root cause analysis
• Payment posting software compared
• RCM integration services

Sources

• CMS Medicare Learning Network, "Medicare Remittance Advice" fact sheet, ICN 908325, January 2016 (copy hosted by the Maryland Department of Health): https://health.maryland.gov/pophealth/Documents/Local%20Health%20Department%20Billing%20Manual/PDF%20Manual/Section%20VI/MC%20Remittance%20Advice%20Fact%20Sheet%202016.pdf
• Blue Cross and Blue Shield of Alabama, 835 enrollment instructions (Availity), revised December 2017: https://essentials.availity.com/availity/documents/E_SB510_BCBSAlabama_835.pdf
• Blue Cross and Blue Shield of Louisiana, ERA enrollment form: https://providers.bcbsla.com/-/media/Files/Providers/ERA_form.pdf
• CAQH CORE Payment and Remittance ERA Enrollment Data Rule vPR.2.0: https://www.caqh.org/hubfs/CORE/CORE_Payment_&_Remittance_ERA_Enrollment_Data_Rule_vPR.2.0.pdf
• Availity, Noridian (Medicare Utah Part B) 835 and 837 enrollment guide, updated August 5, 2019: https://essentials.availity.com/availity/documents/E_03502_Medicare_Utah_PartB_835_837.pdf
• X12, Claim Adjustment Group Codes: https://x12.org/codes/claim-adjustment-group-codes
• X12 Request for Interpretation 1811, CAS adjustment trios: https://x12.org/resources/requests-for-interpretation/rfi-1811-837-multi-cas-wsame-group
• X12 Request for Interpretation 1429, reversals in the 835 (005010X221): https://x12.org/resources/requests-for-interpretation/rfi-1429-cas-required-backed-out-cla
• UnitedHealthcare, EDI 835 Provider-Level Adjustments: https://ams-gateway.uhcprovider.com/content/dam/provider/docs/public/resources/edi/EDI-835-Provider-Level-Adjustments.pdf