Recruiting & Applicant Tracking (ATS)

The control flow a finance team actually needs.

The ERP surface involved.

Job board integration must push postings within 30 minutes of publication and sync applicant data back hourly; ATS must track EEO data (race, gender, veteran status, disability) separately from application data with voluntary self-identification; structured scorecard must require evaluation on each defined competency before submission; offer letter must pull approved compensation and use e-signature workflow; offer approval routing must follow configured delegation of authority; time-to-fill and source-of-hire metrics must be reportable by department and job family.

US and UK teams have different compliance hooks, but the same control problem.

US teams usually care about clean evidence for audit support, vendor records, payment controls, tax reporting, and management review. UK teams usually care about VAT-ready records, approval evidence, digital-record discipline, and traceable postings. The country-specific details differ, but the operating pattern is the same: the ERP needs controlled records, explicit ownership, defensible state changes, and evidence that survives beyond the person who completed the task.

The control matrix.

Audit evidence is a chain, not a folder.

job_requisition { id: string, external_id: string, entity_id: string, position_id: string, title: string, grade: string, comp_band_min_minor: int64, comp_band_max_minor: int64, currency_code: char(3), status: enum(DRAFT,APPROVED,OPEN,FILLED,CANCELLED) };
candidate { id: string, requisition_id: string, external_id: string, stage: string, status: enum(ACTIVE,OFFER_EXTENDED,HIRED,REJECTED) };
(reference, product may differ).

POST /v1/job-requisitions { position_id, grade, comp_band_min_minor, comp_band_max_minor, currency_code, external_id } -> 201 { id, status: "DRAFT" };
POST /v1/job-requisitions/{id}/publish -> 200 { status: "OPEN" };
POST /v1/candidates/{id}/extend-offer { offer_amount_minor, currency_code } -> 201;
emits ats.requisition_published, ats.offer_accepted, hr.new_hire_created;
idempotent via external_id.

DRAFT -> APPROVED -> OPEN -> FILLED;
terminal CANCELLED;
guard: OPEN requires approved headcount;
offer extension blocked if amount outside grade band;
FILLED on offer acceptance.

The useful version of this workflow is not only fast. It is inspectable. A controller, auditor, or operator should be able to move from source event to system record to state transition to final business outcome without guessing.

Implementation contracts.

`job_requisition` { id: string, external_id: string, entity_id: string, position_id: string, title: string, grade: string, comp_band_min_minor: int64, comp_band_max_minor: int64, currency_code: char(3), status: enum(DRAFT,APPROVED,OPEN,FILLED,CANCELLED) }; `candidate` { id: string, requisition_id: string, external_id: string, stage: string, status: enum(ACTIVE,OFFER_EXTENDED,HIRED,REJECTED) }; (reference, product may differ).

`POST /v1/job-requisitions` { position_id, grade, comp_band_min_minor, comp_band_max_minor, currency_code, external_id } -> 201 { id, status: "DRAFT" }; `POST /v1/job-requisitions/{id}/publish` -> 200 { status: "OPEN" }; `POST /v1/candidates/{id}/extend-offer` { offer_amount_minor, currency_code } -> 201; emits `ats.requisition_published`, `ats.offer_accepted`, `hr.new_hire_created`; idempotent via `external_id`.

`DRAFT -> APPROVED -> OPEN -> FILLED`; terminal `CANCELLED`; guard: OPEN requires approved headcount; offer extension blocked if amount outside grade band; FILLED on offer acceptance.