Methodology & sources.

Data sources

All reference rows are stored with source = 'reference' and are clearly distinguishable from live user submissions.

What our data does not cover yet

We would rather tell you where a number is weak than let you price a role on it. These are the current, honest limits of the dataset.

Restating older pay in today’s money

Open compensation sources publish with a lag. A 2023 survey figure is a real observation, but it is a 2023 observation — shown unchanged in 2026 it understates the market. Rather than invent newer numbers, we keep each row’s original observed amount and restate it using a published national wage index. Every figure on EarnWell is therefore observed pay × an official escalation factor, and the original amount is retained so the adjustment can always be recomputed rather than compounded.

Live user submissions are never escalated — they are already current. Australia, Canada, India, Singapore and Switzerland have no ingested official index yet and are left un-escalated rather than adjusted by analogy with another country.

How a benchmark is computed

1. 1
   Cohort selection

   We select all submissions matching the requested role family, level, country and (optionally) metro and company size.

2. 2
   Privacy floor

   If the cohort has fewer than 5 distinct submitters we show "Not enough data" rather than a number — no exceptions.

3. 3
   Wage escalation

   Each reference row is restated from its observed vintage into current terms using the official national wage index for its country (BLS ECI, ONS AWE or Eurostat LCI). Live submissions are used as-is.

4. 4
   Recency weighting

   Each row is weighted by how recently it was submitted. Rows older than 24 months are down-weighted; rows older than 36 months are dropped.

5. 5
   Reference blending

   Where a cohort is thin, credible open-data reference rows fill the gap but are down-weighted vs. live user submissions.

6. 6
   Purchasing power

   For offer evaluations we can restate any package in purchasing-power terms using World Bank / OECD PPP price levels, so cross-border comparisons are like-for-like.

7. 7
   Percentiles

   We report p25 / p50 / p75 / p90 on total cash compensation (base + bonus). Equity is displayed separately when present.

8. 8
   Currency

   Values are stored in the submitter's local currency and converted on the fly using an FX table refreshed nightly from European Central Bank reference rates via Frankfurter. The user picks the display currency.

Validation & quality controls

Every submission — whether from a signed-in user or a bulk reference import — passes through the same server-side checks before it can influence a benchmark.

1. 1
   Authenticated submission only

   User submissions require a signed-in session. The insert runs inside a server function that re-verifies the user's identity — the browser can't bypass it.

2. 2
   Schema validation (Zod)

   Role family, level and region must be valid UUIDs pointing at rows that actually exist. The chosen level must belong to the chosen role family.

3. 3
   Currency + FX sanity

   Currency must exist in our daily FX table. Base is converted to USD server-side and must fall between US$500 and US$5,000,000 — catches missing/extra zeros and wrong-currency mistakes.

4. 4
   Range checks

   Local base must sit between 1,000 and 10,000,000 of the local currency. Equity is capped at 0–500% of base. Bonus is capped at 20,000,000 local. Years of experience 0–70.

5. 5
   Duplicate + rate limit

   A user can submit at most 3 packages per 24 hours, and the exact same (role, level, region, base) tuple is rejected as a duplicate within 24h.

6. 6
   Provenance flag

   Every row is stored with source = 'user' or source = 'reference'. Reference rows are down-weighted vs. live user submissions and are displaced as real data arrives.

7. 7
   Privacy floor at read time

   Even if a cohort passes validation, the benchmark endpoint refuses to return percentiles until N ≥ 5 distinct submitters exist.

8. 8
   Aggregates only

   Underlying rows never leave the server. Only p25 / p50 / p75 / p90 and histogram bucket counts are exposed to the client.

Employer contribution (bulk upload)

Paid employer plans require a one-time company-wide contribution before the full distribution unlocks. It's what keeps the dataset honest — everyone who reads also writes.

1. 1
   Subscribe

   Pick a Starter or Team plan. Checkout completes and the workspace is provisioned immediately — but benchmark values and CSV export remain blurred until step 4.

2. 2
   Prepare a file

   Download the CSV template from /employer/upload. Required columns: role, level, region, currency, base_amount. Optional: bonus_amount, equity_pct, years_experience, company_size, employment_type, notes. Names or slugs both work for role / level / region.

3. 3
   Upload

   Drop in a CSV or .xlsx, or paste a Google Sheets share link. We parse client-side, show a preview grid, and flag missing columns before you commit.

4. 4
   Server-side validation

   Each row runs through the same Zod schema, FX sanity, and range checks as an individual submission. Rows that fail are rejected with a reason; valid rows are inserted with source = 'employer_bulk' and linked to a batch record.

5. 5
   De-identification

   We only accept role, level, region, comp components and coarse metadata. No names, emails, employee IDs, or free-text identifiers. Bulk rows are stored with user_id = NULL so they never appear in anyone's personal history.

6. 6
   Access unlocks

   Once the first batch lands, the soft gate lifts across the employer dashboard — full percentiles, histograms, CSV export and seat management.

7. 7
   Ongoing refreshes

   The upload page stays available. Later batches supersede older rows for the same role/level/region cohort, so your view tracks your live comp bands as they change.

Pay equity (Team plan)

Team-plan employers get a two-lens equity view over their uploaded roster. We deliberately don't require gender / ethnicity / age columns — the analysis works entirely from role, level, region and tenure so there's no protected-class data to store, leak or misuse.

1. 1
   Market-relative position

   For every employee, we look up the EarnWell market cohort for their role / level / region and estimate their percentile by linear interpolation across P10 / P25 / P50 / P75 / P90. Cohorts under N=5 are shown as “—” rather than a misleading number.

2. 2
   Below- and above-market flags

   Rows below the market P25 are flagged “below market”; rows above P90 are flagged “above market” so you can spot compression and outliers in the same pass.

3. 3
   Internal cohort gap

   Within your own upload, we compute the median for each role / level / region cohort with at least 3 employees, then flag anyone more than 15% below or 25% above their own cohort median.

4. 4
   Exportable PDF

   One-click PDF export includes the summary numbers, the full list of flagged rows, generation timestamp and methodology footnote. Suitable for board packs and internal HR review.

5. 5
   No sensitive attributes stored

   We don't ask for and don't accept gender, ethnicity, age, name or employee ID. If your local regulator requires protected-class breakdowns (EU Pay Transparency Directive, UK gender pay gap, US EEO-1), use this report as an input alongside your own HRIS data — it is not itself a regulatory filing.

6. 6
   Informational only

   Percentile estimates are directional. Not an offer, guarantee, or legal advice on pay equity compliance.

What this data is — and isn't