
A remittance advice explains how a payer processed a healthcare claim. Learn what an ERA and 835 file contain and how providers use them.
A remittance advice (RA) is the document a health insurance payer sends to a healthcare provider after processing a claim. It explains what the payer paid, adjusted, denied, or assigned to the patient, along with the codes used to explain those decisions.
A remittance advice may arrive on paper, through a payer portal, or electronically as an X12 835 transaction, commonly called an electronic remittance advice (ERA). Providers use this information to post payments and adjustments, route denials, identify patient responsibility, and reconcile remittance data with the corresponding check or electronic funds transfer (EFT).
This guide explains where remittance advice fits in the healthcare payment cycle, what an 835 file contains, how an RA differs from an explanation of benefits (EOB), and why complete, usable remittance data matters to revenue cycle performance.
A remittance advice is the payer’s response to a healthcare claim. The provider submits the claim, the payer adjudicates it according to the member’s coverage and the provider’s contract, and the remittance advice reports the outcome.
That outcome becomes the basis for several downstream revenue cycle activities. Payment and adjustment information must reach the correct patient accounts, denials and exceptions must be routed for follow-up, and the remittance total must be matched to the corresponding deposit or check. Missing, incomplete, or difficult-to-use remittance data can slow each of those steps.
The X12 837 and X12 835 are two parts of a standardized electronic exchange. The provider sends claim information to the payer using an 837 transaction. After adjudication, the payer returns payment and claim-detail information using an 835 transaction.
An 835 may include information for multiple claims associated with a payment. It can report claim- and service-line-level amounts, adjustment codes, patient responsibility, provider-level adjustments, and payment-identification information. The provider’s systems and workflows then use those details to apply and reconcile the payment accurately.
An ERA explains how claims were processed. It does not, by itself, move money. Funds are sent separately through an EFT or paper check.
When an EFT is used, payment and remittance information can be connected through identifying data such as the TRN reassociation trace number. This enables the provider to match the bank deposit with the 835 file that explains it. CAQH CORE operating rules establish requirements designed to support consistent EFT and ERA enrollment, delivery, and reassociation.
Remittance advice can arrive in several formats. A native 835 file is structured for electronic processing. Paper documents and portal PDFs contain similar information, but they are not automatically usable by most patient accounting or practice management systems.
Although electronic adoption has increased, providers may still receive paper or portal-only remittances from certain commercial payers, workers’ compensation carriers, out-of-network plans, and other payment sources. That remaining volume can create disproportionate manual work because staff must locate, interpret, key, or convert the information before it can follow the same workflow as an ERA. RMS often sees this residual volume become one of the most labor-intensive parts of an otherwise electronic remittance process.
The X12 835 Health Care Claim Payment/Advice transaction is the HIPAA-standard format used to transmit electronic remittance information. Its standardized structure allows compatible systems to interpret payer, payment, claim, service-line, adjustment, and provider-level data consistently.
A valid 835 can support automated posting and reconciliation, but it does not guarantee that every item will post without review. Payer variations, missing enrollment, unmatched deposits, unusual adjustment codes, split files, and system-specific configuration can all create exceptions. Strong remittance workflows automate routine activity while giving staff a clear path to resolve true exceptions.
Medicare may issue a Standard Paper Remittance (SPR), and CMS provides software that lets providers view and print Medicare 835 information. Other payers may deliver remittance documents through portals or on paper, especially when the provider is not enrolled for ERA or when a payment falls outside the payer’s standard electronic process.
For many organizations, the challenge is not understanding the value of ERA. It is completing and maintaining enrollment across a large and changing payer mix. Enrollment gaps can leave teams managing a fragmented stream of native 835 files, paper documents, portal downloads, checks, and EFTs. In RMS enrollment engagements, the work frequently involves identifying those gaps payer by payer and helping create a more consistent path for both remittance data and payments.
A remittance advice provides the information needed to understand how a payer processed one or more claims. The exact layout depends on the format, but common information includes:
For posting and reconciliation to work correctly, the claim and service-line details must roll up appropriately to the payment total, including any provider-level adjustments.
When the paid amount differs from the billed amount, standardized codes help explain the difference. A claim adjustment group code indicates the general category of financial responsibility. Common group codes include CO for contractual obligations, OA for other adjustments, PI for payer-initiated reductions, and PR for patient responsibility.
The group code is paired with a claim adjustment reason code (CARC), which identifies the reason for the adjustment. A remittance advice remark code (RARC) may provide additional detail. Correctly interpreting these combinations is important because the same payment variance may require a contractual adjustment, patient billing, denial follow-up, or another action.
Code usage is not always perfectly consistent across payers. Organizations need reliable payer-specific rules and exception workflows so that unusual combinations do not become incorrect write-offs or unresolved balances. RMS uses payer-specific configuration to account for those differences rather than assuming every payer will use remittance codes in exactly the same way.
Some financial activity applies at the provider level rather than to a specific claim. The 835 reports these items in the provider-level balance, or PLB, segment. Examples may include recoupments, interest, incentive payments, and other adjustments.
PLB activity is a common source of reconciliation variances because the sum of claim payments may not equal the total payment until the provider-level adjustments are included. Workflows that overlook or misclassify PLB entries can leave teams searching for differences that are already documented in the remittance data. RMS can apply customized PLB handling rules so provider-level adjustments are delivered in a way that supports the provider’s reconciliation process.
A remittance advice is generally sent to the healthcare provider, while an explanation of benefits is sent to the health plan member or patient. Both describe the payer’s adjudication of a claim, but they serve different audiences and purposes.
The provider-facing remittance contains information used for payment posting, adjustment handling, denial management, and reconciliation. The patient-facing EOB explains what was billed, what the plan covered, and what the patient may owe. Terminology can vary, and some payer documents sent to providers are labeled as EOBs. The most useful distinction is how the document is used: if it supports provider payment processing, it functions as remittance advice.
Healthcare organizations use remittance advice to:
A clean, properly configured 835 can allow routine payments and adjustments to flow into a patient accounting or practice management system with limited manual intervention. CARC and RARC combinations may also support denial routing and work-queue assignment.
However, automated posting depends on more than receiving an 835. The provider must have the right enrollment, system configuration, payer rules, file routing, and exception management in place. Native electronic data can still create manual work when files are missing, deposits are unmatched, adjustments are unfamiliar, or payer behavior does not match the provider’s setup. This is why RMS distinguishes between data that is simply electronic and data that is truly ready to support automation.
Reconciliation connects the remittance information with the money received. The goal is to confirm that each applicable deposit or check has supporting remittance detail and that each remittance can be tied to the corresponding payment activity.
When the EFT and ERA cannot be matched, cash may remain unapplied even though the money has reached the bank. At scale, those exceptions can delay daily reconciliation, month-end close, and financial visibility. RMS reconciliation workflows are designed to surface missing and unmatched activity so teams can focus on genuine exceptions instead of manually comparing every deposit and remittance.
Paper and portal-based remittance documents do not have to remain manual. They can be converted into standardized 835 files and delivered into the same downstream workflow as native ERAs.
RMS uses proprietary automation powered by AI, OCR, and NLP to identify, extract, interpret, and structure data from paper and portal remittances. That technology is paired with payer-specific configuration and a 100% onshore team rather than an operating model built around offshore keying. The goal is not merely to digitize the document, but to produce a clean, balanced electronic file that can move through the provider’s posting and reconciliation workflow with fewer manual steps.
These issues do more than slow payment posting. They can create unapplied cash, backlogs, delayed close, avoidable write-offs, and limited visibility into revenue performance.
Revenue Management Solutions helps healthcare organizations create a more complete and usable remittance stream. RMS supports EOB conversion, ERA and EFT enrollment, ERA reconciliation, and related remittance and correspondence workflows. Our proprietary technology uses AI, OCR, NLP, and configurable business rules to automate work that would otherwise require manual review or data entry, without forcing providers into a particular bank or clearinghouse relationship.
RMS can convert paper and portal remittances into balanced 835 files, help identify missing or unmatched remittance activity, and deliver information into provider workflows based on each organization’s system and business requirements. Our approach combines proprietary automation with 100% onshore operational support, payer-specific configuration, and flexible bank- and clearinghouse-agnostic delivery.
The goal is not simply to make remittance data electronic. It is to help providers receive the right information, in the right format, with the controls needed to keep payments moving and improve financial visibility.
A remittance advice is the payer’s explanation of how it processed a healthcare claim. It reports payments, adjustments, denials, patient responsibility, and the codes used to explain those decisions.
Not exactly. A remittance advice is generally sent to the provider and supports payment processing and reconciliation. An EOB is sent to the patient or member and explains coverage and potential patient responsibility. Some payers use the terms loosely for provider-facing documents.
An 835 is the HIPAA-standard X12 transaction used for electronic healthcare payment and remittance information. It can include claim and service-line details, adjustment codes, patient responsibility, provider-level adjustments, and information used to connect the remittance with the payment.
A health plan or other payer sends remittance advice after adjudicating a claim. Depending on the payer and the provider’s enrollment, it may arrive as an electronic 835, a paper document, or a portal PDF.
They are claim adjustment group codes. CO indicates contractual obligations, OA indicates other adjustments, PI indicates payer-initiated reductions, and PR indicates patient responsibility. These codes are paired with CARCs and sometimes RARCs to explain why payment differs from the billed amount.
No. The ERA explains how claims were processed. The EFT moves the money. Providers use payment-identification data, including the reassociation trace number when applicable, to match the two.
Yes. Paper documents and portal PDFs can be converted into standardized 835 files so they can enter a more consistent electronic posting and reconciliation workflow.
Remittance workflows often become fragmented one payer, portal, deposit, and exception at a time. RMS helps providers bring those pieces together through EOB conversion, enrollment, reconciliation, and related automation services. Talk with RMS to review where manual work and missing information are slowing your current process.
Explore the latest RMS news, insights, and resources in one place.