A few weeks ago I sat in on a call with the revenue operations team at a mid-sized North American HRIS company. On paper, their stack was a good one. ZoomInfo for firmographic enrichment, Dun & Bradstreet layered on top for verification. The kind of setup that looks, in a vendor comparison spreadsheet, like due diligence.

They were frustrated anyway. Reps would call into a down-market account, the kind of company with ten or fifteen people and a Shopify store, and the numbers on the account record wouldn't hold up. ZoomInfo would say fifty employees. The person who picked up the phone would say six. This had been happening long enough that the team had quietly started describing the data itself as broken.

It isn't broken. It's guessing. And the more interesting question, once you sit with that distinction for a minute, isn't really about ZoomInfo, or about this one HRIS company. It's about why an entire industry built its comp plans, its territory maps, and its lead-scoring models on top of a guess, priced that guess as if it were fact, and never quite noticed.

A formula wearing a fact's clothing

Here is the part of this that almost never gets said out loud to the people using the data: below a certain company size, there is no fact to report. Public companies file 10-Ks. Private companies at real scale leave a paper trail of press coverage, hiring announcements, the occasional funding round. A ten-person Shopify brand leaves almost none of that. There is no earnings call to transcribe, no filing to scrape.

So the enrichment vendor does the only thing it can do: it infers. It looks at signals that correlate with company size, such as job postings, website traffic, and technology footprint, runs them through a model, and returns a number. Employee count in, revenue estimate out, or the reverse. This is not a scandal by itself. Modeling under uncertainty is a completely reasonable thing to do when better information doesn't exist.

The scandal, if there is one, is in the presentation. The output of that model arrives in your CRM in a text field that looks identical to a fact. There is no confidence interval next to it. There is no note explaining that this number is a statistical guess built on proxies rather than something anyone actually observed. It sits in the same cell format as a phone number or a mailing address, both of which are, in fact, facts. Nothing in the interface tells the rep, the RevOps analyst, or the VP building next year's territory model that one of these things is not like the others.

This is, more or less, the horoscope problem. Nobody involved is lying. The person writing the horoscope believes in the framework they're using, more or less, the same way a firmographic model believes in its own correlations. The issue is calibration: the confidence of the output has become completely detached from the quality of the evidence behind it. Political forecasters learned this lesson the hard way in 2016, when a number like "71 percent" got read by millions of people as "certain" rather than as what it actually was, a probability with real uncertainty baked in. B2B data vendors never had to learn that lesson publicly, because nobody was checking their scorecard the way people checked the pollsters'. Until, in this case, someone did.

So we checked

We took 101 down-market accounts and ran them through two parallel paths. One returned observed card transaction revenue: real dollars that moved through each business over a trailing twelve-month window, drawn from actual payment activity rather than inferred from proxies. The other ran through Clay, a widely used enrichment layer built on the same category of firmographic modeling as ZoomInfo and D&B, returning an employee-count bucket and a revenue-range bucket for each company.

This is not a takedown of Clay specifically. Clay is a reasonably representative example of an entire category of tool that does the same thing the same way, and it happened to be the one sitting next to our own data in the same spreadsheet. The comparison is really between two categories: modeled estimate versus observed transaction.

That first result is worth sitting with, because it complicates the easy version of this argument. Card transaction data didn't win by simply covering more ground. Both sources matched the company itself at different rates (100 percent versus 66 percent), but once you narrow to "did this source give me a usable revenue number," they converge to roughly the same coverage: 53 percent versus 50 percent. If completeness were the whole story, this would be a wash.

It isn't the whole story, because completeness was never really the complaint. The RevOps team on that call didn't say the data was sparse. They said it was wrong. So we checked that instead.

What happens when you can actually check the guess

Twenty-four of the 101 accounts had both an observed card revenue figure and a Clay revenue bucket, and were flagged as having genuine ecommerce activity, which matters, because card revenue is the fairest test on exactly this kind of company: a business that sells online should have a meaningful share of its revenue running through card payments.

The forecast wasn't just wrong. It was wrong in the same direction, every time, which is the tell that you're not looking at noise. You're looking at a bias baked into the method.

A random guess misses in both directions. A biased estimate misses in one direction, consistently, because the model was built to infer size from signals like headcount and job postings, and those signals systematically run ahead of realized revenue for small, real businesses. A company can post three job listings and have a slick website long before it's actually generating the revenue a model might associate with those signals. The formula isn't wrong about what it's measuring. It's measuring the wrong thing and calling it revenue.

Numbers like "83 percent" can flatten into abstraction fast, so here's what the miss actually looks like, company by company.

