A builder's guide to the revenue cycle

Arna Meyer

Arna Meyer

Guide

I’m a Technical Product Manager here at Stedi. Before Stedi, I built revenue cycle management (RCM) automations at scale. Now I spend a lot of my time helping health tech companies do the same.

Before we get too far into things, it’s probably worth talking about what the revenue cycle actually is, because the name is a little misleading. The revenue cycle is how healthcare providers get paid for the care they deliver. Despite the name, it really isn’t a cycle. It’s a series of linear steps centered around a patient visit. Simple enough in theory. At a high level, the key steps are:

  1. Scheduling and registration

  2. Eligibility verification

  3. Coding and charge capture

  4. Claim generation and submission

  5. Claim adjudication and remittance

  6. Payment posting and patient billing

  7. Payment tracking

This guide walks through each step. You’ll get the patient’s experience, the provider’s experience, and how it all ties together.

In the revenue cycle, nothing happens in isolation. Errors cascade forward, and outcomes feed back. Understanding the full picture is what allows teams to build well in this space.

The clearinghouse

Almost everyone in the US has been to a doctor, a dentist, or a hospital - and they’ve probably used insurance to help cover the cost of accessing that care. What most people don’t see is what happens after they hand over their insurance card. Verifying coverage, submitting claims, processing payments – all of that runs through the revenue cycle.

In the RCM world, insurance companies are called payers. This includes government programs such as Medicare, Medicaid, TRICARE, and the VA. Payers and providers can communicate the old-fashioned way (phone calls, mail, faxes), but in this day and age it’s much more efficient to communicate electronically. Electronic communication is faster, cheaper and much easier to track. At the center of it is the clearinghouse. Think of it like a Visa or Mastercard: much like supermarkets don’t connect directly to banks to process credit card transactions, providers don’t connect directly to payers. A clearinghouse is used to translate, route, and validate electronic transactions. Checking a patient's eligibility or submitting a claim requires one.

The cycle

The revenue cycle follows a consistent sequence regardless of practice size, specialty, or payer mix. What changes is the complexity at each step.

Scheduling and registration

A patient schedules an appointment. If this is the patient’s first time seeing the provider, the provider collects their demographic details, such as name, date of birth, and insurance information. If the patient has already seen the provider, the front desk will likely ask the patient to confirm the information on file. The reason for this is simple: the information collected at the time of registration flows into every downstream transaction. If the information is incorrect, this can result in delayed or denied payment from the payer to the provider.

If the reason for the visit is known, a procedure code is captured. Procedure codes are standardized descriptions of the services to be performed – for example, a rapid strep test is code 87880. There are several code sets used in healthcare billing, which we'll cover later in the guide. These codes will be used further down the RCM chain in eligibility verification, pre-authorization, and claims.

Insurance verification

An eligibility check sends patient demographic details and insurance information to a payer. The payer responds with whether the patient has active insurance coverage, what their benefits look like, and what cost-sharing (copays, deductibles, coinsurance) may apply. The response also indicates whether specific services require pre-authorization. For a real-time eligibility check, responses come back within 1-3 seconds.

Active insurance coverage is not a guarantee of payment. The payer can still deny a claim later for reasons unrelated to eligibility, such as medical necessity or coding errors. If eligibility comes back inactive (for example, a returning patient switched jobs and has new coverage), the provider needs to resolve that before the visit. This could involve a call to the insurance company or discussing self-pay options with the patient.

Some procedures will require pre-authorization - approval from the payer before a service is performed. Without it, the payer may refuse to cover the cost, even if the patient has active coverage.

With most commercial payers, there’s no additional setup required to check a patient’s insurance - transactions can be submitted immediately. Medicare and a handful of other payers require that the provider “enroll” through their clearinghouse before they will process an eligibility check for that NPI (National Provider Number – essentially a provider’s unique ID number). This is different from the contract a provider has with a payer to accept their insurance – transaction enrollment is specifically about getting permission to send and receive electronic transactions. Check the Stedi Payer Network for your specific payers.

