The Outside-In Revenue-per-Employee Read: Leaner, On-Band, or Bloated

You have a rival or an acquisition target, no income statement, and no reliable headcount, and someone wants to know whether the company is over- or under-resourced. This playbook is for strategy, corporate development, and talent-intelligence analysts who need to estimate revenue per employee (RPE) from the outside and then defend the number in a room. It takes you from a frozen set of definitions to a stage- and industry-adjusted RPE band with a documented headcount correction, a revenue range with a stated error band, and a verdict of leaner, on-band, or bloated against named peer benchmarks.

Every public guide on revenue per employee assumes you own both inputs. You own neither. So the work here is not arithmetic - the division is trivial - it is estimating two uncertain quantities and being honest about how uncertain they are.

Why the outside-in read is different from the textbook one

The textbook formula is annual revenue divided by full-time-equivalent headcount. From the outside you have neither term cleanly, so the job becomes estimating both and carrying the error through to the verdict.

Revenue per employee is calculated as annual revenue divided by full-time-equivalent (FTE) headcount, where one FTE is one full-time worker and part-timers count proportionally - a 20-hour-a-week worker is 0.5 FTE. That is the easy part. The hard part is that most private companies do not report revenue, even shared financials are often unaudited and inconsistent, and the profile counts you use as a headcount proxy count profiles, not payroll.

Two structural facts make the outside-in read fragile, and you should internalize both before you start.

First, the benchmark you choose can flip the answer. Public SaaS runs a median of about $395K in revenue per employee while private SaaS sits at $141,125 - a gap of roughly 2-3x driven by operating leverage and survivorship in public indices. Grade a private target against a public band and you will call it bloated when it is merely private.

Second, the revenue estimate, not the headcount, is where most of your error lives. In one worked competitor case the ad-spend method suggested about $125K in monthly revenue while the headcount method pointed to $500K - a 4x gap on the same company, from method choice alone.

The two inputs you have to estimate, and their error profiles

You are estimating a numerator (revenue) and a denominator (corrected FTE), and each carries a different kind of error. Treat them separately, then combine their ranges rather than pretending either is a point.

The denominator error is bounded and correctable. Profile-based employee counts are typically 70-90% accurate depending on company size and industry, and the errors have known causes: subsidiary roll-up, stale profiles, and uneven platform adoption by geography and sector. You can correct each one.

The numerator error is larger and harder. It comes from unanchored multiples and marketing-share assumptions that compound, and it is why a single method can be off by 4x. The discipline that fixes it is triangulation: run at least two independent methods and report the spread as your error band.

Correcting the headcount: roll-up, stale profiles, and the adoption factor

Start from the raw profile count, then apply four corrections in a fixed order: strip subsidiary roll-up, remove invalid profiles, apply an industry adoption factor, and adjust for country density. The output is a headcount range with a stated correction factor, not a single number.

The corrections, in order of how badly they distort:

• Subsidiary roll-up. Profile platforms typically roll all subsidiary employees into the parent's headcount, which masks structure in corporate-venture and M&A situations. Match records to a verified company domain, cross-checked with other public signals, rather than matching on company name. If your target is a sub, isolate people who list the subsidiary brand as employer.
• Stale and invalid profiles. Counts include profiles of people who have left and profiles with histories that fail basic validation. Exclude incomplete or unvalidatable records before you trust the total.
• Industry adoption. Accuracy is reasonable for software and financial services but routinely under- or over-counts in agriculture, healthcare, manufacturing, and professional services due to low platform adoption and self-reported ranges. Aggregate multiple verified sources and apply an industry-specific scale factor.
• Country density. Platform adoption varies enormously by geography, so a fixed scale factor mis-sizes non-US targets.

That last point is easy to underestimate. In Refolk's index, profiles tagged with the Software Engineering skill number 11,897 in the United States and just 636 in Germany - an 18.7x density ratio for the same role. If you apply a US-calibrated adoption factor to a German target, your headcount correction is wrong by nearly an order of magnitude.

These counts come from Refolk's index; the ratio is derived. Use it to size country-specific undercount risk before you set a scale factor.

For a public parent, skip most of this. The most reliable source is the 10-K filed with the SEC, free through EDGAR, because public companies are legally required to disclose employee data. Reconcile your profile-based estimate against it and use the filing as the anchor.

Estimating revenue by triangulation

Estimate revenue with at least two of four public-signal methods, then take the min-max of the estimates as your outer error band. No single method is trustworthy on its own; the honest output is a range.

The four methods, what each needs, and how each lies:

Comparable-public scaling has a clean rule: if your target has about 25% of a public peer's headcount, divide the public company's revenue by four. Use it as a sanity check against the headcount-times-benchmark method.

The valuation method reverses the standard business-value equation - business value equals annual revenue times a revenue multiple - to back revenue out of a disclosed valuation, and it requires an illiquidity discount of 20-30% applied to private companies versus public peers.

The warning case is the ad-spend method. Assuming marketing is 40% of revenue suggested about $125K in monthly revenue for one target, while the employee-count method (40 employees times $150K ARR divided by 12) pointed to $500K MRR. Same company, 4x apart. Neither number is wrong; the point is that reporting one of them alone would have been dishonest.

Once you can pull the current workforce by function and geography, the headcount correction stops being a hand-wave. Refolk returns people by role, skill, and location in plain English, which is exactly the raw material the roll-up, stale-profile, and country-density corrections need. It also lets you isolate a subsidiary brand's staff from the parent and detect recent departures that signal a layoff before you trust the count.