AAPPTec is bucketed at $25 million to $75 million in annual revenue, with a specific employee count of 27. Its observed twelve-month card revenue was $146,493. Aiphone, a 237-employee manufacturer elsewhere in the file, is bucketed at $200 million to $500 million against $157,000 in observed card activity. To be fair to the model, Aiphone is a business-to-business manufacturer that likely does most of its revenue through invoicing rather than card payments, so its card figure understates its true revenue by a wide margin. AAPPTec doesn't have that excuse. The median company in the overshoot group was running at roughly 2 percent of Clay's stated floor. That is not a rounding error. That is a different order of magnitude, delivered with the full confidence of a fact.

The guess disagrees with itself

One more check, and this one doesn't even require an outside source. Clay returns two separate employee signals for every company: a size bucket, such as "11-50 employees," and a specific employee count. These describe the same company from the same enrichment pass. In principle, they should never conflict.

Just over half the time, they don't agree. Wunderkin Co is labeled "self-employed" in one field and "3" in the other. Whalen Furniture is bucketed at 201-500 employees with a specific count of 185, just outside its own stated range. This isn't a knock on Clay's matching engine specifically. It's a reminder of something more general: a model can be perfectly consistent in its methodology and still produce two outputs that contradict each other, because the underlying inputs, job postings scraped one week, a LinkedIn headcount scraped another, were never reconciled to begin with. If the tool can't agree with itself, asking it to agree with reality was always optimistic.

Why nobody built this to be honest

It would be easy, and wrong, to make this a story about one vendor cutting corners. Nobody at ZoomInfo or D&B or Clay is trying to deceive anyone. The more accurate and more uncomfortable explanation is structural. Nobody in this chain was ever incentivized to be honest about the uncertainty.

The vendor's incentive is renewal, not accuracy audited against reality, and renewal is driven by whether the tool feels indispensable inside daily workflow, not by whether last year's down-market revenue bucket held up. The buyer's incentive, once the tool is embedded in the CRM, is to trust the field, because auditing it means admitting that a system the company paid for and built process around might be systematically wrong, which is an uncomfortable thing to tell a VP who signed the contract. And the RevOps analyst inheriting the tool three years into its deployment has no practical way to check twenty thousand account records against reality one phone call at a time. The lineage of the number, model or observation, gets stripped away the moment it lands in a field labeled "Revenue." After that, it's just data.

So the estimate becomes the input to a scoring model. The scoring model becomes the input to a territory design. The territory design becomes the input to a comp plan. By the time a rep is being told which accounts to prioritize this quarter, the number driving that decision has passed through three or four layers of institutional trust, and at no layer did anyone stop to ask how confident the original number actually was. This is how Big SaaS, broadly, ended up building serious operational infrastructure on top of numbers that were never meant to carry that much weight. Not through malice. Through a long chain of reasonable-seeming decisions, none of which included the step where somebody calls twenty-four companies and checks.

What actually resolves it, and what doesn't

Observed transaction data solves the calibration problem, though it's worth being precise about how, because overclaiming here would repeat the exact mistake this piece is about. Card revenue is not total revenue. It's a lower bound, and for a business that runs heavily on invoicing, wires, or cash, the gap between card revenue and true revenue can be wide, which is exactly what we saw with Aiphone. That's a real limit, and it's why the fairest test in this analysis was restricted to companies with confirmed ecommerce activity, rather than the full 101-account sample, where the gap would have looked even more dramatic and less honest.

What card revenue does offer, within that limit, is a fact rather than an inference. It didn't come from a model guessing at what a company with this many employees probably makes. It came from dollars that were actually observed moving through the business. That's a categorically different kind of information from a bucketed estimate, even when both arrive in the same shaped field in the same CRM.

And the underlying logic holds up: revenue precedes headcount, not the other way around. A company generating real revenue eventually staffs up to support it. A company that "should" have fifty employees according to a formula might just be a formula with a logo. If you're building a target account list for a seat-based product, the account actually worth calling is the one with a hundred thousand dollars a year moving through it and ten employees, not the one a model guessed might have fifty employees and no verified revenue to show for it.

The actual ask

This piece isn't really an argument that our data beats their data, though the numbers above make a fairly strong case for observed transaction signals over modeled buckets down-market. The larger ask is smaller and harder to argue with: know which fields in your CRM are facts and which are formulas, and stop building comp plans and territory maps as though that distinction doesn't matter. Most revenue organizations have never actually run the check we ran here. It takes a spreadsheet and twenty-four phone calls' worth of patience. Before the next renewal cycle, it might be worth finding out what your own numbers would say.