EVV and Billing Are Still Two Systems in Most Home Health and Behavioral Health EHRs. Here’s Why That’s Now a Compliance Risk, Not Just a Chore

Every home health operator we talk to has the same two logins open: one for EVV, one for billing, and a spreadsheet in between to make sure they agree.

Nobody built it that way on purpose. It’s what happens when a scheduling-and-EVV vendor gets bolted onto a billing system that was never designed to talk to it. For years that was survivable. An office manager spent Tuesday mornings matching visit logs to claims, caught the mismatches, resubmitted, moved on. Annoying, but it didn’t cost anyone their Medicaid enrollment.

2026 changed the math. States aren’t just checking whether you submitted EVV data anymore. They’re checking whether it matches the claim, at scale, automatically, and rejecting the claim when it doesn’t. The reconciliation labor problem became a denial problem. That’s a different animal, and most agencies’ architecture hasn’t caught up.

Why This Question Keeps Coming Up Right After “Replace Our EMR”

We hear a version of this same conversation regardless of specialty. An operator is evaluating a legacy EMR replacement, usually because the current system can’t keep up with billing volume or reporting demands, and somewhere in the second or third call, EVV comes up. Not as the reason they’re calling. As a thing they mention almost in passing, like it’s just part of the furniture.

It isn’t. It’s usually the sharpest edge of the whole replacement decision.

The pattern looks the same across the pipeline conversations we’ve had: legacy EMR, plus a bolt-on EVV vendor, plus a person whose actual job is reconciliation. That’s the default configuration for a home health agency that hasn’t rebuilt its stack in the last five years. It’s not the exception. It’s closer to the norm, and it’s the norm because nobody designed it; they inherited it, one vendor decision at a time.

You’ve probably lived some version of this if you’re running visits and claims through two different systems right now.

What EVV Actually Requires in 2026, and What It Doesn’t

Let’s get the regulatory scope precise, because this is the part where a lot of vendor content gets sloppy, and sloppy here costs money.

The 21st Century Cures Act, Section 12006, mandates Electronic Visit Verification for Medicaid-funded Personal Care Services (PCS), effective January 1, 2020, and Home Health Care Services (HHCS), effective January 1, 2023. Both deadlines have passed. Both are fully enforced. That’s the federal floor, and it applies regardless of which state you’re operating in, as long as the service is Medicaid-funded PCS or home health care.

What changed in 2026 isn’t the mandate. It’s the enforcement posture. Medicaid.gov’s EVV guidance and state-level bulletins describe a shift from acceptance-based checking (did the visit get submitted at all) to validation-based checking (does the submitted visit meet an accuracy threshold, typically 85% or higher, across required data fields like time, location, service type, and individual served).

California’s CalEVV program is the clearest example: providers must hit full compliance for any claim received on or after June 1, 2026, or face Corrective Action Plans, and eventually claim denial, not just a data-quality flag.

That’s the setup sentence. Here’s the number that should actually worry you: an 85% accuracy threshold sounds generous until you realize it’s measured per required field, per visit, at volume. One home health agency running 40 visits a day across a small team doesn’t get to fail 15% of those fields quietly. The state sees the pattern within weeks.

Now the part where a lot of behavioral health operators get this wrong, including some vendor pages that should know better: there is no blanket federal EVV mandate for behavioral health. Section 12006 names PCS and home health care. It doesn’t name behavioral health services as a category. What actually happens is state-by-state, and it’s triggered specifically by whether a behavioral health service has an in-home or community delivery component. Michigan requires EVV for behavioral health services that start or stop in the client’s home.

Colorado requires it for in-home or community-based Behavioral Therapies. A behavioral health practice running entirely in-clinic, no home visits, no community-based sessions, isn’t under an EVV mandate at all, federal or state, in most jurisdictions. The trigger is the delivery location, not the diagnosis code.

If your practice has any in-home or community service line, check your state’s specific EVV rule before assuming either way. Guessing wrong in either direction costs you: guessing “we’re covered federally” when you’re not wastes build effort, and guessing “we’re exempt” when your state added the requirement gets you a Corrective Action Plan you didn’t see coming.

The Real Failure Mode: Two Systems of Record, One Reconciliation Job

Here’s what this actually looks like inside an operation, based on the pattern we keep seeing across pipeline conversations, not a hypothetical.

A home health operator we’ve talked with is mid-transition off a legacy scheduling-and-EVV combo. Visits get logged in the EVV vendor’s system, aggregator-submitted to the state, and then someone manually pulls that same visit data into the billing system to generate the claim. Two systems. Two data entries for the same event. One person’s job, functionally, is making sure they agree.

A separate account we’ve worked with runs a physician-first platform integrating across a diverse ambulatory EHR landscape. Different specialty, different regulatory context, same underlying shape of problem: clinical and administrative data about the same encounter living in separate modules that were never designed to share a record, with a human doing the matching by hand because nothing else does it.

Actually, let me be more precise about what “matching by hand” means in practice, because it’s not one task, it’s three: confirming the visit time in the EVV log matches the time billed, confirming the service code entered at the point of care matches what got submitted to the payer, and confirming the individual served (the client ID) ties out across both systems. Miss any one of those three and you’ve got a mismatch, whether or not anyone catches it before submission.

We’re not the only ones seeing this. A home care operations blog, myEZcare, independently describes the identical failure mode: agencies “holding EVV and billing in separate modules connected by a manual export,” and staff spending “hours matching records across two systems that should be one.” That’s not our internal framing bleeding into someone else’s blog. That’s two separate vantage points, one from CRM conversations, one from market-facing content aimed at home care operators, landing on the same description of the same problem.

