Buying stage: diagnosis, finding out what is wrong
When entitlement, sickness and pay figures stop agreeing with each other, the balance is rarely where the problem lives. In a Unit4 estate the drift starts upstream of the balance: in code and category design, in half-pay and nil-pay transfer, in the holiday calculation and the work schedules beneath it, and in the open absences nobody can close.
Absence is the module where a policy decision, a payroll rule and a reporting definition all have to agree with one another. The configuration is designed from first principles: absence codes, categories and grouping, special leave reasons, and the sickness, paid leave, annual leave and statutory schemes that sit over them. Operations then run on that design: balance configuration, holiday calculation, buy and sell annual leave, absence transfer schemes, absence reversal, load templates, and the resolution of open absence errors.
Work schedules sit underneath all of it, and they are not a one-time setup either. Configuration, import, update, migration and the troubleshooting of failed loads are recurring work. Each of the five areas below is a design decision that can be re-examined without touching a single balance.
Code and category design
Absence codes multiply for good operational reasons. A new special leave reason is agreed, a scheme changes, a statutory addition arrives. Categories and grouping are what keep the multiplication legible, because the category is the level most reporting and most scheme behaviour reads rather than the individual code.
Two questions are worth asking of any estate. Is there a current list of active and closed absence codes with the category each belongs to? And can somebody state, for each active code, which scheme it pays under and which report set it lands in? Where two reports of the same period disagree, the grouping is the first place to compare them, because they may be reading different levels of the same structure.
Half-pay and nil-pay transfer
Statutory and occupational absence pay covers statutory sick pay, maternity, paternity, adoption, shared parental leave, parental bereavement leave and jury service, together with the transfer processing that moves an absence from full pay to half pay and from half pay to nil pay. Sickness management adds the rest of the machinery: trigger points over a rolling year, reason categorisation, full-time equivalent calculation, and automated half-pay and nil-pay letters.
The transfer is where an occupational scheme and a statutory scheme meet, and it is worth three separate checks. Is the rolling year the system applies the same rolling year the policy describes? Is full-time equivalent calculated the way the policy intends for part-time and irregular working patterns? And does the letter automation fire from the same trigger as the pay change, or from a second definition maintained beside it? Two definitions of the same rule will agree until the day the policy moves.
Balances and holiday calculation
Balance configuration and the holiday calculation are the visible end of absence. Around them sit buy and sell annual leave, absence transfer schemes and absence reversal, and the load templates used to bring balances in at year start or after a migration. Every one of those is a route by which a balance can change without a person changing it, which is exactly why each needs a named owner and a written rule.
Work schedules deserve their own pass. Ask when each schedule was last reconciled to the working pattern it represents, and what happened to the schedules imported in the last load. Where a load failed part way, the question is whether every affected record was reprocessed or only the ones that errored visibly. Absence reversal deserves a similar question: who can run it, and what record does running it leave behind?
Open absence errors that carry between periods
Open absence error resolution appears in the operations set because it is recurring work rather than an incident. An absence that cannot be closed is still open when the next period opens, so it is present in this period's processing and in the next one's as well.
The check is simple and it is about the trend, not the total. Is your open list shrinking? A count that stays level month after month says the errors are being carried rather than cleared, and that no root cause has been recorded against them. That is a documentation problem before it is a configuration one, and it is usually cheaper to answer in that order.
The schools payroll variant
A local government payroll frequently runs a schools variant alongside the main payroll: school-specific processing, bursar timesheet and absence load templates, and school-level absence transfer handling. It is a common pattern and it behaves like a second payroll wearing the first one's configuration.
Three features are worth checking separately. Absence and timesheet data arrives by load template completed outside the payroll team. Absence transfer is handled at school level. Term-time working patterns are expressed in the work schedule rather than in the contract. In each case, a control that holds on the main payroll does not necessarily reach the variant, and that is a question to settle deliberately rather than discover at year end.
Worked example: a payroll review forecast to free 500 administrative hours a year
A local government payroll running several pay entities, including a schools payroll, carried manual effort that had never been mapped end to end. The engagement was an independent system review: the workflows were mapped, the fixes specified, and the remediation options sequenced into a phased roadmap with consultancy estimates, written for an executive audience.
The published result is a forecast saving of 500 administrative hours a year, and it is stated as a forecast because that is what the source says. The relevant point for absence work is that the review mapped what the estate actually did before it proposed any change to what it should do.