Claims routing
Moves a claim from the provider to the payer in a form the payer's adjudication system accepts. This is the layer that decides whether the claim arrives clean.
Platform reviews · payer to provider
Eight established U.S. names, read by the layer of the workflow each one actually touches — claims routing, payment integrity, remittance posting, patient billing. No pricing opinions, no rankings. Just what each is built to do and where it stops.
Before the comparison
Vendor descriptions change. Every entry below is written to the category the platform publicly places itself in, not to a feature list we invented.
Eight platforms a U.S. practice or revenue-cycle team is likely to meet in a payer-provider workflow, compared inside the layer they operate in.
Reference notes NoteRates, contract terms, implementation quotes and vendor rankings. Those depend on your payer mix, your volume and your practice management system — not on a page like this one.
Out of scope —Platforms are compared inside a layer and nowhere else, on the specific step each one claims to remove from a person's day.
Applied throughout YesA tool that saves a step but adds a system a coordinator has to log into is a wash — so each entry notes what the platform requires from the systems you already run.
Per platform CheckIf you work in revenue-cycle operations and you support a Zelis portal connection for a payer or provider group, the same layer logic applies: find which step the tool removes, then check what it asks of your existing posting system.
The four layers of the payment workflow
A platform usually belongs to one or two layers of a claim's journey — occasionally more, but rarely all four. Comparing a patient-billing tool against a claims router is a category error; the fair comparison is platform-versus-platform inside a single layer.
The larger platforms tend to grow into two adjacent layers over time. When that happens, weigh the second layer lightly — a capability that came with an acquisition rarely behaves like one built for the lane.
Moves a claim from the provider to the payer in a form the payer's adjudication system accepts. This is the layer that decides whether the claim arrives clean.
Guards against incorrect payment after the claim has been adjudicated — eligibility, estimate accuracy, and the conditions that cause a claim to come back.
Remittance posting moves payment data into the practice management system; patient billing handles everything after the patient's share is known. Different owners, different failure modes.
Profiles by layer
Waystar, Optum, Experian Health, Cedar, Avaneer Health, Change Healthcare, Epic and McKesson. Each entry names the layer, the workflow it is built to touch, and the question to hold onto before a demo.
Waystar is a U.S. revenue-cycle platform used widely on the provider side. Publicly, the company frames itself around claims, payments and patient financial experience, with automation across those workflows as the core pitch. In practice, that makes it a benchmark for teams handling large claim volumes across many payers, where the value is in fewer manual status checks and cleaner posting. It is less a portal replacement and more an operating layer over the whole cycle.
Teams that already maintain a Zelis portal connection for a specific payer often keep it alongside a platform like this one — the platform carries the volume, the payer-side portal stays where it is contractually required.
Optum operates on a scale that most revenue-cycle vendors can't match, with capabilities spanning administrative services, data and payment-related workflows on both the payer and provider side. That size is its main story: it can absorb complexity that smaller tools would need to integrate with. The tradeoff is that a large organization's tooling tends to come with a large organization's process, which is worth checking against your own team's bandwidth.
For a twenty-provider practice, the scale argument cuts the other way: the value only arrives if you have people whose job is to run the thing.
It is the tool you'd reach for when your problem is downstream payment friction that started with a bad estimate or an eligibility miss at the front desk. It doesn't route claims; it reduces the number of claims that have problems in the first place.
That places it squarely in payment integrity. If your denial pattern traces back to eligibility and registration rather than adjudication, this is the layer to look at first.
Cedar is a U.S. healthcare financial engagement company focused on the patient. Its products are about statements, digital payment, and making a medical bill legible enough that a patient pays without calling. If your collection problem is patient-facing and the friction is that nobody understands what they owe, Cedar is in that category. It doesn't handle payer remittance or claims routing.
This is the entry most often compared against the wrong thing. Against a claims router, it looks thin; against a patient statement process, it is the whole argument.
Avaneer Health is built around healthcare data and transaction networks, with a stated focus on payer-provider connectivity and reducing manual administrative work. Change Healthcare has been central to claims and payment connectivity across U.S. payer-provider transactions and remains a reference point for what claims infrastructure does. Both sit in the layer most practices never see directly but rely on constantly. When either has a bad day, everyone downstream notices.
This is also the layer that a Zelis portal connection or a zeils agent support question tends to sit near, because payer-side connectivity is where portal access and network access meet.
Epic is the dominant EHR platform at U.S. hospitals and large health systems, and its billing, claims and revenue-cycle functionality is often the wall that other tools have to fit into. McKesson is a broad healthcare services company whose scale touches provider services and payment-adjacent operations, and whose footprint matters because workflow design choices at that scale ripple outward. If you're integrating anything into a hospital system, Epic is nearly always in the conversation.
Treat these two as constraints, not competitors. Your evaluation is often against what the surrounding system will let a third tool do.
Shift change
Reconciliation is the layer that only works if someone picks it up the next morning. What a platform chooses to hand over at end of day — and what it leaves open — is the operational question the entries above keep circling.
The room the lane runs in
Reconciliation only holds if the handoff does.
What separates a platform that helps
The strongest single predictor of a useful platform is whether it reduces the number of systems a person has to log into. A tool that saves a step but adds a login is a wash.
Check one
Count the systems a coordinator opens to move one claim from submission to posting. If the new tool raises that number, the saved step is cancelled out by the new tab — and by the new thing that can go wrong at 5:30pm on a Friday.
Check two
A platform that only works well when you also change your posting system is a project, not an improvement. Ask what the platform hands back to your practice management system, in what form, and whether your existing posting rules already know what to do with it.
The same question applies to a Zelis portal connection or a payer portal your team logs into today: whether the platform removes that step for every payer you have, or only for the ones where it has direct connectivity.
Ask both before a demo
They narrow the field faster than any feature grid, and both answers are specific enough to check against your own numbers rather than the vendor's.
The record end of the lane
Common mistakes
None of these are exotic. They are the mistakes teams make when the comparison happens before the workflow is written down — and they cost the most when a contract is already signed.
Putting a patient-billing tool against a claims router. Both look strong; the comparison itself is meaningless.
Scale rarely helps a twenty-provider practice. It helps the practice that already has an operations team to run it.
Integration effort is usually the majority of the work. A demo shows the tool; the project is what stands between the demo and the tool in use.
You can't evaluate a tool for a process you haven't written down. Write the process first — it is the only fair ruler you have.
How to run a fair comparison
Most bad platform decisions come from comparing a tool's strongest feature against another tool's weakest one. The fix is mechanical: hold the layer constant, hold the step constant, and write down what changes.
Write which of the four layers each platform occupies. If two occupy different layers, they are not competitors — stop the comparison there.
Before any call ScopeOne sentence per platform: the specific workflow step that disappears from a coordinator's day. If the sentence runs long, the value is probably spread thin.
Per platform StepWhat feeds it, what it hands back, and whether your posting rules already recognize that. This is the column that usually decides the project size.
Integration load FitWho on your team owns the platform's output once it's live. If nobody's name goes on this row, the platform is placed but not adopted.
After go-live YouA zeils agent support ticket often starts with the same missing row — nobody wrote down who owns the connection. That single line, filled in before the demo, prevents more rework than any contract review.
The playbook walks the full route a remittance takes — from payer portal, through routing and reconciliation, into posting and release. If your question is about a specific connection in that route, the contact page is the shortest way to an answer.
Read next
The automation playbookHow the claims and remittance lane moves end to end, and where automation actually saves a handoff.
Ask a platform question
Contact Zeils AgentSend the platform and the layer you're weighing. We'll tell you what to check before a demo.
Mon–Fri, 9:00 AM – 6:00 PM · +1-650-723-2300