Field notes · Healthcare · Program leadership
Epic is building your ERP: what changes, and what doesn't
EpicOps is six applications, and Epic has said plainly that three of them are meant to replace a general-purpose ERP outright. If you're picking between Workday and Oracle in an Epic shop this year, that's now part of the decision. What hasn't changed is the seam between the clinical system and the money, which is still where these programs break.
- 1Revenue cycle to GL
- 2The encounter never closed
- 3Labor, time and pay
- 4Chart of accounts
- 5The item master
- 6Worker and provider data
- 7Testing and blame
A large health system finished an EHR go-live and, some months later, found a revenue shortfall its finance team couldn't explain. No interface had failed and no conversion had gone wrong. More than 400,000 patient encounters had never been closed in the new system. In Epic, an encounter that isn't closed never reaches coding, so it never becomes a claim. Every one of those charts sat unbilled. Once 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 had to do with 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's no room in that number for a seam nobody owns.
- 400,000+Patient encounters never closed in the new system, so never billed
- $1BRecovered, close to it, once the encounters were worked and closed
- 2 monthsAbout how long it took to get back on stable footing
- 1% to 2%The margins health systems operate on
I've 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's new in 2026 is that the vendor on the other side of that seam has started selling the thing on your side of it.
Epic's circle
What Epic actually announced
EpicOps is Epic's healthcare-native ERP. 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 line that matters most is one Epic drew itself, and most coverage skated past it. The six applications split into two groups with opposite commercial meanings.
- Live nowTeamworkStaff and space scheduling. Released November 2024. Five organizations live and eleven installing as of June 2026.
- Installs from fall 2026Time & AttendanceTimecards built from scheduled shifts, with automatic cost center assignment when staff float. Go-lives planned for 2027.
- Early 2027Credentialing and Cost AccountingProvider credentialing off the EHR provider master. Cost per procedure tied to clinical outcomes.
- Later 2027Supply Chain and FinancialsInventory, procurement and vendor management, plus general ledger, budgeting and accounts payable.
- Far end of the roadmapWorkforceHR and payroll.
Designed to coexist: Teamwork, Credentialing, Cost Accounting
Epic frames these as add-ons that run alongside both Epic and your existing ERP. Teamwork, for example, sends time and attendance data to payroll in Workday or Oracle. You can adopt them without touching your ERP decision. The catch is that each one adds an interface and a question about who owns the master data. Judge them on their own merits. None of them is a bet on anything.
Designed to replace: Supply Chain, Financials, Workforce
In Epic's words, these are "meant to replace, rather than supplement, a general-purpose ERP." Supply chain and financials arrive later in 2027, HR and payroll later still. That makes them a direct competitor to the platform you're selecting now. The catch is that they're unproven at scale, and Epic implements them with Epic staff. This is the group that belongs in your selection. Usually it isn't in it.
Epic
Designed to coexist
- Teamwork
- Credentialing
- Cost Accounting
Add-ons that run alongside Epic and your existing ERP
Your ERP
Designed to replace it
- Supply Chain later 2027
- Financials later 2027
- Workforce later still
Built by Epic, implemented by Epic staff
Your ERP's circle
What that does to a selection running right now
Most health systems selecting an ERP this year are choosing between Workday and Oracle Fusion. That's 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.
So the shortlist stays the same. What changes is the shape of the contract and the length of the bet.
-
Commit fully
Signing a long-term ERP now
Pick Workday or Oracle on functional fit, run the program, and treat EpicOps as somebody else's problem. It's defensible if your finance and supply chain requirements are deep and your renewal lands before 2032.
The risk you own: a 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'd take
Select 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 cost: you trade some discount for flexibility. Know that going in.
-
Take the add-ons, wait on the rest
Epic-first organizations
Adopt 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 own: every add-on is another interface and another fight over who owns the master data. Coexistence has a cost.
Three things about EpicOps that belong in a selection document
Epic implements it with Epic staff. There's 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 can't staff your program. It also removes your ability to bid the implementation. If you're used to running a separate integrator selection and using it to push on price, you won't have that here. Price and terms are a single negotiation with a single party.
Epic has stated the functional gaps. Health systems sharing ERP infrastructure with a university will need academic program management that isn't in the initial release, and standalone health plans, diagnostics and pharmacy are longer term. If any of those describe you, the replacement trio isn't 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 that ends with an explicit position. A technology evaluation can't settle it.
The lever
Put EpicOps in the RFP as a named scenario, even though it isn't 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. Their answers tell you a lot. Asking at all changes the shape of the offers that come back.
The overlap
The seams don't 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.
-
1
Revenue cycle to general ledger
Fails as a close that won't reconcile
The mapping between them is a design decision that someone has to own.
Epic sideEpic Resolute (hospital billing and professional billing) produces the charges, contractual allowances, write-offs and adjustments.
ERP sideYour ERP owns the GL.
-
2
The encounter that never closed
Fails as revenue that was earned and never billed
It sits upstream of every interface.
Epic sideIf clinicians don't close encounters, no downstream system can bill them. Over 40% of providers now report denial rates of 10% or higher, with incomplete documentation the leading cause.
ERP sideYour ERP will show a clean GL for money you never collected.
-
3
Labor, time and pay
Fails as pay that breaks at go-live
Hours, pay and cost each live in a different view.
Epic sideClinical hours are captured in scheduling. Epic Teamwork and the coming Time & Attendance module put a fourth possible owner in this chain.
ERP sideHours are paid in the ERP or a workforce management platform, then costed to service lines in a third view.
-
4
Cost centers and the chart of accounts
Fails as reporting rebuilt after go-live
The two won't map one to one, and the gap doesn't resolve itself.
Epic sideClinical hierarchies run on service lines, departments and locations.
ERP sideERP financial models run on companies, cost centers and worktags.
-
5
Supply chain and the item master
Fails as cost per case nobody trusts
One item master 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.
Epic sidePreference cards and consumption in Epic OpTime.
ERP sidePurchasing and inventory.
-
6
Worker and provider master data
Fails as nobody being able to say which number is right
Your HR system is upstream of Epic.
Epic sideWorker, provider, position and department data feed Epic user and provider records, security classes and provisioning.
ERP sideOn a recent program, 10% of "active" worker records were duplicates or carried termination dates that contradicted payroll history.
-
7
Testing load and the blame path
Fails as two vendors pointing at each other
The same finance, HR and IT people get asked for double the hours in the same weeks, and there's 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. It's the most common sequencing mistake and the easiest to price before anyone signs.
If the EHR goes live first and the ERP lands 12 to 18 months later, the charge-to-GL interface gets built against the legacy ERP, tested, run in production, and then rebuilt against the new one. That means 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.
Sequence AEHR live first, ERP later
Built twice
The revenue-to-GL interface is built against the outgoing ERP, then built again. Budget both, or the second one becomes a change order.
Sequence BERP live first, EHR later
Built once
The interface is built once against the new GL, but your ERP go-live now depends on a clinical system that's still moving.
Sequence CBoth at once
Built once
One interface and one test cycle, with the highest simultaneous demand your finance and IT teams will ever face. It's viable only with protected resources.
The decision. There's no free option. Pick deliberately, price the throwaway work, and put the choice in front of the executive committee instead of letting it fall out of two independent schedules.
What the program lead owns
The mapping design and the dispute path: the decision about who's right when the two systems disagree, and how fast that decision gets made during close. The interface code belongs to someone else.
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's the structure every financial report in both systems gets built on, and it can't 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.
What the program lead owns
Getting Finance and clinical operations in a room early, forcing the decision, and refusing to let either program build reports until it's settled.
Sequencing 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, more than the calendar, the budget or the software.
- Q1EHR: BuildERP: Select
- Q2EHR: Integrated testERP: Design
- Q3EHR: Dress rehearsalERP: Build
- Q4EHR: FreezeERP: Test
- Q5EHR: Go-liveERP: Mock convert
- Q6EHR: StabilizeERP: Cutover
The overlapping 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're one program.
Run one milestone calendar
The two programs can keep separate work plans. They can't 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 want to find that out in planning, long before 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 don't 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, as it should. Pretending the two programs have equal standing is how ERP milestones end up parked next to an EHR go-live and then slip. Name the priority out loud, agree the shared-resource rules well before the crunch, 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 isn't.
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, and who gets called at 9pm on day four. If the first close is the first time anyone has thought about this, you'll spend a quarter chasing reconciling items and rebuilding Finance's confidence.
The real test is whether two programs keep deciding together long enough to reach a clean close.
Both circles
Check your own exposure
Most organizations are further into this than they think, because the add-on modules tend to arrive through departmental decisions, outside the ERP program.
0 of 7
- 0 to 1: low exposure. EpicOps is a watch item for now. Revisit it when your renewal window opens or when an add-on module shows up in a departmental budget.
- 2 to 3: real exposure. Write a one-page position for the steering committee: what you're choosing, what you're leaving out, and what would change your mind. That page is cheap now and expensive to reconstruct in 2028.
- 4 to 5: high exposure. Put EpicOps in the selection document as a named scenario, and get term length, module reduction rights and renewal flexibility priced before you shortlist.
- 6 to 7: critical exposure. You're about to make a long-term commitment against an unresolved question, with a clinical program in the same window. Slow the contract down and keep the program moving. The sequencing decision and the term structure both need an owner this quarter.
Cheap to prevent in design, expensive to find in test
EpicOps never appears in the selection document.
Fix: name it as a scenario, record the position, and get shorter terms and reduction rights priced.
GL mapping settled late, or settled by the integrator.
Fix: Finance owns the mapping. Sign it off before integration build starts.
Chart of accounts deferred as a design detail.
Fix: force the decision in the first 60 days. No reports get built in either system until it's locked.
Interface analysts committed to both programs at once.
Fix: name them, count their capacity, and protect it in writing before either schedule is baselined.
Two test calendars competing for the same super users.
Fix: one integrated calendar with named resource commitments and protected build time.
Cross-system defects with no tiebreaker.
Fix: name a client-side arbiter before test, someone who works for neither vendor. Defects should get decided in hours.
Nobody owns encounter closure rates after go-live.
Fix: put open encounters on the hypercare dashboard from day one, with a named owner and a daily number.
The first close is the first time anyone planned the close.
Fix: dry-run it during hypercare planning. Assign reconciliation owners and tolerances up front.
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. With two releases a year, that's six weeks of a team's life every year spent 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.
Treat security as design work. 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 wrong. 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.
The space between
Someone has to own the seam
The failure 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 doesn't 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.
The clinical program leadMeasured on the clinical go-live
The ERP integratorMeasured on their scope
Client side
That's the role that gets skipped. It's also the one that decides whether your first close after go-live is a routine week or a quarter of cleanup.
Where 9Nation fits
I lead ERP programs from the client side in health systems running Epic, and what I own is the seam between the two platforms. The collision checklist is the two-page version of all of this: 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, June 24, 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, August 3, 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 come 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 doesn't cover configuring the clinical platform. It's general guidance and isn't a vendor recommendation.
The seven seams, on two pages.
The collision checklist: every seam with its failure mode and its owner, the sequencing decision priced three ways, and the EpicOps questions to put in your selection document before you sign a ten-year term.
Two programs, one close.
If an ERP program and a clinical program are moving at the same time, the seam needs an owner on your side of the table. Let's talk about where that role pays for itself.