How to build an HRIS to payroll sync

What matters here

• Sync the effective date, never the entry date. Backdated changes are normal and paying them in the wrong cycle is not.
• Handle the cutoff explicitly. A change entered the day after cutoff belongs in the next cycle with a retrospective adjustment.
• Hold anything ambiguous instead of guessing. A wrong payment is far more expensive than a delayed one.
• Reconcile before payroll runs, not after. Afterwards it is a correction and a conversation.
• Never sync a termination without a human confirming the final pay treatment.

Who this is for

You run people operations or payroll. Changes are made in the HRIS and rekeyed into payroll, the cutoff is a calendar entry somebody remembers, and corrections happen every cycle.

How it works in practice

From a change in the HRIS to the right amount being paid, in order.

1. 1

   Changes are read with their effective date

   Not the date somebody typed them, because backdating is normal and routine.

2. 2

   The cutoff decides which cycle it lands in

   Before cutoff goes in this run, after goes in the next with a retrospective adjustment.

3. 3

   Anything ambiguous is held, not guessed

   A mid-cycle change with no clear proration, a missing bank detail, an unusual pattern.

4. 4

   Only clean changes flow to payroll

   Everything else waits for a person, because a wrong payment costs more than a late one.

5. 5

   A reconciliation runs before payroll is committed

   Headcount, changes applied, and anything in the HRIS not reflected in payroll.

6. 6

   Terminations always need a human

   Final pay, accrued leave and notice treatment are decisions, not fields.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Set up, then learn how each side dates a change

   The two systems mean different things by date.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Workday and Gusto, or
   whatever we run in those seats.
   
   I need worker records with compensation, employment status and cost
   centre, and specifically how each system represents an effective date
   versus an entry date. They will differ.
   
   Also tell me the payroll cutoff, the pay calendar, and how retrospective
   adjustments are represented. Everything in this build depends on those
   three.

2. 2

   Carry the effective date, always

   The single most common cause of a wrong payslip.

   Headless skills build-workflow

   Copy

   Use build-workflow. Read changes with their effective date and treat that
   as authoritative:
   
     Compensation changes
     Employment status changes
     Cost centre and manager changes
     Working pattern changes, which affect proration
     Leave without pay
   
   Never sync on the date the change was entered. A rise entered in April
   effective from March is owed for March, and a rise entered in March
   effective from April is not owed yet. Both are routine and both are
   wrong if you sync on entry date.
   
   For any change effective mid-cycle, compute the proration explicitly and
   show the working. A prorated amount nobody can explain generates a
   support ticket from the person it was paid to.

3. 3

   Handle the cutoff instead of hoping

   Because the cutoff is currently a calendar entry somebody remembers.

   Copy

   Apply the cutoff explicitly:
   
     Effective date before the cutoff and entered before it: this cycle
     Effective date before the cutoff but entered after: next cycle, with a
     retrospective adjustment for the missed period
     Effective date after the cutoff: next cycle, normally
   
   Tell the employee and their manager when a change will land in the next
   cycle with an adjustment. The surprise is the problem, not the delay, and
   a message beforehand prevents almost every query.
   
   Never silently move a change into a later cycle without saying so.

4. 4

   Hold anything ambiguous

   A wrong payment is far more expensive than a delayed one.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then hold instead of guess. Send to a queue:
   
     A change with no effective date
     A compensation change above a threshold, which should be confirmed
     A worker with missing bank or tax details
     A change that would produce negative net pay
     Two conflicting changes in the same cycle
     Any termination, always
   
   Terminations never sync automatically. Final pay, accrued leave, notice
   and any clawback are decisions instead of fields, and getting one wrong
   is both expensive and personal.
   
   Show the reason and the proposed values in the queue, so approving is a
   glance instead of an investigation.

5. 5

   Reconcile before payroll runs

   Afterwards it is a correction and a conversation.

   Copy

   Reconcile before every payroll commits, not after:
   
     Headcount in the HRIS against headcount in payroll
     Changes applied this cycle against changes expected
     Anybody active in one system and not the other
     Total compensation change against what the HRIS implies
     Anything held, still unresolved, with the cutoff approaching
   
   Send it to payroll before the run. After the run, every difference is a
   correction, a supplementary payment and a conversation with somebody
   whose payslip was wrong.
   
   Report per cycle: changes synced, held and released, adjustments raised,
   and corrections after the run. That last number should trend to zero.

6. 6

   Prove it works, then hand the rules to payroll

   Because cutoff and threshold rules belong to payroll.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production. Run parallel for two cycles: compute everything,
   write nothing, and compare against what payroll did by hand.
   
   Then open the same workflow in Tray Build so payroll can adjust cutoff
   rules, approval thresholds and the hold reasons in the visual canvas.

What it connects to

Two systems of record for the same people, and money at the end of it.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides