An EHR transition billing plan starts with an inventory, not a project schedule. Revenue is at risk in a handful of specific places: payer enrolments that have to be refiled, a clearinghouse identifier change, a fee schedule that loads wrong, and claims that fail for a reason nobody can see.
The inventory that has to be finished before anything moves
A billing system change is a data migration with a revenue cycle attached. The work that decides whether the transition costs you a month of cash is finished weeks before the first claim leaves the new system, and almost none of it happens inside the software. It happens in the enrolment files, the fee schedules and the identifiers that live outside the system you are retiring.
Payer participation and its identifiers decide whether a claim is recognized. The clearinghouse relation decides the route. The EFT and remittance enrolments decide whether you can see the money when it arrives. All three are agreements held by someone else, and none moves when your data does.
| Artefact | Where it lives | What breaks if it is reconstructed wrongly |
|---|---|---|
| Charge master | Inside the billing system, maintained by your staff | Charges post at the wrong amount, so write-offs are wrong |
| Fee schedule, per payer | Payer contract, fee schedule load file, payer portal | Claims pay at a default allowable, or come back as CARC 147 |
| Participation and identifiers | Enrollment records, contracts, PTAN and payer provider numbers | Claims reject as unaffiliated before adjudication |
| EDI enrollment | Contractor enrollment file, submitter ID and credentials | The payer will not accept files from the new submitter |
| ERA and EFT enrollment | Payer enrollment file plus the bank ACH setup | Payments arrive with no matching remittance, or on paper |
| Clearinghouse routing | Clearinghouse contract, payer ID tables, credentials | Claims land at the wrong payer, or at no payer |
The fee schedule is the item practices assume they can rebuild later. Each payer’s schedule, and the document recording when its rates change, has to be dated before the load file is built. A rate that moved in January and was never written down becomes a paid claim at an allowable you have no contract for.
- List every payer, then locate its fee schedule and its fee schedule change notice
- Record each payer’s participation status and every identifier it recognizes, per location
- Tabulate each EDI, ERA and EFT enrollment with its form, file reference and signer
Four migration decisions practices argue about
How much claim history to move is the first argument. Old claims are an archive: past the payer’s filing limit they cannot be rebilled, and adjudicated claims have no operational use beyond reporting and audit defence. Keep the old system readable for those rather than copying them forward.
The open accounts receivable cannot stay where it is, and it cannot be dragged across carelessly. Claims submitted but not adjudicated have filing deadlines attached, and claims in appeal have correspondence attached. A claim worked in a different system than the one that submitted it loses its edit trail.
| Decision | The answer that holds up | Why it costs less |
|---|---|---|
| How far back to move claims | Move only what is open or still inside a filing window | Copied archives add mapping risk and collect nothing |
| What happens to the open A/R | Freeze charge entry, then work the old A/R to zero in the old system | Notes, payer claim numbers and deadlines stay together |
| Does the old system stay readable | Negotiate dated read-only access in the exit terms | Audits and patient questions arrive for years |
| Who owns the data | Extract a complete structured copy before the subscription ends | A closed vendor need not keep your records available |
Who owns the data, how it is extracted and in what format, how long read-only access survives, and what happens if the vendor is acquired are contract questions. Ask them before you sign.
EHR transition billing risk sits in four places
The first is enrolment. EDI and ERA enrolments are filed per contractor and per payer, and they attach to identifiers and destinations rather than to your practice. A new submitter ID, a new clearinghouse or a new billing entity means the enrolment has to be redone with each payer before that payer will accept a file from you.
Medical plan adoption of fully electronic transactions
Source: 2024 CAQH Index, medical plan adoption of fully electronic administrative transactions.
The second is the clearinghouse identifier change. Claims are routed by a payer ID, and the payer’s own list does not always match the list a clearinghouse carries. When a claim arrives at a payer that does not own the member, the payer returns CARC 109 and tells you to send it to the correct payer. The filing window kept running while the claim sat in the wrong place.
The third is the fee schedule load. A rate matched to the wrong procedure code, or a contract rate that expired and was never reloaded, produces a claim that pays less than it should. CARC 147 is the payer reporting that the contracted rate is expired or not on file, and a paid claim at the wrong allowable is harder to catch than a rejection.
CARC 15, the old authorization number code, was deactivated on 1 May 2018 and should not appear on a live remittance. The codes that mark the failures a cutover produces are 16, 22, 27, 29, 109 and 147. A dashboard still reporting 15 is mapping against a list from before 2018.
The fourth is the first weeks of quiet failure. A claim stopped by a clearinghouse edit never reaches the payer, so it produces no remittance, no denial code and no denial work. It sits in the system looking submitted, and the only place it appears is the acknowledgement report.
| Failure point | What you see first | Evidence you can see |
|---|---|---|
| Payer enrolment not refiled | Files rejected before adjudication, and no remittance | Acknowledgement or rejection report, not an 835 |
| Clearinghouse payer ID change | Claims adjudicated by a payer that does not own the member | CARC 109 |
| Fee schedule missing or loaded wrongly | Claims paid below contract, quietly | CARC 147, or a paid claim at the wrong allowable |
| Backlog worked after the freeze | Claims sent after the payer’s filing window closed | CARC 29 |
None of these show up in a monthly financial report in time to matter. They show up in the daily acknowledgement file, in unapplied cash and in the first-pass denial rate.
Enrolment is per payer, and it does not transfer
For Medicare, the EDI Enrollment Form has to be executed by each provider that submits or receives EDI, directly or through a billing service or clearinghouse, before the contractor will accept a file. The Medicare Claims Processing Manual, Chapter 24 keeps the remittance enrolment separate: a provider receiving electronic remittance signs an ERA Enrollment Form before that contractor will transmit an 835.
EFT is a third file. The same manual states that electronic funds transfer between the contractor and the bank is not EDI for enrollment purposes, so a practice that takes EFT but sends no electronic claims should not file the EDI form at all. The EFT Authorization Agreement, Form CMS-588, is signed by the authorized representative named on the enrollment application, filed with each contractor billed, and subject to a pre-certification period in which the bank verifies the account before deposits begin.
- 01
File the EDI enrollment with each contractor
Name every transaction type in use: claims, eligibility, claim status and remittance. The form tells the contractor what a new submitter may send.
- 02
File ERA enrollment where the remittance will land
If the clearinghouse changes, every payer has to be told the new destination. The 835 follows the enrolment, not the participation record.
- 03
File EFT authorization separately
Account name and signer must match the enrollment record the payer holds. A mismatch here does not stop claims. It stops deposits.
- 04
Change payer IDs with the clearinghouse before go-live
Compare the clearinghouse payer list against the payer’s own list first. The payer’s list often carries former plan names that explain a mismatch.
The operating rules behind those enrolments belong to a national authority, not to any software. 45 CFR 162.1603 adopts the Phase III CORE EFT and ERA Operating Rule Set: the EFT Enrollment Data Rule, the ERA Enrollment Data Rule, the reassociation rule that ties a deposit to its remittance, and the 835 infrastructure rule. The enrollment data rules cap what a plan may collect and do not require a plan to combine EFT with ERA enrolment.
Medical plan adoption of electronic remittance advice
Source: 2024 CAQH Index, medical plan adoption of fully electronic remittance advice.
The reassociation rule explains most unapplied cash in a transition. The bank deposit carries an addenda record and the remittance carries a trace number, and the enrolment ties them together. Break that link and the money arrives without the explanation of it. Setup time is the payer’s to state: UnitedHealthcare’s EDI documentation states that once it receives a clearinghouse request for 835 delivery, setup takes about 30 days.
EFT enrollment does not constitute enrollment as a provider or supplier in Medicare, and ERA enrollment is a separate signed agreement from the EDI enrollment. Three files, three signers in the worst case, and none of them is the participation record.
What to freeze, and when
A transition has a freeze window, and the practice sets it, not the software. Charge entry has to stop in the old system on a dated morning, because a claim entered in one system and corrected in another loses the appeal trail.
A freeze is not the same thing as a stop. Clinical documentation continues in the new system from day one. Charges accrued before the cutover are entered in the old system until that backlog reaches zero, and the old fee schedule stays loaded until the last claim from it has been adjudicated.
- Publish the date charge entry stops in the old system, and hold to it
- Reconcile the last batch from the old system against its remittance
- Work the old A/R to zero inside the old system, with notes intact
The backlog rule matters more than the freeze rule. The accounts receivable open on the day of cutover is still a balance, and it needs an owner and a date. Split it across two teams and the oldest claims, the ones nearest a filing limit, become the ones nobody feels responsible for.
A short parallel period has one specific use: it proves the identifiers. Submit one test claim per payer from the new system, with the new submitter ID and payer ID, and trace it from acknowledgement to remittance. It does not test the fee schedule, because a paid claim at the wrong allowable still looks paid.
The first 30 days, and the indicators that move before the cash
Cash follows claims, and claims follow acknowledgements. The numbers that move first in a failing transition are upstream of money, which is why a daily read of a few reports beats a monthly financial review.
| Daily check | What it catches | What wrong looks like |
|---|---|---|
| Clearinghouse acknowledgement and rejection report | Claims that never reached a payer | Rejections clustered on one payer’s IDs rather than spread evenly |
| Remittances received against deposits made | Broken reassociation between payment and remittance | Deposits with no matching 835, or a manual posting stack |
| First-pass denial rate by code | Wrong payer IDs, stale coordination of benefits, bad fee schedule | CARC 109, 22 or 147 appearing at all |
| Unapplied cash balance | Money received that nobody has matched to a claim | A balance growing for three consecutive days |
| Days in A/R and the over-90 balance | A backlog that is not being worked | Both rising while charge volume looks normal |
The most useful single daily number is the count of claims submitted with no acknowledgement. It is the only measure that catches a silent rejection, and it falls to zero as soon as the identifiers are right. A rejection rate that improves while unapplied cash grows is not progress.
Days in A/R is the confirmation, not the warning. It moves weeks after the failure starts, when unpaid claims age into the next bucket. A practice watching it alone learns about a broken enrolment a month late, when the remedy is a rework project.
The pattern is easier to see against a baseline. A clean claim rate measured before the cutover is the number to compare against in week one, and the net collection rate is what confirms the second month. The enrolment mechanics are the ones covered in payer enrollment, and the front-end data a new system inherits is the list in the insurance verification checklist.
A net collection rate that holds while unapplied cash doubles is not a healthy transition. Read the pair together: money received, and money matched to a claim.
Questions practices ask us about this
How long does it take to change billing systems without losing revenue?
No universal answer exists, and any vendor quoting one is quoting its own implementation schedule rather than the payer-facing work. The part you control is enrolment, because each payer and each contractor is filed separately and each states its own setup time. UnitedHealthcare’s EDI documentation, for example, states that once it receives a clearinghouse request for 835 delivery, setup takes about 30 days.
Do we have to re-enroll with every payer when we change billing systems?
If your identifiers or your submission route change, yes. EDI and ERA enrolment is filed per contractor and per payer against a specific submitter or destination, so a new clearinghouse, a new submitter ID or a new billing entity has to be enrolled wherever the transactions will be exchanged. A participation contract is not an enrolment, and it does not carry the electronic transactions with it.
What happens to our open A/R during the transition?
Work it to zero in the system that created it. Claims submitted before the cutover keep their notes, their payer claim number and their filing deadlines there. Moving them mid-appeal splits the documentation across two systems and makes the oldest claims, the ones nearest a filing limit, the hardest to work. Give that backlog its own owner and its own completion date.
Which CARC codes should we watch after a cutover?
CARC 109 means the claim went to a payer that does not own it, which is what a wrong payer or clearinghouse identifier produces. CARC 16 covers missing or inconsistent information, including a provider identifier the payer does not recognize. CARC 147 reports a contracted rate that expired or is not on file, which is a fee schedule load that failed. CARC 22 and 27 point at stale coordination of benefits and eligibility data.
Does an EFT enrollment also cover electronic remittance advice?
No. CMS treats electronic funds transfer as separate from EDI enrollment, and the EFT Authorization Agreement, Form CMS-588, is filed with each contractor billed. The national operating rules for electronic remittance do not require a health plan to combine EFT and ERA enrolment either, so an electronic deposit and an electronic remittance are two enrolments that have to be filed and verified separately.
Want this fixed in your practice?
We run full-cycle billing, coding, credentialing and denial work for practices across the country. Send us a few months of claims and we will show you where the money is going.
Book a free billing review- CMS, How to Enroll in Medicare Electronic Data Interchange. cms.gov/medicare/coding-billing/electronic-billing/how-to-enroll-medicare-electronic-data-interchange
- CMS Medicare Claims Processing Manual, Pub. 100-04, Chapter 24 (sections 30 to 30.4, EDI and ERA enrollment). cms.gov/regulations-and-guidance/guidance/manuals/downloads/clm104c24.pdf
- CMS Form CMS-588, Electronic Funds Transfer (EFT) Authorization Agreement and instructions. cms.gov/medicare/cms-forms/cms-forms/downloads/cms588.pdf
- 45 CFR 162.1603, operating rules for the health care EFT and remittance advice transaction (eCFR). ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-P
- CAQH CORE, Payment and Remittance operating rules, including the EFT and ERA enrollment data rules. caqh.org/core/operating-rules
- 2024 CAQH Index, adoption, cost per transaction and administrative spend for medical transactions. caqh.org/hubfs/Index/2024%20Index%20Report/CAQH_IndexReport_2024_FINAL.pdf
- X12, Claim Adjustment Reason Codes (current list). x12.org/codes/claim-adjustment-reason-codes
- UnitedHealthcare EDI transactions and code sets, including 835 enrollment and delivery setup. uhcprovider.com/en/resource-library/edi/edi-transactions.html
- CMS MLN Matters MM12428, implementation of the CAQH CORE 360 uniform use of CARC, RARC and CAGC rule. cms.gov/files/document/mm12428.pdf
