Coker Group Holdings LLC

10/19/2026 | Press release | Distributed by Public on 10/19/2026 16:03

Auditing as a Service: Who Checks the Machine

Part 3 of a 3-part series on the future of coding, auditing, and revenue integrity

Once automation is doing a meaningful share of your coding, who's checking its work? In Part 1, The Riddle of the Middle, we argued that middle rev cycle is the most underinvested, highest-leverage layer of the revenue cycle. In Part 2, Coding as a Service, we made the case that coding shouldn't be an "AI vs. humans" choice. It's an allocation problem: put automation on volume and expert judgment on the dollars that matter. That allocation model leaves one question open, and it's where we think auditing is changing shape.

‍

Auditing has mostly been a compliance function

For most health systems, auditing exists to answer a fairly narrow question: are our coders getting it right, and are we exposed if a payer or regulator looks closely? That's a legitimate and necessary function. It's also a backward-looking one. Traditional auditing samples a slice of completed claims, checks them against documentation, and flags errors after the fact. It catches human inconsistency, but it wasn't built to catch anything else, because until recently, nothing else in the workflow needed catching.

That's no longer true. Nearly half of large health systems (48%) report using AI in their revenue cycle, according to the 2026 PayZen/HFMA survey. In HFMA's February 2026 survey of 95 finance professionals, 27% said their organizations are deploying AI at scale across multiple functions, and another 53% are piloting it in select areas. As those pilots move into production, we expect autonomous coding tools to touch a growing share of claims before a person sees them. Auditing built around checking people doesn't automatically extend to checking a model.

‍

A model fails differently than a person does

A tired or undertrained coder makes scattered, largely random errors, while an automated coding model makes consistent ones. If it misreads a particular documentation pattern, it will misread that same pattern every time it appears, across every encounter, every day, until someone notices. That's the trade-off with automation: it removes variance, but it also means an undetected error compounds at scale instead of staying isolated to one claim.

A traditional random sample, designed to catch scattered human error, is a weak tool for detecting systematic model error. If the error rate in the sample looks low, it's tempting to conclude the model is performing well, when in reality the sample may simply not have hit the specific pattern the model consistently gets wrong. That's a systematic error, not a scattered one, and it calls for a different kind of audit.

‍

What an AI coding audit involves

Auditing automated coding well means shifting focus from individual claims to patterns across claims. That includes tracking model performance by encounter type and complexity, rather than a single blended accuracy number that can hide weak spots in high-dollar categories. It means watching for drift, since model behavior can shift as documentation practices, EHR templates, or payer requirements change over time. And it means validating the model against the high-complexity cases we flagged in Part 2 as the highest-risk category, precisely because that's where an error is most expensive and least likely to be caught by a routine sample.

This doesn't replace traditional compliance auditing. Coders still need oversight through ongoing coding audit and education, and compliance risk hasn't gone away. But an AI coding audit adds a layer most organizations haven't built yet, and it requires a different skill set: people who understand coding deeply enough to catch a subtle miscode, and who also understand how these models behave well enough to know where to look for one.

Three questions show where your own audit program stands:

  1. Can you see model accuracy by encounter type and complexity, or only as one blended number?
  2. Who watches for drift when documentation templates, EHR builds, or payer rules change?
  3. Has anyone validated the model against your highest-dollar, highest-complexity cases?

If you can't answer all three with confidence, that's the gap to close first.

‍

Bringing the series together

Across these three posts, the throughline has been the same: middle rev cycle carries the most financial risk with the least clear ownership, coding needs a deliberate allocation model instead of a binary choice between people and software, and auditing has to expand to cover both, since the more automation you add, the more that automation itself needs checking.

Picking a side between humans and AI was never the point. The point is an operating model in which each does what it does best, and someone is accountable for the seams in between. That's the model we help organizations build at Acuvance Coker, whether that means coding capacity, audit depth, or the connective tissue that ties both back to revenue integrity.

If any part of this series matched what you're seeing internally, we'd welcome the conversation.

Coker Group Holdings LLC published this content on October 19, 2026, and is solely responsible for the information contained herein. Distributed via Public Technologies (PUBT), unedited and unaltered, on October 19, 2026 at 22:03 UTC. If you believe the information included in the content is inaccurate or outdated and requires editing or removal, please contact us at [email protected]