How Yuzu Flags a Duplicate
Before adjudication, Yuzu compares the claim against the member's other approved claims on the same service date. A match is graded in two levels:
Exact: Every service line on the new claim matches a line on a prior approved claim on procedure code, service dates, repricing status, billed amount, and modifiers
Possible: Some lines match, or the providers on the two claims overlap, but the match is not exact. Common case: two claims for the same date and provider where one line's billed amount differs
An exact claim-level match denies the claim. An exact line-level match denies only the duplicated line. A possible match holds the claim for review instead of denying outright, so a human can have the final decision. Denied duplicates carry remark code 18 on the adjudication.
Two things worth knowing about what the check compares:
First, it only looks at approved prior claims, so a claim denied earlier does not make a resubmission a duplicate
Second, providers are matched on NPI or billing TIN, so the same service billed under a different provider identifier can slip past the check
Original vs. Corrected vs. Void Claims
Every claim carries a claim frequency code (CLM05-3 on the 837) that says what kind of submission it is:
1 (original): a new claim
7 (replacement/corrected): replaces a previously submitted claim. This is how a provider fixes billed data, not by sending a second original. A corrected claim sent as a new original is the most common cause of a false duplicate flag
8 (void): cancels a previously submitted claim entirely
Each submission becomes a new iteration in the claim's history rather than overwriting the prior one. The claim page shows the merged picture across iterations and the history view shows each version as received. Within a single file, originals are processed before voids and adjustments so they apply in the right order.
When a provider calls about a claim "looking wrong," the first question is what they actually sent: if the fix was never transmitted on a frequency 7, we only ever received the original data.
Timely Filing
The timely filing limit comes from the plan's SPD. In Yuzu, the late-claim check works off a configured limit measured from the last date of service (the current system default is 180 days). A claim that arrives past the limit is denied for timely filing with the remark code TIMELY2.
The date that counts is when the claim was first received, visible as the earliest entry under Transmissions on the claim record. For claims with no transmissions, like manual uploads or portal-created claims, the claim's created date is used instead.
Two releases exist for the denial:
A group policy can carry a toggle that disables the timely filing denial. In this case, the warning still shows but the claim adjudicates normally
A claim with a COB flag releases the denial automatically, because a claim delayed by a primary payer should not penalize the member.
Proof of Timely Filing
When a provider disputes a late denial, the useful evidence is:
A clearinghouse or network acceptance report showing the claim was accepted before the filing deadline. What matters is when the receiving party accepted the claim, not when the provider initially submitted it
A prior payer's denial or remittance showing the claim was pending with another carrier during the window
A provider's internal billing records or screenshots showing a submission date are weaker proof, since they don't necessarily confirm when the claim was received by the appropriate payer or network.
For network-submitted claims, compare the network's acceptance date against the earliest Transmission date in Yuzu to identify where the delay occurred.