In an enterprise deal, the business owner who wants your product is surrounded by IT, compliance, procurement, and finance - and the instinct is to carve those people out and sell to the champion who called you in.

In our experience that instinct is wrong twice over. Practically, it leaves a lot of money on the table on every deal it touches. But more fundamentally, it misreads who's actually buying: the auxiliary stakeholders around the table aren't just gatekeepers rubber-stamping someone else's purchase - they're buying too, because the product solves a real problem on their desk as well as the champion's. An HR platform is routinely too expensive for HR's own budget to justify alone, but it also solves problems for IT (provisioning, security) and Finance (reporting, compliance), so splitting the cost across those budgets isn't a pricing trick, it reflects where the value actually lands.

A wallet has different compartments, and there's a credit card in each compartment - and you need to max out every credit card the customer has.

‍- Ulrik Lehrskov-Schmidt, author of The Pricing Roadmap

Wallet structuring turns the buying committee from an obstacle into the structure your pricing is built around. Instead of asking one budget to swallow the whole bill, you ask each budget to pay for the part it already pays for elsewhere in the business.

This is a WillingnessToPay framework - Chapter 5 of The Pricing Roadmap - and it's one of the highest-leverage moves available in enterprise B2B SaaS once a deal moves out of the mid-market band.

Wallet structuring shows up in almost every enterprise repricing we run, and the framework below is how we approach it in practice.

What is wallet structuring?

Wallet structuring is the practice of fitting your pricing structure to the customer's budget structure - so that you capture what every budget your solution touches would pay, not just what your primary buyer will approve on their own.

The starting observation is that enterprise software isn't bought by a person. It's bought by a group of people, and we've come to think of that group as the Wallet.

The Wallet.
‍The buying committee for an enterprise deal. At the centre sits the primary buyer - the business-line person who owns the problem you solve, holds the KPIs, and controls the main budget. Sitting around them are two to five auxiliary stakeholders - the CIO or a technical owner, compliance, the COO, HR, procurement, legal - each of whom can block the sale and each of whom holds a budget of their own.

Like a real wallet, the organization's wallet has compartments - and several of those compartments hold real money. The size of the wallet scales with the deal itself. A small ACV might involve one or two stakeholders. A multi-million-dollar enterprise contract can mean a task force reporting to twenty-five of them.

This is why wallet structuring is an enterprise technique specifically. Below roughly $25K ACV, the wallet is usually shallow enough that the complexity doesn't earn its keep.

Above $50K it starts to matter. Above $200K to $400K, it should be designed deliberately - especially when a product that grew up in SMB or mid-market is now moving upmarket into committee-driven deals.

The committee is your structure, not your obstacle

The reason to lean into the committee rather than route around it comes down to a simple observation about enterprise software pricing: nobody in the room can price an enterprise software purchase as a whole, and, more to the point, no single person in the room is the only one actually buying it.

The honest truth is that the value of a large software purchase isn't a single knowable number - credible arguments put it almost anywhere across a very wide range.

So the committee doesn't evaluate the purchase as one thing. Each member is, in a real sense, buying the part that lands on their desk.

• The CIO assesses, and is buying, the cloud setup and API costs.
• The HR partner assesses, and is buying, the training.
• The Head of Compliance assesses, and is buying, the regulatory and reporting setup.

Each one recognizes that the line item in question is going to land on their budget - or at the very least, that they're the one responsible for judging whether the price on it is fair.

As each auxiliary stakeholder signs off their part, they turn back to the primary buyer, and if the primary buyer's unit economics work for them, they sign off too. The deal is done.

Seen this way, your pricing is really a conversation guide the buying committee uses to evaluate your proposal after you've left the room. The champion pulled all those stakeholders in partly to share the risk of the decision, and partly because they need cross-functional buy-in to implement the product properly once it lands. Wallet structuring just gives each of those people a part they can own, approve, and, for the part that solves their own problem, genuinely pay for.

The method: map pricing onto the budget structure

With the committee reframed as your structure rather than your obstacle, the method itself is concrete and repeatable. We work through five steps on every wallet-structuring exercise, and the output is a pricing architecture mapped cleanly onto the customer's budget structure.

The 5-step method

1. List and categorize everything you deliver - every capability, output, and resource your solution provides. Features, reports, storage, API access, training, integrations, support - all of it goes on the list.
2. Assign each item to the budget owner who already pays for that kind of thing - reports, audits, and security map to compliance; storage, cloud, API calls, and developer hours map to IT; training and certifications map to HR; the core outcome maps to the line-of-business buyer. People readily accept paying for things they're used to paying for.
3. Evaluate each owner's expectation to pay - use the price-perception lens from each stakeholder's point of view (see Pricing Segmentation). The primary buyer pays on the product's value; the auxiliary buyers pay on expectation-to-pay.
4. Price each item in that budget's own language - per API call, per gigabyte stored, per report, per training certificate, per end client. When a charge is phrased in units the target budget already understands, the owner tends to simply accept it.
5. Don't price wildly above perceived cost - each auxiliary line item has to look fair against what the owner expects to pay. Wallet structuring lets you price the primary buyer on value and the auxiliary budgets in a more cost-plus fashion, both at once - but only if the auxiliary items stay believable.

The output at the end of the exercise is a pricing architecture mapped onto the organization's budget structure, designed so a single principle holds throughout - make everybody pay.

Make the customer's budgets pay your costs (cost proxies)

One of the most useful applications of wallet structuring is covering your own costs - specifically the costs a minority of customers can create when they use the platform much harder than the rest.

