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 / paymentInfoId / matchedClaimId	References to the primary claim and its matched ERA
payerId / payerName / payerIdentifier	The secondary payer to bill
subscriberFirstName, subscriberLastName, subscriberPrimaryIdent, subscriberBirthDay, etc.	Subscriber info on the secondary policy (often different from the primary subscriber)
policyNumber, groupName, relationshipCode, insuranceTypeCode, claimFilingIndicator, payerResponsibility	Secondary policy details
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.

A successful response returns the new claim's id:

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

A 204 No Content response means ClaimRev couldn't build the derived claim from the references you supplied — usually the primary isn't actually matched to its ERA, or one of the references is wrong.

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.

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. The matching toolkit:

• POST /api/PaymentAdvice/v1/SearchClaimsForManualMatch — fuzzy claim search to find candidates for an unmatched payment-info row
• POST /api/PaymentAdvice/v1/MatchPaymentInfoToClaim — link a payment-info row to a specific claim
• POST /api/PaymentAdvice/v1/UpdatePaymentInfoControlNumber — correct the control number on a payment-info row so it auto-matches to the intended claim

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