The procedure, start to finish

Work the seven steps in order. The whole read is about a day of analyst time plus a short reviewer pass, and the output is a banded RPE with a sourced verdict.

A note on FTE rules from step one, because they quietly poison everything downstream. Subcontractors you pay for completed work are generally excluded - you are buying output, not employing labor - but contractors who work consistently and contribute to revenue can be included proportionally, weighted by hours. The overriding rule is consistency: include or exclude contractors the same way everywhere, document the rule, and never mix inclusion methods, because mixing makes the FTE data unreliable. Match the period exactly, use gross revenue before expenses rather than net income, and decide up front between point-in-time and average headcount, because average smooths spikes from acquisitions or large hiring waves.

Selecting the peer band and rendering the verdict

The verdict is only as good as the band. Match stage, industry, funding type, and GTM model to a sourced benchmark, then place your RPE band against it: below is leaner, inside is on-band, above is bloated.

Use published bands with disclosed samples, not a single number you half-remember.

Two adjustments matter as much as the size match. Funding type moves the band: bootstrapped $1M-$3M ARR companies ran about $110,000 per FTE versus $94,444 for equity-backed peers. And GTM model moves it roughly 2x at the same stage: enterprise high-touch SaaS runs lower ($200-300K) because of larger sales and customer-success teams, while product-led growth can reach $400-600K.

You can read GTM weight from the workforce itself. A company heavy in account executives relative to engineers is carrying sales load, which pulls its expected RPE down toward the enterprise band. As a sense of scale for how readable that signal is, in Refolk's index US Account Executive profiles number 234,068 against 11,897 skill-tagged US software engineers.

Counts are from Refolk's index; the ratio is derived. Read this as availability of signal, not as any single company's org mix - the AE query used title only while the engineer query required title plus the Software Engineering skill, so the two filters differ. The point stands: functional headcount is a legible proxy for GTM motion, and GTM motion sets the band.

How this read goes wrong

The failure modes below are the most valuable part of this playbook, because each one produces a confident, wrong verdict that survives casual review. Every one has a tell and a check.

The full list of ways the number lies:

• Run-rate inflation. Many AI-native firms quote last-month-times-twelve, not trailing-twelve-month GAAP revenue, which inflates productivity when growth compounds. Tell: RPE far above the public band for a private firm. Check: confirm TTM basis; if only run-rate is available, widen the band and flag it.
• Layoff denominator shrink. Post-layoff RPE spikes and reads leaner. Tell: RPE jumps with flat revenue. Check: compare headcount to a 6-12 month prior snapshot.
• Subsidiary roll-up. Parent absorbs sub headcount and RPE reads bloated. Tell: headcount far exceeds the entity's known product scope. Check: match on verified domain, not company name.
• Contractor gap. Heavy 1099 or offshore workforces missing from profiles inflate RPE. Tell: implausibly high RPE for a services-heavy model. Check: include contractors proportionally and document the rule.
• Cross-industry benchmark. Comparing a services firm to software yields a false bloated. Check: match industry and gross margin before the verdict.
• Point-in-time versus average switch. Switching conventions between periods creates a false trend. Check: fix one convention and state it.
• Acquisition timing. A newly closed deal loads headcount before revenue lands, reading bloated. Check: net out the acquired entity or use average headcount.
• Single revenue method. One estimate hides a 4x spread. Check: require two methods and report the range.

Even elite, well-resourced estimates are method-fragile. Epoch AI flagged Anthropic RPE estimates ranging from roughly $9M to $14M, and OpenAI headcount reported as 7,850 by one source and 4,500 by another - the same company, two numbers, from asynchronous revenue and staff reporting. If the best-covered companies in the market show that spread, your private target will too.

Before you call it done

Run this checklist before the verdict leaves your desk. If any item fails, the number is not defensible yet.

Keeping the read current

An RPE read has a short shelf life, so treat it as a living figure with a re-check trigger rather than a one-time deliverable. A number accurate six months ago may no longer reflect reality after a hiring freeze or a layoff.

Re-run the headcount correction on a fixed cadence - quarterly for active competitive tracking, or on any triggering event like a funding round, an acquisition close, or a visible layoff. The fastest early warning is departures: pulling the people who left a target in the last six months detects a layoff before the aggregate headcount catches up, which is exactly when a stale RPE reads falsely lean. A copy-pasteable methodology header keeps every refresh comparable.

Entity (verified domain): ___
Revenue definition: TTM GAAP  |  If run-rate only, band widened and flagged: Y/N
Period: ___
FTE rule: W-2 only  |  Contractors weighted at ___ hrs basis (applied consistently)
Headcount convention: point-in-time  |  average over period
Corrected headcount range: ___ to ___ (correction factor: ___)
Revenue methods used: [1] ___ = ___  [2] ___ = ___  [3] ___ = ___
Revenue band: ___ to ___ (anchor used: ___)
RPE band: ___ to ___
Peer benchmark: ___ (source, sample: ___)
Gross margin (actual/assumed): ___
Flags checked: run-rate ☐  layoff ☐  contractor ☐  subsidiary ☐  acquisition ☐  cross-industry ☐
Verdict: leaner / on-band / bloated
Next re-check trigger: ___

The discipline that makes this defensible is not precision - it is documented uncertainty. A banded RPE with a stated correction factor, two revenue methods, a named peer benchmark, and a checked flag list will survive scrutiny. A confident single number, however impressive it looks in a deck, will not.