OHIP Rejection Codes Explained

There are roughly 188 OHIP error codes and another 225 Remittance Advice explanatory codes. Nobody memorizes them. What's worth learning is the structure — because the structure tells you, from the code alone, whether the problem is your data entry, the patient's eligibility, or a Schedule of Benefits rule you didn't know existed.

This is a working reference. Every code and description below is verbatim from the ministry's published error code and explanatory code lists.

First: where codes actually come from

Codes reach you through four different files, and confusing them is the most common source of "I fixed it and it rejected again."

| Report | What it is | What it means | |---|---|---| | Claims Batch Edit Report | Acknowledges receipt of each batch | The whole batch was accepted or rejected. No batch edit report at all means the ministry never received your file — or month-end processing is running | | Claims Error Report | Lists individual rejected claims with error codes | These claims are deleted from the ministry's system. They must be corrected and resubmitted to be considered for payment | | Remittance Advice (RA) | What was paid, reduced, or adjusted | Explanatory codes here mostly explain payment, not rejection | | Reject Message | File-level failure | The submission itself didn't parse |

The critical distinction: a claim on the Error Report was never adjudicated. It doesn't exist at the ministry anymore. A claim on the RA with an explanatory code was adjudicated — it was paid, reduced, or refused on the merits. Those need entirely different responses.

The prefix system

Rejection error codes are grouped by cause, and the first letter tells you which:

| Prefix | Category | Where the problem is | |---|---|---| | V | Missing or invalid data per the field specification | Your data entry or your software's file format | | E | Ineligible patient or health care provider data | Eligibility — the patient's card or a provider registration | | A | Missing or invalid data per the Schedule of Benefits | A billing rule — limits, combinations, restrictions |

So a V code you fix at your desk. An E code usually means going back to the patient or checking a registration. An A code means the Schedule of Benefits says you can't bill what you billed, the way you billed it.

Claim statuses — and what "pended" means

Four outcomes are possible once a claim reaches the ministry:

• Paid — adjudicated and paid, usually with explanatory code 33 (Approved) or 50 (Paid in accordance with the Schedule of Benefits).
• Rejected — failed validation. Appears on the Claims Error Report, deleted from the ministry's system, must be corrected and resubmitted.
• Reduced or adjusted — paid at a different amount than submitted. Appears on the RA with an explanatory code telling you why (51 — Fee Schedule Code changed in accordance with Schedule of Benefits, 49 — Paid according to the average fee for this service, and so on).
• Under review — the claim is neither paid nor rejected. It's held.

"Pended" is billing-industry shorthand for that fourth state. It isn't an official OHIP status code, which is why searching for it turns up nothing definitive. The states it maps to are visible on the RA:

| Code | Description | |---|---| | 54 | Interim payment — claim under review | | 56 | Claim under review | | 27 | This duplicate submission is being returned; original submission currently on file pending medical consultant adjudication | | 22 | Code submitted requires prior approval | | 41 | Fee Schedule Code billed — no evidence in supporting documentation provided |

Claims land in review when they're flagged for manual review (either by you, using the manual review indicator, or by the ministry), when documentation was requested, or when a medical consultant needs to adjudicate them. Code 27 is the one that trips people: a claim under review looks unpaid, so the office resubmits it, and the resubmission bounces as a duplicate of a claim that was never actually rejected. If a claim is under review, wait.

Most billing software also uses "pended" internally for the window between submission and the first RA — that's a software label, not an OHIP state.

---

The individual codes

A3H — Maximum Number Services per the Fee Schedule Master (FSM)

What it means: you exceeded the number of times this fee schedule code may be billed for this patient in the applicable period. The Fee Schedule Master is the ministry's table of per-code limits.

What actually caused it: almost always a code with a per-patient, per-physician time limit that someone billed twice. The canonical example is A003 — General assessment ($95.60), which is limited to one per patient per physician per 12 month period. It may be increased to two only if the second assessment is for a clearly different and unrelated diagnosis, or if it's a hospital admission assessment at least 90 days later.

The trap is that the clock runs on the patient's history with you, not on the calendar year — and if a colleague at the same practice already billed it, you may have no visibility into that at all.

How to fix it: check the patient's billing history with your practice for the code in question. If a lesser assessment was genuinely rendered, resubmit with the appropriate lower-level code — A007 or A001 depending on what was actually done. If the second service legitimately meets the exception (unrelated diagnosis, or 90-day admission assessment), resubmit with the manual review indicator and documentation.

Related codes: A3I is the same rejection for X-ray codes. AM1 — Service Limit Exceeded and AC1 — Maximum reached, resubmit alternate Fee Schedule Code are close relatives; AC1 is explicitly telling you which direction to go.

B2 — not an error

