A practical guide to revenue cycle automation

The revenue cycle is how healthcare providers get paid. When it slows down, the provider’s cash flow dries up, and everything else breaks.

Less cash flow means providers have to make tough choices: not hiring needed staff, delaying investments, or cutting back on services. And that means worse care for everyone.

Despite the stakes, most of the revenue cycle is spent waiting.
… Waiting for eligibility responses.
… Waiting for claims to get accepted.
… Waiting for payments to show up.

A lot of that wait is avoidable.

If you're building RCM tools for healthcare providers, automating parts of the cycle – the critical path – can cut 10-20 days off the typical 30-60 day cycle. Providers – your customers – get paid faster, and you'll win more of them.

This guide walks you through what the revenue cycle is, tells you the key roles, and breaks down each step of the critical path: enrollment, eligibility, and processing claims. It shows how billing platforms can use Stedi to automate this critical path so it runs faster and at scale.

What is the revenue cycle?

The revenue cycle is everything a healthcare provider does to get paid.

In theory, it’s simple: a provider sees a patient and collects any co-pay or coinsurance. The provider records what happened during the visit and sends the details as a claim to the payer. The claim is approved, and the provider gets paid.

The reality is more complicated.

To avoid claim denials, providers need to check the patient’s insurance coverage before a visit. When submitting a claim, they have to use billing codes – picking from tens of thousands of them – to precisely describe the service they provided. Once submitted, payers don’t process their submitted claims right away. It can take days or weeks. A mistake means a rejection – which means starting over, delaying payment even more.

Revenue cycle management (RCM) is how providers stay on top of it all. It can be software, services, internal processes, or a mix of all three. Regardless of the methods, the goals are the same: prevent mistakes, get the provider paid faster, and avoid lost revenue.

The players

The revenue cycle involves several different systems and organizations. Each plays a specific role:

Providers
Short for “healthcare providers.” These are doctors, hospitals, dentists, therapists – anyone who delivers healthcare. They’re the ones trying to get paid.

Payers
Health insurers, including insurance companies like Aetna or Cigna, and government programs like Medicare. They receive claims, decide what to pay, and send back money (or denials) to the provider.

HIPAA and X12
A federal law that protects healthcare data and sets rules for how certain transactions must be conducted. HIPAA requires some healthcare transactions to be exchanged in the X12 EDI format. For example:

• A provider must send insurance eligibility checks to medical payers using an X12 270 Eligibility Inquiry.

• The payer must respond with a 271 eligibility response.

270 and 271 refer to official X12 HIPAA transaction types. Stedi’s APIs let you send and receive data for these transactions as JSON. We handle the translation from JSON and X12 (and the reverse) for you. You can also use Stedi to exchange raw X12.

Healthcare clearinghouses
Clearinghouses sit between providers and payers. Their job is to route transactions between the two and ensure that transactions sent to payers are HIPAA-compliant X12.

Most clearinghouses only connect to medical or dental payers. Stedi connects to both. We also connect to some vision and workers' compensation payers. 

For more information on clearinghouses, check out What is a healthcare clearinghouse?.

Billing platforms
Most providers don’t connect directly to clearinghouses or payers. They use billing platforms to manage the work for them. These include EHRs (electronic health record systems), practice management systems (PMS), and revenue cycle management (RCM) systems – often layered on top of each other.

In addition to billing, some of these platforms may help providers manage appointments, documentation, and clinical tasks.

The critical path

To get paid, every provider needs to complete certain steps in the revenue cycle. This “critical path” includes enrollment, eligibility checks, and claims processing.

There are other steps in the revenue cycle, but these are the most important to get right. Mistakes here slow down provider payments and create more work.

The following sections walk through each step in the critical path, covering its purpose, common pitfalls, and how it can be automated using Stedi.

Step 0. Enrollment

Before they can exchange transactions with payers, providers need to complete up to three different types of enrollment. Each enrollment is a one-time process, but providers need to repeat enrollment for each payer:

• Credentialing – Confirms the provider is licensed and qualified.

• Payer enrollment – Registers the provider with the payer’s health plan(s) and sets their contracted rates – the agreed dollar amounts for specific services. These rates are used later to calculate how much the payer will reimburse for a service in claims.
  
  

• Transaction enrollment – Lets the provider exchange certain types of healthcare transactions with the payer. 

Billing platforms may handle some or all of these enrollments for their providers. Stedi only helps billing platforms with transaction enrollment – but we make it faster, more automated, and easier to manage than other clearinghouses. 

Transaction enrollment
All payers require providers to complete transaction enrollment to receive 835 Electronic Remittance Advice (ERAs). Some also require enrollment for other transactions, like 270/271 eligibility checks or 837 claims.

If you're a billing platform serving many providers, transaction enrollment becomes a bottleneck. Each payer has its own enrollment process with different requirements: some need PDF signatures, others require portal logins. Just tracking the status of hundreds of enrollment submissions can become overwhelming. Many billing platforms end up hiring entire operations teams just to manage the paperwork.