When your own sales pipeline and an unrelated industry blog describe the identical failure mode in nearly identical language, that’s not coincidence. That’s a structural gap in how most of these systems were built.

Why 2026 Changes the Stakes

Here’s the shift, stated plainly: EVV data used to be a compliance checkbox. It’s becoming a fraud-detection signal.

Rivkin Radler’s analysis on EVV enforcement frames 2026 as “the new frontier in home health fraud enforcement,” and the mechanism is straightforward. When EVV data doesn’t match the billing claim, that’s no longer read as a documentation gap. It’s read as a signal worth investigating, because visit-verification mismatches are one of the cleanest fraud indicators a state Medicaid program has access to.

CMS is running a 2026 evaluation of how EVV data is actually used for PCS oversight, with a report expected this year, and the direction of travel is more scrutiny on that data, not less.

So what’s actually at stake if your EVV and billing stay unreconciled: not a slow week doing manual matching. Automatic claim rejection at the point of submission, in states running validation-mode checking, and a Corrective Action Plan if the pattern repeats. States aren’t asking “did you submit EVV data.” They’re asking “does your EVV data match your claim,” and answering that question algorithmically, at scale, without a human reviewing the specific case first.

The Architectural Fix: One Record, Two Consumers

This is the part that actually differentiates a build from a bolt-on, and it’s worth being specific about the mechanism instead of waving at “integration.”

The core idea: the visit or encounter record that satisfies EVV verification should be the exact same record that becomes the billing claim, without re-entry, without a second system, without an export-and-match step in between.

What this requires structurally: a shared data model, built around a single FHIR-native Encounter resource rather than two parallel schemas. The Encounter resource captures the data both processes need: start and stop time, geolocation or verified alternative (telephony, fixed-visit confirmation), service type, and the individual served. That one resource becomes the source for two downstream consumers.

The state aggregator feed (Sandata, HHAeXchange, Netsmart, or CareBridge, depending on the state) reads from it to satisfy EVV submission. The billing engine reads from the same resource to generate the claim. Same record, two consumers, zero re-entry.

The sync mechanism matters here, and it’s not automatically real-time. For EVV submission, near-real-time or same-day batch is typically sufficient, since most state aggregators accept daily batch submission windows. For billing, the claim generation can run on its own cadence (weekly, biweekly, whatever matches your existing claims cycle) as long as it’s reading the same underlying encounter record rather than a re-keyed copy.

The point isn’t that everything has to happen instantly. The point is that there’s exactly one authoritative record of what happened during the visit, and everything downstream references it instead of recreating it.

What This Looks Like Differently for Home Health vs. Behavioral Health

This is where the piece has to resist a real temptation: the title names both verticals, and it would be easy to write behavioral health’s section as if it mirrors home health’s. It doesn’t, and saying so plainly is more useful to you than pretending otherwise. A behavioral health practice that runs entirely in-office group and individual therapy, no home visits, no community-based crisis response, has no EVV obligation to architect around right now, federal or (in most states) state-level.

One that runs a home-based intensive outpatient program in Michigan does, and needs the same shared-record thinking as a home health agency.

If your primary question is broader than this EVV slice, general behavioral-health EHR selection, documentation workflows, measurement-based care, that’s better covered in our guide to AI-enhanced behavioral health EHRs, which goes deeper on the full platform question rather than this narrow architecture point.

Build vs. Bolt-On: Why Point EVV Vendors Solve Half the Problem

Point EVV vendors like Timeero, Ankota, and AlayaCare, feeding into aggregators like Sandata, HHAeXchange, Netsmart, or CareBridge, are genuinely good at one thing: getting compliant EVV data to the state. That’s not a knock. That’s their entire job, and most of them do it reliably.

What they don’t do, because it’s not their job, is unify that data with your billing system. They’re a second system by design. You still need something to reconcile what the EVV vendor captured with what your billing system needs to submit a claim. Buying a better point EVV vendor doesn’t remove that reconciliation step. It just makes the EVV half of it more reliable.

What We’d Actually Build

Strip away the vendor names and the state-specific detail, and here’s the technical shape of it: a FHIR-based Encounter resource as the single source of truth for a visit, with the state aggregator integration built as an outbound feed off that resource, not a competing source of truth, and the billing claim generation reading from the same resource on its own cadence.

The audit trail lives at the resource level, so a single record satisfies both the EVV verification requirement and the billing documentation requirement simultaneously, because it’s genuinely one thing being referenced twice, not two things being kept in sync.

Here’s the honest limit, and it’s worth naming directly rather than glossing over: building this in-house doesn’t eliminate the state aggregator submission requirement. States still require aggregator-format data, whichever aggregator your state contracts with.

What the shared-record architecture removes is the reconciliation step, the manual matching between two independently maintained records of the same event. It doesn’t remove the aggregator relationship itself. Anyone telling you a custom build gets you out of dealing with Sandata or HHAeXchange entirely is overselling the fix.

What we still haven’t seen a clean answer to, across the accounts we’ve worked with: how this shared-record model should handle a visit that gets clinically amended after the fact, say a service code correction entered two days later. Does the correction flow back through both the EVV submission and the claim, or does it require a separate amendment trail on each side? We’ve built toward the former. We’d want to hear from anyone who’s solved this cleanly at scale.