One Payroll Setting, No Middle Position: What I Learned Building the Fix for Payslip Leave Visibility
One Payroll Setting, No Middle Position: What I Learned Building the Fix for Payslip Leave Visibility
Showing long service leave to the people who've earned it — and not to those three years into a ten-year wait — turns out to be a setting that doesn't exist. Here's what chasing it taught me.
Here is a small problem a lot of finance people will recognise, and that almost nobody writes about because it sounds too minor to matter.
In Xero Payroll, whether a leave balance shows on payslips is a property of the leave pay item, not of the employee. The decision is therefore organisation-wide. Turn long service leave on, and every employee sees it — including the person eighteen months into a qualifying period, reading a balance that means nothing to them as an entitlement. Turn it off, and it disappears for everyone, including the staff who have earned it and reasonably want to see it.
There is no middle position. Requests for one have sat on Xero's own product ideas forum for years, most commonly asking to show long service leave only once an employee reaches the qualifying period.
That's the whole problem. Not dramatic — but it generates a surprising amount of work.
The workarounds, and what each one costs
In practice, organisations land on one of four responses, and all four have a price.
Show it to everyone and explain it repeatedly. The most common option. The cost is a recurring conversation with people who see a number and reasonably ask what it means, and occasionally a difficult one at exit.
Hide it from everyone and answer requests manually. The cost moves to payroll: an ad hoc query every time someone wants their balance, answered by hand, with no audit trail and no consistency about who was told what.
Suppress the pay item and issue supplementary statements. Now you have two documents that need to agree, produced by different processes.
Change payroll platforms. Data migration, retraining, and a split Single Touch Payroll history — to change one setting. I've watched organisations seriously price this, which tells you how much friction the first three options generate.
The constraint isn't unusual, either. In the other payroll and rostering products I checked, the equivalent control is also configured per leave type, so it also applies to everyone at once. I'm not naming them — that was accurate when I checked, and vendors ship changes without telling anybody.
Why the fix wasn't a five-line change
My assumption going in was that this would be a thin layer: read the data, apply a per-employee rule, render a payslip. A CPA who runs payroll day to day noticing a gap and closing it — that part is true, and worth saying once, because it explains why anyone would care about a problem this specific.
What was not true was "thin." Building against the payroll API surfaced a series of behaviours that don't match what you'd assume from the documentation. These are observations from testing during development, not published product specifications, and vendors change interfaces without announcing it — so verify against the current developer documentation before relying on any of them. They're worth knowing whether or not you ever build anything, because they're exactly the places where an integration, or an AI agent pointed at payroll, will confidently produce a wrong number.
Totals and line items live in different places. The pay run summary carries the calculated totals; the payslip detail carries the line items but no totals. If you derive totals by summing the line items, you get numbers that don't match the payroll system's own figures.
The same amount can be classified two ways. Salary sacrifice is counted as a deduction within the totals, but appears only under superannuation in the line items. The same $50, categorised differently depending on where you read it — which makes a reconstructed payslip look internally inconsistent unless it's handled deliberately.
Year-to-date figures weren't exposed. The payslip a payroll system produces shows YTD. Its activity reports show YTD. The endpoints returned none of it. YTD had to be recomputed by summing pay runs across the financial year, cut on payment date rather than period dates, and adding opening balances only where they fall inside the year being viewed.
Approval state isn't where you'd expect. A leave application created through the API is treated as admin-authorised and scheduled immediately — there's no "awaiting approval" status reachable that way. Any approval workflow built on top of it has to hold the pending state somewhere else and only write once a decision has been made.
Posted pay runs can't be updated. Which means anything you want on a payslip — a message, for instance — has to be set before posting, not after.
And the one the whole thing depends on: the setting that governs payslip display governs display. It doesn't restrict what the API returns.
Why a small fix became a whole portal
There's a design consequence that surprised me, and it's the most interesting part of the build.
If employees keep their normal self-service access to the payroll platform, they can simply look up the leave balances the customisation is meant to hide. The visibility rule is bypassed in one click. Which means the only way the control actually holds is if the portal becomes the employee's single channel — and once it's their only channel, it has to cover everything they'd otherwise go there for.
So it does. Payslip PDFs with company details, earnings, deductions, tax, super, leave and YTD columns, with balances shown according to the rules set for that individual. Leave balances and history, filtered per employee. Leave requests, where the employee submits and the nominated approver responds by email without needing a seat of their own — approved leave is written back, declined leave never is. A YTD summary itemised properly rather than collapsed into a single "other earnings" line. And an archive storing each payslip as issued, so changing a visibility setting later doesn't retroactively alter a document already produced.
On the administration side, the core of it is a matrix of employees against leave types with control at each individual cell, plus a reconciliation warning when line items don't tie back to the payroll system's own totals — which, given the first item on that list above, is not optional.
What it doesn't do
Worth being blunt, because overclaiming is the fastest way to lose an accountant's attention. It controls which leave balances each employee sees. It does not make payslips broadly customisable — no layout, ordering or formatting control. It is not a payroll platform and doesn't replace one; payroll runs exactly as before, and the portal reads from it and writes back only approved leave.
It is also pre-launch: feature-complete and tested, with deployment planned alongside a first customer's onboarding. There are no customers yet, so there's nothing I can tell you about how it performs in the wild.
The delivery question, since it comes up immediately
Whenever payslips move into a portal, someone asks whether that satisfies the employer's obligations. The general position, from the Fair Work Ombudsman's published guidance, is that pay slips may be provided electronically — including through an online portal — and must be given within one working day of paying the employee, with the same mandatory information as a paper slip. Email is not itself mandatory.
Three things alongside that. The Ombudsman's guidance is explicit that employees must be able to access and print an electronic pay slip in private — which is a design requirement for a portal, not an afterthought. Pay slip and record-keeping obligations sit with the employer, not with any software provider. And the obligation to former employees is to provide records on request, rather than to maintain standing self-service access — which is why deactivating a leaver's login while retaining their archived records is defensible.
What to take from this if you never buy anything
Two things, and the second is the more valuable one.
First: if a system setting only offers all-or-nothing where you need something in between, name it as a cost rather than absorbing it as a quirk. Count the manual queries, the repeated explanations, the two documents that should be one. The total is usually larger than anyone assumes, precisely because it's spread across people who each experience it as trivial.
Second: the assumptions in the list above were all reasonable, and all wrong. Every finance function is currently being invited to let something automated read its payroll and act on what it finds. Before that, somebody has to establish what the interface actually returns. That step is unglamorous, and it's the difference between an automation that saves time and one that produces confident errors at scale.
Is a system limitation quietly costing your payroll team a few hours a month?
Most of them are absorbed rather than measured. PFL provides senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations — starting with working out what the friction is actually costing.
Talk to PFL →Xero is a trademark of Xero Limited. PFL Payroll Portal is an independent product and is not affiliated with, endorsed by, or sponsored by Xero Limited.
Comments
Post a Comment