Skip to main content

Conditional 835 Auto-Reversals

This article describes a 2024 planned feature delivered through the myAvatar Product Roadmap. This information is subject to change.

What are we doing?

Adding the ability to conditionally post automatic reversals during the 835 process. This new logic will allow organizations to determine if there are scenarios in which an automatic reversal should not be posted - for example, when the service is denied.

Why are we doing it?

It is common practice for organizations to post contractual allowance adjustments automatically during liability distribution. The reason for this practice is for accurate expected revenue reporting. Posting the contractual adjustments during liability distribution provides a better picture of the expected revenue versus reporting the gross charge. 

During 835 remittance posting, the system can automatically reverse contractual adjustments to allow 835 remittances to post accurately. For example, there may be a scenario where the organization has a contractual adjustment of $40 configured for a service. The actual contractual adjustment on the remittance may be $35. During the 835 remittance process, the system will reverse the initial $40 contractual adjustment to bring the service back to its gross amount and then will post the actual payment, contractual adjustment, and any other adjustments per what is on the 835 remittance file.

This process works well until a service is denied, either partially or fully, due to a reason that will be corrected. Currently the system automatically reverses the contractual adjustment and the service returns to its gross charge. An organization will need time to work a denial and rebill the service. During this time, the organization is overstating their expected revenue. To avoid this reporting issue, organizations often choose to import a payment/adjustment file to place the contractual adjustment back on the service.

This enhancement will allow organizations to configure when this automatic reversal should occur so that expected revenue is reported accurately without needing end user intervention to reapply contractual adjustments. 

How are we doing it?

Adding a new field to the Claim Adjustment Group/Reason Code Definition form titled "Prevent 835 Adjustment Reversal From Posting When This Claim Adjustment Group/Reason Code Is Present On The Service". The 835 process will be updated to evaluate service and claim adjustments to determine if an automatic reversal should post for the service or not. 

 

  • Was this article helpful?