River
Y CombinatorBacked by Y Combinator
FREE TEMPLATE

Group NPI Provider Addition Checklist

Two documents and three sheets that track each payer's own governing date for one addition, and hold every claim until that date actually clears.

Free download  ·  No account needed

Payer Requirement Register

One row per payer, never one blended date

Arrives blank. When a provider and a location are added together, most payers approve them on separate timelines, so the register holds both dates rather than one.

PayerProvider dateLocation dateGoverning date
    
    

Why one date column is not enough

The governing date for billing at the new location is the LATER of the provider-level and location-level dates. A column that blends them into one hides whichever date is actually still pending.

Remaining columns: Addition Type, Notification Required, Effective Date Policy, Notes.

Every result for this query states the same general rule: an enrollment's effective date is the later of the filing date and the date services began. 42 CFR 424.520(d) sets that rule, and it is written for a brand-new enrollment, not for one addition inside a group that is already live. None of the results address what happens when a new provider and a new location join that group together. Most payers approve those two additions on separate timelines, and the group's other providers keep billing normally throughout regardless.

So the Payer Requirement Register tracks a provider-level approval date and a location-level approval date as two separate fields per payer. The governing date for billing at the new location is the LATER of the two. A provider approved to bill under the group while the location is still pending is not billable there yet, and checking only the provider's approval produces a batch of denials weeks later. The Claim Hold List holds claims proactively for that window, before submission, and releases a row only once a payer confirms its own date in writing.

Fennimore Family Health added a physician and a satellite location on the same day, both effective 1 April. Two of its five payers were clean, notified ahead of time. The other three had a real gap: two set their date on approval, not the date of service, and one approved the provider 10 April but the location separately, 20 May. Billing every payer from the go-live date instead would have put 285 claims, $32,670, in front of a payer too early, and reading only the provider approval would have missed 28 of those clinic days.

One addition, five payers, one later date

The requirement register, the gap if billed on the go-live date instead, and the trap inside the Cascadia row specifically.

Payer Requirement Register

Illustrative rows for a fictional group, Fennimore Family Health, adding Dr. Elias Whitcombe and a new satellite location, both starting 1 April.

PayerProvider dateLocation dateGoverning dateStatus
Medicare1 Apr1 Apr1 AprClear
Brightpath Select1 Apr1 Apr1 AprClear
State Medicaid22 Apr22 Apr22 AprHeld 21d
Vantage Health5 May5 May5 MayHeld 34d
Cascadia Advantage10 Apr20 May20 MayHeld 49d

The Cascadia row is the one worth reading twice. Its provider approval landed 10 April, the shortest gap on the register read alone. Its location approval, a separate approval under the same contract, did not land until 20 May, and that later date is what actually governs, since Dr. Whitcombe sees patients only at the new site.

Medicare and Brightpath Select carry no gap because notification went out ahead of the 1 April start, inside each payer's own backdating terms.

What billing on the go-live date would have cost

Clinic days count weekdays only, from the 1 April start date to the day before each payer's own governing date.

PayerClinic daysClaimsAllowedAt risk
State Medicaid1560$74$4,440
Vantage Health24120$132$15,840
Cascadia Advantage35105$118$12,390
Total285$32,670

Medicare and Brightpath Select carry no row here, because their notifications went out ahead of the start date. The other three are the entire exposure, and it exists only because a payer's own governing date and the practice's administrative go-live date are two different things.

Claim counts use each payer's typical daily volume for this addition; full arithmetic in the Effective Date Note.

The Cascadia row specifically

Same addition, read two different ways.

Date usedClinic days heldClaims held
Provider approval only10 Apr721
Provider AND location20 May35105

Reading only the provider approval looks clean. Nine days in, Dr. Whitcombe himself is approved, and a practice that stops checking there resumes billing Cascadia claims on 10 April believing the gap is 7 clinic days.

