What is price configuration? Modelling rate cards, rules and customer-specific pricing
Written by Arnon Shimoni
✓ Expert
Last updated on:
Price configuration is the work of expressing a pricing strategy as something a system can execute. Products, meters, rate cards, tiers, commitments, discounts and customer-specific overrides, defined precisely enough that quoting and billing both produce the same number.
It is the step between deciding what to charge and actually charging it, and it is where most pricing strategies quietly fail. A model that cannot be configured has to be approximated, and approximations get maintained by hand.
Field | Detail |
|---|---|
What it is | Expressing pricing as executable configuration rather than prose or code |
Core objects | Product catalog, meters, rate cards, tiers, commitments, discounts, overrides |
Lives in | The pricing engine inside a billing engine |
Good test | Can you launch a new pricing tier without an engineering deployment |
Bad sign | Accounts that have to be invoiced manually because their structure cannot be modelled |
Related | CPQ, which applies this configuration at quote time |
What has to be modelled
The catalog. What is sellable, in what combinations, with what dependencies between items.
Meters. What counts as a billable unit, how it is aggregated, and what window applies. See usage metering.
Rate cards. Prices per unit, per currency, per segment, with tier or band structure. See volume discounts.
Commitments. Contracted minimums, drawdown rules, rollover and expiry. See minimum commit.
Time behaviour. Ramps, scheduled price changes, promotional periods with end dates.
Overrides. Customer-specific rates that deviate from the standard card, with their own validity windows.
Entitlements. What each configuration grants access to, enforced in real time. See entitlements.
Configuration versus code
The distinction that matters most is whether pricing is data or logic.
Configuration-driven | Code-driven | |
|---|---|---|
Changing a price | An edit, effective immediately or on a date | A code change and a deployment |
Who can do it | Pricing, finance or RevOps | Engineering |
Time to launch a tier | Hours | A sprint, or several |
Historical repricing | Possible, versions are retained | Usually impossible |
Audit trail | Built in | Reconstructed from commits |
Failure mode | Complex configuration nobody understands | Pricing logic scattered across services |
Neither is free of problems, but only one of them puts pricing changes on the engineering roadmap. Companies whose pricing lives in application code test pricing ideas at the rate they can ship releases, which is usually far slower than the market moves.
Where configuration breaks down
Non-modellable deals. A structure agreed in a negotiation that the system cannot express, producing a permanently manual account.
Overrides without expiry. Customer-specific rates that were meant to be temporary and have no end date.
Duplicate definitions. The same rate card configured separately in quoting and billing, drifting apart from the day they are created.
Meters defined by implementation. A billable unit that reflects how the code happens to work rather than something a customer recognises as value.
No versioning. When a meter or rate changes, historical periods can no longer be repriced correctly.
What good configuration looks like
One catalog, referenced by quoting, billing, entitlements and reporting.
Every rate, discount and override carries explicit validity dates.
Meters are versioned so historical periods reprice correctly.
New tiers and structures are configured rather than built.
The effective rate on any account is readable from the system, not reconstructed from a contract.
Nothing is billed manually.
Where Solvimon fits
Solvimon models catalog, meters, rate cards, tiers, commitments and overrides as configuration with explicit validity periods, so pricing changes do not require deployments and negotiated structures do not create manual accounts.
Because quoting and billing read the same configuration, there is no second copy of the rate card to keep in sync.
Frequently Asked Questions
What is price configuration?
Expressing a pricing strategy as executable configuration: catalog, meters, rate cards, tiers, commitments, discounts and customer-specific overrides, defined precisely enough that quoting and billing produce identical results.
Why should pricing be configuration rather than code?
Because pricing changes at commercial speed and code changes at engineering speed. When pricing lives in application code, every experiment becomes a release and historical repricing becomes impossible.
What is a rate card?
The set of prices applied to a customer or segment, including per-unit rates, tier or band boundaries, and currency. A contract may use the standard card or a negotiated override.
Why do meters need versioning?
Because the definition of a billable unit changes as the product evolves. Without versioning, repricing a historical period applies today's definition to yesterday's events, which produces numbers that do not match the invoices already issued.
What causes manually billed accounts?
A deal structure the system cannot express. The commercial team agrees something reasonable, configuration cannot represent it, and someone produces that invoice by hand every period thereafter.
Should quoting and billing share pricing configuration?
Yes. Separate copies drift apart, and the drift shows up as invoices that do not match the quotes customers signed.
Related
Pricing engine. The component that executes the configuration.
CPQ. Applying pricing rules at quote time.
Billing engine. The system the configuration lives in.
Usage metering. Defining the units being priced.
Hybrid pricing models. The structures configuration has to express.
Ready for billing v2?
Solvimon is monetization infrastructure for companies that have outgrown billing v1. One system, entire lifecycle, built by the team that did this at Adyen.
