In most Polish SMEs we walk through this with, the picture is the same. HR prepares payroll in one system. She exports it to a PDF and hands it to the bookkeeper. The bookkeeper opens Excel, retypes the amounts into the ERP, and prays not to make a mistake. It takes 4 to 8 hours a month, and the mistake usually surfaces when an employee gets a paycheck 200 zł short and calls the office.
This process can be integrated. Not for half a million, not with an SAP consultant, and not in a year. Usually in a dozen or so working days, using what you already have. Below we describe what specifically needs to happen and what to watch out for — from the perspective of a shop that has done this dozens of times in Polish SME reality.
Where the mess comes from
In a typical 30-50-person company, HR-payroll and finance live in different worlds. HR works in enova365 or in Symfonia Kadry i Płace, because that's where contracts, holidays, social security, time tracking and all the Polish "small stuff" the ERP doesn't handle live. The bookkeeper works in Comarch Optima or Subiekt GT, because that's where invoices get booked, VAT gets settled and JPK gets filed. Both systems work fine — separately.
The problem shows up at the seam. Payroll is prepared in HR, but has to land in the books as a full set of postings against cost accounts and payables. Someone has to move it. In most companies we've seen, that someone is a human being. Manually. Every month. The same human types the same account numbers and the same amounts, just with different values each time.
This is not just wasted time. It is a source of errors that surface three months later, when someone checks payroll costs on a project and suddenly two thousand złoty don't reconcile. Then the investigation starts into who typed what where — and July's Excel doesn't remember who changed which amount.
A concrete example from our practice
At one of our clients — a 45-person meat processing plant in central Poland — HR worked in enova365 and bookkeeping in Comarch Optima. Every month the HR clerk generated payroll, printed the PDF, handed it to the bookkeeper, and the bookkeeper spent around 6 hours manually retyping 45 employees × several cost accounts into Optima. On top of that came ZUS (social security), PIT (income tax) and enforcement deductions — each as a separate posting.
On average, once a quarter an error of 500-2000 zł would appear, which then had to be reversed the following month.
After the integration, which we shipped in three weeks: the HR clerk still works in enova, but instead of a PDF she generates an export file (a JPK-KR-like accounting structure), which via middleware lands directly in Optima as ready-to-post entries — with the account, cost center and project split already applied. The bookkeeper sees a "document to approve" in Optima, checks it in 20-30 minutes and books it with one click. Retyping errors are gone entirely, because nobody retypes anything anymore.
The recovered 5-6 hours a month is not a revolution. But the 500-2000 zł quarterly error that disappeared — that is, because nobody was counting it as a cost of the process before.
What actually needs to be connected
An HR-payroll ↔ ERP integration usually isn't "one webhook". It's a package of four or five flows that need to be handled separately, because they have different cycles and different consumers.
- Booking the monthly payroll. Monthly, largest volume. Requires precise mapping: payroll item → cost account + cost center.
- Payments to employees. A bank file (Elixir or MT101) generated once a month. Usually the bank does this via ERP integration, but the payment amounts have to match the payroll.
- Social security and income tax settlements. Separate payments, separate accounts, different due dates. Must land in the ERP as dated liabilities, not as cost.
- Absences and time tracking. If the company allocates hours to projects, hours must flow from HR to the project module in the ERP — otherwise project profitability is fiction.
- Hires and terminations. A change in employee status (new hire, contract end) should flow immediately into the ERP and the modules that need to know (e.g. sales users in the CRM).
Each of these five flows can be tackled separately. We usually start with the first one — booking payroll — because that's where the largest time loss and the biggest error risk live.
How this actually works technically
There is no single "right" architecture. In practice, three approaches work in Polish SMEs.
- File export-import. HR generates a file (XML, CSV, JSON) that drops into an agreed folder. Middleware reads it every hour and pushes it into the ERP via API. Simple, cheap, sufficient for most companies up to 100 employees.
- Direct API. The HR system exposes an API (enova365 has for years, Comarch recently), so we connect them directly via a middleware layer. Faster, but requires watching API versions on both sides.
- Shared database. Rarely recommended, but happens when both systems sit on the same SQL Server instance. Then views and stored procedures are the simplest route. Watch out for updates — they'll break the integration overnight.
In each approach you need a middleware layer — even if it's just a PowerShell script. Don't connect systems "on the joint", because the first update on either side will snap the connection and you'll be wondering why payroll isn't landing.
What can go wrong
The most common mistakes we've seen with HR-ERP integrations:
- No account mapping. You start the project, the HR clerk says "I know how", and a month in it turns out that nobody knows which account "discretionary bonus" should go to. Result: the integration stalls until the bookkeeper and the board agree where to book bonuses. Map it on paper, before you write a line of code.
- Ignoring corrections. People get sick, log overtime after the fact, receive back-pay. The integration must handle corrections — otherwise every month you'll have manual patches that undo the point of automation.
- Sending data without approval. We once integrated a company so that data flowed from HR to the ERP automatically at night. The HR clerk once forgot to close the month — an incomplete payroll landed in the ERP. Since then we always add an "approve and send" step on the HR side. Automation without a human checkpoint is dangerous.
- No log. If something fails to transfer, you want to know what and when. Middleware should log every operation with an ID, timestamp and status. In an audit (and for the employee calling about a missing payment) that log saves your evening.
What next
HR-payroll ↔ ERP integration is not a technology project — it's an organizational project with a technical layer. The biggest challenge isn't writing the code; it's getting the bookkeeper and the HR clerk to agree on what goes where and in what shape. The code itself is usually 5-15 days of work.
If someone at your company still retypes payroll from one system to another every month — that is a real cost, just rarely counted. A few hours a month times the bookkeeper's rate, plus periodic errors and end-of-quarter stress. An integration project typically pays back in 4-6 months.
If you want to see what this would look like in your specific setup — which systems you have, where the real bottleneck sits — the first call is free and takes half an hour.
Retyping payroll by hand is not an IT problem. It's 6 hours a month and a 500-2000 zł quarterly error nobody counts as a cost of the process.