What it means on your remittance
The claim was processed against Electronic Visit Verification requirements and the required EVV data was not there — the payer found no fulfilled EVV record backing the service. This is the general-purpose EVV remark payers use when the visit-data requirement itself failed.
Why it happens
- The visit was never captured in the EVV system — the caregiver didn't clock in or out, so no record exists to fulfill the requirement.
- The visit exists in your EVV system but never exported to the state aggregator before the claim processed (a timing race that state Medicaid programs call out as a leading cause).
- The visit reached the aggregator but is stuck in an exception status instead of Verified — the Ohio Auditor found only 28% of EVV entries statewide reached Verified status.
- The claim was billed before the visit finished processing. Missouri's instruction is explicit: do not bill until the visit is visible in the aggregator in VERIFIED status.
How to fix it, step by step
- 1Pull up the visit in your EVV system for the exact date of service on the denied claim line.
- 2If no visit exists at all, this claim needs documentation review before anything else — a claim without any visit record is an audit risk, not just a denial.
- 3If the visit exists, check its status. Anything other than Verified (Incomplete, In Exception, Processed) will not fulfill the requirement — clear each exception with the proper reason code.
- 4Confirm the visit actually posted to the state aggregator, not just your vendor's portal. Vendor-to-aggregator export is a separate hop that fails silently.
- 5Once the visit shows Verified in the aggregator, resubmit the claim within your timely-filing window.
How to tell it apart
N890 is the payer saying 'the EVV requirement itself wasn't met' without naming which element failed. Compare with N819 (the specific person wasn't found in EVV), N820 (units didn't match), or Ohio's 272+N521/N56 pairings (provider or service didn't match). If you get N890, start from 'does a verified visit exist at all.'
The bigger picture
N890 is one of only two RARCs whose official X12 wording names Electronic Visit Verification directly, which makes it the general-purpose EVV denial code payers reach for as enforcement expands state by state under the 21st Century Cures Act.
See if this code is quietly costing you money
Drop your Medicaid 835 into the free X-Ray. It parses in your browser and never leaves your computer.
Run the free Denial X-RayCommon questions
What does denial N890 mean?
The claim was processed against Electronic Visit Verification requirements and the required EVV data was not there — the payer found no fulfilled EVV record backing the service. This is the general-purpose EVV remark payers use when the visit-data requirement itself failed.
How do I fix a N890 denial?
Confirm the visit was captured in your EVV system and reached the state aggregator in a verified status before the claim. If the visit exists, fix whatever kept it from matching (client, caregiver, service, date, units), re-verify, and resubmit.
Can I appeal an N890 denial?
Usually the faster path is correction, not appeal: get the visit to Verified status in the aggregator and resubmit. An appeal without a verified visit record behind it has nothing to stand on — the requirement genuinely wasn't met at the time the claim processed.
Why did the claim deny when my caregiver definitely did the visit?
Because the payer never saw proof. EVV matching runs against the state aggregator's record, not against reality. A real visit that was never electronically captured, never exported, or never verified looks identical to a visit that never happened.