Expiring balance
Warns a set number of days before part of a balance lapses — and only when something will actually be lost.
The classic case is restferie nearing expiry: 30 days before the holiday year ends, tell everyone who still has days that are about to disappear.
When to use
Use it whenever a balance can be lost by not being used: vacation with an expiry date, carried-over days, a flex balance with a recurring cap.
If the date matters more than the loss — “on 1 March, whoever is above 40 hours” — use Scheduled balance check instead.
Parameters
| Parameter | Description | Default |
|---|---|---|
| Account | The time account to watch. | — |
| Days before | How many days ahead of the loss to warn. | 30 |
| Minimum amount | Only warn when at least this much is lost, in the account’s own unit. Leave at 0 to warn about any amount. | 0 |
How it works
Unlike a scheduled check, this trigger takes its date from the data. Each night mTime looks ahead by the number of days you configured and asks what each employee stands to lose on that date.
Two kinds of loss count:
- an accrual reaching its expiry date — vacation that lapses at the end of the holiday year, carried-over days that run out;
- a recurring balance cap forfeiting the surplus at its cut-off.
The amount is what will really be lost, not what the employee holds. Time off they have already booked — approved or still awaiting approval — is subtracted first, so somebody who has planned their holiday is not told they are about to lose it. If nothing will be lost, nothing is sent.
An employee with two different expiry dates coming up gets one message per date, each naming its own date and amount, and each sent only once.
If the nightly check could not run on the day itself, it still warns for up to three days afterwards — a warning that arrives slightly late is far better than none. It never warns earlier than the lead time you chose.
Message
Leaving the subject and text empty sends:
{amount} of {employee_name}’s {account_name} expires on {expiry_date}
{amount} of {employee_name}’s {account_name} balance expires on {expiry_date} and will be lost if it is not used before then.
Available variables: {employee_name}, {workspace_name}, {date}, {account_name}, {amount} (what will be lost) and {expiry_date}.
Examples
Restferie nearing expiry
- Add an advisory and select the Expiring balance trigger
- Choose the vacation Account
- Leave Days before at 30 and Minimum amount at 0
- Turn on Employee as the recipient
Everyone who still has vacation about to lapse hears about it a month ahead, with the number of days they are about to lose.
Two warnings, one early and one final
- Create the advisory above with Days before set to 60
- Create a second one with Days before set to 7 and a more urgent message
Each is its own advisory with its own text, and an employee who uses the days in between never gets the second one.
Only worthwhile amounts
Set Minimum amount to 1 to skip anyone losing less than a day.
Troubleshooting
| Issue | Solution |
|---|---|
| Nothing is sent, but balances clearly expire | Check that the balance actually lapses: an account without an expiration rule and without a cap loses nothing. Check too that the employees still have an unused balance on the expiry date. |
| An employee was not warned although they have a large balance | They have probably booked time off that consumes it before the expiry date. The warning counts what will be lost, not what is held. |
| The warning arrived a few days late | The nightly check catches up for up to three days after an interruption. |
| Two emails for the same person | They have two different expiry dates coming up. Each names its own date and amount. |
| Employees are warned about tiny amounts | Raise Minimum amount . |