CARC and RARC Codes, Explained

CARC and RARC codes are the two standardized code sets a payer uses to explain what happened to a claim. A CARC, or Claim Adjustment Reason Code, states the primary reason a payer adjusted or did not pay a claim line, for example that a service was not covered or that required authorization was absent. A RARC, or Remittance Advice Remark Code, adds supplemental detail that explains or qualifies the CARC, such as which document the payer needed. Both sets appear on the 835 electronic remittance advice, the transaction a payer sends after adjudicating a claim, and on the paper equivalent. Read together, the CARC tells a biller why the claim was denied or reduced and the RARC tells them what to do next.

What is a CARC code?

A Claim Adjustment Reason Code is the payer's stated reason that the amount it paid on a claim line differs from the amount that was billed. Every adjustment, whether a full denial, a partial reduction, or a routine contractual write-off, carries a CARC that names the category of the reason. Examples of the categories you see often include a service that the plan does not cover, a charge that exceeds the contracted allowable, a duplicate submission, a service the payer considers not medically necessary, and cases where required prior authorization or precertification was not obtained. The CARC gives you the class of problem, which is usually enough to route the denial to the right next step even before you read the accompanying detail.

What is a RARC code?

A Remittance Advice Remark Code provides supplemental information beyond what the CARC conveys. Where the CARC names the reason category, the RARC narrows it down, often by identifying the specific document, field, or policy involved. If a CARC signals that information was missing, a RARC typically specifies what was missing, for example a particular attachment, an authorization number, or a required modifier. RARCs come in two forms: some supply additional explanation for a monetary adjustment, and others are informational only and do not by themselves change the paid amount. A single claim line frequently carries one CARC and one or more RARCs together, and it is the combination that gives a biller enough to act. Reading the CARC without the RARC often leaves you knowing the reason but not the fix.

What is the difference between CARC and RARC?

The difference is scope and role. A CARC is the primary reason code: it states, at the level of a category, why a line was adjusted or denied, and it is tied to the money, since every financial adjustment must carry one. A RARC is a supporting code: it explains, qualifies, or adds detail to the CARC, and on its own it may or may not affect payment. Think of the CARC as the headline and the RARC as the footnote that tells you exactly what the headline means for this claim. The two are maintained as separate national code sets, and a payer selects the specific codes that describe each adjustment. You work a denial by reading them in order, CARC first for the category, then RARC for the specific detail.

Where do CARC and RARC codes appear?

Both code sets appear on the 835 electronic remittance advice, the ANSI X12 transaction a payer transmits to report how it adjudicated a claim. The 835 is the electronic counterpart to the paper explanation of benefits or provider remittance advice, and the same CARC and RARC values that show on paper are carried in the electronic file. Within the 835, CARC values sit in the claim adjustment segments alongside the adjustment group codes and dollar amounts, while RARC values sit in the remark segments. Because the codes are national standards, the same electronic format lets billing software parse denials the same way across payers. This mirrors the broader HIPAA electronic transactions, including the eligibility inquiry and response a practice runs before a visit, which CMS administers under Administrative Simplification.

How do you use CARC and RARC codes to work a denial?

Working a denial from its codes follows a repeatable sequence. First, read the CARC to establish the category, then group denials that share a CARC so you handle like problems together rather than one claim at a time. Second, read the RARC for the specific detail, which usually tells you what the payer actually needs. Third, decide the path: if the denial reflects a correctable error, such as a missing modifier or an authorization that exists but was not attached, you fix it and resubmit; if the adjustment looks incorrect, you appeal. Fourth, gather the documentation the RARC points to before you refile, so the second submission answers the exact reason the first was denied. Appeals are worth the effort in aggregate: an analysis of ACA marketplace claims found that insurers denied roughly 20% of in-network claims in 2023 while consumers appealed fewer than 1% of them, which leaves a large amount of potentially recoverable revenue unworked. A tighter grasp of the codes is also part of good insurance eligibility verification, because many denials trace back to coverage facts that could have been confirmed before the visit.

Where an AI agent reads the 835 and routes each denial

Because CARC and RARC are standardized and machine-readable in the 835, denial routing is a good fit for automation. An AI agent parses the incoming remittance, reads the CARC on each adjusted line to determine the category, and reads any RARC for the supporting detail. It then routes each denial by its codes: contractual write-offs are recognized and closed, correctable errors are queued for the fix they need, authorization-related denials are sent toward the authorization workflow, and adjustments that warrant an appeal are flagged with the documentation the RARC identified. The code sets are updated on a published schedule, so the agent works from the current lists rather than fixed assumptions. In our AI denials management work, this turns a stack of remittances into a sorted queue where each denial arrives with its reason, its category, and a recommended next action, and a person reviews the routing before anything is resubmitted. Preventing the denial is better still, which is why the same approach extends to prior authorization automation so authorization-related CARCs show up less often.

Denials are only useful when the codes are read consistently and the follow-up actually happens. If you want to see what AI can take off your team's denial work, from parsing the 835 to routing each CARC and RARC to the right next step, book a call with Flexbone and we will map it against a sample of your own remittances.