The decision layer in software monetization, and why it cannot be automated from the meter.
TL;DR: The pricing decision layer is where a software company’s licensing, packaging, and pricing choices are made. This year, venture funding reached every layer that executes those choices at runtime: metering, billing, entitlement enforcement. The execution stack went always-on. The decisions did not become automatable in the process, and the meter is the wrong instrument to automate them from. Continuous means always-on sensing, deliberate deciding.
The execution stack went always-on. One layer did not.
Inside six months, payments and platform companies acquired the three leading independent usage-metering vendors. We wrote about what that consolidation means for metric independence in Who Owns Your Meter Now?, and the short version has held: the meter now has a landlord, and the landlord earns on transaction flow. Billing was already consolidated infrastructure. This spring the remaining execution layer followed, when a runtime enforcement vendor raised venture money to make entitlement checks a first-class primitive inside the payment stack, describing runtime monetization as infrastructure and the product category as a monetization control plane. The trade press framed the round as helping software companies update pricing faster in the AI era.
Metering, billing, entitlement enforcement: every layer that executes a pricing decision is now always-on, venture-funded, and consolidating into distribution platforms. One layer remains episodic in the industry’s imagination: deciding what the metric, the packaging, and the price should be.
The funding carries an implicit thesis: decisions are set-and-done configuration; execution is continuous. Make pricing changes cheap to ship, the pitch runs, and you can change pricing often. The pitch assumes that knowing what to change is the easy part.
One runtime vendor’s public framing goes further: AI has made software pricing non-deterministic, so pricing must be enforced at runtime rather than through a billing provider’s webhooks. As a claim about enforcement, that holds. As a claim about pricing, it quietly relocates the deciding into the layer that profits from its output.
The decision layer, defined.
The decision layer is the part of software monetization where the three structural decisions are made: the licensing model that selects the value metric, the packaging model that groups capabilities into offerings, and the pricing model that computes what each configuration costs at list and at net. Everything else in the monetization stack executes what this layer produces. The meter counts the unit the licensing decision selected. Billing invoices at the prices the pricing decision set. Entitlement enforcement grants and denies what the packaging decision defined.
We drew the boundary in Operationalized Pricing: billing answers what to invoice for what already happened; the decision layer answers what this deal should be priced at, and why. When the metering acquisitions closed, we made the point sharper. The decision layer is the only part of the monetization stack still independent, because it is not a product anyone can acquire. It is a discipline.
Decision layer vs. control plane
The runtime vendors call their category a control plane, and the term is accurate for what the products do. A control plane distributes state that something else determined. Applied to monetization, it decouples pricing and packaging logic from application code and enforces it at runtime, so a limit change or a plan change propagates without an engineering ticket. That is useful machinery, and vendors should want it.
What a control plane does not hold is the material a pricing decision is made from: the deal record, the contract base a change would land on, the transition plan for the accounts that would pay more. It holds the current configuration and the machinery to enforce it. The decision layer is where configurations come from; the control plane is where they go. A company that confuses the two ends up with flawless enforcement of a model nobody validated.
Continuous vs. automated
The convergence the funding is chasing is mostly correct. Pricing changes should be cheap to ship. The monetization stack should be instrumented. The repricing-every-three-years era is over, and the decision cadence is compressing. The convergence goes wrong on a single assumption: that when decisions go continuous, they go automated.
Decisions do go continuous. That is Continuous Monetization: pricing iterated on the same cadence your team ships product, not a one-time project repeated every few years. Continuous, applied to a decision, describes the operating rhythm. It does not remove the decider. The sensing half runs always-on: telemetry on the live pricing surface, drift detection against the pricebook, simulation of candidate changes against the actual contract base. The deciding half stays deliberate: a governed change, made by people accountable for the customer base it lands on, shipped on the product’s own cadence.
Always-on sensing, deliberate deciding. Cadence compresses; authority does not. That split is what separates a monetization practice from a thermostat.
Who Is Actually Making Your Licensing, Packaging, and Pricing Decisions?
If enforcement mechanisms are answering structural questions your decision layer never resolved, revenue leaks by design. Describe your current architecture and a pricing expert will identify where the decision layer is missing.
Why the meter cannot make the decision
Suppose a runtime layer starts recommending prices from its own meter. Two structural problems arrive with it, and neither is a modeling defect that a better model fixes.
The first is incentive. A layer paid on metered volume profits when the metric generates more billable events, and it bears none of the cost of a customer base that sours under the recommendation. It will recommend more billable events. Embed that layer inside a payment stack and the incentive sharpens, because the infrastructure owner earns on the flow of money it processes. The metric menu drifts toward the infrastructure’s interests. We call that pull infrastructure gravity, and it operates whether or not anyone intends it.
The second is evidence. A meter sees consumption: events, tokens, seats, calls. It does not see why a deal closed or died, what the buyer compared you against, which configurations collapsed in negotiation, what the renewal conversation surfaced about realized value, or which discounts the deal desk approved and why. That record is the calibration a pricing decision runs on. An optimizer trained on the meter is calibrated on the one data source that cannot tell it whether the price was right.
The peer-reviewed record backs the caution. A large-scale randomized field experiment in subscription services tested precisely this move: proactively recommending plan changes to existing customers based on their own usage data. Churn in the contacted group rose by more than half within three months. The damage concentrated in accounts with volatile or declining usage, which are exactly the accounts a meter-driven optimizer flags first. The experiment also isolated the mechanism: outreach alone changed nothing; surfacing usage data and recommending a change is what moved customers to leave.
There is a legal record too. Regulators have argued that algorithmic pricing systems can facilitate coordination between competitors even without any explicit agreement. When one platform operates pricing logic for thousands of vendors at once, that exposure stops being theoretical. A pricing decision made by an algorithm is still a decision someone must govern; the algorithm just makes the governance harder to locate.
We watched a client live the meter-decides loop. A billing modeling tool simulated a new metric from their billing data, and their customers pushed back hard. The metric we ultimately recommended appeared nowhere in that data. They could have simulated inside the microcosm forever; the answer was never in it. It came from patterns borrowed across other industries, and that borrowing is expert judgment armed with scale: a pattern library of $481B+ in transaction activity, presenting the expert with patterns that expand the choice set. A billing meter is a microcosm. The pattern library is the market.
Billing data is survivorship data
The evidence problem has a name: survivorship. Every invoice is a deal you already won. A billing record exists only because a buyer accepted a price, so the meter’s entire history is written by winners. The deals you lost, the quotes that collapsed, the configurations a buyer rejected, the discount a deal desk declined to approve: none of it generates a billing event. An optimizer trained on that exhaust learns what survived. It cannot learn what was tried and failed, and pricing decisions calibrate on exactly that record.
Delineating the corpus a pricing decision actually runs on makes the gap concrete: win and loss events, the buyer’s full choice set (the configurations you offered and the competing vendors they weighed), billing data, usage data, cost data, the product roadmap, a repository of value drivers, validated customer perceptions of value, and expert judgment. Billing exhaust is one line of that inventory. A claim that the corpora are equivalent is a claim that the other eight lines do not matter.
The blend has been tried. One billing platform ran the experiment at $200 million scale: it acquired a well-known pricing consultancy, held it for two years, and divested it, concluding that a fintech is not a consulting business. The meter and the judgment layer did not fuse. The meter ejected the judgment.
Enforcement executes decisions. It cannot legitimately make them: the party doing the enforcing holds the wrong incentives, and the meter it would decide from holds the wrong evidence.
A pricing decision in B2B is a governance event
A price in B2B software does not live in a database row. It lives in contracts. A pricing change lands on an existing customer base account by account: who pays more, who pays less, what transitions at the next renewal, what phases across two cycles. The communication plan, the sales enablement, and the renewal posture are part of the change, and none of them deploy through a webhook.
When the decision is a value metric change, the kind the AI era keeps forcing, the stakes compound. The metric is selected by the licensing decision, and the packaging and pricing models are built around it, so a metric swap re-architects all three. That is simulation-plus-judgment work against your own transaction record. It is not a dial.
You also cannot experiment your way around the deciding. A contract base is not an experiment population: enterprise deals are negotiated one at a time, deal counts never support random assignment, and buyers compare notes. Enterprise buyers treat visible price experimentation as unfairness, and the record on situational pricing shows what that costs. Two buyers finding different prices for the same thing, set by conditions neither can verify, produces distrust and dispute; the market fairness principle exists because similar buyers should pay similar net prices for similar value. A meter-driven repricer adjusting terms account by account is situational pricing with better instrumentation.
What calibrates a B2B pricing decision instead: transaction data across the install base, won/lost deal patterns, renewal behavior, and post-deal conversations about realized value. None of it streams from a meter. All of it takes deliberate collection and governed interpretation. When a change of that weight is on the table, the sequence that works is evidence first: model the change against your own contract base, plan the customer transition, and talk to a pricing expert while the decision is still reversible.
The AI era multiplies decisions. It does not automate them.
The runtime vendors’ strongest argument is cadence, and it is correct. AI monetization forces more pricing decisions per year than seat-era SaaS forced per decade: agent pricing, credit systems and their conversion tables, hybrid meters, metric swaps arriving on model-release timelines instead of planning cycles. We have tracked what happens when vendors bind to the wrong unit under that pressure, including how variable AI pricing suppresses the exploration vendors need. That pressure lands on the decision layer hardest.
More decisions raise the value of calibration. They do not lower the bar for who decides. A company facing ten pricing decisions a year does not need the deciding automated away; it needs the pricing decision layer instrumented, so every decision starts from evidence instead of from a blank page.
Instrumented means the sensing half running for real: candidate metrics and packaging simulated against the actual transaction record, drift caught when deals land off the surface, the contract base modeled before a transition rather than after. That is what LevelSetter exists to run. The deciding half stays where it belongs: with the people accountable for the P&L, supported by practitioners who have carried metric transitions through live customer bases. We hold no meter, process no payments, and have no position in which model shape wins. A decision layer that is not independent is not a decision layer; it is a sales channel for whoever owns the infrastructure.
The execution stack will keep consolidating, and the recommendations from inside it will keep coming. What they earn you is set upstream, by the value metric the price binds to, the packaging customers actually buy, and the net price each commitment should carry. If those choices currently live in a two-year-old deck, talk to a pricing expert about making them observable, governed, and current before the stack starts making them for you.
