CARC and RARC Denial Codes Explained

CARC and RARC are both X12 external code lists used on the 835 remittance advice, and they answer different questions.

CARC (Claim Adjustment Reason Code) is External Code List 139. X12's published scope statement for the list is that these codes describe why a claim or service line was paid differently than it was billed. The list is maintained by CMG03, a code maintenance group operating under X12's External Code List Oversight (ECO) subcommittee within the Registered Standards Committee; CMG03 meets at each X12 Standing meeting. The list version posted as of 17 September 2026 is dated 1 November 2025.

RARC (Remittance Advice Remark Code) is External Code List 411, and X12's code-list directory records it as maintained by CMS. It supplies the additional explanation for an adjustment already described by a CARC, or conveys information about remittance processing. The version posted as of 17 September 2026 is dated 1 July 2026. Washington Publishing Company formerly distributed these lists; X12 now publishes them at x12.org, so work from x12.org rather than from a cached WPC copy.

A single 835 line carries one CARC and zero, one, or several RARCs.

"Adjusted" is broader than "denied." X12's own FAQ for list 139 defines adjusted as meaning the charge amount differs from the payment amount, and gives denial, zero payment, partial payment, reduced payment, penalty applied, additional payment and supplemental payment as examples. A CARC line is therefore not automatically a denial, and treating every CARC as a denial inflates a reported denial rate with contractual write-offs and patient cost-sharing that were never denials at all.

Group Codes. Each CARC line is paired with a two-character Group Code that assigns the adjustment:

So a line of `CO-97` is reason code 97 applied as a contractual obligation. Under HIPAA's electronic transaction rules, payers report 835 adjustments using these national code lists rather than proprietary internal reason codes.

One CARC inverts the division of labour entirely. A1 denies the claim and says nothing more, which is why the line carries a remark code — and why how to work a CO-A1 end to end starts at the RARC rather than at the reason code.

Read this first. The middle column is our plain-language restatement, not X12's published description. X12's code descriptions are copyrighted intellectual property rather than public domain, and X12 requires that a published description be implemented exactly as it appears on the list — so read the official wording at x12.org and load that wording, not ours, into your systems and patient communications.

The status and date columns are taken from the X12 code list itself, read 17 September 2026. "Start" is the activation date — the date all trading partners must support the code. "Last modified" is the date the code's attributes were last revised. Every code below was Current on that reading; none carried a deactivation date.

Status changes are not cosmetic. Codes do get retired: CARC 15 carries a deactivation date of 1 May 2018 on the X12 list, and a system still categorising incoming 15s as a live authorization denial is mis-routing work. X12's FAQ states that a deactivation date is the date trading partners must stop using the code, unless X12 has granted an exception for transmissions describing past activity. Filter the list by status — X12's page offers Current, To Be Deactivated and Deactivated — whenever you refresh your internal tables.

This is not the complete list; ECL 139 runs to hundreds of codes. Which of them dominate your remittances is a property of your specialty and payer panel, and the only reliable way to find out is to rank your own 835 data.

For the codes that drive the most denial volume, we maintain a dedicated guide with the verbatim definition, root causes, the exact fix workflow, payer-specific notes, and an appeal template. Bookmark the ones your practice sees most.

The Group Code in front of the CARC changes how the line is worked. The same reason code reads differently depending on the group it arrives in.

• CO-97 (Contractual Obligation, bundling). A contractual write-off. Review the NCCI edit, appeal with modifier 59 or an X-modifier if documentation supports a distinct service, or accept the write-off when the Modifier Indicator is 0.
• CO-50 (Contractual Obligation, medical necessity). Review the LCD or NCD, assemble documentation, appeal where medical necessity is supported.
• CO-22 (Contractual Obligation, coordination of benefits). The payer believes another insurer is primary. Verify the coverage hierarchy and re-bill if it was in fact correct.
• CO-109 (Contractual Obligation, wrong payer). Identify the correct payer and re-bill.
• OA-23 (Other Adjustment, prior payer impact). Informational on secondary claims; not a denial.
• PR-1, PR-2, PR-3 (Patient Responsibility — deductible, coinsurance, copay). The payer has assigned the amount to the member. What you may actually bill is a separate question, answered below.

A PR group code is the payer's assignment, not your billing authority. It tells you the payer did not pay that amount and attributed it to the member. Whether, and how much, you may collect is governed by things the 835 does not carry:

1. Your participation agreement with that payer. Network contracts define the patient's cost-sharing obligation and, for participating providers, usually prohibit billing the member anything above it. Read the amount alongside the contracted allowed amount, not alongside your billed charge.
2. Whether the member's plan is one where balance billing is restricted. Federal No Surprises Act protections and state balance-billing law limit what may be billed in specific circumstances, and a PR code on the remittance does not displace them.
3. Medicaid and Medi-Cal participation. Programmes generally prohibit billing the beneficiary for covered services beyond defined cost-sharing; a PR amount on a Medicaid remittance is not a licence to bill the patient.
4. Medicare non-covered services. Where a service is expected to be denied as not reasonable and necessary, the patient may only be held liable if a valid Advance Beneficiary Notice was obtained before the service.
5. Whether the PR code is a cost-sharing code at all. PR-1, PR-2 and PR-3 are cost-sharing. A PR code sitting on a plan-rule failure — PR-95, where a referral or notification step was missed — is a different situation: check your contract before transferring that balance, because in many agreements a missed administrative step is the provider's, not the member's.

