If you rank companies by revenue, McKesson shows up near the very top — north of $300B a year, bigger than most household-name tech giants. If you rank them by net margin, it nearly disappears: the margin is well under 1%. Both numbers are correct, and storing only one of them in your company-data schema will mislead every downstream comparison you build.
The issue is that revenue means completely different things depending on the business model behind it. For a software company, revenue is close to value captured. For a pure distributor like McKesson — which moves pharmaceuticals from manufacturers to pharmacies — revenue is mostly pass-through: the cost of the drugs flows straight through the income statement. The company's actual economics live in the thin spread it keeps, not the enormous number at the top of the P&L.
So a revenue column, used as a proxy for "size" or "success" across a mixed dataset, systematically overweights distributors, wholesalers, and retailers against asset-light businesses that capture far more per dollar of revenue. A "largest companies" ranking sorted on revenue alone will tell you McKesson is more significant than companies with a tenth of its revenue and ten times its profit.
The schema fix is to stop treating revenue as a scalar success metric and store the fields that let you compute the one that matters for the question you're asking: gross_profit, net_income, and ideally revenue_model (pass-through vs. value-capture) as an explicit category. Then "rank by size" becomes an intentional choice — revenue, gross profit dollars, or margin — rather than an accident of which column was handy.
I dug into this while writing up how McKesson actually makes money — the thin-margin-at-massive-scale model is the clearest example I've found of why a single revenue figure lies.
How do you handle this in your own schemas — a revenue_model enum, a computed margin column, or something else?
Top comments (0)