Epic Resolute Explained: Hospital Billing, Professional Billing and Integration

Part of our complete guide to how Epic FHIR integration works.

Epic Resolute is Epic's revenue cycle and billing application. It turns the charges captured during care into claims, sends them to payers as X12 837 files, and posts the 835 remittances that come back. It has three parts: Resolute Hospital Billing (HB) for facility charges, Resolute Professional Billing (PB) for clinician charges, and Single Billing Office (SBO), which combines the two into one patient statement.

All Epic modules in one place: see our Epic modules list for what each module does and where apps integrate.

If you are building the claims or remittance side of a Resolute integration, see our X12 EDI integration services.

Revenue is where an Epic integration gets unforgiving. A reporting feed can be a day late, and nobody panics. A claims feed that drops 837 files, or a payment-posting process that misapplies an 835, costs the hospital real money and real staff time. Epic Resolute is the module at the center of that, and any vendor working near the revenue cycle has to understand how it moves money.

This guide explains Epic Resolute for the people who scope and build revenue-cycle integrations: what Resolute is, how Hospital Billing and Professional Billing differ, how claims and remittance actually flow, and where third-party systems connect. For the full module-by-module view, our Epic integration services is the hub this guide links back to.

What is Epic Resolute?

Resolute is Epic's revenue-cycle module. It takes the charges generated during care, turns them into claims, sends those claims to payers, and posts the payments that come back. It splits into Hospital Billing for facility charges, Professional Billing for clinician charges, and a Single Billing Office model that unifies the two for the patient. If money moves through Epic, it moves through Resolute.

The reason Resolute matters to integrators is that the revenue cycle is rarely self-contained. Claims go out to clearinghouses and payers, remittances come back, eligibility is checked against external services, and analytics tools pull billing data for reporting. Each of those is an integration point with its own format and failure modes. Before any of them goes live, the vendor still has to be connected to Epic, which the full Epic integration guide walks through from sandbox to production.

Hospital Billing, Professional Billing, and SBO

The HB/PB distinction confuses people outside the revenue cycle, so it is worth getting right.

Hospital Billing (HB) handles institutional charges, the facility side, and produces 837I claims on the UB-04 standard. 

Professional Billing (PB) handles the clinician's professional charges and produces 837P claims on the CMS-1500 standard. 

Single Billing Office (SBO) combines HB and PB so the patient receives one statement instead of two, which is simpler for patients and increasingly common. Which of these a hospital runs shapes the claim formats and workflows your integration has to support.

How claims and remittance flow

Every Resolute integration handles two opposite flows, and keeping them straight is half the battle.

On the way out, Resolute generates 837 claim files, 837P for professional and 837I for institutional, and sends them to a clearinghouse such as Waystar, Availity, Change Healthcare, or Trizetto, which forwards them to the payer. On the way back, the payer returns an 835 Electronic Remittance Advice that carries payment and adjudication details. Resolute's posting rules auto-post those payments, matching them to the right charge lines by payer ID, procedure code, and contract rates, applying contractual adjustments along the way. For how the two files differ and how each 835 payment matches back to its 837 claim, see our 835 vs 837 comparison.

Denials live inside that 835. When a payer denies or reduces a line, the reason arrives as CARC and RARC codes, and well-configured Resolute routes those to denial work queues so staff can act on them. A revenue-cycle integration that ignores denials leaves money on the table.

When the 835 does not match the bank deposit

Posting is only finished when the 835 and the bank deposit agree. Four cases cause most mismatches:

• Provider-level adjustments. The PLB segment carries adjustments that are not tied to one claim, for example interest or the recoupment of an earlier overpayment. They change the paid total, so the claim lines alone will not add up to the deposit.
• Reversals and corrections. A payer can reverse a claim it already paid in a later 835, using claim status code 22 in CLP02, and then send the corrected claim. Posting has to undo the first payment, not add to it.
• Trace numbers. The TRN segment of the 835 carries the check or EFT trace number. Match it to the trace number on the bank's EFT record to pair the remittance with the deposit.
• One without the other. When an ERA arrives without a deposit, or a deposit arrives without an ERA, hold it in a work queue and do not auto-post until both are present.

For field-level detail, see 835 matching in detail.

Where Resolute integrations connect

Most revenue-cycle work clusters around three connection points.

Clearinghouse integration covers 837 claim submission, the acknowledgments that come back (999 for file syntax, 277CA for claim acceptance or rejection), and claim status inquiry and response (276/277), usually through one of the major clearinghouses. Payment posting automates cash by auto-posting 835 ERAs, applying contractual adjustments, and matching payments to charges so staff are not keying remittances by hand. Denials and analytics use the CARC/RARC data to route denials to work queues and to feed revenue dashboards that show where money is stuck. If you are building near any of these, the data contracts and edge cases are where projects live or die.

Who owns what

The gotchas that cost revenue

The revenue cycle punishes small mistakes, so these deserve attention:

• Claim format precision. 837P and 837I have strict requirements, and payers add their own edits. A malformed claim is a rejected claim and a delayed payment.
• Posting rule accuracy. Auto-posting logic that misapplies payments or adjustments creates reconciliation work that wipes out the time it was meant to save.
• Denial handling. Denials buried in 835 files that never reach a work queue are lost revenue. Routing them correctly is essential.
• Clearinghouse specifics. Each clearinghouse has its own connection and quirks. "We support 837" is not the same as "we are live with your clearinghouse."
• PHI and financial data security. Revenue data is both PHI and financially sensitive, so access control and audit logging are mandatory.

