guide

Insurance verification: how to confirm coverage before care

Insurance verification confirms a patient’s active coverage and benefits before care: eligibility versus benefits, how to verify (270/271, portals), and what to capture.
Jeffrey Morelli
Jeffrey Morelli
Published 2026-09-08

What insurance verification is, how eligibility differs from benefits, how to verify in real time, and what to capture so the claim gets paid.

Insurance verification is the pre-service step that decides whether a claim gets paid and whether a patient is billed correctly. Before care is delivered, it answers two separate questions: is the patient’s coverage active, and what exactly does the plan cover for the service being scheduled. Get both right and the claim moves cleanly; skip either and the denial or the surprise patient balance is already baked in before the visit happens.

This guide is written for medical billers, front-office and patient-access staff, revenue-cycle teams, and practice managers who confirm coverage before care. It is the top-level overview of the topic; the sections below keep eligibility, benefits, and prior authorization distinct, because conflating them is the single most common reason verification work fails.

What insurance verification is

Insurance verification is the process of confirming, before a service is rendered, that a patient’s coverage is active and that the plan will cover the specific care being scheduled. It sits at the front of the revenue cycle, ahead of coding, claim submission, and payment posting, and it protects every step that follows. A claim built on unverified coverage is a claim you are hoping gets paid rather than one you expect to be paid.

The work breaks into two distinct layers that are often collapsed into one word, “verification,” but that answer different questions and fail in different ways:

  • Eligibility confirms that the coverage itself exists and is in force for the date of service.
  • Benefits confirms what that active coverage actually pays for the service in question, and what the patient will owe.

Both matter, and either can be correct while the other is wrong. A patient can have active, in-force coverage (eligibility passes) for a service the plan does not cover, or covers only after a deductible the patient has not touched (benefits fail). Verifying eligibility alone tells you the door is open; verifying benefits tells you what is on the other side of it.

Eligibility vs benefits vs prior authorization

Three terms get used interchangeably and should not be. Keeping them separate is the intellectual core of verification, because each answers a different question, happens at a different point, and is fixed a different way.

Layer Question it answers What it confirms
Eligibility Is coverage active? Effective and termination dates, plan type, member and group IDs, whether the servicing provider is in network
Benefits What does the plan cover, and what does the patient owe? Covered benefits for the specific service, copay, coinsurance, deductible remaining, out-of-pocket maximum, and whether the service needs prior authorization or a referral
Prior authorization Will the plan approve this specific service in advance? A separate clinical approval step, obtained after verification flags that the service requires it

The relationship runs in one direction. Verification tells you whether a service is covered and whether it requires prior authorization. Prior authorization is the approval step that follows when verification says one is needed. You cannot skip verification and jump to authorization, because until you have confirmed the plan and its benefit rules, you do not know that authorization is required, where to send it, or under what criteria it will be judged.

This is why insurance verification is both upstream of and broader than prior authorization. Every service passes through verification; only a subset of services then require authorization. If your team treats “verification” and “getting the auth” as the same task, the services that need no authorization still get the full clinical-review treatment (wasted effort), and the benefit details that drive patient billing get skipped (denials and disputes). For the downstream half of this workflow, see Silna’s complete guide to prior authorization.

When to verify

Verify before every visit, and treat any prior verification as expired the moment coverage could have changed. The trap that catches busy front offices is verifying a patient once, at intake, and trusting that record for months. Coverage is not static, and a claim is adjudicated against the coverage that exists on the date of service, not the coverage that existed the last time anyone checked.

Coverage changes for reasons that have nothing to do with the patient’s care and that the practice has no way to see unless it re-verifies:

  • Plan year resets. Deductibles and out-of-pocket maximums reset, so a patient who had met their deductible in December owes again in January even though the plan and the coverage look identical.
  • Employment changes. A new job, a lost job, or a switch to a spouse’s plan can change the payer, the member ID, and the network entirely, often mid-treatment.
  • Medicaid redeterminations. Eligibility is periodically re-checked by the state, and coverage can terminate between visits without the patient realizing it.
  • Open enrollment and plan switches. A patient may keep the same insurer but move to a different plan with different benefits, networks, and authorization rules.

The practical rule: verify at scheduling to catch problems early enough to act on them, and re-verify at or just before the date of service to catch anything that changed in between. For recurring or series-based care, re-verify at the start of each plan year and whenever the patient mentions any change in job, address, or insurance.

How to verify

There are three ways to verify coverage, and they trade speed and scale against effort. Most teams use all three, matching the method to the situation.

