Medical billing during an EHR migration needs its own cutover plan. Moving patient records is only part of the project. A practice must also protect unbilled encounters, open claims, accounts receivable, payer connections, remittance files, patient balances and access to historical documentation.
A technically successful data transfer can still produce a revenue gap if the new system cannot create a clean claim or the billing team cannot reach the records needed for an appeal. Before go-live, trace several real accounts from registration through payment posting. After go-live, monitor each handoff until the first complete billing cycle reconciles.
Why EHR Migrations Disrupt Medical Billing
An EHR and practice management system may share data, but they support different steps in the revenue cycle. The EHR holds clinical documentation and charge details. The billing platform adds insurance, claim, remittance and collection workflows. When systems are replaced together, a mapping error can affect thousands of accounts.
Common failures include missing insurance plans, incorrect payer IDs, providers attached to the wrong billing entity, unmapped diagnosis codes and ERA files routed to the old system. Staff may also lose access to notes or authorizations needed to correct a denial. None of these problems requires lost clinical records. They arise because the migrated data no longer works inside the billing process.
Name a revenue cycle owner before the implementation begins. This person should coordinate the practice, outgoing vendor, incoming vendor, clearinghouse and billing team. Every unresolved item needs an owner, due date and test result.
The federal SAFER Guides from HealthIT.gov provide additional guidance for assessing EHR safety, system management and contingency planning. Use them alongside the practice’s billing cutover plan rather than treating clinical and financial readiness as separate projects.
Decide What Billing Data Will Move
Ask both vendors for a written data conversion scope. Do not accept a general promise that billing data is included. List the exact fields, date range, format and destination. Specify what will remain searchable in the old system and how long that access will continue.
Open claims and accounts receivable
Decide whether open claims will continue in the legacy platform or move to the new one. Migrating every open claim sounds efficient, but conversion can strip claim history, notes, follow-up dates or payer responses. Working old claims in the original system may be safer if the practice can maintain access and reconcile payments across both systems.
Create a dated A/R inventory by payer, provider, location, aging bucket and responsible party. Include rejected claims, denied claims, appeals, secondary claims and accounts held for documentation. Compare the total with financial reports before and after conversion. Older balances should receive focused accounts receivable follow-up before filing and appeal limits expire.
Patient balances and credit balances
Patient balances need transaction detail, not only a final amount. A balance without the related insurance payment, adjustment and statement history can lead to duplicate bills or unsupported collection activity. Export payment plans, statement dates, collection status and communication notes when available.
Separate credit balances and unapplied payments. Test how the new system represents refunds, deposits and credits tied to old encounters. Assign a team member to reconcile the opening patient ledger before new statements are released.
Payment and denial history
Historical ERA and denial data helps staff understand why a balance exists and whether a corrected claim or appeal is still possible. Preserve payer claim numbers, CARC and RARC codes, appeal records, call notes and supporting documents.
If this detail will remain only in an archive, confirm that billing staff can search it by patient, date of service, payer and claim number. A static collection of PDFs may meet part of a retention need but can be slow to use during daily follow-up.
Build the Revenue Cycle Cutover Plan
Set a cutover rule that every team can explain. The rule may be based on date of service, encounter close date or claim submission date. Avoid allowing staff to choose a system account by account. Inconsistent routing creates duplicate claims and missing charges.
The plan should identify the last day for documentation in the old EHR, the final charge export, the first encounter in the new system and the final legacy claim batch. Include a freeze window for configuration changes and a process for urgent corrections during that window.
Maintain read-only legacy access long enough to finish follow-up, appeals, audits and refunds. Confirm the cost, user count, authentication method and termination date in writing. Export key reports before access changes, including A/R aging, unbilled encounters, claim status, unapplied cash and credit balances.
Configure the New Billing Environment
Providers, locations and payer IDs
Verify every rendering provider, billing provider, taxonomy, service location and place-of-service value. Match legal names, NPIs and tax IDs to payer enrollment records. A provider may appear correctly in the user list while claims still carry the wrong billing identifier.
Load active insurance plans carefully. Similar plan names can use different payer IDs or claim routes. Test commercial, Medicare, Medicaid and secondary claims separately. Practices with several sites should review the billing configuration for each location rather than copying a single profile.
Clearinghouse and EDI connections
Confirm that the new system can transmit 837 claims and receive payer acknowledgments. Check submitter IDs, receiver IDs, trading partner approvals and any payer-specific EDI enrollment. A successful connection to the clearinghouse does not prove that every payer will accept the claim.
Build an acknowledgment workflow for 999 and 277CA responses. Staff should know who reviews rejected files, how quickly errors are corrected and where the status is documented. An 837 file that left the EHR but failed at the clearinghouse is not a submitted claim.
Fee schedules, rules and claim scrubbing
Load the correct fee schedule for each entity, location and payer arrangement. Validate common CPT and HCPCS codes, modifiers, units and diagnosis links against recent claims. Rebuild claim edits that previously prevented predictable rejections.
Do not copy every old rule without review. Some edits may be outdated, duplicated or tied to a former payer requirement. Start with high-volume services and recent rejection patterns, then document which rules were tested.
ERA, EFT and payment posting
Confirm where each payer will send the 835 file after migration. A new clearinghouse, receiver ID or billing service may require updated ERA enrollment. EFT deposits can continue to the same bank while remittance files go somewhere else, leaving staff unable to match the money to claims.
Use an EFT and ERA enrollment checklist for each payer and billing entity. Test the first live remittance through import, posting and reconciliation. Unmatched deposits, duplicate ERAs and rejected 835 files need a named exception queue.
Test Claims Before Go-Live
Use realistic test cases across the practice’s main payers, providers and services. Include a new patient, established patient, secondary insurance, authorization-dependent service, procedure with a modifier and a claim from each location. Synthetic data is appropriate in a test environment when vendors permit it.
A claim test should cover more than form generation. Confirm registration, eligibility, documentation, charge capture, coding, claim edits, clearinghouse acceptance and payer acknowledgment. Then test an ERA or sample remittance through payment posting. Record the expected result and evidence for every test.
If production testing is required, coordinate a small first batch. Do not release a full day of claims simply because one claim passed. Review the batch for duplicates and correct identifiers before submission, then confirm acceptance at the payer level.
What to Do During the Cutover
Keep a live issue log and prioritize anything that stops documentation, charge capture, claim submission or payment posting. A cosmetic report problem can wait. A provider who cannot sign a note or a claim file that cannot reach the clearinghouse cannot.
- Reconcile the final legacy charge and claim batches.
- Confirm that every encounter has one system of record.
- Check interfaces, payer connections and user access.
- Review the first production claims before releasing larger batches.
- Track unbilled encounters and held claims by value and age.
- Keep legacy access available for documentation and follow-up.
Do not hide migration problems by postponing claims without reporting their value. Leadership should see the number and dollar amount of unbilled encounters each day, along with the reason, responsible owner and expected release date.
First 30 Days After EHR Migration
Review billing exceptions daily during the first two weeks. Compare rejection rate, clean claim acceptance, days from service to submission, held charges and unapplied cash with the pre-migration baseline. Break results down by payer, provider and location.
Follow the first claims through adjudication. Match ERA files to EFT deposits and verify that contractual adjustments and patient responsibility post correctly. Review early denials for configuration patterns such as invalid provider combinations, missing authorization data, diagnosis mapping and place-of-service errors. A structured denial management process helps stop the same defect from affecting another batch.
Reconcile both systems weekly until legacy activity is minimal. The old system may continue receiving payments, recoupments and correspondence after new claims have moved. Maintain one combined cash and A/R view during this overlap.
Common Billing Migration Mistakes
- Treating a successful data import as proof that claims will bill correctly.
- Closing legacy access before old claims and appeals are resolved.
- Moving balances without transaction and follow-up history.
- Assuming clearinghouse and ERA connections transfer automatically.
- Skipping tests for secondary claims, multiple locations or less common payers.
- Measuring denials while ignoring held and unsubmitted claims.
The safest response is not a longer checklist. It is evidence that each critical workflow works. Keep screenshots, acknowledgment reports, reconciliations and sign-offs for the tested scenarios.
When to Involve an Outside Billing Team
Outside support can help when the practice has a large payer mix, several locations, limited internal billing capacity or a short migration window. The billing partner should participate before configuration is finalized, not only after denials appear.
Ask who will validate payer setup, test claims, reconcile A/R and monitor the overlap between systems. Confirm how the partner receives data and how access is removed when the project ends. Swift Medical Billing can support migration planning through broader revenue cycle management services, including claim testing, payment posting, denial review and A/R follow-up.
Frequently Asked Questions
What billing data should move to a new EHR?
The scope should address patient and insurance data, unbilled encounters, open claims, A/R, balances, payments, denials, authorizations and supporting notes. Some historical work may remain in the legacy system if access and responsibility are clearly defined.
How long does an EHR migration take?
Timing depends on practice size, system complexity, data quality, interfaces and vendor capacity. Build the schedule around validated milestones rather than one promised go-live date. Billing tests and payer connections should be complete before full claim volume moves.
Should the practice keep access to the old EHR?
Usually yes, at least during the transition. Billing staff may need old documentation, claim history, payment details and appeal records. Define the access period, cost and termination criteria before signing the migration plan.
How can a practice prevent duplicate claims during migration?
Use one cutover rule, assign each encounter to one system of record and reconcile final legacy batches against first production batches. Review corrected and secondary claims separately because their dates may cross the cutover boundary.
What should be monitored after go-live?
Track unbilled encounters, claim rejections, payer acknowledgments, denials, submission lag, unapplied cash, unmatched ERA and EFT transactions, and A/R movement. Compare these measures with a pre-migration baseline.
Protect Cash Flow Through the Transition
Medical billing during an EHR migration works when every encounter, claim and payment has a documented route. Preserve access to the legacy system, test the complete claim cycle, monitor held revenue and reconcile both systems until the overlap ends. If your practice needs an independent billing review before go-live, contact Swift Medical Billing to assess the cutover plan.
