NEMT Billing Software: Stop Losing Revenue on Trips You Already Ran

A driver completes a dialysis round trip on a Tuesday morning. The patient signs, the van logs the miles, everyone goes home. Six weeks later the claim comes back denied. The prior authorization was never confirmed before the trip, so the ride was uncovered the moment it started. The work was real. The money is gone.

That is where NEMT revenue actually disappears. Not at the curb, in the claim. And it is the part most operators have the least visibility into, because billing happens days after the trip, in a different system, run by someone buried in denials.

I work on the billing side of custom NEMT platforms at Mindbowser. The pattern we see is consistent across operators: the dispatch is fine, the drivers are fine, and the revenue still leaks because the billing workflow has gaps that nobody can see until the remittance comes back short. This is a walk through where those gaps are, what billing software has to do to close them, and why the state-specific reality of Medicaid is what pushes serious operators toward a custom build.

What NEMT billing software actually has to do

Strip away the marketing and an NEMT claim moves through six stages. Each stage is a place revenue can leak.

1. Eligibility. Confirm the member is covered and the trip is authorized, before the wheels move.

2. Documentation. Capture the trip: pickup and drop-off, GPS-verified mileage, sequential timestamps, the member signature, and driver attestation.

3. Coding. Assign the right HCPCS code and the right modifiers for the level of service and the origin and destination.

4. Submission. Scrub the claim for errors and send it, usually as an EDI 837P, inside the timely-filing window.

5. Reconciliation. Post the payment from the EDI 835 remittance and catch underpayments and adjustments.

6. Denials. Work the denials systematically, fix the root cause, and appeal.

Five of those six stages are where I see money lost. Billing software is not valuable because it submits claims. Submitting is easy. It is valuable because it closes the five gaps between the trip and the deposit. The underlying Medicaid NEMT billing challenges behind each stage run deep on their own; this page stays on what the software does about them. The rest of this page is those gaps, one at a time.

Confirming coverage before the wheels move

The dialysis story above is the first and most expensive gap. Prior authorization and eligibility both have to be settled before the trip, not discovered after it.

Prior authorization is a medical-necessity check. The payer confirms the member cannot safely use personal or public transportation, that the requested level of service matches the clinical need, and that the provider is enrolled to deliver it. If that confirmation is not in hand before the trip, the claim is exposed. Eligibility is the second half: a member who was covered last month may not be covered today, and a real-time check at the moment of booking is the only way to know.

Both of these are standardized transactions. Eligibility runs on the EDI 270 inquiry and 271 response. Good billing software fires that check at booking, not at submission, so an uncovered trip never gets dispatched in the first place.

Prior authorization is about to get its own standard plumbing. The CMS Interoperability and Prior Authorization Final Rule, CMS-0057-F, requires the payers behind NEMT, Medicaid managed care plans and Medicare Advantage organizations among them, to run a FHIR-based Prior Authorization API, with operational provisions generally beginning January 1, 2026, per the CMS-0057-F fact sheet. What is a phone call and a fax today is becoming a checkable API. Billing software built to consume that API turns prior auth from a hope into a pre-trip gate.

Getting HCPCS codes and modifiers right, or the claim auto-denies

This is the gap that looks small and is not. NEMT claims live on a short list of HCPCS codes, and the modifiers attached to them decide whether the claim pays.

The codes themselves are public and specific:

• T2003 for non-emergency transport, billed per encounter or trip
• A0120 for non-emergency transport by mini-bus, van, or similar
• A0130 for non-emergency transport by wheelchair van
• A0100 for taxi
• S0215 for non-emergency transport mileage, per mile

But the trap is in the modifiers. NEMT uses origin-and-destination modifier pairs, two single-letter codes combined into one, where the first letter is the pickup point and the second is the drop-off. The base transport code and the mileage code on the same claim have to carry matching modifiers. When they do not match, the claim does not get reviewed and questioned. It auto-denies. No human looks at it. You find out six weeks later on the remittance.

I have watched a clean, well-run operation bleed revenue purely on modifier mismatches between the base line and the mileage line. The trips were legitimate, the documentation was complete, and the claims died on a coding rule. Software that validates the code-and-modifier combination at the point of claim creation, before submission, closes this gap entirely. A human coder will miss it under volume. A validation rule will not.

Reconciling GPS to the trips you actually billed

Here is a gap that hides in plain sight. The dispatch system knows where the van went. The billing system knows what was billed. If nothing reconciles the two, the difference is invisible, and the difference is where both fraud and honest leakage live.

A real New York Medicaid operator we worked with named this directly: GPS data was never matched against the billed trips. That is not a small accounting nicety. State and broker trip-verification rules increasingly want the GPS record to back the claim, and the operators who cannot reconcile the two are exposed on both ends, underbilling for legitimate miles they cannot prove and overbilling on trips that did not run as claimed. (To be clear on the rules, NEMT trip verification is state and broker driven, not the federal Cures Act EVV mandate that covers personal care and home health.)