This is the one most likely to send you down a rabbit hole. B2 is a Remittance Advice explanatory code, and it reads:

B2 — Paid in accordance with the OHIP Schedule of Benefits for Telephone Virtual Care Services

B2 means you were paid. It's the ministry noting that the service was assessed against the telephone virtual care rates rather than the in-person rates. If you're seeing B2 on your RA and treating it as a rejection, stop — check the paid amount instead. If the amount is lower than you expected, the fix isn't resubmission, it's billing the right modality code next time.

The whole B-series covers virtual care, and only some of it is bad news:

| Code | Description | Paid? | |---|---|---| | B1 | Service not eligible for payment when delivered by telephone | No | | B2 | Paid in accordance with the OHIP Schedule of Benefits for Telephone Virtual Care Services | Yes | | B3 | Patient-physician relationship requirements not met | No | | B4 | Virtual service not allowed in addition to in-person equivalent service | No | | B5 | In-person service not allowed in addition to virtual equivalent service | No | | B6 | Limited virtual care service already paid | No | | B7 | Comprehensive virtual care service already paid | No | | B8 | Service not eligible for payment virtually | No |

B8 — Service Not Eligible for Payment Virtually

What it means: the fee schedule code you billed cannot be delivered virtually at all. Not "not by telephone" (that's B1) — not virtually, in any modality.

What actually caused it: billing a code that requires physical presence as a virtual service. Procedures, physical examinations, and anything with a hands-on component are the usual candidates. It also fires when a code's virtual eligibility changed in a Schedule of Benefits update and the billing template didn't.

How to fix it: confirm the code's virtual eligibility in the current Schedule of Benefits. If the encounter genuinely was virtual, find the code that covers virtual delivery of that service. If it was in person and got flagged virtual by a template default, correct the modality and resubmit.

Distinguish B8 from B1. B1 means the service is eligible virtually but not by telephone — it needed video. B8 means no virtual delivery is payable at all. Two related codes make the same point from the validation side: AT2 — Must Include Video Modality and AT4 — Modality Not Allowed.

And distinguish both from B4/B5. Those aren't about eligibility, they're about duplication — you billed a virtual service and an in-person equivalent for the same patient, and only one is payable.

V21 — Diagnostic Code Required

What it means: the fee schedule code you billed requires an OHIP diagnostic code and the field was empty.

What actually caused it: the requirement is broad. Essentially all A-prefix and B-prefix codes with the A suffix require a diagnostic code, along with all D-prefix and F-prefix codes and large ranges of C, E, G, and H codes. The exceptions are a short, specific list. If you're guessing about whether a code needs one, the answer is usually yes.

How to fix it: add the diagnostic code and resubmit. Note that OHIP uses its own diagnostic code set, distinct from the international classification systems used for hospital coding. Substituting a code from another system produces V22, not V21.

The V21 family:

| Code | Reason for rejection | |---|---| | V16 | Unacceptable Diagnostic Code — not numeric | | V21 | Diagnostic Code Required | | V22 | Invalid Diagnostic Code | | V30 | FSC/Diagnostic Code Combination Not A Benefit (NAB) | | V20 | Unacceptable Age for Diagnostic Code |

V30 is the subtle one. The fee code is valid, the diagnostic code is valid, and the pairing is not a benefit. There's nothing wrong with either field in isolation, which is why V30 rejections tend to recur — the office corrects one field, resubmits, and hits it again.

V20 is worth reading closely because the ministry spells out exactly what triggers it: service code is A007 with a patient over 2 years old and diagnostic code 916, or service code A003 with a patient under 16 and diagnostic code 917. Age-inappropriate pairings, specifically.

The RA equivalent is DX — Diagnostic code not eligible with Fee Schedule Code, and 82 — Diagnosis required on the error explanatory list.

EH2 — Mismatched Version Code

What it means: the health card version code you submitted doesn't match the ministry's record for that health number.

What actually caused it: the patient's card was reissued — renewed, replaced after loss or damage, or updated after a name change — and your chart still holds the previous version code. The health number never changed, so nothing else looked wrong.

How to fix it: get the current version code off the physical card, or validate against the ministry's Health Card Validation service before resubmitting. Do not guess: the ministry allows only 5 validation attempts per card per day, and there's no checksum on a version code to tell you locally whether you have it right.

Related codes: VH4 — Invalid Version Code (format failure, not a mismatch), VH1 — Health Number is missing/invalid, VH8 — Date of birth does not match the Health Number submitted, VH9 — Health Number is not registered with ministry. On the RA: E2 — Incorrect version code for service date, E3 — Version Code not on File, EV — Check health card for current version code, and EF, which warns that services on or after the 20th of the month won't be paid unless the current version code is provided.

Full detail on this one in The Ontario Health Card Version Code.

The EH-series — eligibility dates

| Code | Reason for rejection | |---|---| | EH1 | Service Date before Eligibility Effective Date | | EH2 | Mismatched Version Code | | EH4 | Service Date after Eligibility End Date | | EH5 | Service Date Not in Eligibility Period | | EH6 | Eligibility Terminated — Deceased | | EH9 | Health Number (HN) Not Activated |

These are not data entry problems. The patient's OHIP coverage genuinely did not cover the date you billed. EH9 in particular shows up with newborns — a pre-assigned health number that hasn't been activated yet. The RA equivalent is code 25 — Incomplete newborn registration, have parent/guardian contact MOH.

ARF / ARP / AC4 — referring physician problems

| Code | Reason for rejection | |---|---| | ARF | Missing Physician Referring Number | | ARP | Referring Physician Number Required | | AC4 | Unaccepted Referral Number | | V09 | Invalid Referral Number | | EQ6 | Incorrect Referral Number — referring provider not registered with the Ministry of Health | | ERF | Referring physician number is currently ineligible for referrals |

Roughly 277 fee schedule codes require a referring provider number — consultations across nearly every specialty, plus requisition-driven diagnostics.

AC4 is the informative one. The ministry lists exactly what triggers it: the number isn't 6 numerics; the number equals your own billing number (you can't refer to yourself); the referring number is in the nurse practitioner range (722900–744292) and the fee code isn't eligible for NP referral; or it's in the midwife range (700000–722899) and the code isn't eligible for midwife referral.

