Outcomes Articles

Before You Automate Finance, Find the Systems You're Still Paying For

October 26, 2026

About This Report

Featuring insights from Jeff Norton, Erik Johnson, and Jeff Thomas hosted by our CEO, Saul Marquez.

The replacement system is live. The old software bill is still arriving. That can happen when a healthcare organization moves to a new electronic health record but still needs patient information stored in its predecessor. A successful launch hasn't necessarily removed the expense it was supposed to replace.

For finance and IT leaders, that gap matters when the next automation proposal arrives. The new platform may improve a difficult process, yet leave contracts, historical records and support work untouched. Evaluating only the new capability can miss the obligations that keep the old cost in place.

Before signing, examine three things together: the work you want to improve, the information you must preserve and the systems you can actually retire. Separate Outcomes Rocket conversations with Jeff Norton, Erik Johnson and Jeff Thomas help connect those decisions without confusing a finance-platform purchase with an EHR replacement. The operational improvement must justify the purchase, including what remains after launch.

Define the Finance Improvement Before Choosing the Feature

What would an earlier month-end close actually change? In Saul Marquez's Outcomes Rocket conversation with Jeff Norton, VP of Business Development at Multiview Financial, faster reporting matters because executives and board members can make decisions with more timely financial information. Start with the decision your team needs to make, not a promised percentage reduction in closing time.

That outcome should guide the technology purchase. In the conversation with Jeff Norton, the emphasis was on removing processes that prevent capable employees from doing effective work, rather than treating automation as a plan to replace people. Start by identifying where finance staff spend time correcting, transferring or waiting for information. Make the workflow repeatable, establish a dependable financial system of record and then determine where automation would help.

Invoice processing offers a straightforward example. Instead of having an employee manually rekey information from incoming invoices, software could capture those details, populate the appropriate fields and support timely payment. The potential improvement is easy to understand, but its value still depends on the organization's existing workload, accuracy requirements and implementation.

The conversation also makes software purchasing more concrete than a subscription price. Existing contract obligations, implementation, data conversion and security all affect the commitment. The promised improvement needs an acceptance test, so the team can distinguish a convincing demonstration from a workflow that works after launch.

Before approving the investment, document how the process works today, what improvement is expected and how users will verify that it works after implementation. A vendor's advertised capability should be evaluated against the team's actual responsibilities.

Defining the improvement is only part of the purchase. The team also needs to know which older systems and obligations will remain after it goes live.

Keep the Records, Not Necessarily the Application

When healthcare organizations merge or replace electronic health record systems, the older applications don't always disappear. In the Outcomes Rocket conversation with Erik Johnson, VP of Marketing at Harmony Healthcare IT, the host described organizations maintaining multiple EHR licenses because historical patient information remains inside those systems. Erik affirmed the problem and discussed preserving access to the information without necessarily maintaining the original application.

That distinction creates an opportunity for finance and IT leaders. The conversation with Erik Johnson treats historical data as information that must remain accessible, rather than material placed in a closed archive. Healthcare organizations may need decades of clinical, financial and operational records for patient care, reporting and other continuing responsibilities. Preserving those records requires understanding how they'll actually be used.

Before identifying an application for retirement, ask which employees still retrieve its records, what information they need and how frequently they use it. A clinician reviewing an older patient record has different requirements from a finance employee researching a historical transaction. Both need reliable access, but neither necessarily needs every function of the original application.

The evaluation should also cover migration requirements, applicable retention obligations, security, retrieval methods and ongoing support costs. Have the responsible users test representative records before approving retirement. Compare the cost of maintaining the existing application with the full cost of preserving access another way, including transition expenses.

Some systems will still need to remain operational. Others may exist primarily because nobody has established a workable alternative for accessing their information. Erik Johnson's conversation doesn't establish that every legacy application can be decommissioned or that an archive automatically satisfies every obligation.

An access plan does not remove the old system by itself. The organization still has to carry out the change and manage what replaces it.

Make Retirement Part of the Implementation

Adding new technology can be easier than removing what's already there. In a separate Outcomes Rocket conversation, Jeff Thomas, SVP and Chief Technology Officer at Sentara Health, described the organization's years-long effort to reduce the number of systems it operates. His account puts particular emphasis on the difficulty of removing accumulated technical debt, rather than simply introducing another capability.

The Sentara conversation describes an eight-year effort, moving from a reported range of 1,300 to 1,500 systems to roughly 500 to 600. That is not a weekend cleanup. Architecture, cloud infrastructure, lifecycle management and financial operations practices, often called FinOps, all figure in the account of reducing complexity while continuing to introduce new capabilities.

These are reported organizational results, not an audited savings calculation or a promise that another health system can reproduce them. The purchasing lesson is to budget for the work of retirement, not merely the installation of a replacement.

People also determine whether the change succeeds. Jeff Thomas emphasized supporting both end users and internal IT staff as technology and responsibilities change. Employees need to understand how their work will operate after implementation, while technology teams need ownership of the systems being retired, the information that remains accessible and the services that continue.

This means assigning responsibilities beyond installing the replacement. Who approves shutting down the old application? Who verifies that necessary information remains available? Who supports users when established workflows change? Who monitors whether operating costs actually decline?

For finance and IT, the purchasing review should distinguish three things: the capability being added, the existing burden being removed and the responsibility the organization must retain. Those decisions may unfold over multiple stages rather than a single deployment.

A go-live date answers when the new platform starts. It doesn't answer when an old contract ends, when records are verified in their new location or when staff can stop supporting the predecessor. Put those events in the implementation plan as separate commitments.

Review the New Capability and the Old Obligation Together

Before approving another platform, bring the finance lead, IT owner, an operational user and the appropriate records or security specialists into one purchasing review. Ask the vendor to demonstrate the promised improvement against the work your team actually performs. The finance conversation with Jeff Norton reinforces the importance of testing whether an advertised use case works as claimed.

Keep the purchasing decision on one page, with five entries:

Work: The current process, baseline and expected improvement.
Proof: The test an operational user must pass before acceptance.
Access: The records that must remain retrievable and who verifies them.
Cost: Transition expenses, continuing support and contracts that can actually end.
Ownership: The person accountable for each change and its approval.

For each proposed retirement, identify the evidence that permits it and the person authorized to approve it. For each retained system, explain why it remains necessary. A cost that cannot yet end belongs in the business case, not in an assumed savings column.

If the improvement is measurable and the continuing obligations are understood, proceed with a bounded implementation. If retirement depends on untested access arrangements or unsupported savings, narrow the scope or revise the plan. Keeping a necessary system may still be the right decision.

Don't approve the new capability without naming the old obligation that stays, the one that ends and the person responsible for each.

About the Conversations

These are three separate Outcomes Rocket conversations, not a shared case study. During the time of recording, the guest names and titles were as follows: Jeff Norton, VP of Business Development at Multiview Financial. Erik Johnson, VP of Marketing at Harmony Healthcare IT. Jeff Thomas, SVP and Chief Technology Officer at Sentara Health.