Remittance Advice Remark Code (RARC)

What a Remittance Advice Remark Code is

A Remittance Advice Remark Code (RARC) is a standardized code set used on electronic remittances (835) and paper EOBs to explain payer decisions about a specific service line or entire claim. RARCs are maintained at the national level and used across payers, often alongside Claim Adjustment Reason Codes (CARCs) and group codes like CO or PR.

Where a CARC tells you the broad adjustment reason, such as noncovered service or missing information, the RARC supplies the narrative detail. Example: a CARC CO-197 for "authorization exceeded" may be paired with a RARC that clarifies which dates or units were not authorized.

RARCs appear in the remark segments of the 835 and in the remark or notes section on EOBs. They are part of the official data you must interpret before deciding to correct and resubmit, rebill to a different payer, write off, or appeal.

Why RARCs matter operationally

RARCs drive operational decisions in denials management and cash acceleration. Misreading them means misclassifying denials, which leads to the wrong workqueues, the wrong owner, and slower recoveries.

For example, N130 often appears when the payer is instructing you to refer to the member's plan documents, which usually means a true benefit exclusion or a noncovered service. That is a quick write off or patient responsibility move, not a case for multiple appeal cycles.

On the other hand, a documentation related RARC tells you exactly what is missing, such as treatment notes for a specific date, so you can route to clinical staff instead of bouncing the claim around billing.

Operationally, clean RARC mapping lets you:

• Separate correctable front-end errors from hard benefit exclusions.
• Identify patterns that warrant process changes, such as recurring "authorization exceeded" on day 31 of residential.
• Build accurate denial reports that show avoidable vs unavoidable write offs.
• Triage work by recovery potential and filing limits, instead of by payer alphabetically.

Each of those points connects directly to dollars. Poor RARC handling typically shows up as higher avoidable write offs and longer days in AR because the same errors repeat with no feedback loop.

How to read and use RARCs in workflow

RARCs show up in specific segments of the 835. In practice, most teams see them in a posting system, billing platform, or clearinghouse portal, not in raw EDI. You should always read RARCs in context: group code + CARC + RARC + units and dates.

A clear operational way to use them:

• Start with the group code and CARC to know the financial category (contractual, noncovered, patient responsibility, etc.).
• Read every RARC attached to the same service line. Many payers stack multiple RARCs to fully explain a denial or reduction.
• Translate each common RARC into your internal denial reason categories, such as "authorization", "eligibility", "medical necessity", "noncovered benefit", or "billing error".
• Tie RARCs back to specific upstream steps, such as benefits verification, utilization review, charge capture, or documentation.

For appeals, RARCs are part of the official story you must answer. A medical necessity RARC will require clinical justification and potentially ASAM-aligned criteria in behavioral health. A billing format RARC might only need a corrected claim with the right modifier or POS.

Strong denial reporting uses both CARC and RARC. CARCs alone are too blunt. When your system parses and stores RARCs correctly, you can see which denials could have been prevented and where in the workflow to fix them.

• Ignoring RARCs and working denials only from CARCs, such as treating every CO-16 the same without noticing that one RARC points to missing taxonomy while another points to invalid NPI, which require different fixes and owners.
• Not mapping remark codes like N130 into an internal category of true benefit exclusion, so staff spend weeks appealing noncovered residential days that can never pay under the member's plan.
• Failing to read all RARCs attached to a line, for example seeing only a documentation RARC and missing a second RARC that flags an authorization overage, which leads to an appeal that only addresses half the denial.
• Letting your practice management or billing system post based only on CARC logic, so RARC-indicated issues such as partial medical record receipt do not create denial work items and end up as quiet write offs at month end.
• Using payer-specific, homegrown reasons instead of standardized RARC descriptions in reports, which makes it impossible to compare denial patterns across payers or identify that multiple plans are using the same national remark code for the same root cause.