EQ6 is the one that costs the most time, because the number passed format validation and rejected weeks later on the merits. The usual cause is a CPSO registration number entered in the referring field — it looks like a plausible 6-digit number and isn't one.

More on the distinction in How to Find an Ontario Physician Billing Number.

AD3 / AD8 / AD9 / ADH — combination rules

| Code | Reason for rejection | |---|---| | AD3 | Not allowed with visit | | AD5 | Procedure allowed previously | | AD8 | Not allowed alone | | AD9 | Premium not allowed alone | | ADF | Corresponding Procedure Invalid, Omitted or Paid at zero | | ADH | Cannot be billed together | | ASP | Not Allowed with Surgical Procedure |

This cluster is about what can accompany what. AD8 and AD9 are the mirror image of the others: the code you billed requires a companion service and you billed it by itself. Premiums are the frequent offender — a premium code submitted without the base service it modifies rejects as AD9, and ADF fires when the companion procedure was submitted but was itself invalid or paid at zero.

ADH and AD3 are the opposite problem: two codes that are individually fine and mutually exclusive.

The RA equivalents show up as D3 — Not allowed in addition to visit fee, D7 — Not allowed in addition to other procedure, and DS — Not allowed, mutually exclusive code billed.

A34 / A36 / AO3 — duplicates

| Code | Reason for rejection | |---|---| | A34 | Multiple duplicate claims | | A36 | Claimed by Other Practitioner | | AO3 | Most Responsible Physician (MRP) Visit Already Paid | | A3L | Other New Patient Fee Already Paid |

A34 is your own duplicate — the same claim submitted twice. A36 and AO3 are somebody else's: another physician already billed the service for that patient on that date. Group practices and shared inpatient coverage generate these constantly, and they're not resolvable by resubmission. Somebody has to determine who actually rendered the service.

The RA versions are 32, 35, 36, 58 — Claimed by another physician within group, and 70 — Corresponding procedure(s) on this day claimed previously by another physician.

V70 — Date of service is greater than the file/batch creation date

What it means: you submitted a batch dated before one of the service dates it contains. From the ministry's perspective you billed for a service that hadn't happened yet.

What actually caused it: almost always a timezone or clock issue in the submitting software, or a batch file that was generated on one day and uploaded on another with dates edited in between.

How to fix it: regenerate the batch with a creation date on or after the latest service date in it. This is a software bug, not a billing error — if it happens more than once, the problem is your file generation, not your data entry.

VJ7 / VJ8 — Stale-dated Claim

What it means: the claim was submitted too long after the service date.

The ministry surfaces this progressively. W3 — Warning: Service date is older than 3 months is a warning, not a rejection. J7 — Claim submitted three months after service date appears on the RA. VJ7 is the hard rejection once the claim is genuinely stale. J3 — Approved for stale dated processing is what you see when a late claim is accepted anyway.

How to fix it: you generally can't, after the fact. Submit within the six-month window from the date of service. If W3 or J7 is appearing on your RA regularly, your submission cadence is the problem — claims are sitting somewhere for months before they go out.

V40 / V41 / V42 / V47 — format failures

These are the codes that indicate a software or data-format problem rather than a billing decision:

