“70-80% of the denials I see aren't payer issues.
They're system or workflow failures.”
r/CodingandBilling operator, Q18
That's the buried problem under every denial worklist. Most appeals are recoverable. Most workflow failures are preventable. The work is there. The system to surface it isn't.
Your first build with us is the denial root-cause and appeal workflow we'll build to classify every 835 line, separate the appealable from the workflow-driven, draft the appeal packet in your firm's voice, and route the rest to a human RCM specialist for review. Inside your existing EMR, clearinghouse, and ERA pipeline.
BAA negotiated and signed in week 1, before any PHI touches the system. Human-in-the-loop. Your licensed staff signs off on every appeal.
Inevi Solutions builds and operates intelligent systems for revenue cycle management, denials operations, and adjacent healthcare-admin work under the same compliance posture every operator we've talked to demands:
- BAA signed before any PHI moves. We negotiate and sign your Business Associate Agreement in week 1, before PHI, an 835, an ERA, an EOB, or a CMS-1500 touches a system we build or operate. No BAA, no engagement.
- Human-in-the-loop by default. Every consequential action (denial classification override, appeal-packet submission, CARC/RARC code assertion, ERA-to-claim relink) routes to a licensed RCM specialist on your team for sign-off. We absorb the back-office workload your specialists never wanted. We don't replace your team, and we don't touch clinical workflow.
- Liability terms scoped in the engagement agreement. Final responsibility for appeal substance, billing-code decisions, and payer-facing communication stays with your licensed staff. The “who's accountable if the classification is wrong” question gets a written answer scoped to your MSA, not a blanket promise on a marketing page.
- Audit log on every action. Every denial classification, every CARC/RARC mapping, every appeal-packet draft, every ERA reconciliation step is logged with timestamp, source 835 segment, model reasoning, and the human who signed off. Reproducible. Exportable. Built for your compliance team and your clients' compliance teams.
- PHI handling protocol. Encryption in transit and at rest. Scoped connectors per clearinghouse and per EMR. De-identification, when used, only via Safe Harbor or Expert Determination, named in writing, never as marketing.
If those aren't deal-breakers in your evaluation, we're not the right partner. They're table stakes for us.
Who this is for
You're one of these:
- RCM consultancy founder or partner. Solo to 20-person firm. You bill $150 to $300 per hour, your specialists run 150 to 200 denials a week each, and you're trying to get more clients onto the same headcount without quality cratering.
- In-house RCM director at a small or mid-sized medical group. Your team owns denials end-to-end, your EMR billing module isn't helping, and your CFO wants the AR aging report to stop drifting the wrong direction.
- Denials-management specialist brought in to recover lost revenue. You know the work. You also know that 30 to 60 minutes per denial is the unit economics nobody's beating with a worklist UI.
You're already living inside the EOB, 835, ERA, and EMR-billing-system stack. You've probably seen Tebra, Kareo, AdvancedMD, Cerner, NextGen, Athena, or worse. You know what happens when an EMR auto-posts denials as full writeoffs with no ERA-to-claim linking. You don't need a tour of the problem. You need the system to start sorting it.
The pain we keep hearing
We don't have named RCM-consultancy customers yet. We're not inventing quotes. Here's what RCM operators actually say in their own words. Quote IDs reference our internal customer-research file.
“Hot take: 70-80% of the denials I see aren't payer issues -- they're system/workflow failures that billing teams are forced to compensate for.”
“The state of EMR/Billing software out in the wild is absolutely AWFUL. I've used about five different ones, and... It's wild how companies think they can get away with: Autoposting denials as FULL WRITEOFFS with NO CONFIGURING FOR AUTOMATIC WRITEOFFS BEYOND 'YES/NO'. Zero ERA attached to claims! As in, you can't check a claim and attached visit date AND see ANY eobs relating to it. I was using a software and they said there's no way to check incoming 835s, and no way AT ALL to simply reference a claim and then find associated EOBS!”
“Erasing and hiding unmatched claims(!) Double-counting AR by counting secondary totals for the full total of the primary... this one made accounting go crazy.”
“The integrated practice management / clearinghouse thing feels like an applefication. Great if it works... but when it doesn't... Now instead when something is broken I test everything on separate browsers, spend 10 minutes writing a ticket, then have the tier 1 support write back a week later (they leave complex tickets for last) saying I need to attach some screenshot or whatever and repeat all the steps I already did.”
The pattern under every quote: the work is real, the volume is climbing, the tools are hostile, and the specialist hours per denial don't bend. That's the gap we build into.
What we build
Inevi is a technology-as-a-service firm. For RCM and denials practices, that means two things working together.
An operating layer
We'll design and build a layer that sits across your existing clearinghouse (Availity, Trizetto, Change Healthcare, Office Ally, or whatever you've got), your EMR billing module (Tebra, Kareo, AdvancedMD, NextGen, Athena, Cerner), and the 835/ERA/EOB feeds flowing through both. It'll pull every denial in, classify it, link the ERA back to the claim, surface the patterns, and write the appeal-packet drafts.
AI employees created by your detailed SOPs
Your firm already has a denial playbook. The way your senior specialist reads a CO-16 on a 99214 from a specific payer, the appeal narrative your firm has built and tuned, the supporting docs you pull, the escalation logic. That's an SOP. We'll turn it into an AI employee that runs that SOP at scale, end-to-end, on every denial that hits the queue, with the human RCM specialist reviewing the exception cases and signing off on submission.
It's not a denial-management black-box scoring tool. It's not a “denial AI” that hands you a confidence score. It's the operating layer we build plus the AI employees we build that operationalize your firm's existing methodology.
Denial Root-Cause + Appeal Workflow
Fixed price. 4 weeks. Proposal-based after the free assessment. This is where every RCM and denials engagement starts. One workflow, scoped tight, built fast, in production.
A system that pulls 835 / ERA / EOB feeds
From your clearinghouse and EMR billing module on whatever cadence your operations run. Daily, real-time, batch. Your call.
Classifies every denial into four buckets
- Workflow failure upstream. Eligibility wasn't checked, demographics drifted, the wrong location of service got coded, the auth was missing, the COB was wrong.
- Payer policy denial. Medical necessity, frequency limits, bundling rules, payer-specific coverage logic. These need a human RCM specialist.
- Billing-code error. CPT/ICD-10 mismatch, modifier missing, CARC/RARC pattern indicates a code-side fix, place-of-service mismatch.
- Authorization missing or expired. PA wasn't on file, PA expired, PA covers a different CPT than the one billed.
Links the ERA back to the claim
Every time, including the failure cases your EMR hides today. Every claim shows its full ERA history with the exact 835 segments, CARC/RARC codes, and adjustment amounts.
Generates the appeal packet
For the workflow-driven and billing-code subset. The right CARC/RARC codes referenced in the appeal narrative. Supporting documentation auto-pulled from the chart. Narrative drafted in your firm's voice from your firm's appeal templates and tone (we ingest your existing winning appeals during onboarding). The appeal level (first, second, external review) determined by the payer's published appeal process and the prior history on this claim.
Routes payer-policy denials to a specialist
With the full ERA, the full CARC/RARC pattern, the patient's relevant clinical context (per BAA, scoped access only), and a structured prompt. The specialist makes the call. The system executes.
Audit-logs every classification
Source 835 segment, the model's reasoning, the supporting evidence pulled, the human who reviewed it, and the final disposition.
Workflow-side patterns surfaced
“You keep getting CO-16 on 99213-99215 from this payer because the auth is missing on these CPT codes.” Your consultancy can take that pattern back to your client's billing department and fix it once, instead of appealing the same denial fifty more times.
ROI math (operational economics, not pricing)
The Q18 voice quantifies the lever: 70 to 80% of denials are workflow failures. Run the math on a representative RCM consultancy.
- Denials volume: 1,000 denials per month per client. With 5 clients, 5,000 per month.
- Workflow-driven share: 75% means 750 of every 1,000 denials shouldn't have happened.
- Specialist time today: 30 to 60 minutes per denial.
- Specialist time on Inevi: 5 to 15 minutes per denial. Classification done. Appeal drafted. ERA linked. Supporting docs pulled. Specialist reviews, edits if needed, signs off.
- Hour reduction: 50 to 80% of specialist time on denials.
For a 5-person consultancy billing $150 to $300 per hour, that recovered specialist time is worth roughly $300k to $500k a year. Either margin you keep, or 2 to 3x more clients on the same headcount. The platform pays for itself in the 4 to 12 month range we hold across every Inevi engagement.
4-week build. Fixed price. Proposal-based after the free assessment.
What happens after
The first build is the wedge. The expansion path is where the consultancy economics actually compound.
Pre-submission claim-scrubbing
Catch the workflow failures before the claim leaves the EMR. The same classification engine, run in reverse: “this claim, going to this payer, with this CPT, missing this modifier, will get CO-16'd. Fix before submission.” The economics flip from recovery to prevention.
Payer-pattern intelligence
Your specific payer mix, mapped to your specific denial root-cause heatmap. Which payers deny which CPTs at which rates with which CARC patterns at which appeal levels. The specialist call you make on a payer-policy denial gets backed by your firm's actual recovery data, not a vendor benchmark report.
Client-coaching content
Your consultancy delivers training packets generated from your client's actual denial data. The same intelligence layer we'll build for the appeal workflow generates the “your medical group keeps getting CO-16'd on these codes because of these workflow gaps” packet. Recurring revenue, not project revenue.
Typical ARR per RCM consultancy: $80k to $150k. Build fees one-time. Ongoing operation a fixed monthly retainer.
Operated by us
Most “denial AI” vendors hand you a tool and walk away. We don't build that way. We design and build it, deploy it, and then we run it.
- Hosting, monitoring, security patching. Our infrastructure, your data, scoped per BAA.
- Clearinghouse and EMR continuity. Your Availity, Trizetto, or Change Healthcare connection stays. Your Tebra, Kareo, AdvancedMD, NextGen, Athena, or Cerner billing module stays. We work with what you've got. No stack swap.
- Renewal of payer rules and CARC/RARC dictionaries. We keep them current. Code set changes don't become your problem.
- On-call response. When the 835 feed breaks at 6am the morning of a payer-deadline appeal, we're who answers. Not your IT generalist. Not a tier-1 ticket queue.
- Single team across build and operation. The same engineers who built it run it.
You don't add headcount to operate this. That's the point.
Why this isn't a “denial management AI” black box
You've seen the pitch. So has every operator on r/CodingandBilling. Optum bought a dozen of them. Tebra ships its own. None of them earned the trust of the people doing the work, because they all do the same thing: hand you a confidence score and ask you to trust the model.
Inevi shows its work.
Every denial classification carries:
- The source 835 line items. Specific segments. CARC/RARC codes verbatim. No paraphrase.
- The model's reasoning. Why this claim got classified as workflow-driven instead of payer-policy. Which prior denial pattern this matches. What the firm's SOP says to do here.
- The recommended action. The exact appeal language, the exact CARC/RARC codes to assert, the exact supporting docs to attach, the exact appeal level to file at, the exact deadline.
- The supporting evidence. Pulled from the chart, pulled from the prior ERAs, pulled from the payer's published policy. Cited. Linked. Reviewable.
- The human who signed off. And when. And what they edited.
If your specialist disagrees with the classification, they override it. Two clicks. The override gets logged with the reason. The model learns from that override on the next training cycle. Your firm's judgment is the ground truth, not the vendor's.
You can't audit a black-box AI. You can audit this one.
What you can verify
Trust isn't a sentence. It's a list of artifacts your compliance team and your clients' compliance teams can actually inspect.
Founder credentials
- Costa Papanikolaou, COO. Computer Science, McGill. Builds the agentic-AI architecture.
- Dimitrios Papanikolaou, CEO. Computer Science, McGill. Built the operational systems for a manufacturing company entering the Canadian market from zero.
- Inevi Solutions Inc., incorporated Quebec 2025, principal office Montreal.
BAA architecture
The BAA we'll execute with you covers data handling, breach notification, audit access, and sub-processor obligations, signed in week 1 before any PHI touches the system. Encryption in transit (TLS 1.2+) and at rest (AES-256). Scoped connectors per integration, so your clearinghouse credential doesn't become a blanket cloud service account. PHI segregation per client tenant. Documented breach-notification protocol that meets HIPAA's 60-day timeline.
Governance and audit log
Every read, write, classification, and human override is logged. Exportable in your format. Retained per your retention policy, not ours.
Liability scoped in the MSA
Final responsibility for appeal substance, code decisions, and payer-facing communication stays with your licensed staff. Inevi's responsibility scope is documented in the engagement agreement before launch. Not buried, not generic.
Classification transparency
Every model decision is reproducible from the same input. Every prompt, every reasoning chain, every retrieval citation is logged. There's no “trust the AI.” There's only “review the work the AI showed you.”
FAQ
How do we audit the AI's denial classifications?
Every classification is logged with the source 835 segments, the CARC/RARC codes, the model's reasoning chain, the retrieved evidence (prior denials, payer policy citations, your firm's SOP entries), and the human who signed off. You can replay any classification, see exactly what the model saw, and see what your specialist did with it. Audit logs export in CSV, JSON, or whatever format your compliance team prefers. Retention follows your policy.
What's the false-positive rate, and how is it measured?
We measure two failure modes separately. Misclassification: the system says 'workflow-driven' but it was actually payer-policy, or vice versa. Missed appealability: the system says 'not appealable' on a denial that actually was. Both are tracked per payer, per CPT, per CARC pattern, and per specialist sign-off. The rates are visible in your dashboard, audited weekly during the first 90 days post-launch, and feed back into the SOP refinement cycle. We don't publish a default accuracy number because the rate depends on your payer mix, your CPT distribution, and how complete your firm's SOP capture is at onboarding. The free assessment establishes a baseline expectation specific to your book.
Can we override the classification, and does the system learn from that?
Yes. Two clicks to override. The override carries a reason code (your specialist picks from a short list, or types one). The override is logged with the specialist's name, timestamp, and the original classification. On the next SOP-refinement cycle (monthly by default, configurable), overrides feed into the model's grounding. Your firm's judgment is the ground truth.
What happens when a payer policy changes?
Two things. First, our payer-rules layer ingests the published change (CMS bulletins, payer provider portal updates, scraped fee schedule revisions per BAA-permitted sources) and updates the classification logic. Second, your specialists see a 'policy change detected' flag on any denial that hits the changed rule, with a side-by-side of the old policy and the new one, so the appeal narrative can address it. We don't silently change the classification logic underneath you.
What's the BAA timeline?
The BAA we'll execute with you is negotiated and signed in week 1, before any PHI touches the system. It covers data handling, breach notification (HIPAA's 60-day timeline), audit access, subprocessor disclosure, termination obligations, and PHI return/destruction. If your legal team has redlines, we run them. Operators have told us repeatedly they won't review even discovery materials without one, so we move on the BAA early.
How do you handle PHI in the appeal packets?
Appeal packets contain only the PHI required by the payer for the specific appeal level being filed. We don't bulk-transmit chart data. We pull the specific CPTs, ICD-10s, the relevant clinical narrative excerpt (per scoped chart-access), the prior auth reference (when applicable), and the explanation-of-benefits citations. The packet generation runs inside the BAA-scoped environment. Outbound transmission goes through your clearinghouse or your existing payer portal credentials, not Inevi's. PHI doesn't leave your environment for any reason that isn't documented in the BAA's permitted-purposes section.
What stays in our existing EMR billing module?
Everything that should. Patient demographics, charge entry, claim creation, claim submission to the clearinghouse, ERA posting (the parts your EMR posts correctly), AR aging, patient statements. We don't replicate your EMR. We sit alongside it. The denial worklist and the appeal-packet generation run in our operating layer because those are the parts your EMR is provably bad at. When an appeal is filed and the payer responds, the disposition writes back to your EMR via the same integration surface your EMR exposes to your clearinghouse today.
Can we keep our existing clearinghouse?
Yes. Availity, Trizetto, Change Healthcare, Office Ally, whatever you're on. We integrate at the 835/ERA receive layer and at whatever submission layer your clearinghouse exposes (SFTP, API, direct portal). If you're between clearinghouses or considering a switch, we'll make the operating layer clearinghouse-agnostic so the switch doesn't trigger a re-implementation. We don't sell a clearinghouse. We don't take referral fees from one. We're stack-neutral.
Book the free assessment
A 60 to 90 minute working session. We map your current denial volume, your current appeal recovery rate, your specialist hours per denial, your clearinghouse and EMR setup, and the SOPs that already live in your senior specialists' heads. You walk out with a written scope, a fixed-price proposal, and a 4-week build timeline. No obligation to proceed.
Book the free assessmentComparing Inevi against another vendor?
See how we frame the build-vs-buy question against the platforms operators are evaluating today.
The next engagement asks
who builds it. Have an answer.
Thirty minutes. No deck. No pitch. A real conversation about the engagement you're running, the gap you're feeling, and whether we can close it. If we can't, we'll say so.
team@inevisolutions.com