And the mirror rule: CO amounts are never billable to the patient. A contractual obligation is an amount the contract says you absorb. Transferring a CO balance to a patient statement is a contract violation and, in many states, a regulatory one. The practical control is a rule in the posting workflow that blocks any CO amount from moving to patient responsibility, with an exception path that requires a named approver.

RARC supplies the detail the CARC alone does not. Where the CARC names the category of adjustment, the RARC names the specific policy, the missing item, or the required next step.

X12's directory records RARC as External Code List 411, maintained by CMS and published at x12.org. As with CARC, the descriptions are copyrighted and must be read and implemented from the source rather than reproduced from a third-party copy, and each code carries its own activation date and, where retired, a deactivation date.

Broadly, remark codes fall into two operational groups:

• Informational. They explain the adjudication without requiring anything of the provider.
• Action-required. They identify a specific deficiency — documentation to submit, an error to correct, information to obtain from the patient.

The practical rule when working denials is to read the pair, never the CARC alone. A medical-necessity CARC paired with a remark code pointing at a Local Coverage Determination is an LCD appeal, which has to address the LCD's own criteria; the same CARC paired with a remark code identifying a missing or invalid diagnosis is a documentation correction and resubmission. Treating both as one "medical necessity" bucket sends half the work down the wrong path.

Because the remark code determines the appeal path, the RARC belongs on the denial worklist as its own queryable field, not buried in a free-text note.

Both lists are maintained externally, and both change on a published cadence. Work from the current source, not from a cached internal copy.

Publication frequency: three times per year. X12's external code list FAQ answers the question "Are all of X12's external code lists (ECLs) published three times per year?" with "Yes, except new lists not yet available for use may be published more frequently." Three, not four — if your internal documentation or a vendor's says the CARC list updates quarterly, it is wrong, and a quarterly refresh calendar will miss or duplicate releases. Our BCBS denial code guide and the CARC glossary entry state the same three-times-per-year cadence.

CARC — External Code List 139. Maintained by CMG03 under X12's External Code List Oversight subcommittee. The version posted as of 17 September 2026 is dated 1 November 2025. The page also publishes the status of pending maintenance requests, so you can see a change coming before it lands.

RARC — External Code List 411. X12's directory records CMS as the maintainer. The version posted as of 17 September 2026 is dated 1 July 2026. Washington Publishing Company used to distribute these lists; x12.org is where they are published now.

What a new version can change. Per X12's FAQ, maintenance covers three things: a new code is added, an existing code is deactivated, or the wording of a code's description is revised. Every entry must carry an activation date — "the date all trading partners must begin to support the code" — and may also carry a deactivation date, an extended description, a technical note or a last-maintenance date. For list 139 specifically, X12 states that CMG03 sets a new code's start date to one of several options, including immediately upon publication, five months after publication of the new version, or nine months after. So publication and the date you must support a code are not the same date, and a refresh process that only reads code numbers will miss the difference.

CMS guidance. For Medicare fee-for-service, CMS issues Change Requests and MAC bulletins that introduce or retire specific CARC and RARC pairings for particular policies. These are worth tracking alongside the X12 releases, because they tell you which codes your Medicare volume will actually start seeing.

Build the refresh into a calendar. Three times a year, confirm your practice management system and clearinghouse have loaded the current tables; read the change log for codes affecting your specialty; and re-check your internal denial-categorisation rules against any code whose description was revised or whose status changed. A stale table is a quiet failure — the codes still post, they just no longer mean what your routing rules assume.

Reading codes is the easy part. Building a worklist that uses them reliably is where most practices fall short.

1. Separate adjustments from denials at ingestion. Not every CARC line is a denial — X12's own definition of "adjusted" covers contractual reductions, patient cost-sharing and additional payments as well. Classify each line first as a contractual adjustment, a patient-responsibility assignment, or a denial, and only route the third group to the denial worklist. Skipping this step is the most common way a reported denial rate ends up inflated by ordinary write-offs.

2. Auto-categorise the denial group by CARC family. Group codes into operational categories at ERA ingestion — eligibility, authorization, coding and bundling, timely filing, payer routing, payer-policy non-coverage — and assign each category to the team that owns the prevention workflow, not the team that works the appeal.

3. Track the NCCI Modifier Indicator on bundling denials. For bundling denials, the PTP Modifier Indicator (0, 1 or 9) determines whether the line is appealable at all. Holding it as a queryable field on the worklist stops appeal effort going into Indicator 0 cases.

4. Carry the RARC into the categorisation, not just the CARC. The remark code decides the appeal path. A single "medical necessity" bucket that ignores the remark code sends LCD appeals and documentation corrections down the same route.

5. Track outcomes by CARC, by payer and by reason for reversal. The value here is comparative and internal: the same reason code will reverse at materially different rates at different payers on your own book, and that difference is what tells you where appeal effort pays. Measure it from your own data — there is no published national overturn rate by code, and any figure quoted as one is somebody's experience rather than a benchmark.

6. Feed prevention data back weekly. Eligibility items route back to the front desk, authorization items to the authorization team, bundling items to coding. Without the prevention loop, the worklist runs forever without shrinking.

A dedicated denial management services team runs exactly this classify-appeal-prevent loop — by CARC family, by payer, with prevention data fed back to your front-end teams weekly.