Inside the 835: Part 1 – CR Codes
By Caleb Dixon, RemitDATA, Inc.
This is Part 1 of a series delving into some interesting happenings inside the 835 Electronic Remittances.
Inside the 835 exists unique logic regarding Claim Reversal (CR) codes. CR codes are negative line item transactions primarily used by payers to indicate a change of adjudication or previously paid transactions. Some people think they are used solely to cause confusion. This can seem very true at times, especially as I’ve seen CR codes used in various ways. Additionally, they did not appear on the Paper EOB and were not used in the older NSF Electronic Remittances. The key is to understand why they exist and what to do with the information they provide.
Change of Adjudication
In this example, you bill Product A, get denied, re-submit the corrected claim, and then get paid. Prior to the ANSI conversion and implementation of CR codes, you
would have received your denial code (whether paper EOB or Electronic Remittance), and then subsequently received your payment after re-submission. Now, you
receive your denial code, and when the claim is paid, receive a negative CR code to reverse the decision of the initial denial and adjudicate with the new payment.
So if we use CO57 as our denial code, the sequence of events would look like this:
Submit claim > CO57 denial > Re-submit claim > CR57 + CO42 payment.
The CR57 reverses the initial denial of CO57 in order to make the net effect result in the CO42 payment. Usually you have a corresponding CO or OA code for every
CR Code. This is necessary in order to have the new adjudication (payment or denial) to replace the CR code adjustment. It gets complicated quickly when your claim involves multiple products getting denied and paid at different times. This brings us to our next example.
Previously Paid Transactions
If the above example had involved Product A and Product B on the same claim where Product A got denied as detailed above and Product B was paid initially, the adjudication with the final payment for Product A would look like:
Product A: Submit claim > CO57 denial > Re-submit claim > CR57 + CO42 payment.
Product B: Submit claim > CO42 payment > Re-submit claim (to get Product A paid) > CR42 + CO42 payment.
You may ask yourself, why would the payer reverse the initial CO42 and pay it again? The perplexing thing is that they did not, but it looks like they did. If your head
isn’t spinning yet, this should do the trick: CR codes do not live on the same claim with the normal payments and denials. They live on their own claim with their own Claim Control Number (ICN). Unfortunately, there are several different ways payers link these two claims together.
So, in our example above for Product B, it appears we have an additional payment for the exact amount we received initially. We also have the unique CR claim
containing the CR42 that does not reverse the original CO42 like it did in Product A’s example, but cancels out this “additional payment” for this transaction. We only know this because of one small field on the CR code claim: Previously Paid. These previously paid transactions no longer exist alongside the original denials and payments, but now live on a unique CR code claim. The two claims must be successfully linked in order for previously paid to be calculated properly.
So, if you’re having problems with double payments on your claims in your billing system, CR code situations could be the culprit. If you’ve ever wondered what the negative payments on the new EOBs are, CR codes are the answer. Always keep an eye out for discrepancies regarding changes in adjudication and previously paid transactions and follow the CR code logic to find the truth.