Coding and charge capture

During the patient visit, services are provided and documented. This documentation is used to ensure that all services rendered are billed, a process called charge capture. Charge capture usually happens at the point of care, directly in the systems used during the visit, such as Electronic Health Records (EHRs), Practice Management Software (PMS), or mobile devices. The services actually performed may differ from what was planned at scheduling, so the codes captured here may change the estimates calculated at registration.

Coding is the process of translating the details from charge capture into standardized medical billing codes. There are two categories of codes: procedure codes describe what was done, and diagnosis codes are used to explain the reason why. Payers check that the diagnosis justifies the procedure and if it doesn’t, the claim gets denied.

The specific code sets used depend on the claim type:

In smaller practices, coding is often handled by the treating provider. Larger organizations typically have dedicated medical coders – and AI is handling a lot of this now, too. Either way, coding errors are one of the leading sources of claim denials, making this one of the highest leverage steps in the entire cycle.

Claim generation and submission

A claim tells a payer what services were performed, the diagnoses that support them, and how much they cost. The codes that were generated during coding and charge capture will be used here. There are three types of claims based on the type of care being billed:

  • Professional (837P) - covers services personally delivered by an individual provider, such as a physician, specialist, or therapist.

  • Institutional (837I) - covers facility-related charges: the room, equipment, nursing staff, supplies, and other resources used during a patient’s care at a facility.

  • Dental (837D) - covers dental services and is usually sent to a separate dental payer.

It is possible for a visit to generate multiple claims. A radiologist may submit a professional claim for their services delivered in a hospital, while the boarding, equipment and support staff will be covered by an institutional claim. A dental visit may include procedures billed to a medical payer.

The claims are submitted to a clearinghouse where they will be checked for errors such as missing information, diagnosis codes that don’t match billed procedures, invalid dates, and so on. If errors are found, the claim is rejected – meaning it isn’t accepted for processing. Rejections can come from the clearinghouse, the payer, or both. The provider corrects the errors and resubmits. This is different from a denial, which happens later when a payer receives the claim but refuses to pay. Once a claim clears validation and is accepted, the provider receives an acknowledgment confirming it was accepted into their adjudication system.

Payers impose timely filing limits - deadlines for how long after a service a claim can be submitted. Missing these windows can result in reduced payment or outright nonpayment.

Similar to insurance verification, some payers will require transaction enrollment before they will accept claims. Check the Stedi Payer Network for your specific payers.

See also:

Claim adjudication and remittance

Once a claim is accepted by the payer, it undergoes a process called adjudication. In adjudication, the payer evaluates the claim and decides whether the claim is valid, and if so, how much of the claim the payer will reimburse the provider for. This can take anywhere from days to weeks.

Providers can check on the status of a claim during this window using a real-time claim status inquiry. The provider sends identifying information about the claim (payer, provider, patient, and date of service) and receives a synchronous response indicating where the claim sits in the payer’s pipeline: received, in review, finalized, or needing additional information. Common reasons to run a claim status check include not hearing back from the payer within the expected timeframe - which can vary payer by payer. The best practice is to wait at least a week after submission before checking, since claims need time to enter the payer’s processing system.

Claim status checks are useful for monitoring, but the full picture arrives in the Electronic Remittance Advice (ERA). The 835 ERA is the payer’s itemized breakdown of payments and adjustments. It details what was paid, what was adjusted, and why - both at the claim level and the individual service line level.

When a payer adjusts or denies a payment, the ERA explains the reason using standardized codes. An adjustment is any difference between what the provider billed and what the payer paid. Every adjustment on an ERA answers two questions: who bears the cost, and why? The answer comes in two structured fields that appear on every adjustment: a Claim Adjustment Group Code (group code) and a Claim Adjustment Reason Code (CARC, or reason code). The group code categorizes the adjustment. The reason code explains it. Some adjustments also include a Remittance Advice Remark Code (RARC), which provides additional context, such as instructions on how to correct and resubmit a claim. If there are discrepancies between what was billed and what was paid, the provider can appeal.

