The short answer: pharmacy claims reject for a short list of recurring reasons: eligibility, formulary and coverage, quantity and days-supply limits, refill timing, prior authorization, and plain data-entry mismatches. The plan returns each as an NCPDP reject code. Most codes are fixable at the counter in a minute; a few are plan design, where nothing on your end is wrong and the fix is a conversation, not a keystroke. Knowing which is which is the whole skill.
A reject code is a diagnosis, not a verdict. In two or three characters, the processor tells you exactly what it objected to. The same handful of codes accounts for most of what any pharmacy sees in a week. This is a reference to the ones you will actually see: what each means, whether it's your error or the plan's design, and the usual fix. Every code and its official reject text below is verified against a published NCPDP reject-code list. The exact wording matters because a code read wrong sends the fix toward the wrong field.
How does pharmacy claim adjudication work?
Pharmacy claim adjudication is a real-time transaction. When you submit a claim, the pharmacy management system packages it in the NCPDP Telecommunication Standard (the messaging format the industry runs on) and sends it to a claims processor. The processor answers in seconds while the patient is still at the counter.
Three numbers on the insurance card decide where it goes. The BIN, a six-digit bank identification number (formally the IIN), routes the claim to the right processor. The PCN (processor control number) picks the right plan or line of business inside that processor. The Group narrows it to the employer or benefit group. Get those right and the claim reaches the plan that's supposed to price it; get one wrong and it lands somewhere that has never heard of the patient. For the broader context, see what prescription data entry actually involves.
The processor then runs the claim against the plan's rules (is this member eligible, is this drug covered, does the quantity fit the benefit, has enough of the last fill elapsed) and returns one of two answers. Paid, with the patient's copay and your reimbursement attached. Or rejected, with one or more reject codes explaining why. Those codes come from a standard list maintained by the National Council for Prescription Drug Programs (NCPDP). The full list is proprietary and gated behind membership, but state Medicaid programs publish their working subset, and the codes below are drawn from those published appendices.
One convention to know before the table: a code that starts with M/I means Missing or Invalid. The plan isn't saying the value is wrong in the world. It's saying the field is blank, malformed, or doesn't match what the plan expects in that position. That distinction points you straight at the fix.
Which pharmacy claim reject codes are most common?
These fifteen codes account for the overwhelming majority of rejects at a community pharmacy counter. Reject text is quoted verbatim from the published NCPDP list; the meaning and fix columns provide the practical reading.
| Code | Reject text | What it usually means | The usual fix |
|---|---|---|---|
| 07 | M/I Cardholder ID | The member ID is blank, mistyped, or doesn't match the plan's records. A transposed digit off the card is the classic cause. | Re-key the ID straight off the card, including any alpha prefix. Confirm you're on the current card, not a termed one. |
| 19 | M/I Days Supply | The days supply is missing or fails the plan's edit, often because it disagrees with the quantity and SIG. | Recompute days supply from quantity and directions and re-enter. Watch insulin, drops, and inhalers, where the math rarely divides evenly. |
| 21 | M/I Product/Service ID | The NDC field is blank or malformed, usually a formatting or padding problem rather than the wrong drug. | Confirm the 11-digit NDC and resubmit. Most systems pad the segments; verify the code matches the package on the shelf. |
| 22 | M/I Dispense As Written (DAW)/Product Selection code | The DAW code is missing or invalid for this claim, common when a brand is billed without the DAW the plan expects. | Enter the correct DAW for what actually happened: 0 for no selection, 1 for prescriber-required brand, 2 for patient-requested brand. |
| 25 | M/I Prescriber ID | The prescriber identifier is missing, malformed, or the wrong number, frequently a group NPI where the plan wants the individual's. | Bill the individual prescriber's active NPI. Validate it before resubmitting; a stale or group NPI is the usual culprit. |
| 41 | Submit Bill To Other Processor Or Primary Payer | The patient has other coverage that pays first. This isn't an error: the plan is telling you the order of billing. | Bill the primary payer, then submit this claim as secondary with the correct other-coverage code and the primary's payment. |
| 54 | Non-Matched Product/Service ID Number | The NDC is well-formed but the processor can't match it, a code the plan doesn't recognize or has never loaded. | Verify the NDC against the bottle and the plan's covered list. A repackaged or unlisted code often triggers this. |
| 65 | Patient Is Not Covered | Eligibility failed. Termed coverage or a member ID that no longer maps to an active plan. | Confirm current coverage: new card, new plan, or a lapse. Re-verify eligibility before refilling. |
| 69 | Filled After Coverage Terminated | The member was covered once, but the fill date falls after the plan ended. Job change and January turnover are the usual stories. | Get the patient's current plan and bill that. The old card will keep rejecting no matter how clean the entry. |
| 70 | Product/Service Not Covered | This NDC isn't on the formulary: sometimes the whole drug, sometimes only this manufacturer's version of it. | Check the formulary for a covered alternative or a different NDC. If the drug is required, the path is prior authorization. |
| 75 | Prior Authorization Required | The plan wants the prescriber to justify the drug before it pays. Not fixable at the counter alone. | Start the PA: notify the prescriber, send the plan's form, and set the patient's expectation in days, not minutes. |
| 76 | Plan Limitations Exceeded | A quantity limit, days-supply cap, or the 90-day-at-retail problem. The plan covers less than the prescription asks. | Re-enter to what the plan covers (often 30 days) and adjust the refill count so total authorized quantity still matches the script. |
| 77 | Discontinued Product/Service ID Number | A valid NDC that the labeler has since retired. Common after a wholesaler switches you to a different generic maker. | Bill the NDC of the stock actually on the shelf, not the prior bottle's obsolete code. |
| 79 | Refill Too Soon | Not enough of the last fill's days supply has elapsed by the plan's threshold. Frequently traces to a wrong days supply on the previous fill. | Check the last fill's days supply and date. If the entry was right, the fix is a vacation override or waiting out the clock, not a re-key. |
| 88 | DUR Reject Error | A drug utilization review edit fired: interaction, duplicate therapy, dose out of range, or early-refill overuse. | Read the DUR response codes, resolve clinically, and resubmit with the appropriate intervention and outcome codes if warranted. |
Two codes worth naming outside the table because they overlap the ones above. MR (Product Not on Formulary) appears on some plans as the specific formulary reject where 70 is the general one, same conversation either way. And a refill-too-soon condition can surface as either 79 or a DUR edit under 88, depending on the plan; the published Medi-Cal list explicitly cross-references the two, so don't be surprised to see the same situation wearing a different code at two different plans.
Which pharmacy claim rejects are caused by data-entry errors?
Roughly half of the codes in the table trace back to how the prescription was entered. Many are preventable by getting the underlying order and claim data right the first time, not by working faster. The codes map to the work this way:
- 07 (Cardholder ID), 41 (other processor), 65/69 (not covered / terminated) are the insurance field. A new card is a data-entry event, not a filing one: a transposed member ID or a stale card in the profile is the difference between paid and rejected.
- 19 (Days Supply) and 76 (Plan Limitations Exceeded) are the quantity-and-days-supply pair. When days supply disagrees with the quantity and SIG, or a 90-day script is billed against a benefit that covers 30, the plan does the arithmetic and objects.
- 21/54 (Product/Service ID) and 22 (DAW) are the drug field. A malformed NDC, a code for the wrong package, or a DAW that doesn't match who chose the brand all reject here.
- 25 (Prescriber ID) is the prescriber field: a group NPI where the individual's belongs, or an identifier that won't validate.
The instructive one is 79, refill too soon. It looks like a timing problem today, but its most common root cause is a wrong days supply entered on the last fill: a 30 keyed where the insulin math said 37 starts the plan's refill clock early, and the reject lands weeks later on a claim that was entered perfectly. That's the pattern with entry errors generally: the claim that rejects often isn't the one that was entered wrong. Each of these fields, and the failure mode attached to it, is walked through in what prescription data entry actually is. For reject handling, the point is simpler: when one of these codes comes back, the fix is not always resubmission. Sometimes it is correcting the field that was wrong to begin with.
Which pharmacy claim rejects come from plan design rather than pharmacy error?
Codes 70, 75, 76, and some instances of 79 can reflect the plan's coverage rules rather than a pharmacy error. The claim may be clean and the answer may still be no, or not yet. These rejects usually need a conversation with the patient or prescriber, not another trip through data entry.
75, prior authorization required. The plan will cover the drug, but only after the prescriber documents why. There is no counter-side fix. The productive move is to start the PA immediately: notify the prescriber's office, send the plan's criteria, and tell the patient honestly that this is measured in days. Offer a short bridge supply where the drug and the law allow it, and flag the claim so it isn't silently waiting on a fax that never comes back.
76, plan limitations exceeded. Often not an error at all: the prescriber wrote 90 days, the plan covers 30 at retail. The fix is mechanical (re-enter to the covered quantity, fix the refills so the authorized total still matches), but the patient conversation matters: they may want the 90-day supply through the plan's mail-order or 90-day network instead, which is a benefit-design choice, not something you can force through at the window.
70 (and MR), product not covered / not on formulary. The drug, or this manufacturer's version of it, isn't on the plan's list. This is a prescriber conversation: is there a formulary alternative that's therapeutically fine, or does the clinical situation justify a prior authorization for the non-preferred drug? Either way, the patient shouldn't leave without knowing which path you're on and roughly how long it takes.
79, refill too soon (when the entry was right). If last fill's days supply was correct and the patient genuinely can't wait (travel, a lost supply, a dose change), the remedy is a plan-authorized override (often called a vacation override), not a resubmission of the same claim. Some plans self-serve it; others require a call. What you don't do is keep resubmitting an unchanged claim and expect a different answer.
The line between the two halves of this reference is the line between speed and judgment. The data-entry rejects reward a fast, accurate operation that gets the order and claim data right and rarely sees them at all. The plan-design rejects reward knowing the benefit and managing the patient's expectations. A good pharmacy handles both without confusing one for the other. Resubmitting a prior-auth reject wastes the day, while treating a genuine typo as "just the plan" leaves money and goodwill on the counter.
Correct entry is where most of the first group never happens: complete the routine order and claim data, verify the result, and run the claim before the patient is standing there. That's what PillPilot's agents do inside your pharmacy system today. See how it works. Remediating the rejects that still come back (triaging the code, routing the prior auth, working the denial) is where we're headed next, on claims and denials.
Sources
- NCPDP reject codes: Medi-Cal Rx Appendix D (published subset of the NCPDP standard, April 2026)
- NCPDP reject codes for the Telecommunication Standard: Missouri MO HealthNet published list
- DAW/Product Selection Code definitions: eMedNY (NCPDP field 408-D8)
- What prescription data entry actually involves (PillPilot)