A remittance file can arrive with a claim number, a paid amount, a patient-responsibility amount, a group code, a Claim Adjustment Reason Code, and a Remittance Advice Remark Code. It is tempting to put the last two fields in a column called denial_reason and route everything from there. That shortcut replaces a record of adjudication with a conclusion the record did not make.
An explanation of benefits is post-adjudication. It records how a payer processed a billed claim and the adjustments applied to it. CMS describes CARCs as the overall explanation for a financial adjustment and RARCs as more specific or additional explanation. Those roles are useful precisely because they are narrow: they say how an amount changed, not the full operational history that led to the change.
The practical rule
- Keep the code, its code set, the group code, amount and claim/line scope together.
- Route for review only after combining the remittance with the claim, authorization and payer-specific workflow.
- Do not label an adjustment as a denial unless a source that actually makes that decision says so.
One remittance, three different questions
The 835 remittance advice has a clear job: account for payment. A Claim Adjustment Group Code allocates financial responsibility, a CARC states the broad reason for an adjustment, and a RARC can refine it or convey related processing information. CMS notes that line, claim, and provider-level adjustments are distinct scopes. An extraction must preserve that scope before anyone attempts to triage it.
That gives an operations team three questions that cannot be collapsed into one: What amount changed? Which standard code describes the adjustment? What evidence is needed before a person decides the next action? The first two can come from the remittance. The third comes from a workflow that has context the remittance does not contain.
| Signal in the EOB | What it can support | What it cannot establish alone |
|---|---|---|
| Group code | Financial responsibility category for the unpaid portion. | Whether a provider should appeal, correct a claim, collect, or wait. |
| CARC | Overall explanation for a financial adjustment. | The clinical or administrative event that caused the adjustment. |
| RARC | Additional adjustment detail or remittance-processing message. | A complete, payer-neutral work instruction. |
| Paid and adjusted amounts | The accounting effect at a line or claim scope. | Whether another claim, authorization, or document changes the response. |
The same code can lead to opposite actions
Consider a remittance row that needs supporting information. In one file, the claim was submitted without a required attachment and a corrected submission is appropriate. In another, the attachment was present but indexed to a different encounter, so the work is document reconciliation. In a third, the payer portal already shows a completed review and the open task is simply stale. A code can be consistent across all three while the next action is not.
This is why an honest document pipeline emits a candidate route rather than an automatic disposition. The candidate is evidence-backed: it includes the group code, CARC, every RARC, claim identifier, service dates, amount, and the page or transaction segment where each was read. The workflow then joins it to the original claim and the organization’s own payer rules.
A routing record, not a denial record
A useful extracted object is deliberately boring. It keeps standard-code fields separate from business labels, records which code list version was used, and distinguishes a missing value from an unread value. A blank RARC is not a failed extraction. A value the system could not read is not an absent remark code.
| Field | Why it travels with the code |
|---|---|
| Claim and service-line identifiers | Prevents a line-level adjustment from being assigned to the whole claim. |
| Group code, CARC, RARC list | Preserves the standard’s separate meanings instead of concatenating text. |
| Adjusted amount and responsibility | Connects the explanation to the accounting effect actually reported. |
| Code-list effective date/version | CARC and RARC lists change; a historical EOB needs its historical meaning. |
| Source location and confidence | Lets a reviewer inspect the remittance rather than trust a normalized label. |
The data model also needs an explicit state for needs context. That state is a successful result. It says the document was read, the adjustment was captured, and the system has stopped before inventing an explanation that belongs to a payer policy or a human review.
CARC and RARC are standards, not proprietary labels
CMS states that payers use CARCs and RARCs approved by X12-recognized code set maintainers rather than proprietary codes to explain an adjustment in claim payment. That makes the codes portable enough to extract consistently, but not identical to a universal resolution policy. A standard vocabulary improves the handoff; it does not erase payer contracts, authorization records, benefit design, or the claim’s submission history.
The code sets also change. Treating the rendered description in an EOB as timeless can make an old file look like it was processed under a later rule. Store the raw code, retrieve the applicable published description for the period when needed, and make any mapping to an internal queue versioned and reviewable.
Keep adjudication separate from care
An EOB is not a clinical record. It may reference a service, but it is not evidence that care was medically necessary, authorized, rendered as documented, or denied for a clinical reason. Those facts live in different systems and can carry different clocks. Calling every unpaid amount a denial collapses those systems and creates unsafe operational language.
That separation is also why this topic differs from medical record abstraction by episode. Episode abstraction joins records to make a reviewable care timeline. Remittance extraction preserves a financial adjudication record. The EOB can be one input to the episode, but it should not take over the episode’s meaning.
Build the exception queue around evidence
Start with an auditable event, not a label. A queue item should link to its remittance segment, the submitted claim, the payer and plan, the authorization or attachment state if available, and the policy version that selected the queue. It should declare what evidence is missing. That makes a correction, a reconsideration, and a no-action closure distinguishable outcomes rather than three names for a code.
- Extract at the native scope — line, claim, and provider-level adjustments are not interchangeable.
- Preserve every standard component — group code, CARC and RARC each contribute different information.
- Join before deciding — the original claim and payer workflow provide the context the EOB lacks.
- Version mappings — internal routing is policy, not a hidden property of a code.
- Require a reviewer-visible source — a queue reason without a location in the remittance is an assertion.
The code starts the review
CARCs and RARCs are valuable because they make an adjustment legible and comparable. They should start a review with a precise, standardized description of what changed. They should not finish the review by pretending the remittance contains the cause of a denial or the next step for every payer.
Good extraction makes that boundary visible. It returns the code, amount, scope and source with enough structure for a team to apply its own documented rules. The decision stays where it belongs: in a workflow that can see the claim, the context, and the policy that owns the outcome.