August 24, 2026
How mental health platforms are managing billing complexity
TABLE OF CONTENTS
RELATED POSTS
Most mental health platforms pick a billing model early and try to scale the model while adding new territories, offerings, and compliance requirements. If you're running billing for a teletherapy or behavioral health platform, you've probably already found that scaling like this leads to cracks. Here's where the three most common models break and what to check before yours does.
Key takeaways:
Mental health platforms tend to run one of three billing models: flat subscription, subscription plus variable charges, or a one-time evaluation that converts into a recurring membership.
Each model has a specific point where it breaks as the platform scales, and it's rarely the pricing logic itself. It's what the pricing logic assumes about the systems around it.
HIPAA-compliant billing infrastructure, clean cancellation logic, and a real distinction between voluntary and involuntary churn aren't nice-to-haves in this vertical. Get any one of them wrong, and you're either out of compliance or writing off revenue you didn't have to lose.
The most common mental health billing models and their breaking points
Model 1: Flat subscription
One price, billed weekly or monthly, cash-pay only. It’s the simplest model in the category and the subscription model most customers know best. The bad part? It’s not always suited to the actual needs of those who use mental health services and it isn't designed to scale flexibly.
Businesses start running into issues when patients want to use FSA or HSA funds or seek insurance reimbursement. A flat subscription charge has no way to itemize by service type, which is exactly what a patient needs if they're trying to submit that charge to an insurer or a benefits administrator or have multiple different types of services. You also lose the ability to report revenue by service type internally, which becomes a problem the first time finance asks how much of your revenue is therapy versus psychiatry versus messaging-only.
Watch for this: If your billing system can't break a subscription charge into its component services after the fact, you most likely can’t support insurance-adjacent payment methods without a rebuild, and you can't answer basic revenue-mix questions without pulling data from somewhere other than your billing platform.
Model 2: Subscription plus variable charges
This model combines a base subscription with insurance-related charges and per-session add-ons. It's more flexible than a flat model, and it's also the one most likely to break.
It is common for three different charge types to hit the same patient account on completely different schedules:
Subscriptions: Billed on a predictable monthly cycle
Copays: Billed per visit, but entirely dependent on successful insurance claim adjudication
Add-on sessions: Billed as they occur, making them highly irregular by nature
The problem with dunning in mental health
When a payment fails, your dunning logic needs to immediately identify which charge type failed and why. A card-decline error and a denied insurance claim require completely different next steps.
Most standard medical billing stacks aren't built to differentiate between these two failure modes. Because the software treats all failures identically, patients frequently receive automated collections emails for a billing error that was never actually a credit card problem. Intelligent retries can actually help solve this problem.
Watch for this: If your system sends the same failed-payment notification regardless of whether a card was declined or a claim was denied, you're generating support tickets and confusing patients over something your billing logic should have already sorted out.
Model 3: Evaluation-to-membership conversion
This is the most common pattern for platforms that started as a clinical service first and added a subscription layer second, and it's the one where the billing complexity is easiest to underestimate.
The typical patient journey relies on a multi-step workflow:
Initial evaluation: A new patient pays a one-time fee for their first visit.
Clinical review: A provider evaluates the case within an Electronic Health Record (EHR) or clinical system to determine if ongoing care is necessary.
Membership conversion: Only after clinical approval is the patient offered a recurring monthly or annual care subscription.
The bottleneck here is that the billing trigger relies on a clinical decision made inside an EHR, a system that may be separate from the subscription billing platform. This is only going to become more critical as calls for reimbursement through insurance for mental health services continue to grow.
Manual syncing and the costs
Because these systems don’t naturally integrate, staff often have to manually bridge the gap between an EHR and a subscription billing platform. When a practice scales, this manual sync becomes a massive liability, resulting in:
Subscriptions being initiated late
Recurring revenue opportunities being missed entirely
Active subscriptions billing patients who have already left the practice
This care model also introduces another major operational hurdle which is multi-party payouts. Platforms running this pattern typically collect all patient payments into a single parent account. They must then calculate and distribute funds to dozens or hundreds of individual providers from that central pool.
Watch for this: If the decision to bill a patient is made in a system your billing platform can't see, you're relying on a human to bridge that gap every single time, and that gap is where revenue quietly leaks.
How these systems break at scale
Regardless of which model you're running, three things separate a billing setup that scales cleanly from one that starts costing you revenue and trust.
HIPAA-compliant infrastructure is table stakes: Every mental health platform handling payment data alongside clinical context needs a billing layer that's HIPAA-compliant from the start, not bolted on after a security review flags it. It shapes how you store patient billing information, and how much manual handling of sensitive data your team is exposed to.
Cancellation has to map to the right billing action: If a patient cancels one scheduled appointment, your system needs to stop the charge tied to that specific appointment, not cancel their entire subscription and not charge them for a session that never happened. Cancellation also needs to be genuinely simple for the patient to execute. Complicated cancellation flows don't reduce churn; they just convert voluntary churn into support tickets and complaints.
Voluntary and involuntary churn are not the same thing: Voluntary churn is a patient choosing to end their subscription. Involuntary churn is a card expiring, an address changing, or a payment method failing for a reason that has nothing to do with the patient's decision to keep receiving care. If your reporting lumps these together, you're overstating how many patients are actually choosing to leave, and you're missing the involuntary churn you could recover with better retry logic and card-updater tools.
Billing complexity in this category rarely comes from the pricing model itself. It comes from the systems surrounding the pricing model: an EHR that doesn’t communicate with the billing platform, dunning logic that can’t distinguish a card decline from a claim denial, and churn reporting that can’t distinguish a choice from an accident. A subscription platform built for regulated health handles all three billing shapes without forcing you to rebuild every time your model changes. If you’re ready to solve these problems, let Recurly help you get your billing stack ready for your next era of growth.
Disclaimer: This article is provided for general informational purposes only and does not constitute legal, privacy, security, or compliance advice. Requirements — including those related to HIPAA, subscription billing, and cancellation practices — vary by jurisdiction and business circumstances and may change over time. Consult qualified legal and compliance professionals to evaluate your organization’s specific obligations. Examples are illustrative and do not guarantee particular outcomes.
