The revenue cycle, run on the operating layer.

The pattern of AI healthcare adoption in 2024–2026 has been narrow. Ambient documentation landed first — the value proposition was crisp, clinicians spent hours per day on notes, AI captured the conversation, hours came back. The market understood it. Demos sang. Practices bought.

The next workflow to land was front-of-house: voice agents for inbound calls, fax intake, appointment scheduling. Same logic. Crisp value, crisp demo, crisp sale.

The pattern in both cases: the vendor solves one surface, sells it, and lets the revenue cycle live wherever it was living before — usually with the existing RCM vendor (Waystar, Athena Collector, eClinicalWorks RCM, R1, Optum). The practice still runs a stack. The AI is one tool in the stack, not the layer underneath it.

That is a defensible product strategy at the company level. It is also what is stopping AI from delivering the unified-operating-layer outcome the market keeps half-promising.

Why most vendors stop at the note

Three structural reasons.

First, payer policy literacy is enormous. A medical practice typically deals with ten to thirty payers, each with its own prior-authorization rules, medical-necessity criteria, modifier requirements, bundling logic, and quarterly policy updates. An ambient scribe doesn’t need to know any of that. A revenue-cycle layer has to know all of it, by payer, kept current. The maintenance burden alone — a small data team running a payer-policy library on a quarterly cadence — is the kind of investment a startup defers as long as it can.

Second, denial taxonomy is unglamorous. The Claim Adjustment Reason Codes (CARC) and Remittance Advice Remark Codes (RARC) catalog runs to several hundred codes deep, with payer-specific interpretations of each.¹ A vendor that wants to handle denials end-to-end has to map every code to a workflow — appeal, additional documentation, secondary claim, write-off — and the mapping varies by payer and by procedure. There is no off-the-shelf dataset for this. It is human-coded specialty knowledge that has to be built and curated.

Third, ERA reconciliation at scale is engineering, not AI. Parsing X12 835 remittance advice, posting payments to the right encounter, applying contractual adjustments, generating secondary claims, catching mis-postings before they compound — this is plumbing work. Not glamorous. Not demoable. Regulated. Has to be right every time.

The vendors that have skipped this work haven’t skipped it because it isn’t valuable. They’ve skipped it because the marketing ROI of a great ambient-scribe demo dwarfs the marketing ROI of a great ERA-reconciliation demo. One sells; the other doesn’t even register.

What “closing the loop” actually requires

Seven stages of depth, in rough order. Each one is a real engineering and operational problem; none can be handwaved.

1. Charge capture integrity.

Every billable encounter has to produce a charge with the right code, the right modifier, the right time stamp, and the documentation evidence linked. Drop a charge and revenue evaporates silently. Capture a charge without supporting documentation and the denial arrives six weeks later. The operating-layer claim is that charge capture is automatic from the note — and that the audit trail back to the documentation is preserved at every downstream stage.

2. Coding accuracy with audit trail.

CPT, ICD-10, HCPCS, modifiers, and time-based codes for AWV / CCM / RPM each carry their own ruleset. A 2025-era AI medical-coding system can produce suggestions at accuracy levels that rival human coders, with audit trails the JAMA literature now treats as routine.³ The harder part is integration: linking each code to its documentation source, surfacing the small share of cases that need human review, and not surfacing the rest.

3. Clean claim preparation.

Payer-specific edits applied before submission — modifier rules, bundling logic, medical-necessity attachments, prior-authorization references — checked against the payer’s current policy, not last year’s. A clean claim is one that arrives at the clearinghouse already passing the payer’s adjudication logic. The industry baseline for clean claim rate sits in the 75–85% range; an operating-layer-grade system targets the high 90s.⁴

4. Clearinghouse routing and submission tracking.

X12 837 generation, electronic submission, acknowledgment ingest, in-flight visibility. The practice should know what’s submitted, what’s acknowledged, what’s pending payer review — without staff opening a clearinghouse portal. The unglamorous engineering work here is in handling the dozens of edge cases (rejections, partial acknowledgments, payer-routing changes) that the happy path doesn’t exercise.

5. ERA ingest, posting, and secondary claim generation.

X12 835 remittance advice parsed automatically. Payments posted to the right encounter. Adjustments applied per the practice’s payer contract. Secondary claims generated where appropriate. The end-of-day reconciliation that used to take a coordinator two hours runs in the background. This is the stage most adjacent to actual money movement; mistakes here compound on the practice’s books, which is why it requires audited plumbing, not pattern matching.

6. Denial management and appeals.

