A large health system finished an EHR go-live and, some months later, found a revenue shortfall its finance team could not explain. The cause was not a failed interface or a bad conversion. More than 400,000 patient encounters had never been closed in the new system. In Epic, an encounter that is not closed never reaches coding, so it never becomes a claim. Every one of those charts sat unbilled. After the encounters were worked and closed, the organization recovered close to $1 billion and was back on stable footing in about two months.
Nothing in that failure was about which ERP they bought. It happened in the space between what clinicians did and what the organization got paid for, which is the same space where ERP programs running next to Epic go wrong. Health systems operate on margins of 1% to 2%. There is no room in that number for a seam nobody owns.
I have run a full ERP platform inside a merged health system: finance, HCM, payroll, supply chain, and a parallel time and attendance track that had to stay in step or pay would break at go-live. The clinical estate had its own leadership, its own release calendar, and its own opinion about whose date mattered. The hardest problems were never inside either system.
What is new in 2026 is that the vendor on the other side of that seam has started selling the thing on your side of it.
01What Epic actually announced
EpicOps is Epic's healthcare-native ERP. It is not a rumor or a roadmap slide. Epic's VP of EpicOps has described it publicly as six applications: Teamwork, Credentialing, Cost Accounting, Supply Chain, Financials, and Workforce, which covers HR and payroll.
Teamwork, the staff scheduling application, shipped in November 2024. As of June 2026, five organizations were live and eleven more were installing. The rest arrives on a published cadence.
The EpicOps rollout
As stated by Epic. Dates are Epic's, not an analyst's estimate.
Workforce, covering HR and payroll, sits at the far end of the same roadmap.
The line that matters most is one Epic drew itself, and most coverage skated past it. The six applications are not one product with one intent. They split into two groups with opposite commercial meanings.
Your EHR vendor is now a bidder in your ERP selection, whether or not you invited it. You do not have to pick EpicOps. You do have to write down why you did not, because a CFO is going to ask that question in 2028 and "nobody raised it" is not an answer.
02What that does to a selection running right now
Most health systems selecting an ERP this year are choosing between Workday and Oracle Fusion. That is still the live decision for the next several years. Nothing in the EpicOps roadmap is mature enough to displace a modern ERP in finance or supply chain today, and the outside view is that 2027 is the earliest anyone should expect meaningful breadth.
What changes is not the shortlist. It is the shape of the contract and the length of the bet.
Commit fully
Signing a long-term ERP nowPick Workday or Oracle on functional fit, run the program, and treat EpicOps as somebody else's problem. Defensible if your finance and supply chain requirements are deep and your renewal lands before 2032.
The risk you ownA ten-year term signed in 2026 outlives the arrival of a competitor your own EHR vendor is building.Commit, with the exits written in
The position I would takeSelect on today's requirements, then negotiate a shorter initial term, module-level flexibility, and the right to reduce scope at renewal without penalty. You still get the platform you need. You stop paying for a bet nobody can win yet.
The costYou trade some discount for flexibility, and you have to know that going in.Take the add-ons, wait on the rest
Epic-first organizationsAdopt Teamwork or Cost Accounting where they solve a real problem, keep your ERP for finance and HR, and revisit the replacement trio once there are reference customers at your scale.
The risk you ownEvery add-on is another interface and another master data ownership fight. Coexistence is not free.Three things about EpicOps that belong in a selection document
Epic implements it with Epic staff. There is no competitive integrator market behind EpicOps the way there is behind Workday and Oracle. That removes a whole category of contract risk, the bait and switch, the change order war, the integrator who cannot staff your program. It also removes your ability to bid the implementation. If you are used to running a separate integrator selection and using it as leverage, that lever does not exist here. Price and terms are a single negotiation with a single party.
The functional gaps are stated, not hidden. Epic has said that health systems sharing ERP infrastructure with a university will need academic program management that is not in the initial release, and that standalone health plans, diagnostics and pharmacy are longer-term. If any of those describe you, the replacement trio is not a 2027 conversation.
Vendor concentration becomes a board question. Putting the clinical record, the revenue cycle, the supply chain and the general ledger inside one vendor is a real simplification and a real dependency. That tradeoff belongs in a governance discussion with an explicit position, not in a technology evaluation.
Put EpicOps in the RFP as a named scenario, even though it is not bidding. Ask Workday and Oracle to price a five-year term with module-level reduction rights at renewal, and ask them what happens to your discount if you later move supply chain to Epic. The answers are informative, and the question alone changes the shape of the offers you get back.
03The seams do not go away
Whether your ERP sits beside Epic or eventually inside it, the same handful of places decide whether the first close after go-live is a routine week or a quarter of cleanup. None of them lives inside either system. All of them land in Finance.
A single ERP program is hard. Two concurrent programs are worse than twice as hard, because the difficulty compounds at the interfaces. Discovery on one program I ran listed 50 integrations. The real number was closer to 90 once we mapped every handshake to banks, carriers, tax engines and downstream apps. That was a single-platform program. Put a clinical system with its own interface engine and its own release calendar next to it and the count rises again, along with the number of teams who each believe someone else owns the handshake.
| The seam | Where it actually lives | |
|---|---|---|
| 1 | Revenue cycle to general ledgerFails as: a close that will not reconcile | Epic Resolute, hospital billing and professional billing, produces the charges, contractual allowances, write-offs and adjustments. Your ERP owns the GL. The mapping between them is a design decision, not an interface spec. |
| 2 | The encounter that never closedFails as: revenue that was earned and never billed | Upstream of every interface. If clinicians do not close encounters, no downstream system can bill them, and your ERP will show a clean GL for money you never collected. Over 40% of providers now report denial rates of 10% or higher, with incomplete documentation the leading cause. |
| 3 | Labor, time and payFails as: pay breaks at go-live | Clinical hours captured in scheduling, paid in the ERP or a workforce management platform, costed to service lines in a third view. Epic Teamwork and the coming Time & Attendance module put a fourth possible owner in this chain. |
| 4 | Cost centers and the chart of accountsFails as: reporting rebuilt after go-live | Clinical hierarchies run on service lines, departments and locations. ERP financial models run on companies, cost centers and worktags. They will not map one to one, and the gap does not resolve itself. |
| 5 | Supply chain and the item masterFails as: cost per case nobody trusts | Preference cards and consumption in Epic OpTime, purchasing and inventory in the ERP, and one item master that both are supposed to agree on. Perioperative supply waste in the 10% to 20% range is a common finding, and it hides in exactly this gap. |
| 6 | Worker and provider master dataFails as: nobody can say which number is right | Your HR system is upstream of Epic. Worker, provider, position and department data feed Epic user and provider records, security classes and provisioning. On a recent program, 10% of "active" worker records were duplicates or carried termination dates that contradicted payroll history. |
| 7 | Testing load and the blame pathFails as: two vendors pointing at each other | The same finance, HR and IT people asked for double the hours in the same weeks, and no named tiebreaker when a defect sits between two systems. |
Seam 1 in practice: the interface you build twice
This one deserves its own arithmetic, because it is the most common sequencing mistake and the easiest to price before anyone signs.
If the EHR goes live first and the ERP lands twelve to eighteen months later, the charge-to-GL interface gets built against the legacy ERP, tested, run in production, and then rebuilt against the new one. Two builds, two test cycles, two parallel runs, two reconciliation exercises for Finance, and a period where the people who know how the first one works have rolled off.
The mapping design and the dispute path. Not the interface code. The decision about who is right when the two systems disagree, and how fast that decision gets made during close.
Seam 4 in practice: settle the chart of accounts in the first 60 days
This is the item most often deferred, because it looks like a design detail and belongs to nobody in particular. That detail decides the schedule. It is the structure every financial report in both systems gets built on, and it cannot be re-cut after go-live without re-implementing reporting on both sides. It also decides whether cost accounting works later, in Epic or in a third-party tool, because cost accounting reads the GL.
Getting Finance and clinical operations in a room early, forcing the decision, and refusing to let either program build reports until it is settled.
04Sequencing an ERP against an EHR go-live
Every inbound and outbound HL7 interface to Epic runs through Epic Bridges, and the people who build and maintain those interfaces are a small, named group. That group is the constraint. Not the calendar, not the budget, not the software.
Where the two calendars actually collide
The amber quarters are the problem. ERP build, test and mock conversion land inside the EHR freeze and go-live window, competing for the same interface analysts, the same super users and the same department managers. On a slide the two programs look independent. On a resource plan they are one program.
Run one milestone calendar, not two
The two programs can keep separate work plans. They cannot keep separate milestone calendars. Freeze dates, mock conversion windows, integration test cycles and go-live sit on one page that one person maintains. If a clinical release lands in the middle of your final mock conversion, you find that out in planning, not in the command center.
Build a joint governance layer, and keep it thin
On the merged health system program I ran a three-tier model: executive steering, a joint steering committee with the integrator, and cross-functional and workstream leads. Each level had defined decision authority and a clear escalation path. Most decisions were made at the workstream level. A smaller share escalated to program leadership. Only the few that mattered reached the executive committee.
That distribution is the whole trick. On a dual program you need one joint body above both programs with real authority over the seam items, meeting rarely and deciding fast. What you do not need is a third steering committee that re-decides what the other two already settled.
Accept that the clinical program wins every tie
Patient safety outranks a financial close, and it should. Pretending the two programs have equal standing is how ERP milestones end up parked next to an EHR go-live and then quietly slip. Name the priority out loud, agree the shared-resource rules before the crunch rather than during it, and place ERP milestones deliberately away from the clinical dates. A program lead who says this in month one is credible. One who discovers it in month fourteen is not.
Protect the close
Decide before go-live what the first three month-end closes look like with both systems live. Who reconciles what. What the tolerance is. Who gets called at 9pm on day four. If the first close is the first time anyone has thought about this, you will spend a quarter chasing reconciling items and rebuilding Finance's confidence.
The real test happens well past whether either system configures. It is whether two programs keep deciding together long enough to reach a clean close.
05Check your own exposure
Most organizations are further into this than they think, because the add-on modules arrive through departmental decisions rather than through the ERP program.
EpicOps exposure check
06Cheap to prevent in design, expensive to find in test
Four more that carry across both programs
Adopt the delivered process, in both systems. At one client, about 80 small customizations added three weeks of regression testing to every release. Two releases a year. Six weeks of a team's life, every year, maintaining decisions nobody remembered making. Both platforms ship frequent releases, so every customization you carry, you carry twice a year, forever.
Rationalize reporting before you migrate. On one program, 400 "critical" legacy reports collapsed to 90 once we checked them against the actual run logs. Nobody asked for the other 310 again.
Security is a design discipline, not a go-live task. I watched an end-to-end testing cycle stop for a full week because one security role exposed compensation data far wider than intended. Every test script that touched pay had to pause. The build was fine. The design decision was not. In a health system you have PHI on one side and compensation data on the other, and the role design has to be right before testing.
Adoption is the number that matters. On the merged health system program, user adoption reached 94% against preset targets. Going live is a date. Adoption is evidence that people actually moved onto the platform. On a dual program your clinical and administrative staff absorb two changes at once, so plan the change load with the same rigor you plan the training.
Someone has to own the seam
The failure mode on concurrent clinical and ERP programs almost never sits in the software. Both platforms work. The failure is governance: two programs, two vendors, two sets of decision rights, and a seam between them that nobody was explicitly given.
EpicOps changes the vendor map and the contract math. It does not change that. If anything it sharpens the question, because the organization now has to hold a position on whether the seam should exist at all in five years, and somebody has to be accountable for that answer.
Not the clinical program lead, who is measured on the clinical go-live. Not the ERP integrator, who is measured on their scope. Someone on the client side of the table with authority over both, whose job is the space between the systems.
That is the role that gets skipped, and it is the one that decides whether your first close after go-live is a routine week or a quarter of cleanup.
I lead ERP programs from the client side in health systems running Epic, which means owning the seam rather than either platform. The checklist below is the two-page version of everything above: the seven seams, the collision calendar, and the EpicOps questions that belong in your selection document.
Related: Selecting and negotiating with your System Implementer, what Workday really costs, and healthcare ERP programs.
Notes and sources. EpicOps module list, rollout dates, adopter counts and the coexist-versus-replace distinction come from Epic's VP of EpicOps, Aparna Sridhar, interviewed by Healthcare IT Today, 24 June 2026, and from Epic's published roadmap as reported by ERP Today and Surety Systems. The unclosed-encounter case, the recovery figure and the 1% to 2% margin context are from Healthrise, 3 August 2026; denial-rate figures are from the Experian Health 2025 State of Claims survey cited in the same release. Perioperative supply waste of 10% to 20% and the coexistence integration questions are from Surety Systems' EpicOps analysis. Epic Bridges as the interface engine for inbound and outbound HL7 traffic, and Resolute covering hospital and professional billing, are Epic product facts. Field anecdotes are drawn from programs I led, anonymized.
Scope note. This is written from the ERP program leadership seat. It covers what the client-side program leader owns when an ERP program runs alongside a clinical estate, and how the EpicOps roadmap changes an ERP selection. It stops short of configuring the clinical platform, and it is general guidance rather than a vendor recommendation.
