What a Canadian employer needs from an applicant tracking system in 2026: pay fields in postings, AI screening disclosure, posting retention, and when to integrate or build.
An applicant tracking system used to be judged on how well it moved candidates through stages. In Canada it is now also the system of record for what your job postings said, which is a different job and one that many products were not built for.
Ontario's job posting requirements start on 1 January 2026 for employers with 25 or more employees, covering pay information, disclosure of AI screening, and retention of postings. British Columbia already requires pay ranges in publicly advertised postings. The practical effect is that your hiring software now has compliance obligations attached to it.
This article is general information rather than legal advice. The point is not to interpret the rules for you, it is to tell you which software questions they turn into. For the rules themselves see Ontario pay transparency.
| Requirement | What the system needs |
|---|---|
| Pay in the posting | A pay field that cannot be left empty, and a range validator |
| Range width limits | Validation at entry, not a note in a style guide |
| Other compensation | A structured field for bonus and commission wording |
| AI screening disclosure | A field, plus a way to keep it true as tools change |
| Existing vacancy flag | A yes or no stored against the posting |
| No Canadian experience requirement | A check across the posting and the application form |
| Retention | A snapshot of each posting as published, with dates |
Two of these are commonly missing in products that otherwise look modern. The first is validation: a free-text pay field lets a hiring manager type anything, including a range wider than the rules allow. The second is retention, which we will come back to because it is the expensive one.
There is also a question most vendors have not been asked yet. If your system ranks or scores applicants in any way, that may be AI screening, and your postings have to say so. Ask for the answer in writing and keep it, because a product update can change it.
Pay fields can be added in an afternoon. Retention cannot be backfilled, because you cannot go back and keep a copy of something you did not keep. This is the one to check before you sign.
The reason most systems fail it is architectural rather than careless. A posting is a database record rendered on request. Edit the record and the old version is gone; take the posting down and the record is archived or deleted. Nothing anywhere holds what the public actually saw in March.
Run that test in a trial account before you commit. It takes ten minutes and it is the single most useful thing you can do in an evaluation.
Your posting usually appears in several places: your own careers page, one or more job boards, and aggregators that pick it up from those. Every public copy is a public posting, so a feed that drops the pay field publishes a non-compliant posting in your name.
Feeds commonly predate the fields. A product added pay fields to its posting form and kept its existing export schema, so the data is captured and not transmitted. Nothing warns you, because from inside the system everything looks right.
Step two is the whole exercise. The preview inside your system is generated from the record. The live posting on a job board is generated from the feed. Only one of those is what a candidate sees.
For most Canadian employers the answer is to buy an applicant tracking system and build the specific pieces it will not do. Building a whole hiring workflow is rarely worth it, because the workflow is not where your difficulty is.
| Option | Good fit when | The real cost |
|---|---|---|
| Buy an ATS that handles it | A vendor can demonstrate retention and feed fields today | Migration, and trusting a roadmap |
| Keep the ATS, build the careers page | The ATS is fine internally but its public pages are not | One integration to maintain |
| Keep the ATS, add a retention service | Everything works except keeping published versions | Small, and it solves the unfixable requirement |
| Build the whole thing | Hiring is a core part of your product | Years of features you could have bought |
The third row is the one most people have not considered. A small service that captures each posting as it is published, stores it with its dates and text, and lets you retrieve it later, solves the hardest requirement without touching your hiring process. It is a contained piece of work and it buys you the thing you cannot get retroactively.
If your careers page is part of a WordPress site, the question is whether the jobs plugin has the fields and whether its feed sends them. If your postings come out of an ATS, the questions are the retention and feed ones above.
Question six and question seven belong together. Six tells you what to disclose today. Seven is what stops your postings quietly becoming inaccurate after an update.
We build careers pages, posting workflows, feed integrations and the retention piece that most products are missing. Describe your hiring stack and we will tell you which gaps are real and which your vendor can close for you, before you spend anything with us.
Pay fields with validation, structured fields for other compensation, an AI screening disclosure field, a flag for whether the vacancy is real, and retention of each posting as published. Retention is the one that cannot be added retroactively.
If it scores, ranks or filters applicants, it may. Ask the vendor in writing, keep the answer, and ask to be told when it changes, because resume ranking and match scores often arrive in routine product updates.
Because the feed schema often predates the fields. The data is captured in your system and not transmitted. Check the live public posting on each destination rather than the preview inside your system.
Rarely. The candidate workflow is well served by products. Build the specific pieces your product cannot do, which is usually the public careers page, the feeds, or retention of published postings.
Snapshot each posting at the moment it is published, storing the text, the pay information, the disclosures and the dates it was live. If your ATS does not do this, it can be added as a small separate service without changing your hiring process.