Retrieving ERAs

An ERA (Electronic Remittance Advice) is the payer's response to a submitted claim — a payment decision delivered as an X12 835 transaction. ClaimRev parses 835s as they arrive and exposes the data as structured JSON via the Payment Advice and ERA Quick Reports endpoints.

When is an ERA available?

• After the payer adjudicates your claim and ClaimRev receives the 835. Typical timeframe: 2–14 business days from submission, depending on payer.
• Payers usually batch ERAs — one 835 may cover many of your claims. Ditto when ERAs land in ClaimRev: a single payment advice record may aggregate many claim-level rows.

Search payment advice headers

The starting point for "what ERAs do I have?" is a header search:

POST /api/PaymentAdvice/v1/SearchPaymentAdvice
Authorization: Bearer <token>
Content-Type: application/json

The body is a search filter (date range, payer, account, etc.) — see the API Reference for the exact shape. Each result row gives you enough to drill into a specific advice.

Get one payment advice in full

Once you have an id from the search:

GET /api/PaymentAdvice/v1/GetPaymentAdviceById?id={id}
Authorization: Bearer <token>

This returns the full ERA payload — payer info, check/EFT number, payment date, totals, and per-claim service-line breakdowns including all CARC/RARC adjustments. Optionally scope to a specific claim control number with the claimControlNumber query parameter.

For a single-claim slice of an ERA:

GET /api/PaymentAdvice/v1/GetSingleClaimPaymentAdviceById?id={id}

Search claim-payment rows

If you want to search across the flattened claim-payment-advice rows (one per claim within an ERA) rather than ERA headers:

POST /api/PaymentAdvice/v1/SearchPaymentInfo

Most reporting use cases (denials, adjustments, deductibles) live here.

Pre-built reports and exports

