If you’ve ever had a sales team close a deal with a pricing structure that couldn’t be implemented in your billing platform without an engineering sprint, you already understand the problem with tier-lookup-only rating engines.
Most billing platforms were built around a simple model: take a usage quantity, find the right row in a rate table, multiply. That model works for flat pricing and basic tiers. It stops working the moment your pricing has more than one variable, and in enterprise SaaS that moment comes quickly. Instead, formula-based pricing is the best fit for these instances.
What Formula-Based Pricing Is
Formula-based pricing is a pricing model where the charge is calculated from a custom expression involving multiple input variables, rather than a simple lookup in a rate table.
- Simple tier lookup: usage quantity → look up rate → multiply. One variable, one lookup.
- Formula-based: (input_tokens × $0.003) + (output_tokens × $0.006). Two variables, one calculated result. No tier table can represent that cleanly.
- Or telecom: per_minute_rate + connection_fee + jurisdiction_surcharge(region). Three variables, two of which require lookups and one of which requires geographic logic.
- Or IoT: (device_count × tier_rate) + (per_event_rate × event_count × frequency_factor). Four variables with a multiplier relationship between them.
In all of these cases, a standard tiered pricing model can’t produce the correct charge without custom engineering. You either bolt on custom code that handles the formula, or you find a billing platform with a native formula-based rating engine.
Where Tier Lookups Break Down
AI / LLM Pricing
Every major AI API charges differently for input tokens and output tokens. The ratio isn’t fixed. A customer’s output-to-input ratio varies by use case and workload. The charge is: (input_tokens × rate_in) + (output_tokens × rate_out). Two variables, both variable. You can’t represent this in a single-dimensional tier table.
Add model versioning (different rates for GPT-4 vs. GPT-3.5, or different rates for fine-tuned models), and the pricing expression now includes a categorical variable (model_id) that determines which rates apply. A formula-based engine handles this naturally. A tier-lookup engine requires you to create a separate rate plan for every model, then add logic outside the billing system to route usage to the right plan. That’s technical debt that compounds.
Telecom / UCaaS Pricing
Telecom pricing has been formula-based for decades. A call has a duration, an origin region, a destination region and a connection type. The charge is a function of all four. Add regulatory surcharges that vary by jurisdiction (themselves calculated as a percentage of the base rate), and you have a formula with five or six variables.
Telecom billing vendors solved this thirty years ago. SaaS billing vendors largely haven’t, which is why telecom and UCaaS companies evaluating SaaS billing platforms frequently find they can’t replicate their existing pricing structure without custom development.
Enterprise Contracts with Volume Discounts
A customer commits to $500K in annual spend. In exchange, they get a 15% volume discount applied to all usage above 10M events per month. The charge for a month where they use 12M events is: (10M × $0.002) + (2M × $0.002 × 0.85). Two tiers, a multiplier and a conditional discount. This is a completely normal enterprise SaaS contract, and it’s a formula-based pricing problem.
Transportation and Logistics
Per-shipment pricing with fuel surcharges. The base rate is a function of distance and weight. The fuel surcharge is a percentage of the base rate, recalculated monthly based on a fuel index. Total charge: (distance × weight × zone_rate) × (1 + fuel_surcharge_pct). The fuel surcharge percentage changes every month. A tier table can’t handle a variable whose value changes dynamically.
What Formula-Based Rating Actually Requires
A formula-based rating engine needs three capabilities that standard tier-lookup engines don’t have:
- Expression evaluation. The engine must be able to evaluate mathematical expressions with multiple input variables: addition, multiplication, division, conditionals, percentage calculations. Not tier lookups — actual expression evaluation.
- Multiple input variables per charge. A single billable charge can depend on two, three or four metered quantities simultaneously. The engine must accept and correctly process multiple inputs per rating event.
- No-code formula configuration. Finance teams and RevOps leaders should be able to configure and modify pricing formulas in a UI, not by filing engineering tickets. If formula changes require code deploys, you’ve shifted control of pricing away from the people who own contracts and given it to engineering.
The Engineering-Sprint Warning Sign
Here’s a reliable signal that your billing platform doesn’t support formula-based pricing: every time sales closes a deal with complex pricing, someone files a ticket with engineering to “implement the pricing logic.”
What’s happening in that scenario: the billing platform can’t represent the pricing structure natively, so engineering is building a custom calculation layer on top of it. That layer is undocumented, fragile, usually not covered by your billing platform’s support contract and completely opaque to the finance team that needs to understand and audit it.
More importantly, it doesn’t scale. The first custom formula is manageable. The fifth is a maintenance burden. The fifteenth is a system that only two people on your team understand, and both of them have probably been recruited away.
Configuring Formula-Based Pricing: What to Expect
In a well-built formula-based rating engine, configuring AI token pricing looks like this: define two metered inputs (input_tokens, output_tokens), enter the formula (input_tokens × 0.003) + (output_tokens × 0.006), save. No code. No engineering ticket. The formula is stored as configuration, version-controlled and auditable.
If you update the rates, you create a new version of the formula with an effective date; the engine automatically applies the old version to usage before that date and the new version after. Split-period rating handled at the formula level.
That’s what formula-based pricing support should look like. If a vendor shows you a workaround involving spreadsheet imports, custom fields or “our implementation team will build that for you,” you’re looking at a platform that doesn’t have native support.
Preguntas frecuentes
What is formula-based pricing?
Formula-based pricing is a model where the charge is the output of a mathematical expression with multiple input variables, rather than a lookup from a single-dimension tier table. For example: (input_tokens × $0.003) + (output_tokens × $0.006) for AI token pricing, or (distance × weight × zone_rate) × (1 + fuel_surcharge_pct) for logistics. Any time a customer’s charge depends on more than one metered quantity, or involves multipliers, conditionals or dynamic rate variables, formula-based pricing is required.
How is formula-based pricing different from tiered pricing?
Tiered pricing uses a lookup table: find the usage quantity in a tier, apply the corresponding rate. It works for single-variable pricing where the charge is a direct function of one quantity. Formula-based pricing uses an expression evaluator: multiple input variables are fed into a mathematical expression that produces the charge. When a pricing structure has two or more independent variables — input tokens and output tokens, base rate plus surcharge, quantity times frequency times discount — tiered pricing can’t represent it without workarounds or custom code.
What does a formula-based rating engine need that a standard engine doesn’t?
Three things: an expression evaluator capable of addition, multiplication, division, conditionals and percentage calculations across multiple variables; support for multiple metered inputs per billing event (the engine must accept input_tokens and output_tokens as separate inputs and feed both into the expression); and no-code formula configuration in a UI so finance and RevOps teams can update pricing without engineering tickets. If formula changes require code deploys, the billing platform isn’t built for this use case.
Why does AI token pricing require formula-based rating?
AI APIs charge different rates for input tokens and output tokens. The ratio between input and output varies by workload. The charge is (input_tokens × rate_in) + (output_tokens × rate_out) — two independent variables, both variable. This can’t be expressed in a single-dimension tier table. Add model versioning (different rates per model) and the expression includes a categorical variable that selects the applicable rates. A tier-lookup engine handles none of this natively; it requires custom code outside the billing platform.
What is the warning sign that your billing platform doesn’t support formula-based pricing?
Every time sales closes a deal with complex pricing, someone files a ticket with engineering to ‘implement the pricing logic.’ What’s actually happening: the billing platform can’t represent the pricing structure natively, so engineering is building a custom calculation layer on top of it. That layer is undocumented, fragile, not covered by your billing platform’s support contract and opaque to the finance team who needs to audit it. The first custom formula is manageable. The fifteenth is a system only two people understand — and both are probably recruiting targets.
For the complete practitioner guide to metering and rating, see billingplatform.com/metering-and-rating.
See also: How Rating Engines Work: A Technical Guide | Metering & Rating for AI Companies | What Causes Revenue Leakage — and How to Stop It | Event Deduplication in Billing | How to Evaluate a Metering & Rating Platform
