AI Insurance Verification Clerk: Tasks, Limits and Switch Plan

What an insurance verification clerk actually does all day

In most clinics, hospitals and therapy practices, the verification clerk works from a daily list. The list is the next day's bookings, plus any visits in the coming week that have not been checked yet. The job sounds like one task, checking insurance, but it is really a chain of small steps, and each step can stall the next one.

A typical day, as clerks describe it, covers these tasks:

• Pull the appointment list for the next one to five working days from the scheduling system.
• Confirm that each patient's policy is active on the date of service.
• Log in to each payer portal, or run an electronic eligibility request, and read the answer.
• Record the copay, deductible, coinsurance, visit limits and whether the provider is in network.
• Save the payer's reference number or trace number against the appointment.
• Find out whether the service needs a referral or a prior authorisation, and get the number from the referring office.
• Phone the payer when the portal gives no usable answer, and wait on hold.
• Submit prior authorisation requests with the documents the payer asks for.
• Chase requests that are still pending close to the appointment date.
• Tell the front desk or the patient what they are likely to owe, and log any denial for billing or clinical review.

Two details matter when you look at your own team's work. First, the verification step is usually repeated. A patient who reschedules, changes employer or adds a second policy needs the check run again. Second, the hold-time and portal-login steps take more of the day than the reading and recording. Many owners find that the clerk's real skill is knowing which payer needs a phone call and which one answers in the portal.

The scale of this work is large in the United States, where prior authorisation is common. The American Medical Association's 2024 physician survey, published on its own site, reported that practices complete about 39 prior authorisation requests per physician each week, and that physicians and their staff spend around 13 hours on them. Those are survey averages for physician practices, not a benchmark for your business, but they show why the work is worth measuring.

Which of those tasks an AI worker takes over, task by task

An AI worker can own the repeatable part of this chain. It does not replace the payer. It runs the checks, reads the answers and writes them into the right record, then tells a person about anything it could not finish. To do this, it needs four things connected before it touches a single patient.

The first is access to the scheduling or practice management system, or the electronic health record, so it can read the bookings and write results back to each appointment. Some verification tools, such as Waystar and pVerify, are built to write into common practice systems. Others, such as Stedi, are developer-focused programmable clearinghouses that return structured data for a team to connect. The choice depends on which system you already run, so the audit starts with that question.

The second is the electronic eligibility route. In the United States, the standard electronic request is called a 270 and the reply a 271. A 271 reply often carries only a few fields, which is why many teams add portal checks for the rest. Availity is a widely used portal and clearinghouse in the US market. Some tools also read payer portals directly, which fills in the copay and visit-limit details the standard reply leaves out. Outside the US, the same idea applies through each country's insurer or claims portal, and the worker needs the right login for each one.

The third is a secure place for credentials and documents. Portal logins should sit in a password vault, not in a spreadsheet. Insurance card images and authorisation letters should go to the document store your practice already uses, with access limited to staff who need them.

The fourth is the inbox and the follow-up channel. Payers reply to the shared inbox or a fax line, and the worker can read the message, match it to the patient and update the tracker. Where your patients already reply on WhatsApp, the worker can send the copay note from there, but only to patients who have agreed to that channel. A spreadsheet tracker is enough for a small team that has no practice system to write to, with one row per pending authorisation, its date, and the next chase date.

Once those are connected, the worker handles the following without a person in the loop:

It builds the daily list, runs the electronic check for each booked patient and reads the reply. Where the reply is complete and the policy is active, it saves the benefit details and the reference number to the appointment, then marks the row as verified. Where the reply is incomplete, it moves to the portal for that payer. Where the portal is down or the payer only takes calls, it flags the row for a person, with a note on what it already found. It submits prior authorisation requests that a person has approved, attaches the documents listed in the request, and records the submission date. It chases pending requests on a schedule and logs each status change.

Some of the work is only partly automatable. Phone calls to payers are the hardest. Voice tools exist that call payers and navigate phone menus, and some vendors sell them, but the results depend on the payer and the call script. Treat phone verification as an exception queue until your own pilot shows how often it works for your payers.

What stays with a person, and why

