Hopefully this question is relatively software agnostic.
For background, I have run payrolls as part of my job 'for ever' but these have generally been for about 30-50 people. I have also supervised a larger factory payroll, but we had really complex systems there.
So, with 30 staff, I tended to have an Excel workbook with one line per employee, and columns for the various pay elements.
I put all my adjustments to gross pay on there first (ie overtime, expenses, starters, leavers).
The list was in pay reference number order - so, longest serving at the top, and newest got added.
Once I was happy with my various totals, I then entered these to Sage payroll, and checked various control totals such as gross pay etc as a means of confirming data correctness.
In my current role, (as it happens, education), adjustments are entered as they arise, directly into Sage. So, there are no 'before and after' checks -
Am I clinging to my own idea of a 'comfort blanket' to have quite liked the idea of an original data set I was happy with, and then checking against it?
I try to avoid pointless processes if I can - it's just I have always done payroll in one way.
Replies (18)
Please login or register to join the discussion.
I’m not sure what the question is, but perhaps something along the lines of ‘what checking could I do’ ? I have not used Sage payroll but my guess is you could export to excel for a month to month comparison checking.
The problem with entering individual components straight in, when they arise, is that there's no cross check / reasonable check.
For payrolls we do in a similar situation where there are a lot of individual components as well as providing (& inputting) the individual component parts we also obtain, from the client, a one sheet overview.
So we do what you feel you should do.
You don't really get a practical, second chance on a payroll without a lot of hassle so basic cross checks are needed.
I would most definitely stick with your “comfort blanket” spreadsheet. It is exactly what I do and wouldn’t dream of pushing the button on something that I couldn’t confirm as being correct nor explain how it has varied from prior month. Your original reason for doing what you do was clearly very sound and nothing has changed.
Dave
At the risk of a lack of conciseness, it depends on what you are expecting from your Payroll. This may sound stupid (isn't it 'to pay the right amount to the right people at the right time'), but there can be a lot more to it - particularly within the Education sector.
Due to all those other factors it's common to capture your 'raw' data neither direct in Payroll nor via an intermediary spreadsheet, but within an integrated HR system.
At the simplest level this should ensure that basic salaries are on the appropriate SC points and allow you to accurately apply pay rises (and to calculate any retrospective component) ... but there's also related aspects of holiday pay, sabbaticals, overtime, strike deductions, pre- and post-salary sacrifice impacts on other values such as pensionable pay, and of course the 'single employment but multiple concurrent contracts' that tend to arise.
I could go on (and on and on for pages!), but what I'm driving at is that you need more than a sanity check on the baseline numbers - as they've a habit of interacting all over the place (often relating to changes from earlier pay periods).
So in the long run you get greater efficiency and a better set of checks by building in those relationships at the point of data capture - which tends not to fall neatly into a particular pay period.
There is of course a 'but' to all this ... a comprehensive system of this sort will cost considerably more than vanilla basic Payroll software, and will take some resource to manage/run it. On the other hand, you will have real-time access to figures that are not merely updated once per month (and can even be used for forecasting or as input to resource scheduling etc). [And if the system is Education focussed then it should also support your related needs for things like Teachers' Pensions on-line reporting, and SIR returns etc.]
So you can see why I started by saying it depends ...
There's absolutely no doubt that your desire to be able to check/review the data about to be processed is essential - but there are other (less simple but enhanced) ways of achieving that.
And those bigger systems will usually have some standard Exception reports (which you can amend) that are run as part of the build-to-gross process (i.e. in time for you to go and ask someone why they entered '£x' 17 days ago, before processing)!
FWIW there's a world of difference between a bespoke payroll system and one that is merely more comprehensive than Sage (and includes all the Education-type examples, and more, that I mentioned within a standard software package).
For a start, it goes through the same robust spec/testing/release procedures of any standard package - and will be in a constant feedback loop from many other Education establishment users.
I fully understand that you have to 'pick your battles' with regard to any potential changes in software ... and the integration of HR and Payroll (in terms of a single database but still as separate functions) tends to require some redesign of internal processes - not to fit the software but to take best advantage of efficiencies.
Pay adjustments are a good example of the bugbears encountered in your sector (particularly for any hourly-paid visiting teachers), but there are solutions that eliminate 99% of them.
So I'd certainly not give up on your current controls within the status quo (which is what I believe you were asking), but just trying to re-assure you that there are better systems if/when it becomes a priority to improve efficiencies by reducing errors/re-workings (and not available only from my company)!
I'd go with what you've got, Tom.
I'd always know what the answer should be (in terms of total pay or whatever) before I started posting up the individual totals.
It depends what those elements are but I'd do as much prep as I could before I started the payroll proper.
Same here
other that the most simple for director only companies, all wages operated for our firm and its clients have spreadsheets that show what gross pay should be before the software gets operated on
I agree you need a method of checking before running. I use Moneysoft and import to the spreadsheet, so that totals can be compared with the data I had initially input to the spreadsheet. But clearly, if you need the various elements identified by Hugo, you’ll need something far more sophisticated
How many mutations do you have from one month to the next? And what pay element do they relate to?
With those factors in mind, can you reconcile the current month's gross to the prior month? The more pay elements you have (within reason), the easier it can be to explain your changes.
How much of the data entry - as opposed to checking - are you doing yourself? Marking your own work is never ideal
Perhaps taking the view that you need to 'prepare' payroll information for an outsourced provider, could be a good way to operate in terms of your day-to-day.
As items arise during the month - deductions, bonuses, etc. - you can keep adding them onto a sheet. Then at month-end, gather your hours and above info into one place and presto on your controls you will need to see once all data is imported into your payroll software.
Consider starting payroll only once all data is in one place - almost as if you are the outsourcer receiving the data from the in-house contact.
Hope this helps.
For payroll, the thing I have always done is a report on base salaries as a "check to last months"
So start add last months gross, add in starters, take off leavers, add in salary increases
And see what it looks like.
Edited to add, i note your comment about lots of variable pay, in which case you wuold need to do this for salaries only, and the variables then perhaps hive off as a separate exercise, or again a simple proof in total ie "total variable last month vs this month from input report, vs from output form payroll"
The main risks on a 250 payroll is the "leaver who still gets paid", and the "salary paid too high". The "salary paid too low "you will know about in about 30 seconds after the payslips hit...
If HR has a good enough output on their inevitable standalone system you can do a annual "proof in total" for base salary on their system (ie what they thing everyone gets paid) vs what is on yours (ie what they do). Dump it into excel and its an hours work max if it all works, especially if there are employee numbers.
All good points in the arena of variance reporting - and all should be standard within grown-up Payroll systems (typically starting with a default Summary report of things like Starters & Leavers, but with additional 'user' parameters to highlight amounts or %ages of specified pay elements that vary by more than 'x' from last month and/or same month last year).
Within the Education sector, the number of things being auto-reported on can include other areas in which typically there is considerable natural variation (such as hours for salaried-but-part-time staff, holiday pay for TTO staff, etc).
The "leaver who still gets paid" should be a rarity nowadays, assuming that the HR system is integrated and not "inevitably standalone".
The integration is a shock invariably to HR at the start, because they can no longer put things like leaver forms (or salary reviews etc) in the filing-tray "for dealing with when we've got time". But once they realise that their data input is a core part of accurate payments (with suitable overview by Payroll), they tend to see the benefits of maintaining data in near real-time rather quickly.
You can eventually go the whole way ... where for instance Heads of Schools enter the basic contractual data, HR review this and add other details, Employees can update their personal details and see the status of their contractual & pay histories ... and Payroll processes the data (after checking for anomalies) before paying staff and HMRC and Pension schemes.
But that's a long way from Sage as a stand-alone payroll system.
With payrolls from one person to nearly forty, all except the ones with basic salary only get a spreadsheet to collate all the hours, rates and extras that give us a Gross pay figure per person and total.
Data then entered to payroll software and we match the gross totals. All too easy to have, say, an bonus in the payroll system that repeats itself the next month but you can spot it through the difference.
When I was responsible for checking a 230 person payroll, I used to print out this time's and last time's payslips, and then reconcile each one using the source documents that had been provided (e-mails, etc). I also used to see the folders for the starters and leavers. Used to work pretty well, with few errors, and meant that we weren't having to input the data twice. However it was a client-server based system, with limited access, and only one person used to enter the data.