Resolute, reporting, and your stack

Revenue-cycle analytics usually reads billing data out of Clarity or Caboodle rather than querying Resolute directly, the same pattern as any other Epic reporting; our Epic Clarity guide and Epic Caboodle guide cover those layers. For real-time financial transactions, Epic also exposes targeted web services; our guide to third-party Epic integration maps those methods.

Inside an 837 claim

It helps to see what a claim integration is really moving. An 837 is an X12 EDI file, a set of segments and loops rather than human-friendly text. A small slice of an 837P carries the billing provider, the subscriber, the claim, and the service lines.

This is a fragment for illustration. It omits the envelope (ISA/GS/ST), submitter, receiver and other required loops, and will not pass validation as a file.

NM1*85*2*FAMILY CLINIC*****XX*1234567893~
SBR*P*18*******MC~
CLM*PATACCT123*250***11:B:1*Y*A*Y*Y~
LX*1~
SV1*HC:99213*125*UN*1***1~
DTP*472*D8*20260518~

Every segment has a job: NM1 identifies a party, CLM carries the claim, SV1 a professional service line with its procedure code and charge. Payers layer their own edits on top of the X12 rules, so a file that passes a generic validator can still be rejected by a specific payer. This is why "we support 837" and "we are live and paid through your clearinghouse and payers" are very different statements.

Why denials deserve their own workflow

Denials are where revenue quietly leaks. When a payer reduces or rejects a line, the reason rides back inside the 835 as CARC and RARC codes. Well-run Resolute setups translate those codes into routed work queues so staff can correct and resubmit, and they feed the same data into dashboards that show denial rate by payer, by reason, and by service line. An integration that posts payments but ignores denials looks like it is working while steadily losing money. Treating denial routing as a first-class part of the build, not an afterthought, is what protects the bottom line.

Charge capture is where it starts

Clean claims depend on clean charges. Resolute relies on accurate charge capture upstream, from charge routers and the clinical documentation that drives coding. When an integration touches charge capture, for example, pushing charges from an external system into Epic, the precision required is high: a missed or miscoded charge becomes a denied claim weeks later. Scoping a Resolute project well means looking at the whole path from the charge to the posted payment, not just the claim file in the middle.

How we approach Epic Resolute work

We build revenue-cycle integrations for healthtech companies. The formats and failure modes above are the ones we test for in claim and remittance integrations.

We build to HIPAA requirements, sign BAAs and are ISO 27001:2022 certified, which matters when both PHI and financial data are in scope. The pattern we see is that revenue-cycle integrations succeed when claim formats, posting rules, and denial handling are designed together, because a gap in any one of them shows up as lost or delayed cash.

Eligibility, prior authorization, and the front end

Clean revenue starts before the claim. A large share of denials trace back to eligibility and prior-authorization problems at registration, not to billing errors later. Resolute integrations often extend to real-time eligibility (270/271) checks and prior-authorization workflows, so coverage is verified while the patient is still in front of you rather than weeks later when a claim bounces. Building these front-end checks into the flow reduces the denial volume the back end has to work.

This is also where Epic's web services come in. Real-time financial transactions such as eligibility do not fit the nightly reporting model or the batch 837/835 exchange; they need a synchronous call, which Epic exposes through targeted web services. A complete revenue-cycle integration usually spans both: synchronous checks at the front end and batch claims and remittance at the back.

The pattern that works is to map the whole revenue cycle once, from registration and eligibility through charge capture, claim submission, remittance, and denials, and then decide which steps you are integrating and which you are leaving to Epic. Revenue leaks at the seams between these steps, so naming the seams explicitly is the most useful thing a scoping exercise can do, because each seam is a place where a charge, a claim, or a payment can fall through and quietly become lost revenue.

What is Epic Resolute Professional Billing?

Epic Resolute Professional Billing (PB) is the part of Resolute that bills for clinicians' professional services, such as an office visit or a surgeon's fee. It sends professional claims as X12 837P files, the electronic form of the CMS-1500, and works the payments and denials that come back.

The University of Iowa's Epic training pages describe PB as Epic's patient accounting product for professional fees, and Hospital Billing (HB) as the product for facility fees. In a Single Billing Office (SBO) setup, the self-pay parts of HB and PB are combined for the guarantor, the person responsible for paying.

Who works on Epic Resolute

Epic Resolute analysts build and support the billing system, usually specializing in PB or HB. They maintain charge rules, claim edits, work queues and payment posting, and they work with the billing office, the clearinghouse and the interface team when claims or payments fail.

• PB analysts focus on professional charges, 837P claims and clinic billing workflows.
• HB analysts focus on facility charges, 837I claims and hospital account workflows.
• Billing staff use Resolute work queues every day to fix claims, follow up on denials and post payments.

Epic runs its own training and certification for each application. Access to it usually comes through an organization that uses Epic or works with it, so check the current rules with Epic or your employer before planning around a certificate.

Planning an Epic billing or claims integration? See our Epic integration services and our revenue cycle software work, or talk to our team.

Where to start

List the revenue-cycle touchpoints you actually need: which claim types, which clearinghouse, whether you are posting 835s, and whether denials route into a queue. That scope decides the formats and integration points your project has to cover.

If you want help scoping or building a Resolute integration, see our Epic integration services and our claims and remittance integration work, or reach out to talk through your revenue-cycle workflows.

Related guides

• Epic Clarity Integration: Reporting & Analytics
• Epic Third-Party & API Integration: How Apps Connect to Epic
• Epic Integration Services (pillar guide)