Hybrid billing software lets companies charge customers through more than one pricing model at the same time. A flat monthly subscription covers base access. Usage-based charges scale with what the customer actually consumes. Time-based billing meters value delivered by the minute or by the hour. All of it lands on one invoice, for one customer, inside one system.
This is not a niche setup. Over 60% of SaaS companies now operate some form of hybrid pricing, up from under 30% in 2021. The billing infrastructure to support it has become a foundational requirement, not an advanced feature.
Why Pure Subscriptions No Longer Work
Subscriptions had a long winning streak. They were predictable, simple to invoice, and easy for customers to budget against. For a decade, SaaS defaulted to them.
Three structural shifts broke that default.
The first was AI. Token usage, agent executions, image generations, and compute minutes do not map to a seat count. Charging a flat monthly fee for unlimited AI usage is a pricing trap for the vendor; charging purely per token creates budget anxiety that suppresses engagement. A hybrid model solves both: a stable base tier plus consumption-scaled charges on top.
The second was infrastructure software pricing on consumption by default. API calls processed, data streamed, events ingested. Companies in this category grew up metered. Their customers expect billing that reflects actual use, and a subscription-first system does not give them that.
The third was the widening gap in value delivery. A tool that delivers 10x more value to one customer than another should not charge them the same. Hybrid billing creates pricing that expands with delivered value, not just with headcount.
A subscription-only billing stack has become a ceiling on revenue, not a foundation for it.
The Building Blocks of a Hybrid Billing Model
Most hybrid billing models draw from some combination of these core components. Understanding each one is useful because each creates different requirements for the billing system underneath it.
Recurring subscriptions. A fixed amount charged on a schedule, monthly, quarterly, or annually. This is the base layer. It provides revenue predictability for the vendor and cost predictability for the buyer, and it creates a minimum commercial relationship before usage charges kick in.
Usage-based or metered billing. Charges that vary based on what the customer consumed during a billing period. API calls, active users, storage, tokens, compute minutes, messages sent. Usage events are collected, rated against a pricing rule, and added to the invoice at the end of the cycle. The billing system needs to collect this data reliably, without losing records and without generating duplicate charges.
Time-based billing. A distinct dimension that most conversations about hybrid billing miss. Instead of metering units of output, time-based billing charges for time spent with the product or service. A legal research tool, a video learning platform, an AI agent, or a coaching product might charge per hour or per minute of engagement rather than per access event. The unit is time, not an action count. The billing system needs a session start event, a session end event, a way to bucket time into billable increments, and a rating engine that converts elapsed time into a charge.
One-time and setup fees. Charges that fire once rather than on a recurring cycle. Onboarding fees, professional services, license activations. These need to appear cleanly on an invoice alongside recurring and metered charges without breaking the invoicing logic.
Credits and prepaid balances. Many AI products sell credit packages upfront and let customers draw down against them over time. The billing system needs to track the remaining balance, apply credits before invoicing live charges, and trigger renewal logic when the balance approaches zero.
A genuinely hybrid billing stack handles all of these. Most billing tools handle one or two well and treat the rest as edge cases.
Where Time-Based Billing Fits
Time-based billing is worth treating as its own topic because it opens a class of monetization that subscription and event-based metering cannot reach.
The use cases where it fits naturally include platforms where value is delivered per session rather than per access: tutoring products, live consultation tools, co-pilot agents where compute time is the honest proxy for value delivered. It also fits content libraries where depth of engagement is the meaningful metric, research databases, video learning platforms, and premium editorial tools where a reader who spends 45 minutes with a piece of content should pay differently than one who glances at the headline.
In all of these cases, a flat monthly subscription underprices heavy users and overprices light ones. Charging per event does not reflect the actual relationship between cost and value. Time is the better unit.
The implementation requirement is specific. The billing system needs native support for session-level events, configurable time rounding (to the nearest minute or the nearest 10 seconds, depending on the product), and a rating engine that treats time as a first-class billing dimension. Most subscription-first billing platforms retrofit this through custom usage fields, which creates engineering debt that compounds as the product grows.
tiun builds subscriptions and time-based billing as two native product types through the same SDK integration. You define how often time is billed, set the per-unit rate, and the platform handles the rest. That is a different architectural starting point than patching session tracking onto a subscription engine.
What Hybrid Billing Software Actually Needs to Handle
A practical way to evaluate any hybrid billing platform is to trace every point where revenue can leak.
Usage ingestion reliability. The system needs to receive usage events without dropping records and without generating duplicate charges when events are retried. This is the first place custom implementations break in production.
Correct proration. When a customer upgrades or downgrades mid-cycle, the billing system calculates what they owe for the partial period. Proration logic that works at low volume often develops edge-case failures at scale. These failures are small per-customer, hard to notice, and quietly erode trust.
Failed payment handling. Baremetrics research puts involuntary churn from failed payments at 9% of monthly recurring revenue for SaaS companies on average. Retry logic, dunning flows, and grace period configuration are not optional features for a hybrid setup.
Cross-dimension invoicing. A customer's invoice needs to be readable. A line for the base subscription, a line for metered usage, and a line for time consumed should appear on the same document with clear labels. This requires the billing system to unify data from multiple charge types without manual reconciliation.
Revenue recognition. Annual subscriptions, monthly usage charges, and session-based fees have different recognition timing. Good billing software either handles this or exports data in a format that does not require a finance team to reverse-engineer it.
The Cost of Stitching Systems Together
Most early-stage SaaS companies build their billing stack by assembling separate tools: one for authentication, one for subscriptions, one for usage metering, and separate analytics on top. Each tool works in isolation. The problems appear at the boundaries between them.
A subscription update that does not propagate to the access control layer fast enough leaves users billed for a tier they cannot access. Usage data that lives in a separate database from customer records requires a manual join to reconcile an invoice. A failed payment that triggers a state change in the billing tool but not in the product database creates support tickets that are difficult to diagnose.
MGI Research found that 42% of companies experience revenue leakage costing between 3 and 7% of revenue annually. A significant portion of that leakage comes not from bad pricing decisions but from synchronization failures between systems that were never designed to communicate with each other.
The architectural answer is a system where auth, billing, customer data, and analytics share a single store. When a customer subscribes, access updates immediately. When a payment fails, the system knows. When a usage threshold is crossed, billing responds. None of this requires custom webhook handlers or reconciliation jobs to orchestrate because nothing is out of sync.
tiun is built on this premise. It is a single backend for authentication, payments, customer data, and analytics. The complexity that typically sits in the business logic layer between tools is handled by the platform. Founders who would otherwise spend weeks writing sync logic can use that time on product instead.
What to Look For in a Hybrid Billing Platform
A few specific criteria matter when evaluating billing infrastructure for a hybrid model.
Native support for multiple product types. Look for first-class support for subscriptions, usage metering, and time-based billing through the same integration, not through custom fields or separate product lines bolted together.
Developer surface area. The more bespoke engineering a billing setup requires at deployment, the harder it becomes to change pricing later. A platform that lets product and growth teams iterate on pricing without engineering deploys is a compounding advantage over time.
Merchant of Record. For companies with customers across multiple countries, tax compliance across jurisdictions is a real operational cost. A billing platform that acts as Merchant of Record handles that responsibility. It removes a layer of legal and accounting complexity that has no product value.
Total cost. The fee structure of a billing platform is itself a pricing decision. tiun charges 3.4% all-in with no platform fee and no international card surcharges. Alternatives in this space charge closer to 5% plus processing, and some add FX margins on top for international transactions. For an early-stage product where margin matters from day one, that difference compounds meaningfully as volume grows.
The Bottom Line
Hybrid billing is not a billing trend. It is how modern software products create and capture value across a diverse customer base. Subscriptions provide the revenue floor. Usage-based charges capture expansion. Time-based billing opens monetization for products where time is the honest unit of value delivered.
The infrastructure question is not whether to support hybrid billing. It is how to build the infrastructure for it without accumulating years of synchronization debt across systems that were never designed to work together.
The answer is a billing system that treats each pricing dimension as a native concern, not as a workaround built on top of a subscription engine. That is what separates billing software that works at launch from billing infrastructure that still works at scale.
Frequently Asked Questions
What is hybrid billing software?
Hybrid billing software is infrastructure that lets a company charge customers through more than one pricing model simultaneously. A single invoice can combine a recurring subscription fee, a usage-based charge calculated from events consumed during the billing period, and a time-based charge metered by minutes or hours of engagement. The key distinction from a basic subscription system is that every pricing dimension is a native concern in the platform, not a workaround built on top of a subscription engine.
What is the difference between usage-based billing and time-based billing?
Usage-based billing charges customers based on discrete events: API calls made, tokens consumed, messages sent, or gigabytes stored. Each event is a countable unit. Time-based billing charges based on elapsed time during an active session, measured in minutes or hours rather than actions. A legal research tool or an AI co-pilot might use time-based billing because the honest proxy for value delivered is how long the user was engaged, not how many individual requests they fired. The two models are not mutually exclusive. A product can charge a base subscription, add usage-based overages, and layer time-based session fees on top, all on the same invoice.
Why do early-stage SaaS companies experience revenue leakage from billing?
Revenue leakage in early-stage SaaS almost always originates at the boundaries between tools, not inside any single tool. When authentication, billing, usage metering, and customer data live in separate systems, synchronization failures accumulate quietly. A plan change that updates in the billing system but not in the access control layer leaves users on the wrong tier. A usage event that fires twice because of a network retry generates a duplicate charge. A failed payment that does not propagate to the product database creates an active user who stopped paying. MGI Research estimates that 42% of companies experience revenue leakage costing between 3% and 7% of annual revenue, and a significant share of that comes from these synchronization gaps rather than from pricing strategy errors.
What does a Merchant of Record do in a billing platform?
A Merchant of Record (MoR) is the legal entity responsible for processing a transaction, remitting sales tax, and handling compliance obligations in each jurisdiction where the sale occurs. When a billing platform acts as MoR, it absorbs the tax registration, VAT, GST, and local sales tax requirements that would otherwise fall on the software company. For a product selling to customers across multiple countries, this removes a substantial layer of legal and accounting overhead. The alternative is registering for tax in each relevant jurisdiction independently, maintaining those registrations as regulations change, and filing returns on a jurisdiction-by-jurisdiction basis. For early-stage teams, that operational cost has no product value. Choosing a billing platform that acts as MoR eliminates it entirely.