A job posting that says "remote" tells you one thing for certain. Someone at the employer picked an option or typed a word into a form. It does not tell you where the new hire will work. It does not tell you whether the policy will last, or whether anyone set the field on purpose. So if you count remote jobs across companies, you are counting employer claims. Those claims arrive in different shapes depending on which applicant tracking system the company uses.
This article looks at how eight common hiring platforms encode the remote question and where those encodings disagree. It then sets out a normalisation model that keeps the uncertainty visible instead of hiding it. We compared the platforms more broadly in Greenhouse, Lever and Ashby compared for data users, so the focus here is one field.
Why the flag is a claim
A recruiter usually sets the remote field while filling out a long requisition form. Three things make it unreliable as a fact.
The first is defaults. Many forms preselect a value or leave the field blank. A posting marked on-site may just be one where nobody touched the dropdown. A blank field is not a negative answer. It is no answer.
The second is marketing. "Remote" draws more applicants, so employers have a reason to use the word loosely. A role with two home days a week can end up labelled remote. The reverse happens too. A fully remote role gets a city in its location because the company is registered there.
The third is drift. Workplace policy can change after a posting goes live. An evergreen posting created under one policy can stay open under the next. The flag shows the moment of the last edit, not today.
In most cases none of this is dishonest. It is what happens when a messy business decision has to fit into a form field.
Eight platforms, eight shapes
Vendors rename fields when they release new API versions. Treat what follows as a description of the patterns at the time of writing. Check each vendor's current documentation before you hard-code a field name.
Greenhouse. The public Job Board API has no remote flag. You get a location name as free text, and the employer writes whatever it likes there. "Remote", "Remote, US", "New York or Remote" and "Hybrid, London" all show up as plain strings. Any remote answer from Greenhouse is inferred from text.
Lever. The postings endpoint has a workplace type with on-site, remote and hybrid values. It also has a value for postings where nobody set it. This is the cleanest shape in the group, because it is a list of values with an explicit unknown. Lever also keeps a free-text location, and the two can disagree.
Ashby. The posting API returns a remote boolean next to a primary location and secondary locations. A boolean can say yes or no. It cannot say hybrid, and it cannot say "not answered". A false value lumps on-site, hybrid and unset together.
Workable. Workable has long exposed a telecommuting boolean. Newer versions of its API describe the workplace as on-site, hybrid or remote. Which one you see depends on the endpoint and version you read. If you ingest both, expect the two to disagree for some jobs.
SmartRecruiters. Remote status is a boolean inside the location object, and newer responses add a hybrid marker. Because the flag sits inside the location, a posting can carry a full street address and a remote flag at once.
Recruitee. Job offers can carry separate booleans for remote, hybrid and on-site. Separate booleans allow combinations that make no sense as a single answer, such as all three true or all three false. Your parser has to decide what those mean.
Teamtailor. Jobs carry a remote status with values for none, hybrid, temporary and fully remote. The temporary value is unusual and useful. It admits the arrangement is expected to end. No other platform on this list says that directly.
Workday. Each employer configures its own Workday careers site. Many put "Remote" into the location name itself, for example a location called "Remote, USA". Some sites expose a separate remote type field and others expose nothing. One vendor can give you three different shapes across three companies.
A ninth source sits on top of all of these. Many careers pages embed schema.org JobPosting markup so search engines can read the job. That vocabulary marks a remote role with a job location type of TELECOMMUTE. It pairs that with applicant location requirements, which say where candidates may live. The markup is often generated from the ATS record, so it inherits the same defaults and errors. It works as a cross-check, not as an independent witness.
Where they disagree in practice
Put similar jobs through all eight platforms and the same question gets different answers. A few patterns come up again and again.
A remote flag with a city. The structured field says remote and the location says Austin. That can mean remote within a state, or remote with trips to a hub. It can also be an old location left over from an earlier version of the posting. The fields alone cannot tell you which.
A negative flag with remote text. The boolean is false but the title reads "Senior Engineer (Remote)". Here the text is usually the better evidence. Someone typed the title on purpose, and the boolean may just be a default.
Remote with limits. "Remote" rarely means anywhere. It usually means within one country, a region or a band of time zones, for payroll, tax and employment law reasons. Most flags carry none of that. If a limit is stated at all, it is in the description.
Hybrid hidden in the description. The flag says remote, but paragraph six asks for three days a week in the office. The flag loses.
One role, many postings. A single requisition can go out as one remote posting plus several city postings. Counting each one inflates both the remote count and the total. We covered this deduplication trap in reading hiring as a company signal.
A normalisation model that keeps the doubt
The goal is not to force every posting into remote or not remote. The goal is one shared shape that shows how confident each answer is and where it came from. Four fields do the job, and you are free to copy the idea.
work_mode takes one of four values: onsite, hybrid, remote or unknown. Unknown counts as a real answer. A blank Greenhouse location, a Lever posting with no workplace type and an Ashby false with no supporting text all map to unknown, not onsite.
remote_scope holds the geographic limit when one is stated, such as a list of countries or regions. When nothing is stated, it stays empty. Empty means not stated. It does not mean worldwide.
evidence records how the answer was reached: a structured field, the location text, the title or the description. With it you can filter to the strongest answers, or measure how much of the dataset rests on text parsing.
raw keeps the original field names and values exactly as the platform returned them. When your rules change, you can derive everything again without refetching.
If you ingest Teamtailor or anything similar, add a temporary marker. Otherwise a temporary remote arrangement quietly counts as permanent.
Then write down your precedence rules and apply them in order.
A list of values beats a boolean. Lever's workplace type or Teamtailor's remote status says more than a yes or no.
A true boolean counts as evidence. A false boolean on its own counts as unknown, because you cannot tell it apart from a default.
Explicit words in the title or location beat a negative or missing structured field. "Remote" typed into a title was a choice.
Office attendance language in the description, such as a set number of days on site, downgrades remote to hybrid.
If no rule resolves a contradiction, the posting stays unknown and both raw values are kept. A guess at this point creates false precision that looks like data.
Text parsing needs its own care. "No remote work" contains the word remote. "Remote-first company, but this role is on site" contains it too. Match phrases, not single words. Test your patterns against real postings before you trust them.
Using the normalised field as a signal
Once the shape is stable, you can track the mix of work modes at each company over time. If a company's new postings shift from remote to hybrid, that says something about its office policy before any announcement.
Two artifacts can fake that signal. The first is an ATS migration. Say a company moves from Greenhouse, which has no remote field, to Ashby or Lever, which do. Structured answers suddenly jump. Nothing changed at the company except the form. Watch the evidence field for a sudden jump, and check the feed hostname before you read anything into it. The second artifact is reposting. Closing old roles and reopening them under a new template can change flags in bulk.
Filings give you a slower cross-check. Since the SEC amended Regulation S-K in 2020, public companies must describe their human capital resources in annual reports where material, as set out in the SEC's announcement. Some companies use that section to describe hybrid or remote work arrangements. You can find those passages with EDGAR full-text search. A 10-K is a yearly summary in the company's own words, so it will never line up with daily feed data. A sharp gap between the two is still worth a look.
Private companies file less, but a startup raising money usually files a Form D. We explain that document in how to read a Form D filing. A new raise followed by a burst of postings is a readable pattern. The work mode field adds one more detail: where the company expects those people to sit.
For the wider economy you do not need job postings at all. The Bureau of Labor Statistics has asked about telework in the Current Population Survey since October 2022. That survey measures what workers say they do, which is not the same as what employers advertise. Comparing the two is a free and honest reminder that a flag is a claim.
Nothing in this article is investment advice. Work mode data describes what one company intends. It says nothing certain about the company's prospects.
Doing it yourself
All of this works with free tools. Greenhouse, Lever, Ashby and several other vendors publish their job feeds openly. Save the raw JSON every day and write the four normalised fields next to it. Keep your precedence rules in one file under version control. When a rule changes, run it again over the stored raw data. A small script and a cron job are enough for a watchlist of companies. Keep request rates polite and respect each vendor's terms.
The best moment to apply this is right after money comes in. Our Startup Capital Raises Form D report tracks new Form D filings and scores them. You can then check the hiring feeds of newly funded companies and see what their remote claims actually say.
Want the signal instead of the raw filings? Get a free report preview. Prefer the tool to the write-up? Browse all data feeds or connect the free MCP server.