| Code | Reason for rejection | |---|---| | V40 | Invalid Fee Schedule Code — missing, or not in the format ANNNA (alpha, 001–999, alpha A–C) | | V41 | Invalid Fee Billed — not 6 numerics, or outside the range 000000–500000 | | V42 | Invalid Number of Services — not 2 numerics, or outside 01–99 | | V47 | Fee not Divisible — fee submitted is not evenly divisible to the cent by the number of services | | V39 | Number of items exceeds the maximum (99) | | V23 | Check Number Of Services |

V40 is worth reading carefully because it documents the OHIP code format exactly: one alphabetic character, three numerics from 001 to 999, and a final alphabetic suffix restricted to A, B, or C. That suffix is the role — A for the provider, B for the surgical assistant, C for the anaesthetist. A four-character code submitted without its suffix rejects as V40.

V47 is the sneaky one. If you bill 3 services and submit a total fee that doesn't divide evenly into three whole cents, the claim rejects — even though the total is correct.

A3E / A3F — the code doesn't exist on that date

| Code | Reason for rejection | |---|---| | A3E | No such service code for date of service | | A3F | No fee exists for this service code on this date of service | | A3G | Fee Billed Low |

A3E means the code was delisted, or wasn't yet effective, on the date you billed. A3F means the code exists but had no fee on that date. Both spike after every Schedule of Benefits update, when codes retire and new ones take effect. A3G — Fee Billed Low is the ministry telling you that you asked for less than the code is worth; the RA equivalent, 14 — Fee billed low, check for current SOB fee, is even more explicit.

A3G costs you money silently if nobody reads the RA. It's the clearest signal that a fee table hasn't been updated.

A2A / A2B / A4D — restriction mismatches

| Code | Reason for rejection | |---|---| | A2A | Outside of Age Limit — patient is underage or overage for this service code | | A2B | Wrong Sex for Service — this service is not normally performed for this sex | | A4D | Invalid specialty for this service code | | A1A | Outside Service Period |

A4D deserves attention because it's not fixable by editing the claim. Your billing number is tied to a registered specialty, and specialty-restricted codes check against it. If A4D is firing on codes you're certain you're entitled to bill, the problem is your provider registration, not the claim. The RA equivalent is 45 — Specialty code restriction on Fee Schedule Code, and EQ2 — Specialty mismatch covers the case where the specialty code is inactive or unregistered on the date of service.

AMR / MR / MM — you didn't meet the requirements

| Code | Reason for rejection | |---|---| | AMR | Minimum service requirements have not been met | | MR (RA) | Minimum service requirements have not been met | | MM (RA) | Claim does not meet requirements of the Physician Schedule of Benefits |

These are Schedule of Benefits content rejections — the code has stated requirements (a minimum time, a set of required elements, a specific documentation standard) and the claim doesn't demonstrate them. They usually mean the wrong level of service was billed rather than that the service wasn't rendered. The right response is generally to resubmit at the level the encounter actually supports.

---

Batch-level rejections

If your whole file bounces, it's not any of the above. Batches reject to the Batch Edit Report for structural reasons — missing batch header, trailer record missing, invalid record identifier, provider number missing, creation date greater than the system date, group/provider not approved for MCEDT, unsupported technical specification release identifier.

These are software and registration problems, not billing problems. One useful piece of ministry guidance: keep batches to no more than about 500 claims. A structural error anywhere in a large batch rejects the entire submission, so smaller batches limit the blast radius.

Working through your rejections

Triage by prefix first. Sort your Error Report by first letter. All the V codes are fixable at your desk in one pass. All the E codes need patient or registration information. All the A codes need a Schedule of Benefits decision. Batching by category is dramatically faster than working down the list chronologically.

Read the RA explanatory codes separately. They're a different category of information. 33 and 50 mean you were paid. 51 and 49 mean you were paid a different amount and here's why. B2 means you were paid at the virtual care rate. Treating any of these as rejections wastes time and generates duplicate submissions that reject as A34.

Don't resubmit anything under review. Codes 54, 56, and 22 mean the ministry is still working on it. Resubmitting produces code 27 and gets you nowhere.

Fix the systemic ones at the source. V70, V41, V47, and V40 are file-generation problems. If they appear at all, they'll keep appearing until the software is fixed. A3E and A3F mean your fee table is out of date. A4D means your provider registration needs attention. None of these are worth fixing claim by claim.

Watch the clock. Rejected claims can be corrected and resubmitted, but the window closes. W3 and J7 are your warning that you're getting close; VJ7 is the door shutting.

---

SnapBill checks every claim against the Schedule of Benefits before it's submitted — diagnostic code requirements, service limits, code combinations, referring provider numbers, and health card status — and decodes every error and explanatory code on your Remittance Advice in plain language. Sign up free — no credit card. Related reading: Understanding Your OHIP Remittance Advice and 5 Ways to Reduce OHIP Claim Rejections.