AI Medical Coding Software: Audit Trails and Upcoding Risk

Check three things before you use AI medical coding software: whether it only suggests codes or submits them without review, whether every suggestion leaves an audit trail you can read, and which named clinician or certified coder signs the final codes. Responsibility for the claim stays with your practice, and the vendor must sign a business associate agreement (BAA).

The temptation is to judge these tools by a headline accuracy figure. A figure measured on the vendor's own test charts tells you little about your notes. A better test is whether a wrong suggestion would be caught before a claim goes out, and whether you could later show a payer who looked at what.

Follow me on Instagram@sagnikteaches

Three modes that look the same on a feature page

Vendors use different words, but coding tools fall into three modes. The mode determines almost everything else about risk.

Connect on LinkedInSagnik Bhattacharya

The examples are vendor descriptions, quoted as claims, and the vendors' pages are the place to check current features. The point for a small practice is that the same vendor can sell two modes, and the contract you sign decides which one you get. Ask which mode is switched on by default and who can switch it.

Subscribe on YouTube@sagnikteaches

Which mode suits a small practice

A practice with a handful of clinicians and a part-time coder should start in suggestion mode and keep it there for the first quarter. Autonomous coding is built for volume: millions of charts, narrow code sets, a coding department that can audit samples. A practice sending 800 claims a month rarely has the volume to justify it and has little capacity to audit the sample that a safe autonomous set-up needs.

Who signs off, and what sign-off means

The software never signs. A person does, and that person must be able to say what they checked. Decide this before the trial, because the arrangement differs by workflow.

• Clinician codes their own visits. The clinician accepts or changes each suggestion at the point of signing the note. Their name is on the documentation and the code, so they must be able to see which words in the note support each code.
• A coder works from signed notes. The coder accepts or overrides each suggestion and records the reason when they override. The clinician is queried if the documentation does not support the code.
• An outside billing company codes for you. Your contract should say that the company, not the software, owns the final code, that it keeps the audit log, and that it will give you the log on request.

Whichever applies, write one sentence in the procedure: "No claim is released until [named role] has accepted the final codes." If a software setting lets claims bypass that step, switch it off, or leave the feature unused.

Upcoding: how AI makes it easy without anyone intending it

Upcoding means billing a higher-paying code than the service documented supports. Few practices set out to do it. The risk with AI is drift. A tool trained to find every billable element can suggest a level that the note technically justifies but the visit did not warrant. A scribe that writes fuller notes can lift suggested levels because the documentation looks longer, not because more was done.

Look for these patterns in the first month:

• A rising share of the higher-level visit codes, with no change in patient mix.
• Diagnosis codes added that nobody discussed, picked up from problem lists or earlier notes.
• Time-based codes suggested from a recording length rather than from the clinician's time.
• Copied-forward text counted as current examination or history.

An illustrative level-mix check

Suppose a six-clinician practice counted its established-patient visit levels over three months before and after adding a coding suggestion tool.

The figures are invented, but the question is real: nine percentage points moved to 99214. Maybe the new scribe finally captured work clinicians were already doing; maybe the tool inflates. You cannot tell from the shift, which is why the next step is a sample. Pull 30 of the new 99214s, ask the coder and one clinician to review each against the documentation, and count how many were supported. If 27 or more are, the drift is probably better documentation. If 20 are, stop and fix the settings before the next claim run.

What the audit trail must record

An audit trail is the answer to a payer who asks how a code was chosen. Check that the software records the following for every coded encounter, and that you can export it without asking the vendor.

MediCodio's page describes codes landing with the note passage that justifies them; whatever tool you use, ask to see that on a real chart of yours, not a demonstration note. A trail that stores only the final code is a log of outcomes, not of decisions.

Retention and access

Ask how long the trail is kept and in what format. Payers can look back across years, so one that disappears on cancellation is a risk. Put the following into the contract: export on request in a readable format, retention at least as long as your own records policy, and written notice before any deletion.

A trial on 100 old charts

Before any live claim, test the software on charts that have already been coded and paid, with the patient identifiers removed or under a signed BAA. A reliable test takes one coder about two working days.

1. Choose 100 completed encounters across your common visit types: 60 routine, 25 complex, 15 unusual.
2. Have your best coder re-code them blind, and an independent person resolve disagreements to create a reference set.
3. Run the software on the same charts in suggestion mode.
4. Compare, code by code, and count five things: exact matches, over-coded (higher than reference), under-coded, unsupported (no evidence in the note) and missed.
5. Repeat with a different 100 in month two, after any settings change.

An illustrative result: 100 charts, 61 exact matches, 14 over-coded, 18 under-coded, 7 with an unsupported code. The vendor might call that 61 percent. A better reading is that 14 over-coded charts, if submitted unchecked, would be 14 claims at a higher level than the documentation supports. That is the number to take to the compliance conversation. Under-coding is not harmless either: it loses legitimate payment and means the record misdescribes what was done.

