A/R at a System Conversion
Nothing about a conversion changes what a payer owes or when it stops owing it. What changes is whether anyone can see the account. Balances that fail to load are not forgiven; they are unwatched, and every filing and appeal window they are spending keeps running at the same speed. The characteristic loss is not a corrupted record — it is an account that arrived intact, dated wrongly, into a report that now shows it as new.
Updated 11 min read
On this page
Key takeaways
- A conversion is the only routine event that can lose a receivable with no denial, no notice, and no write-off. The account stops being visible while its deadlines keep running.
- The most common real damage is the aging start date resetting at load, so the oldest and least collectible balances emerge from the cutover looking the freshest.
- Balances convert more reliably than the context around them. Follow-up notes, denial and appeal state, and adjustment history are what usually do not survive, and they are what make an account workable.
- Decide before the cutover whether legacy A/R is worked in the old system or the new one. The failure mode is neither: a system nobody logs into any more, holding real money.
- Reconcile the receivable immediately before and immediately after the load, and treat the difference as a required explanation rather than an expected loss.
- The old system is not disposable the day the new one is live. Under the Security Rule, disposal and media re-use are Required specifications, and addressable specifications are not optional either.
- Anything that has to be retrieved from the legacy system later — an appeal record, a proof of timely submission — should be tested for retrievability while the system is still running.
The clock does not pause for the project
A conversion is a project with a plan, phases, and a go-live date. The receivable is not part of that project's schedule and does not observe it. A claim submitted six weeks before the cutover is six weeks into its appeal window on cutover day and does not become newer because the data moved. Timely filing deadlines and appeal deadlines run on the calendar, not on the implementation timeline.
This produces the cluster's recurring shape in an acute form. The argument in unbilled and held claims is that the riskiest money is the money the reports structurally cannot show. At a conversion the practice can lose the report — for a period, everyone's attention is on whether the system works at all, and during exactly that period the ordinary machinery for noticing an aging account is degraded or absent.
The quiet failure has no error message
The start date is where the money actually goes
If only one thing from this article is acted on, it should be this one. Balances typically load into a new system carrying the date they loaded, because that is the simplest thing for a migration to do and often the only date the load reliably has. The consequence is precise: A/R aging restarts from zero for the entire book on the same day.
The report inverts
The fix is to carry the original service and submission dates through the load and to age from them, and where that is impossible, to keep the pre-conversion aging as a separate reference for the legacy population until it clears. Either is a decision someone has to make deliberately. Neither happens on its own.
Balances convert; the reasons for them often do not
Migrations are usually specified around amounts, because amounts are what reconcile and what anybody would think to check. What makes an account workable is the context attached to it, and context is both harder to map and easier to omit without the omission showing up in any total.
| Element | How it usually fares | Why it matters |
|---|---|---|
| Open balance amount | Converts, and is what the reconciliation checks. | It is the figure everyone agrees to verify, which is why a conversion can be declared successful on this alone. |
| Original service and submission dates | Frequently replaced by the load date unless carried deliberately. | The aging, the deadline calculation, and every prioritization built on either. |
| Follow-up history and call notes | Often the first thing dropped, or loaded as an unsearchable blob. | Without it every account restarts at the first touch. Work already done is repeated, and the record of what a payer said is gone — the whole point of documenting a follow-up call. |
| Denial and appeal state | Partially converts; the balance arrives, the position in the appeal sequence often does not. | An appeal in progress with no record of what level it reached, or of what was already argued, is an appeal that will be restarted or abandoned. |
| Adjustment and payment history | Commonly summarized to a net balance. | A net figure cannot be reconciled to a remittance later, and it removes the evidence behind any dispute about what was paid. |
| Credit balances | Convert, and are easy to net into a total and lose sight of. | These are usually obligations rather than assets — credit balance refunds covers why they cannot simply sit. |
The pattern is consistent: what reconciles converts, and what is needed to work the account is optional to the migration unless someone makes it mandatory. That is a specification decision taken early, usually before anyone in follow-up is consulted.
The legacy system is not disposable on go-live day
There is a pull toward decommissioning quickly — the license costs money, the hardware is old, and the project is trying to close. The receivable argues the other way, and so does the Security Rule, though it is worth being precise about what it does and does not say.
Under 45 CFR 164.310(d) (opens in a new tab), device and media controls govern the receipt, removal and movement of hardware and electronic media holding electronic protected health information. Two of its specifications are marked Required — disposal, addressing the final disposition of ePHI and the media it sits on, and media re-use, requiring removal of ePHI before media are made available for re-use. Two are marked Addressable: accountability, meaning a record of the movements of hardware and media and the person responsible; and data backup and storage, meaning a retrievable, exact copy of ePHI created when needed before movement of equipment.
“Addressable” does not mean optional, and the rule says so
Test retrieval before you need it, while the system still runs
Pick real cases — a proof of timely submission, a full remittance behind a disputed payment, an appeal file — and retrieve them from the legacy system as an exercise. Retrievability that has never been exercised is an assumption, and it will be tested for the first time under time pressure, in front of a payer or an auditor.Decide what is archived, in what form, and who can read it
An archive nobody can query is a compliance artifact rather than a business record. Whether the format is still readable, and by whom, after the application is gone is the question that decides which of those it is.Keep the retention obligation separate from the project plan
The record retention schedule is set by regulation, payer contract and state law, and it is not shortened by a decommissioning date. A conversion is a good moment to confirm what the schedule actually requires rather than to discover it afterward.Record the movement and the disposal
What hardware moved, who was responsible, and what happened to the media at the end. The regulation asks for this directly, and it is also the only evidence that disposal was done properly rather than merely intended.
Running the overlap deliberately
For a period the practice has two books. That is normal and manageable, and the failure mode is not complexity — it is ambiguity about which book an account belongs to and who is working it.
Reconcile immediately before and immediately after
Take the receivable on the day of the load and again on the day after, and require that the difference be explained rather than accepted. This is the same discipline as reconciling A/R to the general ledger and the same rule applies: a variance nobody can name is the finding, whatever its size.Name where legacy A/R gets worked, and staff it
In the old system or the new one — either can work. What fails is neither, which is the default outcome, because the team's attention follows the new system and the old one quietly becomes a place nobody logs into that still holds real money.Protect the deadline-driven work first
During a cutover, capacity is short and everything feels urgent. The accounts that cannot wait are the ones approaching a filing or appeal window, because those are the only ones where a delay is irreversible. Everything else can be late.Watch cash rather than activity for the first periods
Claim counts and productivity figures after a conversion measure the conversion, not the receivable. Cash received against expectation is the measure that tells you whether money is actually moving, and a shortfall shows up there before it shows up anywhere else.Set a date to close the legacy book, and decide what remains
An overlap without an end date becomes permanent. Fix a date on which the remaining legacy balances are either transferred, pursued deliberately, or written off as a recorded decision — which is a decision with an owner, not an account quietly ceasing to be worked.
The one check worth scheduling for the month after
Common questions
Our balances reconciled exactly after the conversion. Is the A/R fine?
It means the amounts arrived, which is worth confirming and is not the same question. A reconciliation on totals cannot detect the failures that cost the most: original dates replaced by the load date, follow-up history dropped, appeal state lost, or payment and adjustment detail summarized into a net figure. Every one of those leaves the total correct. The additional checks are cheap — compare the shape of the aging with the last pre-conversion run, open a sample of accounts and look for the notes and the original dates, and confirm that an appeal in progress still shows what level it reached.
Should we work old A/R in the old system or the new one?
Either is defensible and the choice matters less than making it explicitly. Working in the legacy system keeps the full context and avoids trusting the migration for accounts that are already at risk, at the cost of running two workflows. Working in the new system gives one queue and one set of reports, and depends on the context having converted well enough to act on. The outcome to avoid is the one nobody chooses: the work drifts to the new system because that is where attention is, and the legacy balances sit in an application people stop opening.
Can we decommission the old system once everything is loaded?
Not on the basis that the data was loaded. Retention obligations come from regulation, payer contracts and state law and are unaffected by a decommissioning date, and the practical need is separate again: proving timely submission or producing a full remittance behind a disputed payment often means going back to the original system. The Security Rule also has direct requirements when equipment and media move — disposal and media re-use are Required specifications, and creating a retrievable exact copy before equipment moves is addressable, which obliges you to assess it and document the decision rather than pass over it.
What does “addressable” actually require?
It is not a synonym for optional, which is the common reading and the wrong one. An addressable implementation specification requires the entity to assess whether it is a reasonable and appropriate safeguard in its own environment; then either implement it, or — where implementing it is not reasonable and appropriate — document why not and implement an equivalent alternative measure if that is reasonable and appropriate. The difference from a required specification is that you may reach a different answer for your environment. The obligation to consider it, decide, and write the decision down is the same either way.
How long should we expect cash to dip after a go-live?
No honest general answer exists, and any number offered would depend on payer mix, the scale of the change, how much was tested and how well the staff know the new system. What is worth doing instead is deciding in advance what you will watch and what would count as a problem: cash received against your own recent history rather than against any published figure, plus the age distribution of the book. Both are available from your own data, and both will show a real deterioration well before a productivity report will.
Key terms in this article
Defined once, on their own pages.
Continue learning
The report a conversion distorts, and the controls it tests.
A/R Aging Buckets
Why the start date is a choice — and the report that inverts when a load resets it.
Reconciling A/R to the General Ledger
The before-and-after check, and the rule that an unexplained variance is the finding.
Documenting a Follow-Up Call
The record that most often fails to convert, and what it is for.
Unbilled and Held Claims
The population no report shows — the same failure a cutover creates for the whole book.
Cash Application Controls
The controls that are supposed to keep working through a conversion, and the evidence they leave.
HIPAA Security Rule for Billing
The safeguard framework the device and media controls sit inside.
Authoritative sources
- 45 CFR § 164.310 — Physical safeguards (opens in a new tab)
Sets the device and media controls standard, requiring policies and procedures governing the receipt and removal of hardware and electronic media containing electronic protected health information into and out of a facility, and their movement within it. Its implementation specifications are Disposal (Required) — addressing the final disposition of ePHI and the hardware or media on which it is stored; Media re-use (Required) — removal of ePHI from media before they are made available for re-use; Accountability (Addressable) — maintaining a record of the movements of hardware and electronic media and any person responsible; and Data backup and storage (Addressable) — creating a retrievable, exact copy of ePHI, when needed, before movement of equipment.
- 45 CFR § 164.306 — Security standards: General rules (opens in a new tab)
Defines the Required and Addressable construction used throughout the Security Rule. Required specifications must be implemented. For an addressable specification, a covered entity or business associate must assess whether it is a reasonable and appropriate safeguard in its environment, with reference to its likely contribution to protecting ePHI, and then either implement it or, where implementing it is not reasonable and appropriate, document why not and implement an equivalent alternative measure if reasonable and appropriate. Paragraph (e) adds a continuing duty to review and modify security measures as needed and to update the documentation of them.