Denials routed by CARC / RARC code with the supporting clinical history already pulled from the chart. First-pass appeals drafted by the system; complex denials staged for a human with everything they need attached. The operating-layer claim here is that no denial sits in a thirty-day backlog because someone forgot to look at it — the layer routes everything within hours.

7. A/R follow-up and patient billing.

Aged claims worked on a payer-specific cadence — calls to payers for status, escalation triggers when claims age past threshold, structured documentation of every contact. A/R aging surfaces in the Monday standup, not the quarterly board deck. Patient billing then closes the loop with statements, payment plans, online-portal payments — with patient responsibility communicated clearly the first time, not after three rounds of confused phone tag.

The “AI is good at coding” trap

Since roughly 2024, the medical coding market has been called solved. CodaMetrix, Fathom, Nym, and others can produce CPT and ICD-10 suggestions at accuracy levels that rival or exceed human coders, with audit trails the JAMA literature now treats as routine.³ The category has investor enthusiasm. The demos sing.

This narrative has produced a peculiar second-order effect: practices and vendors alike act as though “AI handles coding” is the same statement as “AI handles the revenue cycle.” It is not. Coding is one of seven stages. The other six — charge capture, claim prep, clearinghouse routing, ERA ingest, denial management, A/R follow-up — are arguably harder, and in any case are entirely separate engineering and operational problems.

A vendor that has done excellent work on AI coding has done excellent work on AI coding. That is not the same as having done the work to close the loop. A practice evaluating an AI coding tool should expect to keep its existing RCM vendor; a practice evaluating an operating-layer should expect that vendor to handle the rest of the stack on its own.

Why the operating-layer frame matters

The value of unifying the cycle into a single operating layer lives at the seams between stages.

A medical practice today typically runs four to seven disjoint tools across the revenue cycle: an EHR-native or third-party coding tool, a clearinghouse, an RCM vendor for posting and A/R, possibly a denial-management point tool, possibly a separate patient-billing platform. Each tool’s intelligence is calibrated to its narrow lens. The denial-management tool sees denials but not the chart. The coding tool sees the note but not the payer’s prior-auth history. The clearinghouse sees the claim but not the documentation evidence behind it.

The operating-layer claim is structural: when one system holds the full chart, the full payer history, the full A/R book, and the documentation linked to every charge, the system can do things the disjoint stack literally cannot. A denial that comes back for medical necessity has the supporting note already attached when it lands in the appeal queue. A clean-claim edit applies because the system saw the prior-auth conversation that justifies the modifier. An A/R follow-up call comes with all four prior touches already documented.

This is not a marketing distinction. It is structural. The reason ambient-scribe-only vendors can’t close the revenue loop is that they don’t see the loop — they see a thirty-minute audio clip and a final note. A revenue-cycle layer needs to see the year.

What practices should expect from an RCM-inclusive vendor in 2026

Six asks a practice should make of any vendor claiming end-to-end revenue-cycle coverage. Parallel in spirit to the broader buyer’s guide⁵ — specific to the revenue stack.

• Show me an end-to-end claim — from documentation to coding to submission to ERA posting to closure. Every stage in the system, in one walkthrough, on a real-shaped (de-identified) record.
• Show me your denial categorization. How are you mapping CARC and RARC codes to workflows? What does the system do automatically; what stages for human review?
• Show me your ERA reconciliation logic. Where do mis-postings get caught? What happens when a remittance doesn’t match the expected adjudication?
• Show me your A/R aging report — by payer, by procedure type, by aging bucket. The shape of this report tells you whether the vendor actually runs the cycle.
• Show me your patient-billing flow. Where most vendors are weakest. Statement generation, payment plans, online-portal reconciliation, collections handoff — or if you don’t do these, tell me what you hand off and to whom.
• Tell me what your roadmap response is when a payer changes policy mid-quarter. The cadence of policy ingest, the team that owns it, and the deployment pipeline that gets the change live.

The next two years

Two regulatory shifts make the next two years the window in which this gap closes or hardens.

CMS-0057-F went live January 1, 2026. By 2027, every impacted payer must expose a FHIR Prior Authorization API. Vendors that operate at the seam of clinical and financial cycles — pulling clinical justification, querying payer policy, submitting through the API, ingesting the response, applying it to the claim — benefit structurally. Vendors that operate at one cycle or the other don’t.⁶

The 2025 HIPAA Security Rule update raises the bar on data-handling consistency. Vendors that fragment PHI across point tools have a harder downstream-compliance story than vendors that operate one layer.⁷

The operating layer was always going to close the revenue loop. The vendors that do, will define the next decade of clinical operations. The vendors that don’t will be sold by the vendors that did.