Three errors a suggestion tool makes and how a reviewer catches them

Examples help more than rules. These are illustrative, but each reflects a kind of mistake that coding tools and human coders both make, and each shows what a reviewer should look for.

A negated symptom coded as present

Note text: "No chest pain, no palpitations. Breathless on stairs for three weeks." A weak tool picks up "chest pain" and proposes a chest pain code alongside the breathlessness. The coder checks the cited passage, sees the negation and rejects it. The audit log should show the rejection and the reason, because a pattern of rejected negations tells you the tool needs different settings or a different vendor.

A family history coded as a current condition

Note text: "Mother had breast cancer at 52. Routine review, no breast symptoms." A suggestion tool proposes a malignancy code. The correct handling is a family-history code, since nothing in the note says the patient has the disease. This is the kind of error that raises both the claim value and the risk, so check any suggested malignancy code against the passage it cites.

A suspected diagnosis coded as confirmed

Note text: "Possible early diabetic nephropathy, awaiting repeat urine test." In an outpatient setting, uncertain diagnoses such as "possible" or "probable" are generally not coded as established; the symptoms or findings are coded instead, under the coding guidelines your coder follows. A tool that jumps to the diabetes-with-kidney-complication code overstates the visit. Ask the vendor how its rules treat uncertainty words, and test it with five notes that use them.

A supported code, correctly accepted

Not every suggestion is wrong, and the reviewer should be quick on the good ones. Note text: "Type 2 diabetes with hyperglycaemia, HbA1c 9.2 percent. CKD stage 3 due to diabetes. Metformin continued, glargine increased." A suggestion of the type 2 diabetes with hyperglycaemia code, plus the type 2 diabetes with diabetic chronic kidney disease code and a stage 3 kidney disease code, is supported by named words in the note. The coder accepts them in seconds, and the log records one click and the cited passage.

The sums for a billing company with 800 claims a month

Illustration: an outside billing company handling 800 claims a month for three practices. A coder takes about six minutes a claim now. In suggestion mode, including checking each cited passage, assume three and a half minutes. Valuing coder time at $35 an hour (an assumption; use your own), the figures run as follows.

• Now: 800 x 6 minutes = 4,800 minutes, or 80 hours, which is $2,800 a month.
• With suggestions: 800 x 3.5 = 2,800 minutes, or 46.7 hours, $1,633 a month.
• Saving: 33.3 hours, about $1,167 a month, before the software price.
• Audit sample: 5 percent of claims, 40 charts, at 12 minutes each by a second coder is 8 hours, $280 a month.

The saving after the sample is about $887 a month. If the software costs $600 a month, the net is $287, which is thin. It improves only if volume rises or the sample can shrink once the error rate is proven. The sum also shows why the audit is not optional overhead: it takes $280 of the $1,167 gross saving, about a quarter. Drop it and you have a cheaper process that nobody can defend. Run the sum with your own volume and rates, and ask the vendor what the price is at your volume, not at theirs.

Questions for the vendor demonstration

Bring a real, de-identified note, not their sample. Then ask each question and write down the answer.

1. Which mode is on by default, and can a user release claims without review?
2. Show me the audit trail for this chart, and export it now.
3. How does your tool treat negations, family history and "possible" diagnoses?
4. How often are your code rules updated, and how do I see which version coded a chart?
5. What does your accuracy figure measure, on whose charts, and how recently?
6. Do you train models on our notes, and will you say so in the contract?
7. What happens to our data and logs when we leave?

A vendor who answers these plainly, and shows a cited passage without being asked, is worth a trial. One who offers a percentage and a testimonial in place of an export is telling you what the audit will be like.

Keeping the incentives honest

Judge software and staff on agreement with documentation, not on revenue per visit. A scorecard that rewards a higher average code level will produce one. A better scorecard for the first six months:

• Percentage of sampled claims where the code was supported by the note.
• Over-coded and under-coded rates reported separately.
• Number of override reasons recorded.
• Clinician queries opened and resolved.
• Days from visit to clean claim.

Report these to the person responsible for compliance, not only to the person who owns the revenue. If the same person owns both, ask an outside adviser to look at a sample twice a year.

An AI second look that does not push the code upwards

If you use a general assistant to double-check a code, build the neutrality into the prompt, and only use it with notes that have no patient identifiers unless your vendor has signed a BAA.

Below is an anonymised visit note and the code the coder chose.
List, in two columns, the documentation that supports the code and
anything the code requires that the note does not show.
Do not suggest a different code. If you are unsure, say so.

Illustrative output: "Supports: two chronic conditions addressed, medication adjusted. Not shown: the total time or the level of data reviewed. Unsure whether the second condition was assessed, or only listed." What you do with it: ask the clinician about the second condition. The prompt asks for gaps, not a bigger code, and that is what keeps it on the compliance side.

Payer and compliance exposure, in plain terms

