EDI 837 Claim and 835 Payment transactions have transformed the adjudication cycle for providers and health plans over the last two decades, but challenges remain in reconciling payments with claims. Recently, we’ve broken down the requirements for SNIP 3 claim balancing. Today we’ll focus on the 835 Claim Payment/Remittance Advice. Health plans submit 835s to providers (or their intermediaries) to explain which claims are being paid, and any reductions to the submitted amount and the reasoning for the adjustment. This is an important function – a significant pain point experienced by providers is the reconciliation of their income against claims submitted.
Before this valuable information can be loaded in practice management software, the 835 should pass validation checks. Common issues affecting 835s are balancing errors between the header and detail payment amounts. Imbalanced 835s lower the quality of reporting and can lead to billing errors and lost revenue.
WEDI describes up to seven levels of validation, referred to as SNIP 1-7. Many integration platforms, such as BizTalk, support the first two SNIP levels, which entail EDI structural validation and HIPAA codeset compliance. SNIP 3 balancing, on the other hand, typically requires specialized products or custom development.
The T-Connect X12 Studio Toolbox provides SNIP 3 for 837 claims balancing for 837 claims and 835 remittance advice transactions out of the box. Today we’ll focus on the rules that X12 Studio Toolbox uses to validate 835 payments, and how the validation results can be used to track and correct errors.
EDI 835 file structure
The important takeaway is that the 835 breaks down into three main groupings. Table 1 is a header containing summary information about the total payment amount. Table 2 is the core of the transaction. It describes payments on claim and service line levels, including any adjustments and their associated reason codes. These adjustment codes, referred to as CARCs and RARCs, are critical to understanding the payer’s reasoning in the adjudication process. Table 3 is comprised solely of the PLB segment. This segment contains additional adjustments not pertaining to specific claims in Table 2, but rather affecting the overall reporting total in Table 1. Monthly capitation payments are an example of adjustments that show up in the PLB segment in Table 3.
Balancing the 835 is required at three levels: the service payment line, the claim payment line, and the header total. Working from the inside out, let’s look at balancing the payment service lines first.
Service Payment Balancing
An 835 payment service line corresponds to a claim service line in an 837. These lines report on procedures (CPT codes) which roll up to a parent claim. The 2110 SVC segment reports service payment information. The two elements relevant to balancing the payment service line are:
- SVC02 – Submitted charge for the service line
- SVC03 – Amount paid for the service line
The remaining considerations are the CAS elements related to the service. A single CAS segment may contain up to six adjustments, and it’s possible for a service line to continue reporting adjustments with additional CAS segments.
The formula used to balance the service line is:
SVC02 – (CAS03 + CAS06 + CAS09 + CAS12 + CAS15 + CAS18) = SVC03
Balancing 837 Claims and 835 Payments: Claim payment information in the 835 corresponds to the 2300 claim level in an 837. The 2100 CLP segment in the 835 is used to represent claim payment information. Like the SVC segment on the service level, the CLP segment contains two relevant elements:
- CLP03 – Total submitted charges for the claim
- CLP04 – The amount paid for the claim
CAS adjustment segments may also occur on the claim level, and figure into balancing. It’s important to note that the same adjustment should not be reported on both the claim and service level.
The formula used to balance the payment claim line is:
CLP03 – (CAS03 + CAS06 + CAS09 + CAS12 + CAS15 + CAS18) = CLP04
EDI Transaction Balancing – Balancing the entire 835 transaction requires combining elements from each of the three tables in the 835. The components of this formula are:
- Sum of Claim Payments – this is derived by summing each CLP04 claim payment element from Table 2
- Provider Adjustment Amounts – these are the adjustments from Table 3, which affect the total payment but are not specific to a single claim in the 835
- Total Amount Paid – this is the total amount reported paid in the BPR segment from Table 1
The formula used to balance the entire transaction is:
SUM(of each CLP04 element) – (PLB04 + PLB06 + PLB08 + PLB10 + PLB12 + PLB14) = BPR02
X12 Studio Toolbox
Caliber Health’s T-Connect X12 Studio Toolbox provides a set of features helpful for streamlining HIPAA processes, including SNIP 3 balancing. X12 Studio can identify failures in any of the three balancing rules described above and surface the errors for remediation.
X12 Studio loads EDI transactions into a hierarchical tree view. With search features and expandable nodes, it’s easy to navigate and understand the structure of your EDI documents. The SNIP 3 feature allows for an 835 to be balanced on all three levels. Any warnings are reported in the validation results tab, which anchors back to the tree view to easily navigate through any issues identified.
Visit Caliber Health’s EDI software comparison page to pinpoint the best solution to meet your healthcare data management needs.