The location add is a separate approval under the same contract, confirmed 40 days later on 20 May, and it is the one that actually governs, since Dr. Whitcombe sees patients only at the new site. The extra 28 clinic days of claims would go out and deny anyway, because the location, not the provider, was still pending.

The Claim Hold List holds this row on the later of the two dates specifically so this reading never happens.

What's in the pack

01

Payer Requirement Register

One row per payer, holding the provider-level approval date and the location-level approval date as two separate fields, plus the notification requirement and the effective-date policy each payer actually uses.

02

Change Notification per Payer

Drafted in the format that payer's own submission channel expects, stating only what the practice has confirmed as fact, separate from completing the enrollment application itself with the supporting document checklist it needs.

03

Notification Tracker

What was sent, when, and on which channel, with each payer's own stated response window recorded next to it so an overdue confirmation is flagged rather than left to age silently.

04

Claim Hold List until Effective

One row per payer, holding claims proactively before any of them are submitted, and releasing a row the moment its governing date is confirmed in writing, not before and not later than necessary.

05

Effective Date Note

States the governing date per payer and prices what billing on the administrative go-live date instead would have cost in claims that deny or get recouped. Renewal cycles on the credentials behind this addition run on their own dates in the expiration tracker.

06

Claim Hold and Effective-Date Watch

A daily read of the register, the tracker and the hold list, reporting rows now safe to release, rows correctly still held with days remaining, and any notification that was never confirmed.

How to use it

  1. 1

    Open in River, or download the pack

    Open the pack in River and let the agent build the register from what you send, or download the blank Word and CSV files and track it yourself.

  2. 2

    Send the payer list and the addition

    Every payer the group is enrolled with, and whether this addition is a new provider, a new location, or both together, since that changes what has to be tracked.

  3. 3

    Send what you know about each payer's policy

    How that payer sets its effective date and what it requires as notification. Where it is not known yet, the register leaves it blank rather than assuming one policy fits every payer.

  4. 4

    Hold on the governing date, not either approval

    The later of the provider-level and location-level date, confirmed in writing, before any claim for this addition goes out to that specific payer.

Frequently asked questions

Is this template free?

Yes. Download the two documents and three sheets as Word and CSV files with no signup and no card. "Edit with AI" is a separate, optional path for practices that want the agent to build the register and draft notifications from what they send it. The rest of the library is at the template library.

What format are the downloaded files?

Word documents (.docx) for the Change Notification per Payer and the Effective Date Note, and CSV (.csv) for the three tracking sheets, zipped into one download. They open natively in Word, Pages, Google Docs, Excel, Numbers and Sheets.

Do I need to hold claims for the whole group while this is pending?

No. The rest of the group, every provider and location already enrolled, keeps billing normally throughout. The hold applies only to the specific new provider-payer or location-payer combination that this addition actually creates, never to the group NPI as a whole.

What if the provider and the location aren't added on the same day?

Then they run as two separate rows with two separate governing dates, each tracked against its own start date. The LATER-of-two rule only applies when both are added together for the same payer; a provider joining a location the group already bills from has one date, not two.

Does Medicare really set the effective date this way?

For the provider and supplier types the rule covers, yes. 42 CFR 424.520(d) sets the effective date as the later of the filing date of an application subsequently approved and the date the provider first began furnishing services at the new location.

Do I still have to report the new location to Medicare separately?

Yes, and it is a different deadline from the effective date. Physicians and practitioner organizations must report a change, addition or deletion of a practice location within 30 days under 42 CFR 424.516(d)(1), regardless of when that location's billing effective date lands.

Does this replace getting a new provider credentialed in the first place?

No. That is the provider credentialing checklist, a separate process for a provider who is not enrolled anywhere yet. This pack covers a narrower case: adding a provider or a location to a group NPI that is already live.

Find out which payer's date is actually governing this addition

Download the blank pack as Word and CSV files, or open this exact pack in River and let the agent build the register and hold claims until each payer's own date clears.

Edit with AI