Every share of wallet formula has a numerator you know and a denominator you do not. The numerator is what the account pays you, and it sits in your billing system to the cent. The denominator is what the account spends in the whole category, including every dollar it sends to competitors, and no customer is going to hand you that number. So every share of wallet analysis in B2B is an estimate of a ratio in which the bottom half is a guess.
Most guides skip past this. They give you the division, a tidy worked example, and a list of data you should gather. Then a RevOps team builds a dashboard where one account shows 31% share and another shows 64%, and nobody in the forecast call can say whether that gap is real or an artifact of two different guesses. This article is about the guess: the proxies you can use for the denominator, how wrong each one tends to be and in which direction, and which decision each one is accurate enough to support.
The formula, and the half you cannot see
The calculation itself is not in dispute. HG Insights describes it as the account's annual spend with you divided by its total annual spend in the category, times 100. An account that spends $80,000 with you out of $240,000 in the category is at 33%.
A 2012 SAS Global Forum paper on wallet and share of wallet estimation splits the same idea into two parts: internal spend (what the customer spends with you) and external spend (what it spends with other providers). Wallet is the sum. The paper then names the reason the method is common in one industry and rare everywhere else: credit card issuers can buy external spend data from the credit bureaus, and most other industries cannot, because that external spend is unknown.
That is your situation. A software vendor, a distributor, or a services firm selling to mid-market companies has no bureau feed of what each account pays its other suppliers. Everything that follows is a way of standing in for that missing feed.
It is also worth separating two different denominators before choosing a proxy, because teams mix them up constantly:
- Total wallet. Everything the account spends in the category, including spend you could never win (a product line you do not sell, a region you do not serve).
- Realistic wallet. The part of that spend you could plausibly capture with what you sell today. The SAS paper builds its whole method around estimating this one, the "most realistically attainable" wallet, by looking at what the top spenders among similar customers actually spend.
A 20% share of total wallet and a 20% share of realistic wallet lead to very different territory plans. Decide which one you are computing before you pick a data source, and label the column accordingly.
Five proxies for the denominator, and their error bars
There is no clean public benchmark for how far off each method runs, and any vendor quoting you a precise accuracy figure for its spend estimates is quoting its own marketing. What you can know is the shape of each proxy's error: which way it leans, and what makes it worse. That is enough to choose well.
1. Revenue times an industry spend ratio
Take the account's revenue, multiply by a category spend ratio for its industry and size band, and call that the wallet. It is fast, it covers every account on your list, and it needs only firmographics you probably already hold.
Its error is wide and systematic. Two companies with the same revenue and industry code can run completely different operating models: one outsources the function you sell into, the other built it in house. The ratio also averages over the category boundaries that matter most to you. Use it to rank a territory into rough tiers. Do not use it to tell a strategic AE that an account is "at 22%."
2. Installed-base and technographic signals
Look at which competing or adjacent products an account runs, then price those products. This is closer to real spend because it points at named vendors, and it tells you who holds the dollars you are not getting.
The error here comes from overlap and staleness. HG Insights' own data in the article above says that 75% of companies with 100 or more employees running HubSpot CRM also have Salesforce installed. An installed product is not the same as a paid, fully deployed one: a detected tool might be one team's trial, a legacy contract being wound down, or a duplicate after an acquisition. Technographics tend to overstate the wallet when you price every detection at list, and understate it when a large contract sits behind a single detected domain.
3. Seat or unit counts times a price
If your category prices per user, per location, or per unit, estimate the number of units (headcount in the relevant function, number of sites, number of vehicles) and multiply by a realistic blended price. For per-seat software this is often the most defensible proxy you have, because the unit count is observable from hiring pages and public profiles.
The error lives in the price, not the count. Discounting on large contracts is steep and invisible to you, so multiplying seats by list price inflates the wallet for exactly the biggest accounts. Use your own closed-won discount curve by deal size instead of list.
4. Your best lookalike customers
This is the approach the SAS paper formalizes, and it draws on earlier wallet estimation work by IBM's predictive modeling group. Group your customers by the attributes that plausibly drive spend, find the high spenders in each group, and assign that high percentile to everyone in the group as their realistic wallet. The logic is that an account which looks like your top spenders could spend what they spend.
Its strength is that it uses real money you have actually collected. Its weakness is survivorship. Your top spenders in a segment are the accounts that already chose you for most of the category, so the method can only find wallet in shapes you have already won. An account that buys a category in a way none of your customers do is invisible to it. The paper's own method also starts with a survey of customers to learn their external spend, which is a reminder that the lookalike step needs some ground truth to calibrate against.
5. Direct evidence from the account
The narrowest proxy and the most accurate one: what the account has said or published about this category. A public-sector tender with a contract value. A procurement notice. A job posting for someone to "consolidate our four vendors." An annual report that names a key supplier. A customer success manager's notes from a QBR where the buyer mentioned the other contract up for renewal.
It exists for a minority of accounts and it is dated, but where it exists it beats every model above, because it is the account's own number or the account's own words. The practical move is to use it to overwrite the modeled estimate account by account, and to keep the source link next to the override so the next person can check it.
| Proxy | Coverage | Error leans | Good enough for |
|---|---|---|---|
| Revenue times industry ratio | Every account | Wide, either direction | Tiering a territory |
| Installed base priced out | Most mid-market and up | High when pricing every detection at list | Naming the competitor holding the spend |
| Units times realistic price | Per-unit categories | High on the largest accounts if priced at list | Account-level expansion targets |
| Best lookalike customers | Segments you already serve | Low on accounts unlike your base | Setting quota and capacity |
| Direct evidence | A minority of accounts | Narrow, but dated | A specific call this quarter |
Match the proxy to the decision
The mistake is not using a rough proxy. The mistake is using a rough proxy for a precise decision. Share of wallet feeds at least four different decisions, and each tolerates a different amount of error.
- Territory design and capacity. You need the sum across hundreds of accounts to be roughly right. Individual errors cancel out. Revenue ratios and lookalike models are fine here, and the extra cost of better data is rarely repaid. If this is the job, it belongs with your territory planning work, not with account-level targets.
- Prioritizing accounts inside a book. You need the ranking to be right, not the number. A proxy with a consistent bias (for example, units times a realistic price) still orders accounts correctly even if every estimate is 30% high. Rank, and show the rank instead of the percentage.
- Setting an expansion target for one account. Now the absolute number matters, because an AE will be measured against it. Use the installed base or unit proxy, override with direct evidence wherever you have it, and show a range instead of a point.
- Deciding to call this quarter. The share percentage is almost irrelevant here. A 20% share account with nothing happening is a worse call than a 55% share account whose competing contract renews in March. This decision runs on evidence of change, not on the ratio.
That last row is where most share of wallet programs quietly fail. The analysis finds a lot of low-share accounts, which is exactly what whitespace analysis is built to surface. Then the list goes to the field with no reason to act on any particular account now, reps work the ones they already had relationships with, and the dashboard stops being opened.
Show the uncertainty instead of hiding it
An estimate presented as a single precise percentage invites arguments that nobody can win. An estimate presented with its method and a range invites a better question: what would narrow it? A few conventions help.
- Report bands, not points. "Share: 20 to 35%, from seats times our median discounted price" is more useful than "27.4%," and more honest.
- Label the method per account. A column that says which proxy produced each estimate lets a rep discount a revenue-ratio number and trust a direct-evidence one.
- Date the denominator. Category spend changes. HG Insights lists treating the denominator as static as one of the common mistakes, alongside getting subsidiary roll-ups wrong. A wallet estimate from last year's headcount is stale in a company that doubled a team.
- Roll up the hierarchy before dividing. If the parent buys centrally and you sold to one subsidiary, dividing the subsidiary's spend by the parent's wallet understates your share, and the reverse overstates it.
- Keep the evidence with the override. When a rep or CSM corrects an estimate from a conversation, the correction should carry a note of where it came from and when.
Why satisfaction scores will not fill the gap
A common shortcut is to treat high satisfaction or a strong NPS as evidence of high share, and low scores as evidence of wallet leaking elsewhere. The research does not support that shortcut. In a 2011 Harvard Business Review article, Keiningham, Aksoy, Buoye and Cooil argue that traditional loyalty metrics correlate poorly with share of wallet. A customer can be very satisfied with you, recommend you, and still spend more with a competitor it likes just as much.
For an expansion team this is practical, not academic. A happy account is not a safe proxy for a high-share account, and an account's health score will not tell you where the rest of its budget sits. You still need a denominator estimate, and you still need a reason to raise the conversation.
From a ratio to a reason to call
Take the proxies above seriously and you end up in a reasonable place: a ranked book, a range for each account, a method label, and direct evidence overriding models wherever it exists. That is a good planning asset. It is still a picture of where the money is, not an argument for why the account will move it.
The fifth proxy, direct evidence, is doing two jobs at once. It narrows the error bars on the denominator, and it is usually the same material that explains why an account would shift spend this quarter: a renewal date, a consolidation project, a new leader who came from a company that ran your product, a hiring push in the function you serve. Those are buying signals, and they are specific to what you sell. A tender for a new ERP matters to a finance software vendor and means nothing to a logistics provider.
That is the gap PitchSmart is built for. It researches each account on your list against the products you actually sell and returns the buying signals that apply to each product, with the source for every one, so the low-share account on your dashboard arrives with the evidence of why to raise it now. It does not estimate the denominator for you, and it does not replace your spend model. It supplies the part of the analysis the model cannot produce: dated, checkable reasons tied to a specific product.
If you run expansion on a book of existing customers, pair the two. Let the share of wallet model decide where to look, with its uncertainty shown honestly. Let account-level evidence decide who gets a call this quarter and what the call is about. The same logic sits under any land and expand strategy: the land tells you the account can buy from you, and the evidence tells you when it is ready to buy more.
The same question applies above the account. Price volume mix analysis separates a revenue change into price, volume, and mix, so an expansion quarter that came from discounting does not get mistaken for one that came from selling more of the right product.
