Blog · Wallet share and penetration
Separate a single customer's wallet-share movement into changes in your category sales and changes in the customer's total category spend, with an exact ordered bridge.
Share-of-wallet change decomposition explains why one customer's percentage moved. Your sales may have increased while the customer's category spend increased faster. Alternatively, the new percentage may reflect a revised estimate rather than a change in buying. The account conversation depends on which of those occurred.
The wallet calculation guide owns the formula. The fixed-cohort guide owns changes in a whole book's customer mix. Here the unit is one matched customer and category across two periods.
Keep the customer entity, category, currency and period length consistent. Record measured sales, wallet, source type, reference period, evidence date and method version for both observations. A trailing twelve-month sales figure cannot be compared with an unmatched fiscal-year customer declaration without an explicit adjustment.
Verify that credits, returns and one-off transactions follow the same policy. A customer acquisition or change in reporting scope can alter both figures, so separate that event from a same-scope commercial movement.
Use the source-label guide to distinguish current customer statements, inference and stale evidence. Unknown or nonpositive wallets cannot support an ordinary percentage bridge; report the reason instead of dividing by a placeholder.
Let sales0 and wallet0 be opening values, and sales1 and wallet1 closing values. In a sales-first bridge:
Opening share = sales0 / wallet0
Sales effect = (sales1 − sales0) / wallet0
Wallet effect = sales1 / wallet1 − sales1 / wallet0
Adding opening share, sales effect and wallet effect yields sales1 / wallet1 exactly. Express effects in percentage points, not percentages of the opening share.
The order matters for the allocation between effects. A wallet-first bridge is also valid if declared, but its individual contributions differ. Do not compare sales-first effects in one period with wallet-first effects in another as though they were the same statistic.
These figures are synthetic annual USD category totals, not a customer case study.
| Measure | Opening | Closing |
|---|---|---|
| Your category sales | $100,000 | $120,000 |
| Customer's category wallet | $400,000 | $600,000 |
| Wallet share | 25% | 20% |
Sales grew 20%, while category spend grew 50%. The share declined five percentage points.
The sales-first bridge is:
| Step | Calculation | Share or effect |
|---|---|---|
| Opening share | 100,000 / 400,000 | 25% |
| Sales effect | 20,000 / 400,000 | +5 points |
| Interim share | 120,000 / 400,000 | 30% |
| Wallet effect | 120,000 / 600,000 − 120,000 / 400,000 | −10 points |
| Closing share | 25% + 5 points − 10 points | 20% |
The account bought more from you. Its overall category expansion outpaced that increase. Calling the five-point decline a $20,000 sales loss would contradict the ledger.
At the closing wallet, holding the opening 25% share would mean $150,000 of sales. Actual sales were $120,000, a $30,000 shortfall to that constant-share scenario. That is a counterfactual comparison, not an invoice loss or automatically winnable revenue.
If a reachable-share target is used, name it and explain its evidence. Do not assume the business can capture every dollar it does not currently hold. Product fit, procurement timing and supplier concentration preferences may constrain expansion.
Suppose the closing wallet rises only because a new declaration replaces an outdated estimate. Label that as an evidence revision. Where feasible, recompute the opening period on a consistent method and retain both the original published result and the restated comparison.
Use estimate sensitivity if denominator uncertainty is large enough to alter the conclusion. The precise arithmetic of a bridge does not make uncertain input values precise.
Keep the four original inputs and bridge formulas together. Microsoft's scenario documentation supports inspecting alternative inputs; its SUMPRODUCT reference supports aggregating declared weights when extending the review. Book-level movement still needs matched totals and explicit mix treatment.
Send the account owner a short interpretation: measured sales movement, observed or inferred wallet movement, scope/evidence exceptions and next question. Discuss the required records and output with Covirage. Use the result to investigate an account, not to assign commercial blame from one percentage.
Yes. If the customer's total category spend grows faster than your sales, your percentage falls. Review both amounts before calling the movement lost business or poor account management.
Not necessarily. Replacing a stale estimate with better evidence changes the reported denominator even if buying behavior did not change. Show evidence revisions separately from observed category-spend movements.