When a payer audits, it reviews claims against notes. Errors typically lead to repayment demands covering a sample extended across a period, and a pattern of unsupported higher codes can invite deeper review. Deliberate or reckless patterns carry legal liability, and the rules vary by payer and jurisdiction, so ask a qualified compliance adviser what applies to you. For a practice, the sensible stance is that software does not change who is accountable, and that evidence of checking is protection.

A short list of what to do before the first live claim:

• Name the sign-off role in writing.
• Run the 100-chart trial and keep the results.
• Switch off any release without review.
• Agree a sampling plan: for example 20 charts per clinician each quarter.
• Check the BAA, subprocessors, retention and export terms.

The BAA and the contract clauses that matter

Coding software reads notes and claims, so it handles patient information. A BAA is the minimum. Beyond it, look for four clauses: the vendor may not train its models on your charts without written permission; subprocessors are listed and you are told about changes; audit logs are yours and exportable; and the vendor explains in writing what happens to your data when the contract ends. If the vendor refuses a BAA, that settles the matter. The vendor-security questions in the scribe security tutorial apply almost word for word.

Where it fits in the wider billing workflow

Coding is one step between the visit and the payment. If the real problem is denials, scrubbing or slow follow-up, a different tool may help more; see the best AI tool for medical billing by job and what AI can do in billing and coding and what still needs a human. For a clinic with fast visits and a scribe, urgent care notes and coding checks covers the interplay. And the note errors checklist explains why a code is only as sound as the note beneath it.

If you would like help designing the trial and the sampling plan, that is what my AI implementation consultation covers.

Questions practices and billing companies ask

Who is responsible if AI picks the wrong code?

The practice or billing entity that submits the claim. A vendor contract may share cost in some cases, but payers and regulators look at who submitted the claim and who attested the documentation. Treat the software as a tool whose output a named person approves.

Is autonomous coding ever acceptable?

It can be reasonable for narrow, high-volume, low-complexity work with a measured error rate and routine sampled audits. It is a poor first step for a small practice. Start with suggestion mode, measure, then consider autonomy for specific note types only.

Can an AI scribe also suggest codes?

Some do. Freed's Premier plan lists ICD-10 and CPT coding support, and Heidi's Clinician plan lists billing-code support routines. Treat those as suggestions to check against documentation, not as coding decisions.

What error rate is acceptable?

Set it before the trial, by code family, and make over-coding count more heavily than under-coding. A vendor's headline accuracy figure is a claim about its own test set, not about your notes. Measure on your own charts.

Do I need a BAA for coding software?

Yes if the software processes notes or claims containing patient information. Get the agreement signed before any real chart is uploaded, and ask for the list of subprocessors and the data-retention terms.

Further reads

• What to Ask Before Buying Any AI Tool for a Medical Practice — General questions to put to any medical AI vendor.
• AI Solutions for Medical Practices: Build, Buy or Hire Help? — Compare buying software with outsourcing or hiring a coder.
• AI Chatbot for Healthcare: A Small Clinic's Data and Consent Checklist — Data and consent checks for patient-facing tools.
• Is an AI Scribe Worth It for a Small Private Clinic? — Whether a scribe that also suggests codes pays back.
• AI Platform for Doctors: One Suite or Separate Scribe and Phone Tools? — Choosing between a bundled platform and single tools.
• Do Small Medical Practices Need an AI Consultant? — Whether a small practice needs outside help on AI at all.
• AI Claim Scrubber: What It Catches and What It Misses — Modifier, bundling and diagnosis edits are caught; eligibility, documentation and fresh payer rules often are not. Test one on 50 claims.
• AI Tools for Medical Practices: A Stack for Three Doctors and Four Staff — The first three AI tools for a seven-person practice, scribe, phones and billing checks, with list prices, a monthly total and what to check first.
• AI Tools for Physicians: Seven Worth Paying For in Private Practice — Seven AI tools for a private-practice physician, scribes, clinical assistants, phones and claim checks, with what each does and what to verify.
• ChatGPT for Medical Billing: Appeals and Claim Checks Without PHI — A redaction method, appeal and claim-check prompts, and the review step that lets a billing team use ChatGPT without pasting patient data.
• Medical Billing Proposal: Draft Practice Quotes With AI — Draft a medical billing proposal with AI: percentage vs flat-fee pricing, a scope table, an onboarding timeline and a fully worked quote.
• Using AI for Medical Billing: Spot Missed Charges From Visit Notes — A weekly reconciliation that finds delivered-but-unbilled services, with the spreadsheet step, the AI step and the owner's review.
• AI for Medical Billing Companies: Seven Jobs to Automate First — Seven jobs for a medical billing company to automate first, ranked by risk, with sample prompts, a worked denial-letter example and the human checks each needs.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Freed and Heidi pricing and plan pages, Fathom and MediCodio product pages (vendor claims quoted as claims), and the official ICD-10-CM coding guidelines for the outpatient uncertain-diagnosis rule, checked 4 November 2026.