Stedi automates transaction enrollment requests and lets you avoid most of the manual work. You can submit and track enrollment requests using Stedi’s Enrollments API, the Stedi portal, or a bulk CSV file. For the 850+ payers that support one-click transaction enrollment, that’s it – you’re done. For the rest, we offer delegated signature authority, where Stedi signs enrollment forms on your behalf. It’s a one-time step that eliminates 90%+ of your enrollment-related paperwork.

When manual enrollment steps are needed, we do the work for you. You only take action when absolutely needed – and we tell you exactly what to do next. We complete most enrollment requests in 1-2 business days.

Step 1. Eligibility check

Before a patient visit, providers need to know three things:

• Does the patient have active insurance?

• Does the patient’s plan cover what they’re coming in for?

• How much will the patient owe at the time of service? What’s the co-pay, coinsurance, or deductible?

An eligibility check checks a patient’s insurance to answer these questions. The checks help prevent claim denials and surprise bills. It’s especially important for specialty care – like therapy – where coverage can vary by service type.

In some cases, especially for scheduled services, providers may also need to give the patient an estimate of their out-of-pocket costs. For certain services, that estimate is required by the No Surprises Act.

To check coverage, you send a 270 eligibility request to the patient’s payer. The payer responds with a 271 eligibility response that includes benefit details: covered services, copays, coinsurance, deductibles, and more.

Real-time and batch eligibility checks
Most providers need to make eligibility checks in real time – during intake or on the phone – right before a visit. Fast, accurate eligibility responses are important. Stedi’s Real-Time Eligibility API typically returns results in 1-3 seconds.

Many providers also want to run weekly or monthly batch refreshes. These refreshes catch coverage between visits, which is helpful for recurring patients or upcoming visits. You can use Stedi’s Batch Eligibility API or a bulk CSV to run 1,000 checks at a time without interfering with your real-time checks.

Insurance discovery and COB checks
Payers only return a patient’s eligibility data if the request matches a single patient. Some payers can match a patient based on their name and date of birth alone, Many require a member ID.

If a patient doesn’t know their member ID or doesn’t know their payer, you can use an insurance discovery check to try to find active coverage using just their demographics, like name and SSN. Results aren’t guaranteed, but it’s a way forward when eligibility checks aren’t possible. If the discovery check returns multiple plans, use a coordination of benefits (COB) check to determine the primary plan.

MBI lookup
Medicare eligibility checks require the patient’s Medicare Beneficiary Identifier (MBI), the Medicare equivalent of a member ID. If a patient doesn’t know their MBI, you can use Stedi’s MBI Lookup feature to get it. If there’s a match, Stedi automatically runs an eligibility check using the MBI to return the patient’s benefits information.

Using Stedi
The following table outlines how billing platforms can run eligibility and related checks using Stedi.

Step 2. Charge capture

Once coverage is confirmed, the provider delivers care. During or after the visit, the provider captures what was done using procedure codes – structured billing codes that describe their services. Providers typically enter the codes into their EHR or PMS.

Later, these codes become the core of the claim sent to the payer. The type of code used depends on the service:

• Current Procedural Terminology (CPT) codes – Used for most medical services. Maintained by the American Medical Association (AMA).

• Healthcare Common Procedure Coding System (HCPCS) codes – Used for things like medical equipment, ambulance rides, and certain drugs. Includes CPT codes as Level I.

• Current Dental Terminology (CDT) codes - Used for dental services. Maintained by the American Dental Association (ADA).

Accuracy is important in this step. The captured codes later become part of the provider’s claim. Mistakes can mean a rejected or denied claim.

Stedi doesn’t handle charge capture directly. But many EHR and practice management platforms that integrate with Stedi do. To find them, check out our Platform Partners directory.

Step 3. Claim submission

Once care and charge capture are done, the provider uses their billing platform to submit a claim to the patient’s payer.

Claims must be submitted using an 837 transaction. There are three types:

• 837P – Professional claims, used for services like doctor visits, outpatient care, and therapy
  
  

• 837D – Dental claims
  
  

• 837I – Institutional claims, used for services like hospital stays and skilled nursing

You can use Stedi’s Claim Submission API or SFTP to submit 837P, 837D, and 837I claims.

275 claim attachments
Some services require additional documentation – like X-rays or itemized bills – to show that the service occurred or was needed. This is common in dental claims, where payers often require attachments for certain procedures.

Providers must send this documentation to the payer as one or more 275 claim attachments. The type of attachments required depends on the service and the payer. Without required attachments, the payer may delay (pend) or deny the claim.

You submit attachments separately from claims, but the request must reference the original claim. Most claim attachments are unsolicited – meaning they’re sent upfront without the payer requesting them.

You can use Stedi’s Claim Attachments API to upload and submit it as an unsolicited 275 claim attachments.

Using Stedi
The following table outlines how billing platforms can submit claims and claim attachments using Stedi.

Step 4. Claim acknowledgment

Payers don’t process claims in real time. After you submit a claim, you’ll receive one or more asynchronous 277CA claim acknowledgments: 

• First from Stedi or your primary clearinghouse. For Stedi, this usually arrives within 30 minutes of submitting the claim.

