top of page

Defining Front, Mid, and Back-End Revenue Cycle

Updated: Sep 29, 2023

I remember my first introduction to the full Revenue Cycle (RC). The company I worked for at the time broke RC into 3 segments of Front, Mid, and Back-End. I could not tell where one ended and the other began. I thought maybe I was missing something. Did some companies not break it up this way? Even people within the RC departments could not clearly articulate when the segment ended and the work moved to the next stage of the cycle. It took me a while, but I finally figured it out. So here are my definitions of the three sections of the RC.

Front-End Revenue Cycle: From the point of Account Creation and/or Scheduling to point of Discharge. Mid-Stream Revenue Cycle: From the point of Discharge to the point where the account is ready to be Billed. Back-End Revenue Cycle: From the point of Billing to the point where the account closes. Now, to be clear, these segments do not mean that work does not occur in overlapping sections by teams. It does. A team member could be completing registration verification on an account in Front-End while coders are processing the account in Mid-Stream. It only serves to indicate segments of work types, and how RC is organized in a healthcare setting.

Front-End RC is pretty straight forward. You cannot contribute more to those sections without more patient interactions. So once the patient has left (been discharged from the system), that ends the scope of work functions.

Mid-stream is probably the most confusing. There are many overlapping scopes of work, and the teams that operate in this middle space feed both up and downstream activity; correct this, don't forget that. This area is also heavily sensitive to time. Once a patient discharges, that timely filing clock has started. It is now a race of productivity combined with accuracy to get claims out of Mid-Stream RC coding and edits into the Back-end billing and claims submission space.

Finally, we have the Back-End, starting with billing and claims submissions. The clock is still running, but we are closer to getting claims through the editor, submitted through the clearing house as an 837. Back-End is by far the largest section. It's Billing, AR Follow-up, Denials, Patient Early Out billing, and Reconciliation. While we do not have to worry about the payor specific timely filing deadlines, there are other timelines that are of focus. Mainly AR aging. If accounts are sitting active (meaning they have unreconciled, unpaid/adjusted, or unposted charges on their balance) then cash is not coming in. The main metric here is AR Aging >90. Most payors turn the majority of AR (clean claims) within 90 days. So anything of volume sitting in active AR aging >90 days likely is of concern.

I could probably spend an entire article providing examples of issues I have found in AR <90. The fact is that there will always be issues occurring, as something is always changing in healthcare. These are things like payor contracts, yearly federal regulation changes, denial issues, or even just straight up errors in account processing. This drives the need for regular monitoring of the entire RC. Each segment of RC feeds the next, and the only way you will learn, is from learning from your mistakes and misses, and developing/implementing processes that will prevent the same errors from occurring the next time around.

Recent Posts

See All


Post: Blog2_Post
bottom of page