EraQuickReports/* provides ready-made aggregations rather than raw payload reads:

• POST /api/EraQuickReports/v1/GetClaimList — claim-payment list for a search filter
• POST /api/EraQuickReports/v1/GetClaimDetails — claim-header detail (adjustments + service lines)
• POST /api/EraQuickReports/v1/GetClaimDetailsPdf — translated-ERA PDF (returned as base64)
• POST /api/EraQuickReports/v1/GetDeniedServiceLineReport (and *Csv variants) — denied service-line rows
• POST /api/EraQuickReports/v1/GetDeductibleServiceLineReport, GetCoinsServiceLineReport, etc. — patient-responsibility breakdowns

CSV-export variants are available alongside most of these for spreadsheet workflows.

Adjustment reason codes

Every line-item adjustment carries a group code (CO contractual obligation, PR patient responsibility, OA other adjustment, PI payer-initiated reduction) and a CARC reason code. Common examples:

Group	Reason	Meaning
CO	45	Charge exceeds fee schedule
CO	97	Service included in another procedure's payment
PR	1	Deductible amount
PR	2	Coinsurance amount
PR	3	Co-payment amount
PI	204	Service not covered under plan

The full CARC and RARC catalogs are published by the X12 standards body: x12.org/codes.

Raw 835 EDI

Self-serve raw 835 retrieval through the public API is not currently exposed. The bytes exist — the portal supports raw 835 download in two places — but the underlying endpoints live in a legacy controller that isn't published to the developer-facing Swagger today.

If you need raw 835 EDI for your integration, contact ClaimRev support; it can be made available through a legacy API on request. Migrating raw-EDI download into the v1 public surface is on the roadmap.

Secondary Claim Creation (COB)

When a patient has dual coverage, the primary payer adjudicates first; the secondary payer needs the primary's adjudication data to coordinate benefits. Once a primary claim is matched to its 835 ERA, you can derive a secondary claim from that combination — ClaimRev carries forward the COB data (paid amounts, adjustments, deductibles, copays) automatically.

POST /api/PaymentAdvice/v1/CreateDerivedClaim
Authorization: Bearer <token>
Content-Type: application/json

The request body is a CreateDerivedClaimRequest:

Field	Purpose
paymentAdviceId	Required. The ERA line to derive from: one claim's payment within an 835. See Finding the ids below.
matchedClaimId	Optional. The primary claim. Defaults to the claim the ERA line is matched to.
payerId / payerName / payerIdentifier	The secondary payer to bill
subscriberFirstName, subscriberLastName, subscriberMiddleName, subscriberSuffix, subscriberPrimaryIdent	The policyholder on the secondary policy, often a different person from the primary's. subscriberPrimaryIdent is the member ID.
relationshipCode	Required. The patient's relationship to the secondary subscriber. See below.
patientAddress1, patientAddress2, patientCity, patientState, patientZip, patientBirthDay, patientGender	Optional. Corrections to the patient's demographics. Each defaults to the patient on the primary claim.
policyNumber, groupName, insuranceTypeCode, claimFilingIndicator, payerResponsibility	Secondary policy details (SBR03, SBR04, SBR05, SBR09, SBR01)
serviceLineMatches	Optional: which service lines to flow into the derived claim
modifyControlNumber + newControlNumber	Optional: override the control number stamped on the derived claim

The full schema is in the API Reference.

Finding the ids

An 835 usually pays many claims. ClaimRev splits each ERA into one ERA line per claim, and a derived claim is built from one ERA line plus the primary claim it was matched to. You only need the ERA line's id: ClaimRev looks up the matched claim from it.

Starting from an ERA. Search the ERA lines with SearchPaymentInfo. Each row has:

Row field	Use it as
paymentAdviceId	paymentAdviceId
paymentInfo.matchedClaim.id	matchedClaimId (optional). Empty when the line is not matched to a claim.
payerPaymentAdviceId	Not used here. This is the whole ERA.

Starting from a claim. Search claims with POST /api/ClaimView/v1/SearchClaimsPaged. Each result has:

Result field	Use it as
singleClaimPaymentAdviceId	paymentAdviceId. All zeros (000000000000000000000000) means no ERA has been matched to this claim yet.
objectId	matchedClaimId (optional)
paymentAdviceId	Not this one. On a claim search result it identifies the whole ERA, and the request fails with 404.

Send matchedClaimId only when the ERA line is matched to more than one claim; ClaimRev tells you when that is the case. If you do send it, it must be a claim that ERA line is matched to.

paymentInfoId appears in older examples. It is no longer needed and is ignored: ClaimRev takes it from the ERA line.

A successful response returns the new claim's id:

{
  "claimObjectId": "65f1234abcd...",
  "claimTypeId": "..."
}

If the request cannot be used, the response is a 400 or 404 whose body says what is wrong:

{ "message": "This ERA line is matched to 2 claims (65f1..., 65f2...). Send matchedClaimId to choose one." }

Status	Meaning
400	paymentAdviceId is missing or malformed; the ERA line is not matched to a claim; it is matched to several and matchedClaimId was not sent; matchedClaimId is not a claim that line is matched to; or the claim could not be built.
404	No ERA line or claim with that id exists in an account your credentials can access.

The derived claim flows through the normal claim pipeline from there. Most integrators using ClaimRev's portal won't call this directly — the portal handles secondary claim creation as part of normal claim management. The API is exposed for EMR integrations that want to script the COB flow.

Subscriber, patient and policy fields on a derived claim

The patient is the same person on every payer, so ClaimRev carries the patient's address, birth date and gender over from the primary claim, and for a dependent their name too. You describe only what changes, which is the policyholder and the patient's relationship to them. (With "18" the patient is the policyholder, so the name comes from the subscriber* fields.) relationshipCode decides where the patient ends up:

relationshipCode	Loop 2000B SBR02	Patient loop (2000C)	Patient's address, birth date and gender are written to
"18" (the patient is the secondary policyholder)	18	Removed	The subscriber (2010BA)
Anything else, e.g. "19" (the patient is a dependent)	Empty	Created or kept, with PAT01 = your code	The patient (2010CA)

What that means in practice:

• Send relationshipCode. Unlike CreateClaimEdi, do not leave it out. ClaimRev writes SBR02 empty for you when it is not 18 and uses your code as PAT01.
• The subscriber* fields are the policyholder on the secondary policy (2010BA NM1, with subscriberPrimaryIdent as the member ID in NM109). For a dependent, the policyholder gets no address or DMG; the TR3 only requires those when the subscriber is the patient.
• Leave the patient* fields out unless the primary claim had the patient's details wrong. Any you send replace the primary claim's value for that field only; the rest are kept.

Policy fields go to loop 2000B:

Field	Segment
payerResponsibility	SBR01
policyNumber	SBR03, the insured group or policy number
groupName	SBR04, the insured group name
insuranceTypeCode	SBR05
claimFilingIndicator	SBR09

Send either policyNumber or groupName, not both: the TR3 says SBR04 is not used when SBR03 is present, and ClaimRev's validator rejects the claim if both are filled. The member ID is not a policy field. It goes in subscriberPrimaryIdent.

The primary payer's COB loop (2320) is built from the original claim, not from this request. Its SBR02 is the original subscriber's relationship code, or the original patient's code when the original claim had a dependent.

Unmatched ERAs

Occasionally a payer sends an ERA that doesn't cleanly auto-match to a submitted claim — wrong control numbers, missing identifiers, etc. The portal surfaces these for manual resolution. Each unmatched row is one single claim payment: one claim's payment within the ERA. The singleClaimPaymentId of a row from GetClaimPaymentAdviceInfos is that single claim payment id (its payerPaymentAdviceId is the ERA it came from), and it is the id every call below takes. Every id in the response is a 24-character hex string. The matching toolkit:

• POST /api/EraQuickReports/v1/GetClaimPaymentAdviceInfos — list single claim payments for your default account; with showUnmatched: true, only those that finished processing without matching a claim
• POST /api/PaymentAdvice/v1/SearchClaimsForManualMatch — fuzzy claim search to find candidates for an unmatched payment
• POST /api/PaymentAdvice/v1/MatchPaymentInfoToClaim — link a single claim payment (paymentAdviceId = the single claim payment id) to a specific claim
• POST /api/PaymentAdvice/v1/UpdatePaymentInfoControlNumber — correct the payer and/or claim control number on a single claim payment (paymentAdviceId = the single claim payment id; paymentInfoId is not needed) and retry automatic matching; returns whether it matched
• POST /api/PaymentAdvice/v1/RematchSingleClaimPayment — retry automatic matching for one single claim payment (singleClaimPaymentId); returns whether it matched
• POST /api/PaymentAdvice/v1/MatchPaymentAdvices — queue every unmatched single claim payment matching the search (same body as GetClaimPaymentAdviceInfos, your default account) for automatic matching; returns how many were queued, and results arrive over the next few minutes

These calls only act on single claim payments in your own accounts.

Most integrators won't need these directly; ClaimRev's portal handles unmatched-ERA resolution for you.