Left unattended, those customers can be losing money without anyone on the finance team noticing for a while. Wallet structuring gives you a way to load that cost onto the customer budget that already sits closest to it.

That mechanism has a name in our framework:

Cost proxies.
‍A pricing metric that tracks a cost line rather than strictly causing it. You don't need a metric that mechanically drives the cost; you need one that correlates strongly enough that pricing on it moves in the same direction as the cost, at the same scale. The clearest example is charging per end client because the number of end clients correlates tightly with platform, security, and compliance spend, even though not every end client makes a call.

This trading-software provider example is the one we use most often to explain it:

Roughly $12.5M of a $50M operational IT bill sat in a single "trading platforms" cost line, and when we asked what drove that cost line up over time, the answer wasn't trades or assets under management - it was the number of end clients. There were about 1M of them. Dividing $12.5M by 1M gave roughly $12.50 per end client per year, which rounded neatly to about $1 per month.

We then repeated the same exercise on the other IT cost lines - API calls, back office, manual trades - and between the four proxies covered more than 90% of the IT cost base without needing perfect causation on any of them.

The pitch to the customer is straightforward when it's phrased honestly - "we charge per end client because that's what drives our security and compliance costs, and there's no margin on this line."

Forecast the cost curve at scale and you can price the proxy to hit your target margin at each ARR level without ever squeezing the primary buyer for it.

Unload the primary buyer's unit economics

The second power move inside the method is subtler than cost proxies, and in most projects we run it does more of the heavy lifting on deal size.

By shifting pricing load off the primary buyer's budget and onto the auxiliary budgets, you can make your offer look cheaper on the metric the primary buyer watches - even when the net amount the organization pays comes out the same.

The trading-software provider used exactly this move to close deals faster.

Several of the banks it was selling to cared most about brokerage rates, and the provider could offer better brokerage rates precisely because it was charging separately for the platform itself.

The banks paid roughly the same in total across the two line items, but the brokerage number they watched most closely came in lower - which meant the head-of-trading conversations went a lot smoother than they otherwise would have.

Seen from a distance, a well-run wallet-structuring exercise is a pre-made internal budget negotiation, run on the customer's behalf before they have to run one themselves.

Load your entire licence onto one budget and you're asking the primary buyer to fund 100% of a solution that - had they built it in-house - would have been spread across nearly every budget in the organization.

Spreading it back out shifts the question from "is the whole organization willing to pay this?" to "can this one budget afford its share?" - and the second question almost always clears at a lower threshold than the first.

Wallet structuring as a no-churn repricing lever

Because wallet structuring opens budgets beyond the primary buyer, it turns out to be one of the cleanest ways we know to raise enterprise prices without triggering churn.

The move is intuitive once you see it. When the primary buyer's unit economics are maxed out - they simply can't take another dollar on the core metric - you go to the budgets that have money for things those owners would already have paid for elsewhere, and you charge those instead.

The case we use most often to illustrate this is an insurtech running a claims-management system for large insurers.

The insurtech wanted higher margins, but hit heavy resistance when it tried to raise the core per-claim price - which was the number the head of claims cared about, and where the primary buyer's unit economics had already stretched about as far as they could. Pushing harder on that number would have started to threaten the renewals themselves.

The fix wasn't to keep pushing. It was to add API calls, storage, and third-party data priced to the IT budget, and to add regulatory reporting priced to the compliance budget.

Every one of those line items was for something those owners were already paying for elsewhere, so none of them landed as unfair. The per-claim price held steady. Roughly 60% of new revenue was added on top across the IT and compliance budgets. On a company doing about $30M ARR, prices came up by more than 50% - and churn came in at zero (see also: SaaS Price Increases & Repricing at willingnesstopay.com/saas-price-increase).

That's the pattern to remember: don't squeeze one budget harder, bring more budgets in. Enterprise deal structures that map cleanly onto the buyer's organization also tend to close faster on the way in.

Thirdfort's move to a tiered, value-based structure that captured value across every segment accelerated enterprise deal closure by 96%. (Thirdfort case study: willingnesstopay.com/case-studies/thirdfort)

Guardrails

Wallet structuring is powerful, but it isn't a blank cheque. A handful of rules keep the structure honest and durable over time, and every wallet-structured deal we run gets tested against them.

It isn't a licence to raise prices indiscriminately. Every auxiliary charge has to be defensible to the owner it lands on. Adding a line item to compliance because compliance has a budget doesn't work if compliance can't explain the line item to their own boss.

Don't price too far above perceived cost. If an item looks expensive against what that budget expects to pay, trust erodes and the sign-off stalls. Comparable market costs matter here: you can't charge $1 per API call if every large vendor in the market charges $0.001, no matter how cleanly the logic maps to your own infrastructure spend. The whole architecture depends on every part looking fair when the budget owner assesses it in isolation.

Match complexity to the size of the deal. Wallet structuring adds complexity to your pricing architecture by design, and the complexity has to be worth carrying. Match it to the size of the wallet and the deal, not more - this is the complexity budget from SaaS Packaging (willingnesstopay.com/saas-packaging).

Keep it inside one framework. Bespoke, one-off budget carve-outs that don't generalise are how you accumulate commercial debt (willingnesstopay.com/commercial-debt) - and commercial debt is the slow way to stall an otherwise well-designed pricing system.

Used with those guardrails, wallet structuring lets you price the primary buyer on value and the rest of the organization in a cost-plus fashion - value pricing and cost-plus, running at the same time.