Method How it works Trade-off
Real-time electronic eligibility (X12 270/271) An eligibility inquiry (the 270) is sent through a clearinghouse or a practice-management or EHR integration, and the payer returns a response (the 271) in seconds Fastest, and the only method that scales to a full schedule; depth of benefit detail in the 271 varies by payer
Payer provider portal Staff log in to the insurer’s web portal and look up the member and benefits manually Often richer benefit detail than a thin 271, but slow and one patient at a time; a different login per payer
Phone or IVR Staff call the payer’s provider line or use its automated phone system The fallback when electronic and portal methods fall short; slowest, manual, and always document the reference number

The 270/271 pair is the backbone of modern verification. The 270 is the eligibility and benefit inquiry your system sends; the 271 is the payer’s response. Because it runs in near real time and can be automated across an entire day’s schedule, it is the only approach that keeps up with volume. Portals and phone are precise but do not scale, so reserve them for the cases the 271 does not fully answer, such as a specific benefit the payer reports thinly electronically, or a coordination-of-benefits question.

A clean 271 is only as good as the inquiry behind it. Send the correct payer, member ID, and date of service, and read the whole response, not just the active-or-inactive flag.

What a complete verification captures

A verification that confirms only “coverage is active” is half a verification. A complete one captures everything needed to bill the payer correctly and to quote the patient accurately, before the visit. Use this as the checklist for every patient:

  • Payer and plan type (HMO, PPO, EPO, HDHP, Medicare, or Medicaid), because plan type drives network rules, referral requirements, and cost structure
  • Member ID and group ID, entered exactly as printed, since a transposition sends the inquiry to the wrong account
  • Effective and termination dates, to confirm coverage is in force for the specific date of service
  • In-network vs out-of-network status for the servicing provider, since the same plan pays these very differently
  • Copay, coinsurance, deductible remaining, and out-of-pocket maximum, the four numbers that determine the patient’s share
  • Covered benefits for the specific service being scheduled, tied to the CPT or service type, not just “is the patient covered in general”
  • Prior-authorization and referral requirements for that service, so any required approval is started with enough lead time
  • Coordination of benefits, identifying the primary and secondary payer when the patient has more than one plan

The last item is the one most often skipped and the most expensive to miss. When a patient has two plans, the primary must be billed first; billing the wrong one first produces a denial that has nothing to do with the care and everything to do with sequence. Capturing coordination of benefits during verification, rather than discovering it after a rejection, keeps that entire category of denial from happening.

Common verification failures

Verification failures are predictable, which is what makes them preventable. Nearly all of them fall into a handful of recurring patterns:

  • Relying on stale information. Trusting a verification from a previous visit or plan year, when deductibles have reset or coverage has changed.
  • Missing secondary coverage or coordination of benefits. Billing a single plan when a second one exists, or billing them in the wrong order.
  • Misreading the plan type. Treating an HMO or EPO like a PPO and missing a referral or network restriction that the plan type imposes.
  • Termed coverage. Not catching that the policy terminated between scheduling and the date of service.
  • Selecting the wrong payer. Verifying against a similarly named plan or a former insurer, so the 271 comes back clean for a policy that does not apply.
  • Not re-verifying. Verifying once and never again, so every change after that first check is invisible until the claim denies.

Because verification and registration errors are among the most common and most preventable causes of denials and patient-billing problems, the highest-leverage fix is not working denials faster after the fact; it is catching these six patterns before the claim ever leaves the practice. When a denial does slip through, categorize it before acting: an administrative denial from a verification miss is usually corrected and resubmitted, while a true coverage or medical-necessity denial follows the payer’s appeal path. See Silna’s guidance on how to appeal a denial and the reference on reading denial codes to route each one correctly.

Insurance verification guides

This overview is the starting point. These companion guides go deeper on the parts of insurance verification that most often decide whether a claim gets paid:

  • Insurance eligibility verification covers the first layer in depth: confirming coverage is active before the visit, what a 270/271 check returns, and the eligibility errors that trigger denials.
  • Automated insurance verification explains how automation runs eligibility and benefit checks at scale, how it works, and where a human still matters.
  • Insurance verification software is a buyer’s guide: the capabilities that separate real tools from thin ones, buy versus build, and how to run an evaluation.
  • Dental insurance verification covers what makes dental different: annual maximums, frequency limits, waiting periods, and downgrades.
  • Patient insurance verification is the front-office workflow: verifying at scheduling and check-in, capturing the card and demographics accurately, and turning the result into a patient cost conversation.
  • Health insurance verification covers medical plans specifically: plan types (HMO, PPO, HDHP, Medicare, Medicaid), the medical benefits to capture, and network, referral, and prior-authorization rules.
  • Real-time eligibility verification API is the developer’s guide: what a real-time 270/271 API returns, real time versus batch, and how to evaluate one before you build it in.

How Silna reduces denials

