What Does MA04 Mean
MA04 remark code means a secondary payer cannot process your claim because it never received usable identity or payment information from the primary payer. Its name, paid amount, or adjustment details show up missing, blank, or illegible on the claim itself. The MA04 remark code flags a data problem, not a coverage review the secondary payer has already completed. Nothing about this claim has been read and rejected on its merits. Until it sees what the primary payer decided, the secondary payer cannot calculate a payment of its own.
The Official MA04 Definition, Explained
What X12 Says
X12 classifies MA04 as a Remittance Advice Remark Code. It is not a Claim Adjustment Reason Code, though at least one denial-code reference online mislabels it that way and sends readers toward the wrong code family when they go looking for a fix. The X12 remark code registry lists both code types, and MA04 has appeared there since January 1, 1997. The code has never been revised since. Close to three decades of an unchanged definition means the registry’s MA04 remark code description is the only wording that matters here.
The Common Misconception About MSP Codes, and Why It Is Wrong
Several published sources describe MA04 as resulting from an invalid or missing Medicare Secondary Payer code. That description does not match the registry text. X12’s actual wording is about the primary payer’s identity or payment information being missing or illegible on the claim itself, not about a code failing a validation check. The difference changes what a biller fixes. A biller chasing a bad MSP code checks a value field. Someone working the real problem instead chases down the primary payer’s finalized payment details, since that is the document the secondary payer is waiting on. This mix-up comes from how often MA04 shows up in Medicare Secondary Payer scenarios, where MSP codes are a separate part of the claim. The two are not the same field, and mixing them up sends a biller down the wrong repair path.
Why You Are Seeing an MA04 Denial
Denial code MA04 traces back to one of a few gaps in what the secondary payer received. Check these first.
- The primary payer’s EOB never made it onto a paper claim.
- The coordination of benefits fields on the 837 electronic claim sat blank.
- The claim reached the secondary payer before the primary finished adjudicating it.
- The payer order in your system lists the wrong payer as primary.
- For Medicare, the MSP record on file does not match how the claim was billed.
- The primary paid amount got keyed into the wrong field during data entry.
Any one of these triggers the code by itself. Most billers find more than one problem once they pull the actual claim and compare it against the primary’s remittance.
Which CARC Pairs With MA04: CO-22 or CO-16
DME Claims Pair MA04 With CO-22
On durable medical equipment claims, MA04 rides alongside CARC 22. Noridian’s own DME jurisdictions list this pairing under Reason Code 22, described as care that may be covered by another payer per coordination of benefits. The remark code and the reason code work as a pair here. CARC 22 tells you the payer suspects another payer should have paid first. MA04 tells you what is missing before that suspicion gets resolved: the primary payer’s identity and payment details.
Part A and Part B Claims Pair MA04 With CO-16
On Part A and Part B claims, the same MA04 remark code instead pairs with CARC 16, a broader code covering claims that lack information or contain a submission error. Noridian’s own Part B jurisdiction pages label this combination Medicare is Secondary Payer. A biller who only checks the reason code number without confirming claim type can end up chasing the wrong fix. Someone working a DME claim looks for a coordination of benefits issue, while a Part B claim under CARC 16 calls for the more general missing-information fix instead. Same remark code, two different reason codes, depending on which claim type crossed the desk.
This split shows up in Noridian’s own published guidance. Its DME jurisdiction pages document the CO-22 denial code pairing. The Part B jurisdiction pages document the CO-16 pairing on a separate page, under a separate heading, for the same MA04 remark code. Neither page cross-references the other.
The table below lines up both pairings side by side.
| Claim Type | Paired CARC | What the Pair Means |
|---|---|---|
| DME | CO-22 | Another payer may be responsible per coordination of benefits |
| Part A and Part B | CO-16 | Claim lacks information or has a submission error, missing primary payer data |
No published source lines these two MA04 pairings up side by side the way this table does. Confirm claim type before you start chasing a fix, and the right pairing tells you which document to go find first. N130 works the same way: how N130 pairs with its own CARC follows this identical logic on a different code.
The mechanism behind both pairings sits inside CMS’s Coordination of Benefits and Recovery program, which governs how Medicare decides who pays first in the first place.
How to Fix an MA04 Denial on an Electronic Claim
Fixing an MA04 denial code on an electronic claim starts with the primary payer’s finalized 835 or ERA. Confirm it shows the paid amount, the allowed amount, the adjustment codes, and the adjudication date. Without all four, you do not have enough to move forward yet.
Institutional claims carry that primary payer information in Loop 2320. Professional claims carry the equivalent data in CMS-1500 items 11 through 11D instead. Carry the adjustment amounts from the primary’s remittance into the outgoing claim as the primary reported them. Do not round, do not estimate, and do not recalculate anything yourself.
Resubmit as a corrected secondary claim, not as a new original claim. A new original claim tells the payer’s system this is the first time it has seen this service, which creates a duplicate-claim problem layered on top of the one you already had. Marking it corrected instead tells the system to replace what it received before with accurate information.
Once the corrected claim goes out, the fix is done on your end. What happens next depends on the secondary payer’s processing timeline, which sits outside your control.
A zero-dollar primary payment still counts as usable information, and this trips up more billers than it should. If the primary denied the service outright and its 835 shows a paid amount of zero, that zero is the primary’s adjudication decision. Report it to the secondary payer the same way you would report a positive payment. A denial from the primary is not the same as silence from the primary, and the secondary payer needs to see the difference.
How to Fix an MA04 Denial on a Paper Claim
Attach a complete, legible copy of the primary payer’s EOB to the paper claim. It needs to show the payer’s name, the paid amount, the allowed amount, and the adjustment codes in a way the secondary payer’s staff can read without guessing at a smudged number.
A partial EOB or a faded photocopy causes the same denial again, with the added frustration of having done the work once already.
The timely filing clock for the secondary payer keeps running in most cases while you wait on the primary, so a clean EOB is not a reason to sit on the resubmission. Once the document is in hand, send the corrected claim the same day if you can.
If the primary payer is slow to send anything usable, call and ask for the remittance instead of waiting on the mail. A phone-requested copy often arrives faster than the standard mailing cycle.
MA04 Resubmission Checklist
Before you resubmit an MA04 remark code denial, confirm you have every item below. Missing even one sends the claim right back.
- Primary payer name and identifier
- Primary paid amount
- Primary allowed amount
- The specific adjustment group and reason codes from the primary’s remittance
- The adjudication date
- Confirmation that the payer order in your system is correct
- For Medicare-secondary claims, confirmation that the MSP record matches how the claim is billed
Run through this list against the actual document in front of you, not from memory. A biller who assumes the payer order is right without checking ends up back in the same denial queue a week later.
If this checklist feels familiar every month on the same handful of accounts, that pattern is worth a closer look rather than another one-off fix. A full denial audit of your AR can show whether the issue sits in one workflow step or spreads across several.
Is MA04 Appealable
No. Filing a formal appeal on an MA04 denial code is the wrong move. The secondary payer has not made a coverage decision on this claim. It cannot make one yet, because it does not have the primary payer’s information in front of it. A redetermination request challenges a decision that already happened, and no decision exists here to challenge.
The correct move is administrative: supply the missing primary payer data and resubmit as a corrected claim. That is the entire fix.
The timely filing window for the secondary payer keeps running in most cases while this gets sorted out, so speed still matters even without an appeal in play. Confirm the specific window with the payer in question rather than assuming a standard clock applies across the board.
MA04 vs MA83: Do Not Confuse These Two Codes
MA04 and MA83 both involve the primary and secondary payer relationship, and billers mix them up often. They describe two different failures.
MA83 fires when the claim never indicated whether the payer is primary or secondary, most often because Item 11 on the CMS-1500 form sat blank. That field carries the insured’s policy, group, or health plan number for the payer being billed, and a blank field there tells the payer nothing about who else might be covering this patient. MA04 fires further down the process: the claim already identifies itself as secondary, but the specific primary payer identity or payment information behind that claim is missing or unreadable.
The fix for each is different. An MA83 denial gets fixed with a data-entry correction: complete the payer-order field itself. Fixing MA04 means tracking down the primary’s payment detail, a separate document that has nothing to do with payer order.
Both trace back to incomplete coordination of benefits data at the point of submission. They fail at different stages of that same data.
How to Prevent MA04 Denials
Prevention starts at the front desk, not in the billing office, since MA04 is a data-collection failure that happens before the claim ever goes out.
Verify coverage and payer order at every visit, not only at intake. Coverage changes, and a payer order that was correct in January can be wrong by June.
Train front desk staff to record every active policy in the correct order, not the first policy a patient mentions. Most patients will not volunteer which coverage is primary unless someone asks.
Hold the secondary claim until the primary’s remittance has posted. Submitting on a guess is how illegible or mismatched data ends up on the claim in the first place.
Configure your billing software to pull the primary’s adjustment data straight from its 835 into the secondary claim’s coordination of benefits fields. Manual re-entry is where a lot of that data gets garbled or dropped.
Even with all of this in place, some cases slip through. Medicare Secondary Payer situations shift when a patient’s own coverage history changes without your practice knowing.
That kind of recurring gap is what hands-on revenue cycle management is built to catch, before it reaches a remittance at all. When claim-side problems like this show up across more than one code, the pattern sits at the revenue cycle level rather than in any single code. See everything One O Seven RCM handles for a fuller picture of where that kind of oversight fits.
The 2026 CMS Update on CARC and RARC Codes
The MA04 remark code definition has not changed since it was introduced on January 1, 1997, and the 2026 update does not touch that text.
What changed is broader. CMS instructed Medicare contractors to implement an updated CARC and RARC code set effective July 1, 2026, with an implementation date of July 6, 2026, under Transmittal 13666 and Change Request 14410.
CMS updates these code lists three times a year, in March, July, and November. Each update can add, retire, or modify codes elsewhere in the same list MA04 lives in, even when MA04 itself is untouched.
Do not assume a code you learned five years ago still carries the same meaning today without checking. Verify against the current list, starting with CMS Transmittal 13666 itself, rather than a memorized definition.
Related Remark Codes Worth Knowing
The N4 remark code means missing, incomplete, or invalid prior insurance carrier EOB, close enough to MA04’s own territory that a biller troubleshooting one may well be looking at the other on the same claim.
MA130 means the claim contains incomplete or invalid information and carries no appeal rights, since an unprocessable claim has nothing to appeal yet. That connects to the broader missing-information family MA04 sits inside on Part A and Part B claims through its CARC 16 pairing.
MA125, N418, and N657 also surface alongside MA04 in current search and AI-generated related-topic patterns, though that connection is closer to co-occurrence than a shared cause. They are worth knowing by name without assuming they share a fix with MA04.
The Code Trio pattern here, a group code, a reason code, and a remark code working together, shows up again on CO-11: the same Code Trio pattern on CO-11 follows the identical structure on a coding-specificity denial instead of a coordination-of-benefits one. Reading one denial apart from its code trio is how billers end up solving half a problem.
Frequently Asked Questions About MA04
What causes code MA04?
An MA04 remark code claim most often shows this because the primary payer’s payment or adjustment details never made it onto the secondary claim, either because the electronic coordination of benefits fields sat blank or because a paper EOB was missing or hard to read.
How do I mitigate code MA04?
Get the primary payer’s finalized remittance before you submit to the secondary payer, and confirm the payer order in your system is correct before you resubmit anything.
Does MA04 apply only to Medicare claims?
No. MA04 is a HIPAA-standard remark code, not something unique to Medicare. Any payer processing electronic remittances can apply it. Medicare Secondary Payer scenarios are where it shows up most in practice, which is why the two get associated so often.
How long does it take to resolve an MA04 denial?
The resubmission itself takes minutes once you have the right information in hand. Waiting on the primary payer to finish adjudicating and issue a usable remittance is almost always the real bottleneck, and that timeline belongs to the primary payer, not to you.
