Building a Defensible Pay Band From Posted Salary Ranges

This is a repeatable method for producing one market pay band, for one role at one level in one location, built from the salary ranges companies now post in job ads. It is written for strategy and research teams, talent-intelligence analysts, and operators sizing a market who need a band they can defend in a leadership review. By the end you will have a band with a stated sample size, filtered ranges, a geographic adjustment, and a freshness date, plus a written account of what the sample can and cannot see.

Posted salary ranges barely existed as a benchmarking source before pay-transparency mandates. The generic salary-benchmarking article pitches a vendor tool and hides the judgment calls inside it. This guide does the opposite: it shows you where the judgment sits, so the number you present is yours to defend and not a black box.

Why posted ranges are a usable source now

Posted ranges are usable because roughly half the US market now discloses pay in the ad itself, a share that barely existed a few years ago. That is enough to build a band from - but only if you understand where the visible half comes from.

Explicit pay hit 50.4% of US postings on Indeed in July 2026, the highest since the series began in 2020. The New York Fed puts the national share at about 53% since January 2024, up from roughly 15% before 2018. The mechanism behind the jump is regulatory: when a mandate takes effect, the share of postings with pay rises by about 20 points in the implementation month.

The catch is that the visible half is not a random half. Roughly a quarter of covered listings still omit salary, and the ones that omit it are not random either - small-employer exemptions and plain noncompliance mean the postings you can see skew toward larger, more compliant employers. So "no range on this posting" carries information, and treating the disclosed set as representative of the whole market overstates the pay of the roles you cannot see.

Where the coverage bias lives

You can only benchmark from-posting in jurisdictions that require the range in the posting itself, so every band you build tilts toward those labor markets. Name the tilt before anyone in the review asks.

As of mid-2026 there is no federal law, and counts vary by how sources scope "in-posting" versus "on request." One tracker states 13 jurisdictions require the range in the posting itself and names California, Colorado, Hawaii, Illinois, Maryland, Massachusetts, Minnesota, New Jersey, New York, Vermont, Washington, plus Virginia and DC, with Maine and Delaware following. Another counts 27 enacted jurisdictions once localities are included. The disagreement is real, and it matters: your pull is only legitimate from the in-posting set.

Size thresholds compound the tilt. They range from 4 employees in New York City to 50 in Hawaii, so even inside a covered state you under-sample small employers. A band built only from mandate states and presented as national is a specific, common failure. State which jurisdictions and size thresholds your sample can and cannot see.

Supply density tells you which cells will be thin

Before you pull a single posting, know that equal effort yields unequal samples, because supply is not uniform across levels or countries. The same pull over-samples junior roles and starves senior ones, and silently turns a "global" band into a US band.

In Refolk's index of professional profiles, the shape of supply is easy to see for one concrete role. Entry-level supply outnumbers senior supply by half again, and US supply dwarfs Germany's for the identical role and level.

Table A - Supply density by seniority band (US, Software Engineer + Python)

Table B - Same role and level, two countries (Senior Software Engineer + Python)

Read Table B as a warning about pooling. US senior supply is 15.7 times Germany's, so a "global" band silently becomes a US band the moment you pool them. Keep the slices separate and report each on its own.

Concentration inside a thin market is worse still. In Refolk's index, the German senior sample was about 44% Berlin, against a US sample spread across New York, Los Angeles, San Francisco, Boston, and Chattanooga where the top metro was only about 16% of the sample.

Table C - Geographic concentration of the senior sample

Table C is a caution, not a national rate: it says that in a thin market your "band" may rest on near-zero local observations clustered in one city. If you are benchmarking a role where local supply is thin, expect the from-posting method to give you a Berlin band dressed up as a Germany band.

In a thin market the from-posting method hands you a one-city band wearing a whole country's name.

The procedure, start to finish

Here is the full method in order. It runs about a day and a half of analyst time for one role-level-location cell. The one rule that overrides everything else: slot to level before you attach pay.

The order dispute worth knowing about is leveling-first versus pay-first. Primary job-leveling sources insist level comes before pay, which is why step 3 sits ahead of steps 4 and 7. Reverse it and you anchor the band to incumbent pay, formalizing whatever inconsistency already exists.

Normalizing titles to levels

Slot each posting to a level by scope, complexity, autonomy, and judgment - not by the posted title and not by tenure. This is the step that decides whether your pooling means anything.

The documented order is: inventory the real distinct jobs rather than HRIS titles, define levels by scope and autonomy, slot each role against the criteria not the person, and benchmark pay last. Title inflation is the reason. "Senior" at one firm is "Engineer II" at another, so pooling on the posted title mixes two different jobs into one band. Some roles legitimately straddle two levels; when they do, say so explicitly rather than forcing a choice.