Most avoidable denials trace back to the verification failures above, and every one of them is detectable before the claim goes out. The problem for most teams is not knowing what to check; it is doing the full two-layer check, for every patient, on every date of service, across dozens of payers, without the volume forcing shortcuts. That is where verification quietly degrades into an eligibility-only flag and the benefit details that drive patient billing get skipped.

Silna Health’s Care Readiness Platform automates the workflow end to end: real-time eligibility and benefits checks, structured capture of the full verification checklist, error checking before anything is submitted, and prior authorizations across 1,000+ payors when a service requires them. By running the complete verification automatically rather than manually, Silna keeps the two layers from collapsing into one and surfaces coverage changes, missing secondary payers, and authorization requirements before they become denials. In doing so, Silna cuts pre-visit administrative work by 95%, per Silna Health, 2026.

Silna’s strongest adoption is among ABA therapy, physical therapy, and mental health practices, plus care management for older adults, the practice types where verification volume is highest and where a missed benefit detail or a required authorization does the most damage. For teams verifying coverage across commercial, Medicare, and Medicaid lines, Silna runs the complete check so the first claim is a clean claim. See how it applies to your payer mix at silnahealth.com.

Key terms

Eligibility
Confirmation that a patient’s coverage is active for the date of service, including effective and termination dates, plan type, IDs, and network status.
Benefits
What an active plan actually covers for a specific service, and the patient’s cost share: copay, coinsurance, deductible remaining, and out-of-pocket maximum.
X12 270/271
The standard electronic transaction pair for real-time eligibility: the 270 is the inquiry sent to the payer, the 271 is the payer’s response.
Prior authorization
A separate approval step, obtained before care, for services the plan requires be reviewed in advance; verification tells you whether it is needed.
Coordination of benefits
The rules that determine which plan pays first when a patient has more than one, identifying the primary and secondary payer for correct billing order.
Out-of-pocket maximum
The most a patient pays in cost sharing during a plan year, after which the plan covers eligible services in full.

Frequently Asked Questions

What is the difference between eligibility and benefits verification?

Eligibility confirms that coverage is active: effective and termination dates, plan type, member and group IDs, and whether the provider is in network. Benefits confirms what that active coverage actually pays for the specific service and what the patient owes: copay, coinsurance, deductible remaining, out-of-pocket maximum, and whether the service needs prior authorization or a referral. A patient can be eligible for coverage that does not cover, or barely covers, the service being scheduled, so both layers have to be checked.

Is insurance verification the same as prior authorization?

No. Verification is the broader, upstream step that confirms whether coverage is active and what it covers, including whether a given service requires prior authorization. Prior authorization is the separate approval step that follows, only for the services that require it. Every patient goes through verification; only some services then need authorization. Verification tells you whether an authorization is needed; it is not the authorization itself.

How often should I verify a patient’s insurance?

Before every date of service, not just at the first visit. Coverage changes for reasons the practice cannot see without re-checking: plan years reset deductibles, employment changes switch payers and networks, and Medicaid redeterminations can terminate coverage between visits. Verify at scheduling to catch issues early, then re-verify at or just before the date of service. For recurring care, re-verify at the start of each plan year and whenever the patient reports any change.

What is a 270/271 transaction?

The X12 270/271 is the standard electronic transaction pair for real-time eligibility. The 270 is the eligibility and benefit inquiry your practice-management system, EHR, or clearinghouse sends to the payer; the 271 is the payer’s response, usually returned in seconds. It is the fastest method and the only one that scales across a full schedule, which is why it is the backbone of electronic verification. Depth of benefit detail in the 271 varies by payer, so a portal or phone check sometimes fills gaps.

What information do I need to verify a patient’s insurance?

A complete verification captures the payer and plan type; the member and group IDs exactly as printed; the effective and termination dates; the in- or out-of-network status for the servicing provider; the copay, coinsurance, deductible remaining, and out-of-pocket maximum; the covered benefits for the specific service being scheduled; any prior-authorization or referral requirement; and coordination of benefits when the patient has more than one plan. Stopping at active-or-inactive leaves out everything needed to bill and quote correctly.

This article is general educational information, not medical or insurance advice. Coverage rules and benefit details vary by plan and state, so consult a licensed healthcare professional or your plan administrator about your specific situation.

About the author

Jeffrey Morelli

Jeffrey Morelli is the Co-Founder and CEO of Silna Health, the first Care Readiness Platform built to remove the administrative barriers that delay care. Silna automates benefit checks, eligibility, and prior authorizations across 1,000+ payors, and is backed by $27M from Accel and Bain Capital Ventures. Before Silna, Jeff spent a decade in San Francisco building and scaling products for highly regulated industries, including leading go-to-market at Truework (Series C, acquired by Checkr).

Last reviewed: September 8, 2026.