Payroll

Send approved time to your payroll system, and see what has already been sent.

Overview

The Payroll page is where a payroll administrator releases approved time to the payroll system. It is a different job from approving timesheets: a manager decides whether the hours are right, and the payroll administrator decides when they are paid.

Everything on the page is organised around a run.

A run is one payroll system, one cut-off date.

The cut-off dates come from the payroll system itself: each integration states its own schedule, and the runs are that schedule laid out over time. Nothing about your employees’ payroll periods decides them.

If your workspace sends to two payroll systems — during a migration, or because different groups are paid by different systems — each gets its own runs, with its own deadlines and its own files. That is the reason a run names one system: a timesheet period can face two of them at once and could not state one deadline for both.

A run is not a single send. It accepts several deliveries up to its cut-off, so you can release what is approved now and top it up as the rest comes in.

Two ways a payroll system is fed

Some payroll integrations deliver on their own, as each timesheet is approved. Others hold what they have until a payroll administrator releases it. Both appear on this page, and the difference is one setting on the integration — Wait For Payroll Run :

An automatic run is still worth having on the page: it is the only place that says what that payroll system has been given, and for which periods. There is deliberately no Send button on it, because freezing a period the payroll system has already been paid for would pay it twice.

For an automatic run, each timesheet says what became of it: Delivered, or Not delivered yet with the reason — a delivery that failed, or a source with no payroll code for that system. Once the cut-off passes, the run’s timesheets are sealed exactly like a sent run’s, whether or not the payroll system received them, so an undelivered one stays flagged where you can act on it.

What you need first

Payroll only appears in the menu once an integration that receives payroll is turned on. Its runs then appear once two things are configured:

1. A payroll integration is turned on — see Integrations. The built-in Payroll CSV Export needs no credentials, only a go-live date (Export from ).
2. That integration has a cut-off schedule — Payroll Cut-Off Cadence (Cut-Off Cadence on the Payroll CSV Export) set to monthly (with a day of the month) or fortnightly (with one anchor date, from which the rest are laid out). This is what creates the runs. An integration with no cut-off schedule has none at all, and the page stays empty for it.

If you turn Wait For Payroll Run on without a cut-off schedule, mTime refuses the change rather than accepting it. Without a schedule there would be no runs, so nothing would ever release the held input, and the timesheets would simply stop reaching payroll with nothing on screen to say why.

For amounts to appear, the activities and time accounts you want paid also need that integration’s salary code on them — the code attribute the integration adds to activities and time accounts, for example Salary Code for Intega Løn or Payroll Code for the Payroll CSV Export. A source with no code for a payroll system is never sent to it — which is exactly what lets two systems run side by side, each receiving only what it is coded for.

Banked allowances are not sent as allowances

An allowance that a settlement policy reads as an input is banked: it is credited to that policy’s time account at the policy’s rate, and it reaches payroll — if at all — as a payout from that account. Such an allowance is never sent to payroll as an allowance in its own right, whatever code it carries. The timesheet statement says which is which: its Allowances table shows where each one goes, the account row shows the arithmetic (Overtime 2h00 × 1.5 = 3h00), and its Salary block lists exactly what the period sends to salary.

Opening the page

Open Payroll from the sidebar. The page has two sections:

• Open runs — what is waiting to be sent, each with a deadline.
• Sent runs — closed runs, as the record of what was sent.

The period filter at the top bounds how far back the page looks.

Reading an open run

Each open run is a card. The heading names the payroll system and the cut-off — the deadline is what matters, so a cut-off that falls today or within the week is called out in colour.

The progress bar

A run’s state is a proportion, not a single status: part of it can be sent while the rest is still open. The bar splits into three:

The three numbers

Every run states what it pays in the three categories a payroll administrator checks:

The FTE figure divides the paid hours by each employee’s full-time week — their employment’s own reference week where a work-time policy sets one, and your workspace’s Standard Weekly Hours under Admin › Workspace otherwise (see Employment terms). It therefore means the same thing here as everywhere else in mTime. Each timesheet counts against its own period, so a late one does not inflate the run that happens to pay it.

Seeing who is holding a run up

Press View details on a run (or click its name) to open its page. The page starts with the run’s own card — the same one the payroll page shows, with the deadline, Send to payroll, the progress bar, the three amounts and the files already sent — so everything you can do to a run, you can do from here. Below it, the page lists one row per timesheet, not per employee — the same person can appear twice, for instance with a late timesheet from an earlier period alongside the current one.

Rows are grouped by what to do about them:

Clicking a row opens the usual timesheet detail in a panel over the run’s page, so you can see the hours, approve, or ask for changes without losing your place.

Sending to payroll

Press Send to payroll (or Send N more, once the run has already delivered once). The confirmation states:

• which delivery this is, and that earlier deliveries are untouched by it;
• what it carries in each of the three categories;
• how much of it is late — worked in an earlier period and paid now;
• how many timesheets are not approved and therefore stay out.

The send runs as a background job. The page updates when it finishes; a large workspace takes a moment.

What happens to work that misses a run

Nothing is lost. Once a run passes its cut-off it takes no further delivery, and anything still unsent is picked up by the next run for that payroll system — shown there as late, with the period it was actually worked in.

This is why approving a timesheet after the cut-off still works and is still worth doing: the hours are paid one run later rather than not at all.

Sent runs, and what “delivered” really means

The sent-runs table lists closed runs with what each one paid, how much of it was late, and how it was delivered. The Delivered column is deliberately precise about what mTime can actually know:

For a file export there is no third fact available: mTime can tell you it produced the document and that it was collected, but never that the payroll system accepted it. The not downloaded warning is the one worth acting on — without it, a run nobody ever collected would look exactly like a successful one.

A run can produce several files, one per delivery, numbered in the file name. A later file adds to the earlier ones; it does not replace them.

Rebuilding a file

If a file went out with a payroll code missing or wrong, fix the code on the activity or time account and press Rebuild the file on that delivery. mTime renders a fresh file over exactly the timesheets that delivery carried, and marks the old one as replaced rather than deleting it — a payroll audit trail has to be able to show what went out the first time.

A rebuild is offered only where mTime holds a record of what the file carried. For a file delivered before mTime began keeping that record, the button says so and points you at sending a new file for what still needs paying instead.

Checking the detail

The Payroll report lists the payable amounts per employee and source, each traced back to the timesheet it came from, with whether that timesheet has been sent. Because the sent state is a filter rather than a fixed scope, the same report answers both “what am I about to send?” before a run and “what did I send?” afterwards. Its date range selects payroll runs by their cut-off — the run that sent an amount, or the next open run for one not sent yet — not timesheet periods, so a late May timesheet paid in July’s run is in July’s report. It exports to Excel like every other report.

Permissions

Paying a period is a separate permission from approving timesheets, so you can grant it without granting the ability to edit or approve anybody’s hours.