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 needs the payer and the billing rules in place. Set the data down before the setup is there and it has nowhere correct to land. This is what that setup covers, why turning the system on is not the same as setting it up to bill, and why the wrong answer stays quiet until a claim rejects. It sits inside the full picture in how to prepare for an AdvancedMD data migration. This is the configuration job, in depth.
Turning the system on is not the same as setting it up to bill
There is a real difference between switching an office on and setting it up so the practice’s numbers work on the first day. The first is a switch anyone can flip. The second decides whether your first month of claims goes out clean or comes back to be reworked, and it is the largest of the migration jobs by hours. Every setting has a right answer for how your practice actually bills, and the wrong answer does not announce itself. It waits until a claim rejects or a payment posts short, weeks after go-live, when the cause is buried under a month of real work. That gap is why configuration is worth the same care as the data itself.
Payers, and the identifiers each one needs
A payer is not one setting with a name. Each one needs the identifier your claims actually go out on, and that is not always the same as the identifier used for a real-time eligibility check, and some payers use a third setup again for institutional claims. Get the claim identifier wrong and every claim to that payer rejects. Get the eligibility identifier wrong and your front desk’s coverage checks come back empty, so no one knows what a patient owes at the time of service. Each payer also carries its own rules and quirks that your billing team has learned over years, and a single payer configured wrong is every claim to that payer, delayed.
Fee schedules and contracted rates
Your fees are not a single number. There is what you charge, and there is what each payer has contracted to allow, and those contracted rates differ payer by payer. If the new system does not hold the contracted rate for a payer, it cannot tell you when that payer underpays, so a short payment posts as if it were correct and nothing flags it. Setting up each payer’s contracted rate, rather than one default fee, 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, or 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 you carry points at them. Modifiers are where this gets sharp: a modifier changes what a code means to a payer, and payers can be strict about which they require and which they reject. Place of service matters too, and telehealth is where it bites, since a telehealth visit carries a different place-of-service code and often a modifier, and those rules have shifted repeatedly and vary by payer. 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 payers so you can see how you are doing by payer type. Adjustment and write-off reason codes record why money left the ledger, which is the difference between a write-off you chose and 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, because if the classes do not match how you think about your payers, or the reasons collapse distinct problems into one bucket, the reports come out technically correct and practically useless, and you find that out only when a number you trusted turns out to have been hiding something.
Scheduling and clinical templates
The calendar is machinery that has to exist before the appointments load: the appointment types and their lengths, the statuses an appointment moves through, the rooms and equipment you book, the rules for who can be booked when, and the group or class structures if you run them. The reminder and recall rules that keep patients coming back are part of it too, and a practice that goes live without them loses the quiet machinery that was keeping the schedule full. Clinical documentation runs on templates, and the ones your providers use every day have to be set up so that from the first visit they document the way they always have, not fight a blank system. A provider wrestling a documentation setup on go-live morning is a provider seeing fewer patients, and that cost lands straight on the schedule.
The checks that protect your clean claim rate
The tests that catch a bad claim before it goes out are their own configuration, and they are what protect your first-pass rate on day one. Claim scrubbing rules, the checks a claim passes before submission, have to match the payers you bill and the errors you tend to make, or claims go out with problems a properly configured system would have caught. Your statements have to be set up to look right and follow the cycle you intend, or the first ones out the door confuse patients and generate a wave of calls. And the dunning cycle, how and when overdue balances are chased, is part of this, since 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 enough to note on its own. Every provider needs a record with the correct identifiers and settings, and that record is only as good as the provider’s standing with each payer, which lives outside the software and is its own job, covered in provider credentialing and enrollment across locations. The electronic connections that let claims, remittances, and payments move are configured here but approved by outside parties on their own clock, which is why they set your timeline and are handled in payer and clearinghouse enrollment when you switch systems. And every person who touches the system needs an account with the right permissions for their role, set 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, name the same payer the same way, or classify the same balance the same way. Merging them means deciding, once, how the combined group will run, and settling those differences on paper is far cheaper than untangling them after, when the data from several practices is already mixed together and no one can tell which office’s convention a record followed. For a group standardizing the practices it acquires, this reconciliation is the actual work of the migration, and the conversion is the easy part at the end of it.
Why configuration runs alongside, not after
Because the setup has to be ready before the data arrives, 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, and in practice it is several 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. So the practices that finish clean are the ones who started the configuration alongside everything else and gave it the hours it actually needs, rather than treating it as a switch to flip at the end.
Before the data lands
On the configuration side, these should be true.
- Payers are set up with the right claim and eligibility identifiers, not one identifier assumed to cover both.
- Fee schedules hold each payer’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 dunning cycle are set up, not left as defaults.
- Provider records, the outside enrollments, and user permissions are handled, with credentialing and enrollment tracked as their own jobs.
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 payer and rules. Without the setup first, the data has nowhere correct to land, and the system cannot use what it received.
Is turning on a new system the same as setting it up to bill?
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?
Payers 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, and the wrong one surfaces as a rejection.
Why do claims reject after a system migration?
Usually a setup that does not match how a payer 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, which is why configuration matches the way each payer actually bills.
What happens if contracted rates are not set up?
The system cannot tell when a payer 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 payer’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 often a modifier, and those rules have shifted repeatedly and vary by payer. Set up to code the way in-person visits do, or the way last year’s rules said, and the claims go out wrong from the first day on the new system.
Do provider credentialing and enrollment happen during configuration?
The provider records are configured in the system, but credentialing and payer 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 payers, 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 was keeping 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 payers, 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, and give it the hours it needs alongside the data, and your first month of claims goes out clean instead of coming back to be reworked.