Verify statement periods
Checks that submitted and approved timesheet periods still come out the way they were settled, and lists every difference in a report you can download.
Overview
When a period is submitted, mTIME freezes its results on the statement: worked and expected time, the allowance totals, and every time account’s opening balance, movements and closing balance. Nothing recalculates them afterwards.
This job recalculates those periods and compares the result with what was frozen. Use it to check that the configuration and the data behave the way the stored periods say they did, for example:
- After a migration from mTIME 5. Each migrated period carries its mTIME 5 figures, and the job shows where mTIME X would have calculated something else.
- After a change to policies or employment terms. A change that takes effect back in time shows up in the periods it reaches.
The job only reads. It never changes a statement, a balance, a registration or a payroll line, so it is safe to run on a live workspace.
Who can run it
Only the workspace owner can run this job and download its report. The report holds every employee’s balances and payouts, which no single permission covers, so an administrator without the owner role does not see the job.
How it works
The job checks every submitted or approved period that overlaps the dates you choose. Periods that are still open have nothing frozen yet and are skipped.
For each period, the job:
- Starts from the stored opening balances. Each period is checked on its own, so a difference shows up in the period that causes it rather than in every later one.
- Recalculates the days. Work time, allowance policies and counters are worked out again from the period’s registrations, check-ins and absences.
- Recalculates the balances. Absences are consumed, the time-off policies’ accruals are granted, time-off balances that expire in the period expire, and the settlement policies (credits, caps, payouts) run, just as when the period was submitted.
- Compares the result with the frozen figures, exactly, minute by minute.
Policies are applied as recorded today, in the version that applies to the period. A change that only takes effect from today does not affect past periods; a change made back in time does. Each policy in the report says whether it was changed after the period was settled, so you can tell a configuration change from an error.
What is compared
| Level | Compared |
|---|---|
| Time accounts | Each account’s opening balance, accruals, consumption, expiration, payout, adjustments, transfers and closing balance |
| Period totals | Worked, expected and the difference between them, and each allowance activity’s total |
| Days | Worked time per day, and each automatically registered activity per day |
The job also checks that each period’s opening balance matches the previous period’s closing balance. A mismatch there points at the stored data rather than at a rule.
What is not checked
The report tells you what it could not check, so a gap is never mistaken for a match:
- Not compared: the stored period does not hold the figure. For example, a migrated period that carries only opening and closing balances is compared on those two only.
- Not simulated: the job cannot recalculate the figure reliably. This applies to expiring time-off balances in periods from before an account’s history starts in mTIME X (before the migration date), and when a later payout or correction makes the earlier balance impossible to rebuild. It also applies to a day whose registrations could not be evaluated.
Running the job
- Go to .
- Click Run Job and choose verify-statement-periods.
- Set the dates and, if you want, the employees to check, then run it.
Parameters
| Parameter | Default | Description |
|---|---|---|
| From | 1 January of the run date’s year | First day of the window. Every submitted or approved period that overlaps the window is checked |
| To | The run date | Last day of the window |
| Employee IDs | Everyone | Comma-separated employee IDs, to check a few employees quickly |
The job does not run on its own; it only runs when you start it. On a large workspace a full year can take a while, so start with a few employees to check a fix.
The report
When the run has finished, open it in and click Download report . The download is a zip file with two files:
| File | Contents |
|---|---|
summary.md | A readable overview: how many periods were checked, how many differ, the differences grouped by kind with examples, and what was not checked |
report.ndjson | Every checked period and every difference, one per line. Each difference names the employee, the period, the account or day, the figure, the stored value, the recalculated value and the policy behind it. A period with differences also carries its days and the policies that applied |
report.ndjson holds one JSON object per line, so it can be filtered with standard tools or handed to an AI assistant to investigate.
Each download is recorded in the security log.
Reports are kept for 30 days. After that, the nightly verify-statement-periods-cleanup job deletes the file. The run itself stays in the list with its totals, but can no longer be downloaded.
Job results
| Metric | Description |
|---|---|
from, to | The window that was checked |
employees | Employees with at least one checked period |
periods | Periods checked |
deviating_periods | Periods with at least one difference |
deviations | Differences found |
deviations_by_kind | Differences per kind: movement, summary, allowance, day, chain |
error_periods | Periods that could not be recalculated (their error is in the report) |
failed_employees | Employees whose periods could not be loaded at all |
not_compared, not_simulated | What could not be checked, and in how many periods |
Troubleshooting
| Issue | Solution |
|---|---|
| The job is not in the list | Only the workspace owner sees it |
| Many differences in one account and field | Check whether the policy behind them was changed after the periods were settled (changed_since_period in the report). If not, the difference is worth investigating |
| A difference in every period of a migrated account | Check the opening balance check first: a mismatch between a period’s opening and the previous period’s closing points at the migrated data |
| Expirations are reported as not simulated | Expected for periods before the account’s history starts in mTIME X, and for accounts with a later payout or correction |
| The download button is missing | The report is older than 30 days and has been deleted. Run the job again |