The new system has to be set up before your data lands in it, because the data points at the setup. A charge needs its procedure code and its fee schedule to already exist. An appointment needs its type and its provider. A claim, the bill you send an insurer, needs the insurance company and the billing rules in place.
Set the data down before the setup is there, and it has nowhere correct to land. This piece covers what that setup includes. It covers why turning the system on is not the same as setting it up for billing, and why the wrong answer stays quiet until a claim rejects. It sits inside how to prepare for an AdvancedMD data migration.
Turning the system on is not the same as setting it up for billing
There is a real difference between switching a practice management system on and setting it up so the numbers work on day one of go-live. The first is a switch anyone can flip. The second is the largest migration job by hours. It decides whether your first month of claims goes out clean or comes back to be reworked.
Every setting has a right answer for how your practice bills. The wrong answer does not announce itself. It waits until a claim rejects or a payment posts short, weeks after go-live. By then the cause is buried under a month of real work. That gap is why configuration is worth the same care as the data itself.
Insurance companies, and the identifiers each one needs
An insurance company is not one setting with a name. Each one needs the identifier your claims actually go out on. That is not always the identifier used for a real-time coverage check. Some insurers use a third setup again for hospital claims.
Get the claim identifier wrong, and every claim to that insurer rejects. Get the coverage-check identifier wrong, and your front desk’s checks come back empty. Then nobody knows what a patient owes at the time of service. Each insurer also carries quirks your billing team has learned over years, and one insurer configured wrong is every claim to it, delayed.
Fee schedules and contracted rates
Your fees are not a single number. There is what you charge. There is what each insurance company has contracted to allow. Those contracted rates differ insurer by insurer.
If the system does not hold the contracted rate for an insurer, it cannot tell you when that insurer underpays. A short payment then posts as if it were correct, and nothing flags it. Setting each insurer’s contracted rate is what lets the system catch an underpayment instead of banking it as normal.
And if your practice adjusts fees, by a cash rate, a membership, or a hardship discount, that schedule has to exist too. If it does not, the discount a patient was promised silently reverts to full fee.
Codes, modifiers, and place of service
Everything you bill leans on shared reference lists, and they have to match how the new system expects to see them. Procedure and diagnosis codes and places of service all have to exist, because every charge and claim points at them.
Modifiers are where this gets sharp. A modifier, a code added to say how a service was done, changes what a code means to an insurer. Insurers can be strict about which they require and which they reject.
Place of service matters too, and telehealth is where it bites. A telehealth visit carries a different place-of-service code and, for some insurers, a modifier. Those rules have shifted repeatedly and vary by insurer. Set them to last year’s rules, or to the way in-person visits are coded, and the claims go out wrong from day one.
The categories under your reporting
Underneath every report sit the categories that make the numbers mean something. Financial classes group your insurers, so you can see how you are doing by insurer type. Adjustment and write-off reason codes record why money left the ledger. They separate a write-off you chose from one that signals a problem.
Aging buckets define what counts as 30, 60, and 90 days old, which is how you see where money is stuck.
These are easy to treat as defaults and expensive to get wrong. If the classes do not match how you think about your insurers, the reports mislead. If the reasons collapse distinct problems into one bucket, the reports come out technically correct and useless. You find that out only when a number you trusted turns out to have hidden something.
Scheduling and clinical templates
The calendar is machinery that has to exist before the appointments load. That means the appointment types and their lengths, the statuses an appointment moves through, the rooms and equipment you book, and the rules for who can be booked when.
The reminder and recall rules that keep patients coming back are part of it too. A practice that goes live without them loses the quiet machinery that kept the schedule full.
Clinical documentation runs on templates. The ones your providers use every day have to be ready, so that from the first visit they document the way they always have. A provider fighting a blank system on go-live morning is a provider seeing fewer patients, and that cost lands straight on the schedule.
The checks that protect your first-pass rate
The tests that catch a bad claim before it goes out are their own configuration. They protect your first-pass rate, the share of claims paid on the first try, on day one.
Claim scrubbing rules, the automatic checks a claim passes before it is sent, have to match the insurers you bill. They also have to match the errors you tend to make. Otherwise claims go out with problems a proper setup would have caught.
Your statements have to be set up so they look right and follow the cycle you intend. If they do not, the first ones out the door confuse patients and generate a wave of calls. The cycle for chasing overdue balances is part of this too, and a practice that goes live without it either chases nothing or chases everyone at once.
Providers, enrollment, and access belong here too
Three more pieces sit inside configuration, and each is large on its own. Every provider needs a record with the correct identifiers and settings. That record is only as good as the provider’s standing with each insurer. That standing lives outside the software and is its own job, covered in confirming each provider with each insurer across locations.
The electronic connections that let claims, payment reports, and payments move are configured here. But their enrollment, the paperwork that lets them move electronically, is approved by outside parties on their own clock. That is why they set your timeline, and they are handled in filing your outside enrollments when you switch systems.
And every person who touches the system needs an account with the right permissions. Set them neither so loosely that records are exposed, nor so tightly that staff cannot work on go-live morning.
Bringing more than one practice together
If you are moving more than one practice onto a single system, every list above has to be reconciled across all of them before anything loads. Two offices rarely code the same procedure the same way. They rarely name the same insurer the same way, or classify the same balance the same way.
Merging them means deciding, once, how the combined group will run. Settling those differences on paper is far cheaper than untangling them after, when the data from every practice is already mixed together. For a group standardizing the practices it acquires, this reconciliation is the real work of the migration, and the conversion is the easy part at the end of it.
Why configuration runs alongside, not after
The setup has to be ready before the data arrives. So this job runs at the same time as the data and the documents, not after them. That overlap is what calendars miss.
A migration looks like a sequence when you draw it. In practice it is a set of jobs running at once, against a date fixed by the slowest enrollment. The data cannot be tested until the setup it points at exists. And the setup that reflects how your practice bills cannot be guessed from a default.
The practices that finish clean start configuration alongside everything else. They give it the hours it needs.
Before the data lands
On the configuration side, these should be true.
- Insurance companies are set up with the right claim and coverage-check identifiers, not one identifier assumed to cover both.
- Fee schedules hold each insurer’s contracted rate, and any discount or self-pay schedule exists.
- Procedure and diagnosis codes, modifiers, and places of service match how you bill, including current telehealth rules.
- Financial classes, adjustment reasons, and aging buckets reflect how you actually read your numbers.
- Scheduling, clinical templates, claim scrubbing, statements, and the overdue-balance cycle are set up, not left as defaults.
- Provider records, the outside enrollments, and user permissions are handled, with credentialing tracked as its own job.
If the setup is not ready, the data has nowhere correct to land. Configuration is what turns a system that is switched on into a system that bills.
Common questions
Why does a new system have to be configured before the data loads?
Because the data points at the setup. A charge needs its code and fee schedule to exist. An appointment needs its type and provider. A claim needs the insurance company and its rules. Without the setup first, the data has nowhere correct to land.
Is turning on a new system the same as setting it up for billing?
No. Switching the office on is a step anyone can take. Setting it up so claims go out clean is the larger job, the biggest of the migration by hours. Every setting has a right answer for how your practice bills, and the wrong one hides until a claim rejects.
What does practice management configuration include?
Insurance companies and their identifiers, fee schedules and contracted rates, codes and modifiers, places of service, financial classes and aging, scheduling, clinical templates, claim scrubbing, statements, provider records, electronic enrollments, and user permissions. Each has a right answer for how your practice bills.
Why do claims reject after a system migration?
Usually a setup that does not match how an insurer wants the claim. A wrong claim identifier, a missing modifier, a stale telehealth place-of-service, or a code that means something different than before. The claim looks fine and rejects anyway.
What happens if contracted rates are not set up?
The system cannot tell when an insurer underpays, so a short payment posts as if it were correct and nothing flags it. Underpayments are the leak that never announces itself, because a claim that pays less than it should still pays. Loading each insurer’s contracted rate is what catches them.
Why is telehealth billing a common migration problem?
A telehealth visit carries a different place-of-service code and, for some insurers, a modifier. Those rules have shifted repeatedly and vary by insurer. Configure it the way in-person visits are coded, or the way last year’s rules said, and the claims go out wrong from the first day.
Do provider credentialing and enrollment happen during configuration?
The provider records are configured in the system. But credentialing and enrollment live outside it, tied to the practice, the location, and an effective date. A record can be set up correctly while the provider is not enrolled, and the claims still deny. Credentialing across locations is its own job.
Why do aging buckets and adjustment codes matter?
They shape every report you use to judge whether the practice is healthy. If financial classes do not match how you think about your insurers, or write-off reasons collapse distinct problems into one bucket, the reports come out technically correct and useless. You find out only when a trusted number hides something.
What configuration is needed for scheduling to work on day one?
Appointment types and lengths, statuses, bookable rooms and equipment, the rules for who can be booked when, and any group or class structures all have to exist before appointments load. Reminder and recall rules belong here too, or the practice loses the machinery that kept its schedule full.
How should I configure a system for more than one practice?
Reconcile every setup list across all of them before anything loads, because two offices rarely code, name insurers, or classify balances the same way. Decide once how the combined group will run, and settle the differences on paper. That reconciliation is the real work when you standardize acquired practices.
When should configuration start in a migration?
At the beginning, alongside the data and the documents, not after them. The data cannot be tested until the setup it points at exists, and setup that fits how you bill cannot be guessed from a default. It is the largest job by hours, so it needs an early start and real time.
Where this leaves you
Configuration is the quiet difference between a system that is switched on and one that bills. Set it to match how your practice actually works, not to a default. Give it the hours it needs alongside the data. Then your first month of claims goes out clean instead of coming back to be reworked.