Three things stay with people. The first is clinical need. Whether a scan, a course of physiotherapy or a drug is medically necessary is a judgement made by a qualified clinician. The worker can find that a payer requires a justification note, and it can gather the notes the clinician has already written. It should not write the medical reason, and it should not choose between two codes on its own.

The second is denials and appeals. A denial needs someone who can read the reason, check the chart, decide whether to appeal and sign the letter. Under the US Centers for Medicare and Medicaid Services' Interoperability and Prior Authorization Final Rule, known as CMS-0057-F, covered payers must give a specific reason for a denial from 2026 onwards. That helps the person reading the denial, but it does not make the appeal a machine task. The worker can sort denials by reason and deadline, which saves time. The decision to appeal stays with a person.

The third is anything that involves a patient's health information and a sign-off on what the patient will pay. In the European Union, health data is a special category under Article 9 of the General Data Protection Regulation. Processing it is prohibited unless a listed condition applies, and the processing still needs an ordinary lawful basis. Your organisation must decide which condition applies and who is accountable. A person should approve the rules the worker follows, and check the access logs. This explains the rule in general terms; it is not legal or tax advice for your case.

Relationships also stay with people. A senior clerk who knows a payer's contact by name can get a decision through in an afternoon. The worker cannot negotiate a one-off exception, and it should not be presented to payers as if it could.

How this role differs by business type

The task list is similar across settings, but the payers, the paperwork and the risk differ. The table below shows where the role changes most.

Practices with a small number of bookings a day can often run the check manually in under an hour. Automation starts to pay off where the same checks repeat across many patients and many payers.

How the switch happens, week by week

A switch that works keeps the current clerk in the chair, moves the repetitive part to the worker in stages, and narrows the clerk's job to review. The steps below assume a practice with one or two clerks and one practice management system. A larger group will run the same sequence per site or per payer group.

Weeks one and two: map the work

Write down the real steps your clerk takes for three typical days. Count the portal logins, the phone calls and the time spent on hold. List the payers that answer electronically and the ones that need a call. Pull a sample of last month's denials and sort them by reason. This is the baseline that the free audit reviews with you, and it is the only honest way to judge the result later.

Weeks three and four: connect read-only access

Give the worker read access to the schedule and a test login for one payer portal. Let it build the daily list and run checks, but write nothing to the patient record. The clerk compares the worker's answers with their own on the same bookings. Any mismatch goes into a log, and the cause is found before anything is written.

Weeks five to eight: write results, route exceptions

Turn on writing for the payers where the comparison matched. Every incomplete reply, portal outage or phone-only payer goes into an exception queue that the clerk clears each morning. The clerk still signs off on anything the patient will be charged for. Add one payer at a time, and keep the portal credentials in the vault throughout.

Weeks nine to twelve: move the clerk to review

When the exception queue is small and stable, the clerk's day shifts to reviewing the worker's output, handling denials and appeals, and calling the payers the worker cannot reach. If the change means fewer hours or a different role for the person, the notice, consultation and severance rules that apply where you operate must be followed, and any change should be agreed with the employee or checked with a lawyer first.

Risks and when not to automate this role

There are real risks. The first is portal change. A payer redesigns its portal, the worker's route breaks, and checks fail quietly unless someone watches the failure count. Set an alert for any day when the number of unverified rows rises sharply.

The second is wrong data written to a patient record. If the worker matches a reply to the wrong patient, a clinician may see the wrong coverage. Check identifiers, such as date of birth and member number, before any write, and keep the audit trail so each change can be traced.

The third is security. Portal logins and health data are high-value targets. Use role-based access, multi-factor login for staff, and a written list of who can see what. Ask any vendor where data is stored and who can access it.

Do not automate this role if your volume is low, if most of your payers accept only phone or paper requests, or if your clinical sign-off process is not written down. In those cases the work is better handled by a trained clerk with a good checklist, and the money is better spent on training and a shared tracker. The same applies when your team cannot yet say which tasks take the most time. Measure first.

Be clear about what the worker will never do. It will not decide that a treatment is needed, it will not negotiate with a payer's medical reviewer, and it will not agree to a patient payment plan without a person. Results depend on your own check volume, your payer mix and how clean your schedule data is, which the free audit measures from your figures.