How do I generate the 835 Payment Report and use it to track unmapped payments?

The 835 Payment Report is a new accounting export that provides visibility into every payment that has been received from an 835, whether the 835 was received electronically from the clearinghouse or manually uploaded into AlayaCare. From this report, you can see which claims and service lines have been updated and identify any unmapped payments from the 835.

 

You should run this report regularly to make sure all payments are successfully mapped to their corresponding claims and service lines.

• Generating the 835 Payment Report 
• Using the report to track unmapped payments

Generating the 835 Payment Report 

To generate the 835 Payment Report, go to accounting>accounting exports and select add accounting export.

 

 

Select Electronic Billing 835 Payment Report as the type.

 

The format will automatically be set to CSV. Enter a start date and end date for the report. Note that this date range is inclusive. Click save to prepare the report.

 

 

 

Once the report is ready, click the Electronic Billing 835 Payment Report button in the download column to download the file.

 

Using the report to track unmapped payments

Once you have ran the export, you can use it to identify any unmapped payments from 835 files. 

 

The export is divided by check number (column B), which is mapped to claim number (column D) and service line number (column M).  Column C will display one of the following payment reconciliation statuses based on whether the payment number could be successfully mapped to all claims and the service lines within these claims:

• Full: this status indicates that the payment received in the 835 was successfully matched to all claims and all service lines IDs associated with those claim. 
• Partial: this status indicates that only a portion of the payment was not matched. This status may occur when the claim ID but not the service ID was received or if the service line number received by AlayaCare is incorrect. It may also occur if some of the claims were voided, and the claim payment could not be mapped to the voided claim. 
• No_match: this status is expected if the Claim ID contained within the 835 did not not match to any claim IDs within Alayacare.
• Error: this status will be displayed if the payment encounters an unexpected situation. For example, this status will occur if all the claims that the payment maps to were voided between sending the 837 and receiving payment via the 835. As a result, the payment will not be able to map to any of the claim IDs.

Column D displays the reconciliation status at the claim level. The following claim reconciliation statuses may be displayed:

• Full: this status indicates that the payment from the 835 was successfully mapped to all service lines on the claim. The claim is paid in full. 
• Partial: this status indicates that some but not all of a claim has been successfully matched to the payment in the 835. It may occur if a service line cannot be correctly matched to a service line ID in the 835 because the incorrect service line ID was received. 
• FIFO allocation: this status indicates that the payment from the 835 was mapped to the service lines on the claim by using FIFO ("first in first out") allocation. This method of allocation is used when payment in the 835 is mapped at the claim level but not the service line level. In these situations, payments for the claim will instead be mapped to service lines in chronological order based on the date of service. In the case of an overpayment, the overpaid amount will be linked to the service line with the latest date of service.
• Error: this status will displayed will occur if an error occurred in mapping the 835 payment to this particular claim. You can learn more about the specific error by looking at the reconciliation error column.
• No_match: payment could not be successfully mapped from the 835 to the claim. 

The reconciliation error column will contain more information about any errors that occurred when mapping the payment to a claim. The following possible errors may be displayed:

• 835 error: mismatch client last name: this error may occur if the client's last name on the claim does not match the client name in the 835. 
• Cannot process 835 for already voided claim with id [123]: this error will occur if the claim has been voided.
• Unknown payer adjudication code: this error occurs if an unexpected payment status is received.
• 835 error: duplicated payment: this error may occur if the possibility of a duplicate payment at the file, claim, or service line level has been identified.
• Missing service date or bill code: this error will occur if the service line was not identified in the 835 using identifier (6R segment), and the payment level/service level information does not contain the service date or the bill code.
• No match to existing service line:  the system was unable to reconcile a service line with payment using an identifier and date of service and bill code. 
• FIFO: no service line can be selected for claim data id [123]: when trying to allocate payment using FIFO, the system was unable to find an eligible service line on the claim to match to the payment.

Each row on the export will either represent a service line number or claim ID depending on what AlayaCare receives in the 835:

• When AlayaCare receives an 835 that does not contain the service line information, each row on the export will represent 1 payment per claim.
• When we receive an 835 that does contain the service line information, each row on the export will represent 1 payment per service line. In this case, the same claim ID will be listed for each service line in the claim.

You can filter on different columns in the report to identify which claims require follow-up.

 

For example, column L displays the claim status.  You can filter out paid claims to view claims that have not been successfully mapped to a payment.  The reasons the payments were not mapped may vary, but in most cases the service line number field for the unpaid claims will be blank or contain an unknown number.

 

You can also filter out void or denied claims. 

 

For payments with a file status of partial, you can filter by the status partial and then filter for each individual payment number to identify which lines for that 835 do not contain a claim ID or service line number. You can then narrow down which claims in AlayaCare may require further action.

 

The complete list of fields in the 835 Payment Report are listed by below:

• Check date (column A): the payment date. It will repeat for all claims included in the 835.  Segment: BPR-16.
• Payment number (column B): the payment identifier from the 835. Segment: TRN-02. 
• Payment reconciliation status (column C): the status of the payment made in the 835 at the file level. The status will be full, partial, no_match, or error depending on whether the payment file could be successfully mapped to all claims and service lines.
• Claim number (column D):  the ID for a claim referenced in the 835.  The check number must be mapped to valid claim IDs for a payment to be successful. Segment: CLP-02.
• Claim reconciliation status (column E): the status of the payment made in the 835 at the claim level. The possible statuses will be full, partial, FIFO-allocation (meaning that the system was able to successfully map the payment to the claim using FIFO allocation), and no_match depending on whether the payment has been fully reconciled with the claim. 
• Payor (column F): the name of the electronic billing payor associated with the claim. Segment: N1.
• Claim payment status (column G): Indicates if the claim was processed by a primary or secondary or if there is a reversal of previous payment (clawback).
• Claim payment amount (column H): the amount paid for the claim. Segment: CLP-04.
• Claim total billed (column I): the total amount billed for the claim. This value will only be displayed if a claim ID from the 835 was successfully matched to a claim in AlayaCare. Segment: CLP-03.
• Internal control number (column J): the unique ICN received on the 835. Segment: CLP-07.
• Client first name (column K): first name of the client associated with the claim.
• Client last name (column L): last name of the client associated with the claim.
• Claim status (column M): the status of the claim (paid, denied, void, etc.). 
• Service line number (column N): the ID for a service line on a claim. Segment: REF*6R*.
• Service line submitted amount (column O): the original value for payment sent on the 837. Segment: SVC-02.
• Service line payment amount (column P): the amount paid for the service line from the 835. Segment: SVC-03.
• Service line paid quantity (column Q): the number of units paid for the service line from the 835. Segment: SVC-05.
• Service date (column R): the date of the service. 
• Reconciliation error (column S):  any errors that have occurred in reconciling the payment to the correct claim and service line will be displayed in this column.
• Denial reason (column T): if payment was denied, the denial reason will be displayed here.
• AC payment reference (column U): a reference number for the payment in AlayaCare that will be populated if the payment was successfully processed.
• AC payment transaction date (column V): the date that the payment transaction was processed. 
• Source system (column W): either Waystar or manual upload depending on whether you are importing payments into AlayaCare electronically or manually.
• File transferred on (column X): the date that the 835 file was received.