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.