• From one or more intermediary clearinghouses, if applicable.

• Finally from the payer. This acknowledgment is the one you usually care about. You typically receive a payer acknowledgment 2-7 days after claims submission, but it can take longer.

Payers send claim acknowledgments to the provider’s – or their designated billing platform’s – clearinghouse. You can use a Stedi webhook or Stedi’s Poll Transactions API endpoint to listen for incoming 277 transactions. When a 277CA arrives, you can use the transaction ID to fetch the claim acknowledgment’s data using Stedi’s Claims acknowledgment (277CA) API.

Claim acceptance and rejection
The payer acknowledgment tells you whether the claim was accepted for processing or rejected:

• Acceptance  – The claim passed the payer’s initial checks and made it into their system. It doesn’t mean the claim was approved or paid.
  
  

• Rejection – The claim didn’t meet the payer’s formatting or data requirements and wasn’t processed at all. It doesn’t mean the claim was denied.

If the claim is rejected, fix the issue and try again. If it’s accepted, wait for the 835 ERA – the final word on payment or denial.

Claim repairs
The acknowledgment step is where most claim rejections happen. When you submit a claim using the Claim Submission API, Stedi automatically applies various repairs to help your requests meet X12 HIPAA specifications and individual payer requirements. This results in fewer payer rejections.

Prior authorization
Some services require prior authorization, or prior auth, before you can submit a valid claim. It means getting the payer’s approval for a service in advance – usually through a portal, fax, or EHR. Prior auth isn’t handled by Stedi and isn’t covered in this guide.

Using Stedi
The following table outlines how billing platforms can use Stedi to retrieve claim acknowledgments.

Step 5. Remittance and claim status

The 835 Electronic Remittance Advice (ERA) transaction is the final word on a claim. It’s the single source of truth for:

• What was paid and when

• What was denied and why

• What the patient owes

• How to post payments and reconcile accounts

Like a claim acknowledgment, the ERA is sent from the payer to the provider’s – or their billing platform’s – clearinghouse. You can create a Stedi webhook or Stedi’s Poll Transactions API endpoint to listen for incoming 835 transactions. When an 835 ERA arrives, you can use the transaction ID to fetch the ERA’s data using Stedi’s 835 ERA API. 

Claim approval and denial
Later, after the claim is processed, you may receive an approval or a denial:

• Approval – The payer agreed to pay for some or all of the claim.
  
  

• Denial – The claim was processed but not paid, usually because the service wasn’t covered or approved by the patient’s plan.

If the claim is approved, you can post the payment and reconcile the patient’s account.

If it’s denied, review the denial reason in the ERA. If the denial was incorrect or preventable, you can correct the issue and resubmit the claim. Otherwise, you can appeal or escalate the denial with the payer or bill the patient. The steps for appealing and escalating claims differ based on the payer’s rules and the patient’s plan.

Real-time claim status checks
If the claim is approved, an ERA typically arrives 7–20 business days after claim submission. If you haven’t received a claim acknowledgment or ERA after 21 days, you can check the claim’s status using a 276/277 real-time claim status check.

A real-time claim status check tells you whether the claim was received by the payer, is in process, or was denied.

You can make a claim status check any time after claim submission, but most billing platforms wait until day 21. Then they monitor the claim using real-time claim status checks until they receive a final status or an ERA. For example, the following table outlines a typical escalation process.

Using Stedi
The following table outlines how billing platforms can use Stedi to retrieve ERAs and make check claim statuses.

Step 6. Revenue recovery

Sometimes, the provider has already delivered care, but the claim gets stuck. This could be because:

• They didn’t check eligibility or collect the right insurance information, so they can’t submit a claim.

• They submitted a claim, but it was rejected or denied.

The result is the same: the claim and its revenue are considered lost.

To recover it, run an insurance discovery check to try to find active coverage for the patient. Results aren’t guaranteed, but even a low success rate is acceptable. This is a last-ditch effort to recover lost revenue, and there’s limited downside. If discovery returns multiple plans, run a COB check to determine the primary.

If you can identify the patient’s primary plan, submit a claim using the Claim Submission API or SFTP, and pick up the revenue cycle from there (Step 3).

Using Stedi
The following table outlines how billing platforms can submit claims and claim attachments using Stedi.

The rest of the revenue cycle

This guide only covers the critical parts of the revenue cycle. The rest of the cycle happens outside the clearinghouse.

After the 835 ERA comes in, the billing platform or another RCM system typically takes over any remaining steps. These can include:

• Posting payments to the patient’s account

• Billing the patient for their share of payment

• Following up on denied or unpaid claims

• Collecting payment or writing off balances

• Running reports and reconciling revenue

If you're looking for tools to handle those downstream steps, check out the Stedi Platform Partners directory.

Start automating your workflows today

If you’re building RCM functionality and running into scaling issues, Stedi can help you out. Our APIs let you automate core workflows so you can onboard more providers with less manual work.

If you want to try Stedi out, contact us for a free trial or sign up for a sandbox account. It takes less than 2 minutes. No billing details required.