Short answer
Checkr announced on September 24, 2026 that it had partnered with Workday on income and employment verification for participating eligible employers with U.S. employees that opt in. The announcement describes a planned late-October route through Workday Total Benefits, not verified current availability or implementation results. Before opting in, employers should test who can request data, what is released, how records are corrected, and who owns failures across system boundaries.
Checkr announced the partnership on September 24, 2026. Its announcement says that eligible employers with U.S. employees may opt in to make employment and income information available through Checkr, with a stated late-October availability route through the newly announced Workday Total Benefits solution. Checkr’s September 24 announcement is evidence of that announced event.
It is not evidence that the service is currently available to every Workday customer, that a particular employer is eligible, or that a given configuration, field set, contract, implementation, or outcome has been verified. Checkr attributes expected benefits such as less manual HR work and faster verification decisions to the partnership. The supplied announcement does not provide test methods, failure rates, implementation requirements, pricing, retention terms, or independent outcome evidence.
Treat verification as a controlled data release
Employment and income verification is not only a source-record question. A record may be accurate in an employer system while a request is still unauthorized, a person match is wrong, a released field is excessive, or a downstream recipient never receives a usable response.
Proposed buyer workflow map, not a documented technical architecture:
- An external requester initiates a verification request for a stated purpose.
- A requester-validation control determines whether that requester may proceed.
- Checkr receives or processes the request, subject to its configured controls.
- A matching process attempts to connect the request to an employee record.
- Workday is a potential employer-system boundary for the underlying employment and income information.
- A release rule determines which approved fields may leave the employer-controlled context.
- Checkr returns a status or response to the requester.
- The employee, employer, and vendors need defined routes for correction, exception handling, audit review, and withdrawal of participation.
The announcement supports the partnership and opt-in concept. It does not specify the actual interfaces, matching method, authorization path, data fields, timing, retention, or ownership at each step. Mark each of those points as unverified until confirmed in procurement and implementation materials.
Original practical framework: Verification-Release Worksheet
Use this worksheet for each proposed verification purpose, not just for the overall vendor relationship.
| Checkpoint | Question to answer | Evidence or test to request |
|---|---|---|
| Request origin | Where does the request begin, and is the source recorded? | Sample request log with a traceable request identifier. |
| Requester validation | Who verifies the requester and what blocks an unknown requester? | Control description, approval rules, and negative-test results. |
| Applicable purpose | What specific purpose is supported for this release? | Purpose taxonomy and documented exclusions. |
| Employee matching | How is a request matched, and what happens at low confidence or duplicate records? | Match rules, manual-review route, and mismatch test. |
| Fields released | Which employment and income fields are returned for each purpose? | Field-level data dictionary and minimization approval. |
| Data freshness | What timestamp accompanies the response, and when is a record considered stale? | Refresh schedule, source timestamp, and stale-data test. |
| Access controls | Which employer and vendor roles can configure, view, or export data? | Role matrix, administrator logs, and access-review process. |
| Response status | Can the recipient distinguish completed, unavailable, disputed, and pending responses? | Status definitions and sample response records. |
| Correction route | How can an employee dispute an incorrect record or response? | Notice, intake route, owner, and resolution record. |
| Audit record | What evidence remains for request, match, release, response, and correction? | Audit-log schema and retention terms. |
| Revocation or exit | What changes after employer withdrawal, employee separation, or contract end? | Offboarding runbook and post-exit access test. |
A completed worksheet should identify a named accountable owner for every row. “The integration” is not an owner. Assign ownership separately to the employer, Workday, Checkr, requester, or another party where applicable.
Practical failure tests before a broader rollout
These are proposed tests, not claims about the announced connection.
- Stale income data: change a test record through the approved process and verify whether the response shows a source date, a pending state, or an outdated value.
- Mismatched employee records: use controlled duplicate or similar identity records and verify that the system stops, routes, or explains an uncertain match rather than returning a record.
- Excessive fields: submit a request tied to a narrow purpose and inspect whether the returned response contains only the approved field set.
- Unrecognized requester: attempt a request from an unapproved requester profile and confirm that the event is blocked and auditable.
- Disputed response: create a controlled discrepancy, follow the employee correction route, and record the responsible party, status visibility, and closure evidence.
- Unavailable service: test how the workflow communicates an outage or unavailable source without silently producing a misleading result.
- Withdrawn employer participation: confirm what requests, access, and retained records remain after a documented opt-out.
- Unresolved downstream handoff: simulate a response that leaves the verification service but is not accepted by the requester. Confirm who owns investigation and how the employee is informed.
Procurement evidence to request
Ask for written evidence of employer eligibility and opt-in controls, supported verification purposes, supported Workday configurations, and geographic limitations. Request a field-level description of employment and income data, requester qualification controls, employee notice and visibility, data freshness rules, retention, security materials, dispute handling, implementation ownership, pricing, and contractual exit terms.
Also request a responsibility matrix that separates source-record maintenance, requester validation, employee matching, release authorization, response delivery, corrections, incident handling, and audit production. The press release does not provide those details, so they should not be assumed from the partnership announcement.
A fictional example: why a successful lookup is not enough
Fictional example, not customer evidence: A participating employer receives a request connected to an employee applying for housing. The requester is recognized, but the income record reflects a recent pay change that has not reached the source record used in the response. The response is technically delivered, yet the employee disputes it.
A usable operating design would show the data timestamp, give the employee a defined correction path, identify the owner of the source update, preserve the request and response record, and tell the requester whether the response is disputed. Without those controls, “completed” would not necessarily mean accurate, authorized, or resolved.
How this differs from a Workday Total Benefits proof test
This article is narrowly about an external release of employment and income information. It asks whether a requester can receive the right approved record, for the right purpose, with a correction and audit path.
A broader Workday Total Benefits buyer proof test is useful for evaluating benefits-information answers, eligibility context, provider handoffs, source attribution, and escalation to people. Read that companion page when assessing benefits information and provider handoffs. Do not treat success in one workflow as proof that the other workflow is controlled or effective.
Glossary: practical meanings for this review
Applicable purpose: The documented reason a requester is allowed to seek a verification response. The purpose should be specific enough to determine whether a request is in scope and which fields, if any, may be released. It is not simply a free-text explanation supplied by a requester.
Audit record: The retained evidence needed to reconstruct what happened. A useful record can connect the request origin, requester identity, purpose, employee match, approved fields, response status, timestamps, correction events, and responsible owners. An audit record does not by itself prove that every decision was correct.
Data freshness: How recently the returned information reflects the source record. A current-looking response without a meaningful source timestamp can conceal a lag. Freshness should be assessed separately for employment status and each income-related field because they may update on different schedules.
Employee matching: The process that links a verification request to an employer record. Matching is separate from data accuracy. An accurate record attached to the wrong person is still a serious release failure. A buyer should establish what happens when identifiers are incomplete, duplicated, or inconsistent.
External requester: The organization or party asking for verification, rather than the employer, employee, Workday, or Checkr. A request may relate to employment, lending, housing, or a government-benefit process, but the supplied announcement does not define the controls used for each requester type.
Field minimization: Limiting a response to the information approved for the stated purpose. The relevant question is not whether a system can technically return a field, but whether the field is necessary, configured, authorized, and auditable for that request.
Release rule: The configured or contractual condition that governs whether information can be returned. It should connect purpose, requester status, employee match, approved fields, and any required review. A release rule needs a defined owner and a way to test exceptions.
Revocation or exit handling: The process applied when an employer withdraws participation, a contract ends, or an employee relationship changes. The review should distinguish stopping future requests from handling access, retained records, open disputes, and downstream copies already received by a requester.
System boundary: A point where information, responsibility, or control passes between parties or systems. Boundaries are where assumptions often fail: a data source may be accurate, a receiving system may be unavailable, or a recipient may not be able to use a delivered response.
Unresolved handoff: A state in which one party reports that it sent or completed a response while the next party cannot use, receive, or confirm it. It requires a visible status, named investigation owner, and closure evidence rather than an informal assumption that the issue belongs elsewhere.
Questions to carry into the decision
Is the Checkr and Workday connection verified as currently available?
No. The supplied evidence is a September 24, 2026 Checkr announcement that describes planned late-October availability through Workday Total Benefits. Confirm current availability, eligibility, configuration, and contract scope directly during procurement.
Does a verified employer record guarantee a valid verification outcome?
No. The record also needs to be matched to the correct person, released to an authorized requester for an approved purpose, delivered successfully, and correctable if disputed.
What should an employer decide before opting in?
Decide the supported purposes, approved fields, employee notice and correction route, requester controls, accountable owners, test cases, audit requirements, and conditions for withdrawal or contractual exit.