Not every claim gets paid in full on the first pass. When a payer reduces or denies payment, what happens next depends on the type of denial.

Some denials are administrative. Examples of administrative denials include missing modifiers (additional codes that provide extra detail about a procedure), invalid codes, mismatched subscriber IDs (the patient’s insurance member number). These claims can be fixed and resubmitted without formal dispute. The CARC and RARC codes on the ERA usually make the issue clear.

Some denials are clinical. This is where the payer determines that the services don’t meet medical necessity, or the documentation doesn’t support the procedure. These denials require formal appeal, and often need supporting clinical documentation.

Some “denials” aren’t denials at all; they are underpayments. The payer paid, but it is less than expected. These need to be reviewed against the provider’s contract with the payer to determine whether the reimbursement was correct - and if not, they can appeal or resubmit the claim.

All payers require providers to enroll for ERAs through their clearinghouse. ERA enrollment is also exclusive – when a provider enrolls to receive 835 ERAs through a clearinghouse, that clearinghouse becomes the clearinghouse that ERAs will come through for that payer-provider combination.

See also:

Payment posting and patient billing

Once the insurance has paid, the payment details are posted into the billing system. Each procedure code will have the payments and adjustments recorded against it so that the patient account balance reflects what was actually paid. The ERA details what was paid and why, but the actual funds arrive separately, typically via electronic funds transfer (EFT) or paper check. An ERA can cover multiple claims, so each payment needs to be matched back to the correct open claim. This process can be automated using the data in the ERA.

The adjustments in the ERA determine what happens next. If the patient has more than one insurance plan, the remaining balance is submitted to the next payer in line (the secondary payer) before anything is billed to the patient. Once all insurance plans have paid and those payments are recorded, any remaining balance becomes the patient’s responsibility.

The patient then receives a statement from the provider breaking down the services rendered, what each payer covered, and what remains. This is the patient’s bill. Separately, the payer sends the patient an Explanation of Benefits (EOB), which explains what the payer covered and why. The EOB is not a bill, but patients often confuse the two. Statements are sent electronically or by mail. Outstanding patient balances may be collected through payment plans, or if unresolved, written off or sent to collections.

Payment tracking

Payment tracking is the ongoing process of monitoring what’s been paid, what’s outstanding, and what needs action. Providers track this through Accounts Receivable (AR), which is the running total of money owed to the practice. AR is usually broken into aging buckets: 0-30 days, 31-60, 61-90, 91-120, 120+. The longer a balance sits, the harder it is to collect it.

AR work involves following up on two fronts. On the payer front, the work is following up on claims that haven’t been paid within expected timeframes and identifying patterns in denials and underpayments. On the patient front, it means monitoring outstanding statements, managing payment plans, and determining when to write off a balance or send it to collections.

Payment tracking is also where the most useful operational data lives. If the same CARC keeps appearing for a certain payer, that’s a signal to investigate and correct how claims are built for that payer. If a procedure code is constantly denied, there may be a coding or documentation issue that needs addressing. The revenue cycle improves when the end of the process informs the beginning.

Building from here

That’s the revenue cycle end to end. The next series of guides walk you through how to build each step – starting with eligibility: A quick start guide to eligibility checks

Share

Twitter
LinkedIn

Get started with Stedi

Get started with Stedi

Automate healthcare transactions with developer-friendly APIs that support thousands of payers. Contact us to learn more and speak to the team.

Get updates on what’s new at Stedi

Get updates on what’s new at Stedi

Get updates on what’s new at Stedi

Get updates on what’s new at Stedi

Backed by

Stedi and the S design mark are registered trademarks of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.

Get updates on what’s new at Stedi

Backed by

Stedi and the S design mark are registered trademarks of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.

Get updates on what’s new at Stedi

Backed by

Stedi and the S design mark are registered trademarks of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.