In behavioral health, RARCs often carry the real nuance behind carve outs and long episodes of care. For example, when a behavioral health benefit is carved out to a separate vendor, the medical plan may apply a CARC like CO-96 with a RARC clarifying that behavioral services are handled by another administrator. If your team misses that RARC, you can waste 30 to 60 days appealing to the wrong payer while timely filing for the true behavioral vendor burns down.

Concurrent authorization and utilization review issues also surface in RARCs. Per-diem residential, PHP, and IOP are prone to partial denials where early days are paid and later days are denied with an authorization related remark code. Those RARCs often name the last approved date or units. That detail determines whether UR should request an auth extension, whether you should cut discharge earlier, or whether to write off days as noncovered.

State Medicaid and Medicaid MCOs frequently use RARCs to encode program-specific behavioral rules, such as exclusion of certain SUD services for adults, ASAM level restrictions, or missing required assessment tools. Those can be easy to miss because the base CARC looks generic. Reading and coding these RARCs correctly into your denial analytics is how you spot that one program needs different documentation or a different level-of-care coding strategy.

AI can help with remittance advice remark codes by reading every 835 remittance, extracting all CARC and RARC pairs, and mapping them into consistent internal categories. That removes the manual work of scanning PDFs or screens, hand-coding denial reasons, and maintaining payer-specific code maps in spreadsheets.

Supabill's denials agent can ingest remittances, interpret the RARC plus CARC context, and classify each line item into workqueues such as auth, eligibility, benefits exclusion, or documentation, using payer rules you define. Humans still need to own edge cases, appeal strategy, and conversations with payers and clinical teams, especially for medical necessity and level-of-care disputes. AI should do the reading and sorting at scale, while your staff use judgment to decide which denials to fight and how hard.

How are Remittance Advice Remark Codes different from Claim Adjustment Reason Codes?

Claim Adjustment Reason Codes (CARCs) describe the broad reason for an adjustment, such as noncovered service, duplicate, or benefit maximum reached. Remittance Advice Remark Codes (RARCs) add narrative context and detail, such as specifying that a service is not covered for the diagnosis submitted, or that only a portion of the stay was authorized. Operationally, use CARCs to understand the financial category of the denial, and RARCs to understand the specific fix or appeal argument. Source

Who maintains the official list of RARCs, and do all payers have to use them?

RARCs are part of the national code structure tied to the HIPAA standard for electronic remittance (835). CMS and standards bodies such as X12 coordinate the code sets and their use. Medicare and most commercial and Medicaid payers use the standard RARC list. Some payers may also include plan-specific text, but the standardized RARCs are the part you can reliably map and trend across payers. Source

How should behavioral health providers store and report on RARCs?

Behavioral health providers should capture RARCs at the service-line level in their billing or analytics platform, not just at the claim header. Then map each common RARC to a small set of internal denial categories such as authorization, benefit exclusion, medical necessity, documentation, or billing format. For residential, PHP, and IOP, make sure your reports show RARC patterns by day-of-stay or unit, because many Medicaid and commercial plans use the same few RARCs when they cut off authorization mid-episode. Source

Can RARCs change over time, and do we need to update our denial mapping?

Yes. The national lists of RARCs can be updated periodically with new codes, retirements, or clarified descriptions. Plans may also change which RARCs they use for a given scenario as policies evolve. Your denial mapping logic should be reviewed regularly, with someone responsible for checking new remittance patterns and confirming that any new or frequently used RARCs are correctly categorized. Ignoring this can cause silent shifts in your reported denial mix and hide new problems. Source

What should we do when the RARC text is unclear or seems to contradict the CARC?

If the RARC seems unclear, compare it against the official description from the standard code list and review other recent remittances from the same payer to see how they are using it. When a RARC appears to contradict the CARC, treat the situation as a payer clarification issue and contact the payer's provider line or portal messaging with a specific example claim. For behavioral health, keep examples of concurrent auth or medical necessity cases handy, since those often expose inconsistencies in payer use of RARCs that you can address through escalation or contract discussions. Source

• CMS
• X12