Key takeaways
- Nearly all demographic denials share one parent code, CARC 16, paired with a different remark code depending on which CMS-1500 field was wrong.
- The seven most common remark codes, N382, N329, MA60, N340, N48, N30, and MA75, all trace back to a front-desk or registration gap, not a coding error.
- Member ID, plan, and policy data carried forward from a patient’s last visit instead of reverified at check-in drives a large share of these denials.
- Real-time eligibility verification at check-in, rather than batch verification run 48 to 72 hours out, prevents most of these codes from ever reaching a claim.
- Tracking denials by remark code, payer, location, and registration staff member turns a recurring pattern into a fixable process gap, often within 60 to 90 days of data.
The 7 most common demographic denial codes and what they tell you about your intake process
Your coder did everything right. The procedure was covered, the patient was eligible, and the claim still came back as a demographic denial because someone typed the wrong date of birth at the front desk. That is the piece most denial management conversations skip entirely.
Demographic denials are not clinical errors and they are not coding errors. They are front-desk errors that look small on a single claim, so billing teams correct and resubmit without asking why the same claim denials keep coming back. Month after month, the same fields trigger the same correction cycle and burn staff time that should go toward real revenue cycle work.
The problem is not bad data. It is the intake process that keeps letting bad data in, and almost every demographic denial traces back to one root code, CARC 16, paired with a different remark code depending on which field was wrong. Here are the seven remark codes billing managers see most often, the CMS-1500 field behind each one, and the intake fix that stops them from cycling back.
Table of contents
- Why demographic denials deserve their own tracking
- CO-16 with N382: missing or invalid patient identifier
- CO-16 with N329: missing or invalid patient birth date
- CO-16 with MA60: missing or invalid patient relationship to insured
- CO-16 with N340: missing or invalid subscriber birth date
- CO-16 with N48: claim information inconsistent with another carrier
- CO-16 with N30: missing or invalid insured information
- CO-16 with MA75: missing or invalid patient or authorized representative signature
- What all seven codes have in common
- Where to start if your denial rate is climbing
- Where the right intake technology fits
- Conclusion
- Frequently asked questions
Why demographic denials deserve their own tracking
Most denial workflows lump codes into four buckets: clinical, authorization, eligibility, demographic. The demographic bucket usually gets the least attention. Individual claim values seem low, the fix looks obvious, and the default response is to correct it and move on.
That logic is exactly why the same remark codes keep showing up. Demographic denials are not random one-off errors. They are patterns tied to specific fields on the CMS-1500: the member ID box, the birth date box, the relationship box. Each one tells you where your intake process has a gap, whether that is in how data gets captured at registration, how it gets verified before submission, or how staff handle insurance cards and patient IDs.
All Claim Adjustment Reason Codes (CARCs) and Remittance Advice Remark Codes (RARCs) are maintained by ASC X12, the standards body that governs HIPAA-adopted electronic transaction standards. Tracking demographic denials by remark code, payer, location, and staff member is what turns a recurring pattern into a process you can actually fix.
CO-16 with N382: missing or invalid patient identifier
N382 means the patient identifier on the claim doesn't match what the payer has on file, or the field was left blank. Most often this isn't a data entry mistake at all. It's a card. Patients hand over whatever insurance card is in their wallet, and if their employer switched carriers or they got a new ID number after a plan renewal, the number on that card may already be retired. Staff key in exactly what they're handed. The payer can't match it, and the claim lacks the information it needs to adjudicate.
Where it breaks down at intake: ID verification happens once, at a patient's first registration, and then never again. A returning patient's card from eighteen months ago becomes the assumed source of truth. Build a step that re-scans or re-keys the member ID at every visit, not just new patient visits, and flag any patient who hasn't been seen in 90 days for a fresh card check.
CO-16 with N329: missing or invalid patient birth date
N329 is the plainest of the seven: the date of birth field is missing or doesn't match. It's also the easiest to dismiss as a one-off typo, until it shows up on the same patient's claim a second time, or a third. A transposed month and day, a year off by one, a field skipped during a rushed check-in: all of it lands the same way.
Where it breaks down at intake: DOB is one of the only fields patients can correct themselves on a kiosk or portal form, yet many practices still have staff hand-key it from a driver's license or insurance card under time pressure. Move DOB capture to a step the patient verifies directly, even when a staff member is also keying the visit, and require a side-by-side check against the insurance card before the claim is created.
CO-16 with MA60: missing or invalid patient relationship to insured
MA60 flags a missing or invalid answer to one question: is the patient the subscriber, or someone covered under another person's plan? It shows up constantly in pediatric visits, on spousal plans, and with young adults still covered under a parent's policy under the ACA's dependent coverage rule. The patient in the chair isn't always the person the payer has on file as the policyholder, and if registration never asks the question directly, the claim goes out with a relationship field that's blank, defaulted to "self," or simply wrong.
Where it breaks down at intake: Staff ask who the patient is. They don't always ask, separately, whose insurance it is. Make relationship-to-insured a required field with no default value, and train staff to ask it as its own question rather than assuming the answer from context.
CO-16 with N340: missing or invalid subscriber birth date
N340 looks almost identical to N329 on a remit, but it flags a different field entirely: the subscriber's birth date, not the patient's. When the patient and the subscriber are the same person, this rarely trips. When they're not, the patient's correct DOB gets entered everywhere, and the policyholder's birth date, the one the payer actually needs to verify the plan, never gets collected at all.
Where it breaks down at intake: Intake forms with a single "date of birth" field implicitly assume patient and subscriber are the same person. Once relationship-to-insured is captured correctly, a second DOB field for the subscriber needs to follow it every time, not just when staff happen to remember the patient is a dependent.
CO-16 with N48: claim information inconsistent with another carrier
N48 means the claim's accident or coordination-of-benefits answers contradict what another carrier already reported to the payer. The patient has two active plans, or a recent accident claim, and the answer on file doesn't match what the other carrier has on record. Coordination of benefits rules determine which plan pays first, and that determination doesn't default to whatever the patient reported at their last visit. This one rarely traces to a single bad keystroke. It traces to a question that only gets asked once, usually at the first visit, and never gets revisited as circumstances change.
Where it breaks down at intake: COB and accident-indicator questions get treated as a new-patient form field instead of a standing part of every check-in. Add a COB confirmation step to every visit, not only intake, and don't let the patient's self-report stand in for a real-time eligibility check against payer records when the plan involved is one your practice has seen flagged before.
CO-16 with N30: missing or invalid insured information
N30 is the broadest of the seven and the one most likely to repeat across an entire patient panel at once, because it covers the plan name, the policy or group number, and the secondary plan information all under one code. The most common trigger: the plan in your system is the plan the patient had at the last visit, not the one they have now. Employer plan changes happen mid-year, group numbers get reissued at renewal, and none of it reaches the front desk unless someone asks.
Where it breaks down at intake: Plan information gets pulled forward from the last encounter and treated as confirmed rather than re-verified. Build a required plan confirmation step before every visit, not only for new patients, and treat a group number or plan name that hasn't been checked in over a year as unverified by default.
CO-16 with MA75: missing or invalid patient or authorized representative signature
MA75 means the claim went out without a valid signature on file, either the patient's general consent or the assignment of benefits that lets the payer send payment to the practice. It's easy to miss because the signature usually exists, somewhere, on a paper form from a visit two years ago or buried in a portal the patient never opened. What the payer needs is a signature on file that's current and tied to the claim being submitted, not one that technically exists in an old chart.
Where it breaks down at intake: Signature capture happens once at first registration and is assumed to carry forward indefinitely. Confirm signature status at check-in the same way you confirm insurance, and flag any patient whose authorization is missing, expired, or was never captured electronically in the first place.
Where to start if your denial rate is climbing
Pull the last 90 days of denials and filter for CARC 16. Sort by remark code, then break the results down by payer, service location, and the staff member who handled registration. The pattern surfaces quickly.
If N382 and N30 dominate, the issue is in how your team verifies member IDs and plan information at the front desk. If MA60 and N340 cluster together, dependent and subscriber intake is the gap. If one payer generates most of your N48 denials, the issue is in how you capture or transmit COB data for that payer's specific requirements. Most practice management systems can filter denial reports by the user who performed registration. Cross-reference the denial date against the registration record and 60 to 90 days of data will show you exactly where to look.
The real cost extends beyond the denied claim itself. The time required to identify, fix, and resubmit a claim adds administrative work for everyone it touches. Multiply that across 90 days of demographic denials cycling back month after month, and the number adds up fast. Each of these seven remark codes is a process gap generating that rework on a loop. Fix the intake step that lets the error in, and the loop stops.
When the pattern in your denial data points to a systemic gap rather than a single staff member needing retraining, the next step is automation, applied in layers rather than all at once. Scheduling AI is the first layer because it sits earliest in the patient's journey through your system, standardizing appointment details, patient demographics, and basic plan information at the moment a visit is booked, whether that happens online, by phone, or through a referral. When that data is accurate from the first touchpoint, registration staff aren't starting check-in by correcting or guessing at information that should already be on file, which cuts directly into the volume of stale or wrong fields behind N382 and N30.
If demographic denials are still climbing after scheduling data is cleaned up, add Insurance Verification AI. It runs a real-time eligibility check against the payer's system at check-in instead of relying on a batch verification pulled 48 to 72 hours in advance, which means it catches a same-day coverage termination, an inactive plan, or a coordination-of-benefits conflict before the encounter closes rather than after the claim has already gone out. This layer targets N48 directly and reinforces N30, since it confirms plan, policy, and coverage details against the payer's own records instead of whatever happens to be sitting in your system from the patient's last visit.
Denial Management AI comes last, and only once Scheduling AI and Insurance Verification AI are both in place and the same remark codes are still recurring. At that point the gap usually isn't prevention, it's whatever still slips past both upstream checks, and this tool's job is to catch, analyze, and correct those claims before they age past a payer's filing window. Using it as a first response instead of a last resort means treating the symptom while leaving the upstream gap open, which is exactly the cycle this article is trying to break.
Conclusion
Every code in this list traces back to one moment at registration. A member ID pulled from an outdated card. A relationship-to-insured field nobody asked about. A signature that exists somewhere but isn’t current.
The rework cycle costs more than the individual claim. There is the $25 to $118 per denial in direct correction cost. And there is the cost that never shows on a report: the billing staff hours spent fixing data fields instead of working a complex payer dispute or sitting with a patient who needs a payment plan conversation.
Demographic denials do not need better coders. They need the error caught before it leaves the front desk.
Real-time insurance verification at the point of check-in is where that happens. When eligibility, benefits, and identity are confirmed against the payer’s system before the encounter closes, N382 and N30 don’t reach your billing queue because the member ID and plan information are current. MA60 and N340 don’t show up because the subscriber question gets asked every time. N48 doesn’t return because COB gets reconfirmed at the visit, not just at enrollment. The data is right when the claim is created, which means it doesn’t need to be corrected after the denial.
Pull the last 90 days of remittance data. Sort by remark code. The one at the top of your list tells you exactly which intake step to close first.
A claim rejection occurs before a claim reaches the payer and is typically flagged by the clearinghouse because of missing or invalid information. A claim denial occurs after the payer receives and processes the claim. Demographic errors can cause both—a rejection when required fields such as the patient's birth date or member ID are missing, and a denial when the information is present but does not match the payer's records. Because the causes, timelines, and corrective actions differ, practices should track rejections and denials separately.
Eligibility should be verified at scheduling and again during patient check-in, particularly for patients who have not visited the practice within the last 30 days. High-volume practices can further reduce eligibility-related denials by running batch eligibility checks the night before scheduled appointments to identify terminated coverage or plan changes before patients arrive.
A Remittance Advice Remark Code (RARC) provides additional detail alongside a Claim Adjustment Reason Code (CARC) to identify the exact issue with a claim. For demographic denials, CARC 16 generally indicates that required information is missing, while the RARC pinpoints the specific problem. For example, N382 indicates a missing or mismatched patient identifier, N329 identifies an incorrect birth date, and MA60 indicates that the patient's relationship to the insured is missing. Reviewing the RARC before resubmitting helps prevent repeated denials.
Most demographic denials are corrected rather than appealed because they result from inaccurate or incomplete patient information rather than coverage decisions. The appropriate approach is to update the incorrect demographic information, such as the member ID, birth date, or relationship to the insured, and resubmit the claim within the payer's filing deadline. If the filing window has expired due to circumstances outside the provider's control, some payers may consider a timely filing exception when supporting documentation is provided.
Under 42 CFR § 424.44, Medicare claims generally must be submitted within one calendar year from the date of service, with limited exceptions for documented administrative errors or retroactive eligibility. Commercial payer filing limits commonly range from 90 to 180 days, although some plans allow up to 365 days. Medicaid filing deadlines vary by state, so providers should always verify payer-specific requirements to avoid missing timely filing limits.
An N48 denial related to Coordination of Benefits (COB) should be resolved by obtaining an updated COB statement from the patient and verifying any additional coverage with the appropriate insurance carrier. If another policy is confirmed as primary, the claim must first be submitted to that payer before being billed to the secondary insurer. Many practices also ask patients to confirm their COB status at every visit to reduce future billing disputes.
Most practice management systems allow denial reports to be filtered by the user who completed patient registration. If that feature is unavailable, practices can compare denial records with registration logs containing user IDs and timestamps. Reviewing 60 to 90 days of data across the most common demographic denial codes helps determine whether errors are concentrated with a particular staff member, office location, or payer workflow, allowing targeted training or process improvements.
