Payroll export
A payroll file is a configuration, not a report: a Jira admin defines it once in Settings → Payroll export, and whoever runs payroll exports it from the Approvals tab for whatever dates they need. Nobody edits a mapping on payday.
Define the file once
Pick your payroll system and the preset fills in the columns, the file format and the naming. Presets ship for ADP Workforce Now, Gusto, Paychex Flex, Workday, QuickBooks Payroll, Rippling, and a generic CSV — and every part of a preset stays editable, so a system we didn’t name is a column mapping away.
Edit columns is where the file takes shape: one row per column in the output, the payroll system’s own header text on the left, where the value comes from on the right, with a live preview of real cells underneath. A column without a source is an error before you save — never a silent empty column in a file payroll has already imported.
- Hours
- Approved hours — as one column, or split into regular and overtime.
- People
- Employee ID, display name, or email.
- Work
- Project, issue key, issue type, or any Jira field — mapping one of these splits a person into one row per value, which is how per-department files happen.
- Constants
- The range dates, a label typed at run time (ADP’s Batch ID), or a fixed value.
Employee IDs
The pane lists everyone who has ever logged time; type each person’s payroll ID beside their name. A person with no ID is excluded from the file and named at export — never exported with a blank ID, because a blank ID in a payroll import is a silent mispayment.
An email column only carries addresses the person running the export can see, and most Jira profiles keep email private — so an email-keyed file tends to exclude people through no fault of yours. The run screen names each one and why. Employee IDs are yours, always present once typed, and every preset that matches by email also accepts an ID column instead.
Rounding, day boundary, overtime
- Round each entry
- Rounding happens per entry, then totals are summed — so a day can land a few minutes off the timesheet, and the run screen always states that delta before you download. It is never absorbed silently.
- Day boundary
- Where one payroll day ends and the next starts. Night shifts move it: at 03:00, work until 3 a.m. counts to the day before. Entries logged with clock times can count whole to their start day or split at the boundary; entries logged as a plain duration have no clock to split and always count on their own date — the run screen says how many of each are in the file.
- Split overtime
- Anything past a person’s weekly target inside a Monday-based week goes to the overtime column — measured across the whole week even when your export range cuts through it, so a fortnightly export never under-pays the week it splits.
Run it from Approvals
The Export menu on the Approvals tab holds both files: the mapped payroll file, and these timesheets (CSV) — every visible entry raw, no mapping, for anyone who just wants the rows.
- Pick dates. Any range — we don’t model pay calendars, so presets cover the common windows and a custom range covers yours.
- Pick people. Everyone with logged time, or specific people — which is how a single corrected timesheet gets re-run on its own.
- Pick what to include. Approved time only is the default and what payroll should ever see; the alternatives say their consequence next to the option. Rejected time is never included.
- Read the card before you download: how many rows and hours, what changed since the last export of this range, how many entries crossed the day boundary, what rounding moved, and everyone who is not in the file, by name, with the reason and the fix.
- Export downloads the CSV and records the run.
Re-runs and corrections
Every export gets a number — EXP-0042 — and every entry remembers which file it went into, so an approver can see at a glance that a week was, or was never, in a payroll file. Re-running a range is normal: late approvals and corrections land, the new file carries them, and the screen says what changed since the previous file of the same range. The earlier file stays exactly as it is in your payroll system — import the correction there too.
Defining the file and employee IDs takes a Jira admin. Running an export takes an approver or an admin — the same people who already see everyone’s submitted time. The export never includes a person the file’s columns cannot identify.