Moving Billing Systems
Without the Cash Chaos
Every practice reaches a point where the billing system isn't working anymore. The question isn't whether to change — it's how to move without leaving money behind. This is that framework.
The most expensive billing migration isn't the one you plan. It's the one you rush. And many migrations get rushed — because the decision to change is driven by frustration rather than evidence, and frustration doesn't wait for diagnostic data.
Changing a billing system feels like the answer to every practice frustration. Claims keep rejecting? Change the PMS. Cash is slow? Change the bureau. Reports are opaque? Change everything. The instinct is understandable — but migration driven by frustration alone doesn't erase leakage. It relocates it into a new platform, a new support contract and a new set of onboarding fees, while the old system's open claims quietly age toward write-off in a queue nobody checks anymore.
The most dangerous version of a billing migration is one driven by frustration alone. Open claims are its first casualty.
This article gives you a structured migration framework across eight phases. If you've already done the diagnostic work in Article 2, you already have the numbers you need to start Phase 1.
The loyalty trap — and why it costs more than the exit
Many doctors stay with underperforming billing systems for years. The stated reason is usually fear: fear of losing patient history, fear of disrupting cash flow, fear that the new system will introduce different problems. These fears are rational.
But here's the part that's often not calculated: the cost of staying.
The practice stayed with a familiar bureau because the front office feared data loss. Over six months, R184,000 in rejected and short-paid claims aged beyond effective follow-up. The actual cost of migration would have been R40,000 in transition time and setup fees. The cost of staying loyal to a leaking stack was R184,000 — and counting.
The principle to remember
Loyalty should belong to the architecture that supports your practice's cash generation — not to a specific software vendor, a familiar interface or a bureau relationship that has outlived its accountability. Inertia isn't prudence. It's just inertia with an invoice attached.
Run the numbers before you give anyone notice
Never initiate a vendor search, sign a new contract or give notice to an incumbent provider before completing a 30-day diagnostic. Without this baseline, you can't prove the migration worked — and you won't know what "working" even means.
| Document or report | What it reveals |
|---|---|
| PMS and bureau invoices (last 3 months) | Your actual all-in billing cost, including every add-on |
| Claims submitted report | Volume, timing and submission patterns |
| Rejection report with reason codes | Whether problems are systemic or isolated |
| A/R ageing at 30/60/90/120 days | How much cash is stuck, and in which age buckets |
| ERA allocation report | Whether received payments are reconciled to individual claims |
| Patient balance report | Size and age of the patient-side debtor population |
| Write-off history (12 months) | Cash that was earned but permanently abandoned |
| Staff workflow map | Who owns each step in the billing chain — and where ownership is absent |
You can't prove the migration worked. You can't hold the new vendor accountable. And you can't make a rational decision about whether migration — versus renegotiation or process redesign — is actually the right answer. Don't move blind.
Create the Open Claims Register — before go-live day
Open claims are the most financially significant casualty of poorly managed migration. When the new system goes live, administrative attention moves forward. Legacy A/R in the old system is frequently left to age, then quietly written off because nobody is watching that queue anymore.
Create an Open Claims Register and assign a named owner before you touch anything else:
| Register field | What to record |
|---|---|
| Claim ID | Unique identifier from the existing system |
| Patient and scheme | Reference detail for follow-up |
| Submission date | Date the claim was transmitted to the scheme |
| Current status | Unpaid, rejected, short-paid or pending ERA |
| Outstanding value (R) | Rand value at risk |
| Ageing bucket | 30 / 60 / 90 / 120+ days |
| Named owner | The specific person accountable for resolution — not "admin" |
| Target close date | Date by which the claim must be resolved or formally escalated |
Before go-live, the practice identified 142 open claims worth R312,600. A named staff member worked the register daily for 90 days post-migration. R241,800 was recovered that would otherwise have vanished into the old-system fog. The register cost two days to build. It returned R241,800.
The control rule
A migration plan without named accountability for legacy open claims is not a migration plan. It is a write-off schedule with a go-live date attached.
Your data is your data — get it in writing before you cancel
Your practice remains the responsible party for all patient information processed through the billing stack. That responsibility doesn't transfer to a software vendor when you sign a contract — and it doesn't disappear when you cancel one.
Before giving notice to any incumbent vendor, get written answers to these questions:
| Question to ask in writing | Why it matters |
|---|---|
| In what format will data be exported? CSV / HL7 / FHIR / SQL? |
Determines whether the export is usable in the new system |
| Is full data export included in cancellation — or charged separately? | Some practices only discover data-release fees after they've already given notice |
| How long will read-only access remain after cancellation? | Needed for scheme audit responses, medico-legal matters and record continuity |
| What happens to incoming ERAs routed to the old switcher codes? | Scheme payments can go missing in the transition gap — with no alarm raised |
| Is clinical note history exportable in a compatible format? | Clinical records must remain accessible and intact, regardless of which system holds them |
The responsible party must ensure compliance with the conditions for lawful processing. For your practice, that means data access, data integrity, retention and responsible vendor exit terms must all be controlled — before cancellation, not after.
Patient record continuity matters during system changes. A migration cannot compromise access to clinical history, billing evidence or records needed for continuity of care.
Different specialties need different migration sequences
What data matters — and what must migrate first — depends entirely on how your practice earns money. The same data means different things depending on the specialty.
| Practice type | Primary migration focus | Critical data to preserve |
|---|---|---|
| Solo GP | Booking continuity, same-day billing, chronic and PMB record migration | Chronic disease registers and benefit-check configurations |
| Radiology | RIS/PACS alignment, authorisation history, ERA reconciliation history | Modality billing templates and historical pre-authorisation records |
| Ob/Gyn | Maternity episode tracking, PMB records, ICD-10 mapping | Open maternity episodes; PMB pathway records; ongoing authorisation numbers |
| Interventional radiology | Multi-site procedure records, theatre-list data, hospital authorisations | Per-hospital authorisation audit trails; component billing configurations |
| Mental health | Session records, PMB mental health benefit history, treatment plan registers | Cumulative session counts per patient per scheme; PMB authorisation history |
| Allied health | Session billing continuity, outstanding patient balances, authorisation limits | Per-patient session counts; outstanding balance register; scheme-specific limits |
Run both systems simultaneously — don't just flip a switch
A parallel control period means both the old system and the new system are running concurrently. New claims go to the new system. The old system is maintained for legacy claim follow-up and ERA monitoring only. This is not inefficiency — it is insurance.
Solo GP: 30 days minimum. Low-value claims; fast ERA cycles.
Group or specialist practice: 60 days minimum. Higher-value claims; longer ERA cycles.
High-volume radiology or interventional: 90–120 days. Complex authorisation chains; multiple hospital ERAs; higher financial risk per claim.
| Control check during parallel period | Frequency |
|---|---|
| New system same-day submission rate vs old system baseline | Daily — first 2 weeks; weekly thereafter |
| New system rejection rate and reason-code distribution | Weekly |
| Old system Open Claims Register — progress vs target close dates | Weekly |
| ERA routing check — confirm old switcher codes still routing correctly | Weekly |
| Bank reconciliation — new system collections vs expected based on ERA receipts | Weekly |
Train on the consequence, not just the screen
Staff training that covers only screen navigation is one of the most costly kinds of training — because staff who understand the system but not the consequence make revenue-destroying errors with clean hands and good intentions.
Every training session on any billing step should answer the same question: "What happens to cash flow if this field is wrong, late or skipped?" When staff understand the financial consequence of a missed benefit check or a delayed submission, they perform differently — not because you told them to, but because they understand why.
Train on the consequence, not just the screen. A staff member who understands that a missing authorisation number delays payment by 30 days will prioritise that field differently than one who was just shown where to click it in.
Go-live is a technical milestone. These are the real success metrics.
The question to ask at 30, 60 and 90 days post-migration isn't "is everyone using the new system?" It's: does money move faster, cleaner and with fewer surprises than it did before?
The problem was not the previous system alone. Further migration is not the answer. Another diagnostic is. Sometimes the practice needs to stop blaming software for a management-control problem that will follow it to every platform it ever uses.
Outsourcing billing work is not the same as outsourcing accountability
A good billing bureau is a genuine asset. But the moment you stop receiving regular performance data is the moment you stop knowing what you're paying for. Whether you run an in-house billing function or outsource it completely, this is the minimum monthly report you should be receiving:
- Claims submitted during the period — volume and total value
- Rejection rate and dominant reason codes
- Rejection-to-correction turnaround (against SLA)
- Collections received and balances outstanding
- Current A/R ageing across all buckets (30/60/90/120+)
- Patient-side balances created and collected this period
- Write-offs approved, with named authorisation
If your bureau or in-house team cannot produce this report every month, without being asked, you're not managing a billing function. You're hoping one exists.
Before you give anyone notice — this week
- Complete the 30-day diagnostic. Quantify current monthly leakage in rands. This is your migration justification.
- Create the Open Claims Register. Every unpaid, rejected and short-paid claim — with a named owner and target close date.
- Secure your POPIA data-export clause. Confirm format, timeline, cost, ERA history inclusion and read-only access period — all in writing, before notice is given.
- Define the parallel control period. 30 days minimum for GPs; 60–120 days for specialist practices with complex authorisation chains.
- Set 90-day financial metrics. Define what "success" looks like in rand terms before the migration begins — and build them into the vendor contract.
If you're unsure whether migration or renegotiation is the right answer, GoMedPay helps practices make that determination before they commit to either. The Revenue Leakage Review is designed to answer exactly that question — with evidence, not guesswork.