Vendor taxonomies do not solve this for you. They require a clean role taxonomy as input; they do not fix title chaos upstream. That work is yours.

Finding the incumbents who actually hold a level - so you can sanity-check what "senior" means in this market rather than trusting the ad copy - is where a plain-language search earns its keep. Instead of scraping and de-duplicating title strings by hand, Refolk lets you ask for the population directly.

Filtering junk ranges

The junk-range filter is the single real defensibility lever you control, and no law sets it for you. Regulators require a "good faith" range but publish no numeric width cap, so your threshold, not the statute, determines the result.

Documented junk ranges show how far this goes: $50,000 to $180,000 and $140,000 to $450,000 in New York, and $40,000 to $400,000 posted against a real target of $90,000 to $110,000. A single band that wide, left in the sample, drags the median and produces a wide, meaningless result that still looks well-sampled. A workable rule of thumb is to drop any range wider than about 40 to 50 percent of its own minimum, plus any posting missing either a min or a max. Sources disagree on where the cutoff sits, so document the one you chose.

posting_id :: employer :: posted_min :: posted_max :: span_pct :: rule_triggered :: kept_or_dropped
JR-0142 :: (employer) :: 50000 :: 180000 :: 260% :: span > 50% :: dropped
JR-0187 :: (employer) :: 145000 :: 175000 :: 21% :: within threshold :: kept
JR-0203 :: (employer) :: 130000 :: (missing) :: n/a :: missing max :: dropped
Filter rule applied: drop span > 50% of min OR missing bound. Dropped: __ of __.

Sizing the sample and adjusting for geography

Two things separate a defensible band from a plausible-looking one: an honest sample count per slice, and a geographic adjustment that uses cost of labor rather than cost of living.

On sample size, no published standard sets a minimum number of posting observations for a role-level-location band specifically - treat that as not established publicly. The borrowable anchors come from survey statistics. Cochran's formula yields n=384 for plus or minus 5% at 95% confidence on a large population, and 278 for a population of 1,000. A standalone benchmark reaches plus or minus 10% at 90% confidence at n=65. When sampling is genuinely hard, practitioners relax to a 20 to 30 floor, noting that data at n=18 to 19 is just a bit less precise. The non-negotiable rule: each geographic and level slice must clear its own minimum, not the pooled total.

On geography, the documented method compares the cost of labor in the target location to the base location and applies the percentage differential to the range. This is cost of labor, not cost of living: 89% of companies use salary surveys for differentials, and only 11% use cost of living as the primary input. One published blend weights 70% market data, 20% cost-of-labor index, and 10% cost-of-living. For remote postings, if a role can be performed from a pay-transparency state, the strictest applicable law governs, so a remote range reflects the highest-cost covered market. Flag remote observations and identify the governing market; never fold them in as a national rate.

How this goes wrong

The failure modes below are where a band that looks solid quietly lies. Each one has a false positive that survives a casual review, so build the check into the method rather than hoping to catch it later.

The two that catch experienced analysts most often are the pooled-n trap and the stale-band trap. The pooled-n trap is dangerous because the pooled total is genuinely large; only when you break it into level-location cells does the emptiness show. The stale-band trap is dangerous because the headline hides it: overall tech pay moved just 0.8% to 1.6% year over year, which invites an annual refresh, while mid-level AI engineers moved up 9.2%, DevOps up 12%, and senior software developers down 10%. A single decay cadence across a role family is simply wrong, because demand concentrates in narrow skill pockets.

Setting the refresh cadence and keeping the band current

Stamp a freshness date on every band and set a refresh cadence tied to how fast that specific role family moves. Traditional salary surveys already lag 6 to 12 months; posted ranges let you refresh faster, but only if you calendar it.

The documented dating rule is quarterly refresh for high-surge role families and semi-annual or annual for slow movers, always with a freshness date. A band set in January can be out of step by Q3, so the freshness date is not decoration - it tells the reviewer exactly how much to trust the number today. When you re-pull, do not compare against the prior number; recompute from scratch, because the compliant set and the metro mix both shift underneath you.

The mechanism to re-check, rather than a value to memorize: pull the current year-over-year movement for your exact role family from a recruitment salary guide, and if it exceeds a few points, drop to quarterly. If it is flat, annual is defensible. The point is to re-check the movement, not to trust a cadence you set once.

A band that carries all of these is one you can put in front of a leadership review and defend line by line. It states its own limits, which is exactly what makes it stronger than a vendor number nobody in the room can trace. When the next refresh comes due, run the same eight steps again, recompute from the raw pull, and update the freshness date. The method holds; only the numbers move.