APIs are becoming an expected part of modern payroll technology. But connecting two systems is only the first part of the integration problem. Payroll also needs to know what the data means, when it is ready to use and what should happen when it changes.
API-first has become an increasingly familiar language across payroll technology. Increasingly, when we assess payroll software, HR systems, time and attendance platforms or other technology around the payroll process, one of the first questions is whether it has an API.
That represents real progress. Nobody wants to build the future of payroll around repeatedly downloading spreadsheets from one system and uploading them into another.
But there is a danger that we start treating the existence of an API as evidence that the integration problem has been solved. For payroll, it only answers the first of three separate questions:
Can I connect it?
Can I understand it?
Can I safely use it in this payroll?
The API principally answers the first question. A proper payroll integration model has to answer all three.
Can I connect it?
An API gives two systems a structured way to communicate. It can allow a payroll service to retrieve information from HR, time and attendance, rostering, holiday, expenses or other source systems without somebody manually moving the data between them.
Likewise, information generated through payroll can flow back out into finance, employee platforms, pension services, reporting tools and other systems that need it. That is clearly better than disconnected systems.
But an API tells us that information can move. It does not necessarily tell us when it should move, what state it should be in when it moves, or whether the information being retrieved is actually ready for payroll.
Consider a time and attendance system. Employees and managers might be updating it throughout the period. Missing shifts are corrected, overtime is approved, absences change, and managers review timesheets. Someone may even discover a mistake after approval and change the information again.
Technically, an API could make every one of those changes available almost immediately. That does not mean payroll should consume every change immediately.
| Key point Real-time connectivity does not remove the need for a payroll cut-off. It makes the definition of that cut-off more important. |
The cut-off may not simply be Tuesday at 3pm. It might be an event, such as all timesheets have been reviewed, the manager has approved them, and the client has confirmed that the payroll input is complete. That is a very different thing from asking whether the API is available.
Webhooks add another useful layer. Rather than repeatedly asking a source system whether anything has changed, a webhook can tell another system that an event has happened. But here again the business meaning matters – ‘something changed’ is not the same message as ‘this has been approved for payroll’.
Even ‘this has been approved’ may not be the end of the story if the source system allows somebody to reopen, amend and reapprove it afterwards. The technology can work perfectly while the payroll process still needs rules about what happens next.
Can I understand it?
There is then a second integration problem. Different systems can describe broadly the same thing in very different ways.
One time system may record basic hours and overtime separately. Another may return shifts, pay elements and rate codes. One HR system may represent an employee change in one structure and another in a completely different one.
The same problem exists at the other end. Different payroll calculation engines have their own structures, terminology, fields and import requirements. An API does not remove those differences; it simply gives you a better mechanism for accessing them.
If every source system has to understand every payroll engine directly, the integration estate can quickly become difficult to build and maintain. Add another HR platform and more mappings may be required. Add another payroll engine and the same problem appears again.
The alternative is to establish a common payroll data model. A shared payroll language where source systems translate their information into that common payroll structure. Payroll engines then understand the same common structure on the other side.
Instead of expecting every system to understand every other system, each needs to understand the shared payroll model. This is a well-established idea in wider systems integration, although the technical phrase often used – ‘canonical data model’ – matters far less here than the principle itself.
For Luna, this is the thinking behind the Luna Standard Payroll Model, or LSPM. LSPM is designed to provide the common payroll structure between the systems providing information and the payroll engines ultimately calculating the pay.
That does not eliminate integration work. Every source still needs to be understood and mapped properly, and every payroll engine still has its own requirements. But it changes the nature of the problem.
Rather than repeatedly asking how System A talks directly to Payroll Engine X, and then how System A talks to Engine Y, the more useful question becomes – how does System A express its payroll information through the common model? The same principle can then be applied to System B, System C and the payroll engines on the other side.
Connectivity gets the systems talking, while a common payroll model helps make sure they understand one another. But we still have the third – and arguably most operationally important question.
Can I safely use it in this payroll?
This is where payroll integration becomes an operational issue rather than simply a technical one.
Suppose a manager approves a timesheet at 10am. Payroll captures it at midday. At 2pm the manager spots an error, reopens it and changes an overtime entry. Which version now belongs in payroll?
There is no universal technical answer to that question because it depends on the operating process. Perhaps the change should immediately replace the previous information. Perhaps payroll should be alerted to an exception. Or maybe the amendment requires another approval or the current payroll is already locked, and the difference should be dealt with in the next period.
What matters is that the integration model knows there is a question to answer. The distinction between available data and payroll-ready data is fundamental.
A source application might contain perfectly valid information while it is still being prepared. Payroll needs some way of knowing when the relevant information has reached the appropriate state for the pay cycle. That might involve review, approval, a formal client submission, a cut-off event or another agreed control.
It may also require the integration to understand version and change.
- What did we receive originally?
- What was approved?
- What did we use?
- Has something subsequently changed?
- What requires somebody’s attention?
These are workflow questions, but they are also integration questions because they determine whether the data moving between systems can actually be relied upon operationally.
| Key point The real integration question is not simply whether payroll can retrieve the data. It is whether payroll can identify the right data, in the right state, at the right point in the pay cycle. |
Payroll data also has to go somewhere afterwards
It is easy to think about payroll integration principally as an inbound problem. Get starters from HR, hours from time and attendance, add in absences and expenses, and feed everything into the payroll engine.
But the calculation is not the end of the data journey. The output from payroll may need to feed employee-facing services, payslip delivery, finance and accounting, pensions, payment processes, reporting, analytics and other systems.
So a payroll integration model has to think about the whole cycle – information coming into payroll, information moving through payroll, and information going back out again.
The same questions remain relevant.
- What information should be released?
- At what point?
- In which structure?
- To which destination?
- What happens if the underlying payroll is subsequently changed?
A collection of APIs can provide the pipes, but it is the integration model that defines how the information should flow through them.
Three questions are better than one
For bureau owners and managers, this changes the conversation when evaluating integrations. Instead of asking only ‘Does it have an API?’, there are three better questions.
- Can I connect it?
Can the source and destination systems exchange the information we need? Is that through an API, webhook, file exchange or another mechanism? Can information move in both directions where the process requires it?
- Can I understand it?
How is information mapped between systems? Are different source-system structures being translated consistently? If we use several payroll calculation engines, are we creating separate mappings for every possible combination or using a common payroll model between them?
- Can I safely use it in this payroll?
How do we know the information is ready? Has the client reviewed it? Has it been approved? What defines the cut-off? What happens if information changes afterwards? How are exceptions surfaced, and can we see what was actually received and processed?
These questions move the discussion away from connector counts and towards the quality of the integration architecture. That matters particularly for payroll bureaus.
A single employer may only need to connect a relatively small number of systems. A bureau can potentially encounter dozens of different HR, time, attendance and other source platforms across its client base, while also choosing to operate one or several payroll calculation engines.
The answer cannot realistically be to treat every new combination as an entirely new integration problem.
From API-first to integration-first
None of this is an argument against API-first payroll. Quite the opposite.
APIs are an essential part of building a more connected payroll service. But they are a component of the answer, rather than the answer itself.
The direction we have taken with Luna reflects that distinction.
- LunaversalAPI provides the connectivity layer.
- LSPM creates a common payroll data model between source systems and payroll calculation engines.
- The wider Luna workflow provides the environment in which the payroll process itself can be managed and controlled.
The detail will vary between source systems. Some expose approval events and rich APIs. Others provide far less. Different payroll engines offer different levels of connectivity. A good integration model has to accommodate those realities rather than pretend every system behaves in the same way.
That is why the next question for payroll technology should not simply be whether another API can be added. It should be whether we have designed the integration model that makes all those connections usable.
| Key point Because connectivity asks whether the systems can talk. A common payroll model helps them understand one another. And the payroll process decides when it is safe to act on what they are saying. |
Find out how Luna approaches payroll integrations
See how LunaversalAPI, LSPM and the wider Luna environment support a more connected payroll service.