And reconciliation is a software job. The trip’s GPS breadcrumb, its timestamps, and its billed mileage should be matched automatically, with the mismatches flagged for review. Done well, this is also your fraud control and your audit trail in one, which is why we treat reconciliation as a first-class part of a billing build, not an afterthought. The same data that proves the trip to a state auditor is the data that catches the trip that was billed wrong. The GPS and route data you already collect for dispatch is the input; billing is where it has to land.

Working denials systematically, not by hand

When a claim is denied, the EDI 835 remittance says why, in a standardized reason code. CO-16 for missing information. A code for an eligibility problem. A code for a documentation gap. The information to fix and refile is right there in the file.

But the gap is that most operators work denials by hand, if at all. A denial lands, it goes into a pile, and the pile is worked when someone has time, which under volume is never. Revenue ages out of the timely-filing window and is written off, not because it was unrecoverable but because nobody got to it.

Billing software changes the economics. It posts the 835 automatically, sorts denials by reason code, routes the fixable ones into a worklist, and surfaces the patterns. And the patterns are the real prize. When forty claims deny for the same modifier reason, that is not forty problems, it is one problem you can fix at the source so the next four hundred claims do not deny. This is the same denial-management discipline that drives healthcare billing automation across revenue cycle work generally, applied to the specifics of transport.

Handling the trip that did not go to plan

Real transport does not follow the schedule. A patient no-shows. A trip gets canceled at the door. A single authorization covers a multi-leg trip with a wait time in the middle. A ride deviates from the planned route for a real reason.

Off-the-shelf billing assumes the clean case and falls apart on the exceptions, which means a person has to handle them by hand. The same New York operator put exception handling on their list of core gaps: there was no clean path when a trip deviated from plan. Every exception became manual cleanup, and manual cleanup under volume becomes lost claims. Billing software that models the exceptions, the no-show, the cancellation, the multi-leg trip, the wait time, keeps those trips inside the billing workflow instead of dropping them into someone’s inbox.

Billing brokers, not just Medicaid

This is the layer a lot of billing software ignores. In most states, you do not bill Medicaid directly for a large share of your trips. You bill a broker. The broker is contracted by the state to manage the transportation benefit, build the provider network, authorize trips, and pay providers. Your claim goes to them, and their remittance comes back to you, in their format, on their cycle.

The broker market has consolidated hard, and that matters for your billing. MTM Health now owns MTM, Veyo, which it acquired in August 2022, and Access2Care, acquired in October 2024, which makes it the dominant broker holding company across much of the country. ModivCare, long the largest broker, filed Chapter 11 in August 2025 and emerged as a private company in December 2025. Fewer independent brokers means fewer formats to integrate, but it also means more of your revenue runs through a single counterparty whose portal and remittance rules you do not control.

Practically, billing software has to reconcile broker remittances the same way it reconciles a Medicaid 835: match the broker’s payment back to the trips you submitted, catch the trips they did not pay, and flag the underpayments. The operators who treat broker billing as a manual side process are the ones who cannot tell you, at the end of a month, which submitted trips a broker simply never paid.

Why custom billing software wins for state-specific Medicaid

Here is the honest reason this ends in a custom build, and it is not a sales line. Medicaid NEMT billing rules are set state by state. The covered codes, the modifier conventions, the rate schedules, the documentation requirements, the prior-auth rules, the broker arrangements, all of it varies by state, and some of it varies by program within a state. An off-the-shelf billing tool is built to the average. Your revenue lives in the specifics.

A custom platform encodes your state’s actual rules: the exact code-and-modifier validation that prevents your auto-denials, the eligibility and prior-auth checks your payers require, the broker formats you actually submit to, the reconciliation logic that matches your remittances. That is the difference between software that submits claims and software that gets you paid.

The broker consolidation and the ModivCare bankruptcy sharpen the case. When the network around you is shrinking and restructuring, owning the platform that runs your revenue, rather than renting it from a vendor whose roadmap is not yours, is a resilience decision as much as a revenue one. This is the same logic behind custom NEMT software development across dispatch and integration, applied to the part of the business where the money actually moves.

How Mindbowser approaches a custom NEMT billing build

We build the billing engine to your state’s rules, not to a generic average. In practice that means encoding the code-and-modifier validation that stops your specific auto-denials, wiring real-time eligibility and the prior-auth check into booking, reconciling GPS to billed trips, posting and working 835 and broker remittances, and modeling the exceptions that off-the-shelf tools drop.

I want to be straight about proof, because billing vendors throw outcome numbers around freely. Our differentiator is the engineering depth to build Medicaid and broker billing correctly for a specific state, demonstrated across our healthcare billing and integration work. We are not going to borrow a denial-rate percentage from someone else’s case study and put our name on it. When we ship a delivered NEMT billing build with its own measured result, that number will live here. Until then, the capability is the claim, and it is a real one. Pairing the billing engine with EHR-connected transport data is where this gets genuinely hard to match, because eligibility and authorization can flow from the clinical record instead of a separate lookup.

What operators tell us they need maps cleanly onto these gaps: prior authorization confirmed before the trip, real-time eligibility at booking, GPS reconciled to billing, exceptions handled cleanly, and denials worked systematically instead of by hand. That is the build.