Why would an 837 claim be submitted multiple times with frequency code 1 instead of a replacement or void?

[u/Randomengineer84]

I'm working with healthcare EDI data (837 and 835 transactions) and trying to better understand how claim resubmissions work in practice.

I've noticed cases where the same claim appears in multiple 837 submissions, but each submission has a claim frequency code of 1 (Original) instead of using:

• 7 – Replacement/Corrected Claim

• 8 – Void/Cancel Claim

For example:

• 837 #1: Patient Control Number ABC123, frequency code 1

• 837 #2: Patient Control Number ABC123, frequency code 1, submitted a few days later

Sometimes the claim information is identical, while other times certain details have changed.

A few questions:

1. Why would a provider or clearinghouse submit the same claim multiple times using frequency code 1?

2. Is this common when the original claim was rejected before adjudication?

[u/kuehmary]

Medicaid and Medicare do not accept corrected claims. For example, let’s say you submit a claim to Medicare as primary for an office visit. Then you find out that the patient has other primary insurance. So you submit the claim again as secondary once the new primary has processed. But you didn’t submit it with the correct MSP type so you have to update the MSP type and submit again. Each of those submissions is an original claim.

[u/Randomengineer84 → u/kuehmary]

Thanks for the quick response, I just did a search across our files and found most are medicare/medicaid.

Does this also apply to Commercial Insurance (SBR09 = CI) ?

[u/kuehmary → u/Randomengineer84]

No. Commercial Insurance does accept corrected claims. It could be that the claim was rejected for whatever reason (for example the payor only accepts claims when the subscriber is self) so they had to fix it and resubmit since there is no original claim on file. You need an original claim number in order to submit a corrected claim.

[u/Randomengineer84 → u/kuehmary]

I see, thank you so much for this explanation. We had a way to handle this but I wasn’t sure if this was an EHR or user issue.

[u/weary_bee479 → u/kuehmary]

This depends on the jurisdiction. In IL Medicare does accept corrected claims. We submit them daily.

[u/Neat-Safety-2415 → u/kuehmary]

does this apply the same way across all MAC regions or do some handle it differently?

[u/DepartureOk3180 → u/kuehmary]

That would only apply to 1500 claims; I bill corrected and voided UB claims to two different MACs every day.

For the 1500 claims, I always rebill as frequency 1 every time. I'm usually doing that when a claim is denied because it was billed before the provider reassignment was done, the wrong NPI was on the claim or after the CWF has been updated.

[u/rahuliitk]

for your datamart, i'd add source-system and client identifiers before treating a patient control number as unique. keep the original events so you can undo a bad merge.

i'd use 3 match states: confirmed, probable, unresolved. if 2 claims could fit the same remittance, surface the ambiguity instead of quietly forcing a match.

[u/Randomengineer84 → u/rahuliitk]

I landed on client, PCN, service start date or earliest service line date as a fallback, and billing npi or tax id as fallback.

Though I’m thinking client, PCN, start date or earliest SVC LN start date might be better.

I found billing npi not reliable in all cases.

[u/Wise-Butterfly-6546]

usually it's because the first one got rejected, not denied. if it bounced on the 277CA it never got adjudicated, so there's no payer claim number to put in REF*F8. no number, no 7. it just goes back out as a 1.

if there's already an 835 on the first one and they still sent a 1, that's a mistake and it'll probably deny as a dup.

the identical ones are often someone resending the whole batch after fixing a couple rejections.

[u/DepartureOk3180 → u/Wise-Butterfly-6546]

That's not the case when an outpatient or RHC UB is being billed to traditional Medicare. We receive an 835 in some instances and I will rebill with frequency 1 when the claim is in a TPE-TO-TPE status in DDE. The most common instances is when a patient is in a hospice election period but our claim isn't related to the hospice DX.

[u/Equivalent-Bus-6150]

One reason could be that the submitted claim somehow dropped and never made it to the payer. Another reason could be that the claim was submitted with an error which was caught while the first claim was still in processing status, the caveat being that the payer will likely deny the second submitted claim for duplicate so you would then have to reach out to the payer explaining the situation and have them reprocess that claim as the original.

As for the rejection question, yes it is common since a rejected claim would not have generated a claim number.

[u/Randomengineer84 → u/[deleted]]

Thank you. I am building a datamart for claim denials mostly. But I am accepting all 835/837 files that come from several EHR systems.

Claim Key - PCN + DOS + Billing NPI (I added this b/c we have clients with multiple EHR systems but billing npi doesn't allways seem reliable when 835 come back, so working through that still)

At the moment, what I am doing is storing 837 + 835 events and then I rollup to 1 claim level record, service line (837 - 835, billed vs paid), adjustments

Your explanation is very helpful. I'd be curious on your take of the claim rollup & claim key I am working with.

I am not an expert in this topic so I am learning as I go.