Exporting Absence Data to Payroll: Why Mapped CSVs Win

On the last working day of every month, somewhere, an accountant emails a founder: who was out in July, and with what? And the founder rebuilds the month from memory. Scrolling Slack for "feeling awful, taking today off". Squinting at a wall planner that stopped being true around the 10th. Payroll is the one HR deadline with someone's salary on the other end: get a sick-leave date wrong and you're not fixing a typo, you're running a corrected payroll and amending social-insurance filings.

Strip away the ceremony and payroll needs three columns per person. What kind of absence, in the codes the payroll system uses. How many days of it. And only the days that fall inside the month. Not the request as the employee filed it, and not the reason they gave, because payroll has no business knowing the reason. Type, days, boundaries respected. That's the whole handoff.

The integration you're imagining doesn't exist

When the monthly rebuild gets annoying enough, the instinct is to go looking for an integration: surely the leave tool can talk to the payroll system directly. Here's what that instinct runs into, using Poland as the worked case because it's ours. Polish payroll runs on enova365, Symfonia, or Comarch Optima. In a company of 30, the person driving that software usually isn't your employee. It's an external accounting office, running their own installation, on their own license, with API access that depends on which version and modules they happen to have bought. You don't get to plumb a webhook into that. What every one of these systems does have, in every version, at every accounting office, is import from a spreadsheet.

So below roughly 150 people, the file is the API. An integration is something you maintain: credentials, version drift at the accounting office, a rebuild when they switch vendors. A mapped CSV is something you generate. If you run payroll in-house, or your payroll bureau ingests machine feeds because you're 500 heads and growing, ignore this post and build the real pipe. Everyone else is better served by a boring file that is correct.

The catch is that "correct" is doing a lot of work in that sentence.

The two ways the hand-built file lies

The first is the month boundary. Marta books vacation from 28 July to 7 August 2026. One request, two payrolls: July should be charged four working days (Tuesday the 28th through Friday the 31st) and August five. A spreadsheet built from requests, rather than dates, charges all nine to whichever month the request got filed in. The same trap runs the other way: Adam calls in sick on 30 June and comes back on the 4th of July. One day of that belongs to June's payroll and three to July's. If your export can't split a single absence across two months, then someone is quietly reconciling this by hand every cutoff, or nobody is and you find out during an audit of a correction run.

Half days make it worse. A half-day Friday is 0.5 in the export, and a "week off" for someone on a four-day schedule is 4 days, not 5. Per-date counting against each person's actual working pattern is the only arithmetic that survives contact with real teams.

The second failure is code drift. Your leave tool says Vacation; the payroll configuration says UW. Sick leave is ZLA. That mapping is five lines long and perfectly stable, right up until someone adds a "Conference" leave type, nobody maps it, and it either rides along silently as vacation or vanishes from payroll entirely. The mapping has to be written down, and it has to live where the export happens, not in the head of whoever set it up.

The playbook, whatever tool you use

Count per date, not per request, so absences split cleanly at month boundaries. Export approved absences only, and settle the stragglers before you export, because a pending request is invisible to the file. Keep the type-to-code mapping in a written table next to the export routine. And re-run the previous month at every cutoff: late sick notes are a fact of life, and comparing last month's file against what you actually sent is how a correction becomes a line item instead of a surprise.

None of this needs particular software. It needs the arithmetic done per date and the mapping kept honest, every month, including the month the person doing it is on vacation themselves.

Where SquadBear keeps this

SquadBear counts leave per date against each person's own schedule, so the boundary problem never exists in the data: Marta's request is stored as its individual days, and July's report simply doesn't include the August ones. Reports → Leave → Absence has the absence summary with a last-month preset and a CSV button, approved absences only, half days as 0.5. Each leave type carries a short code, visible under Workspace settings → Leave policies, which leaves the payroll mapping as the only manual step. A connected agent can hold that too:

"Pull approved absences for last month for the whole company and give me CSV text I can save as a file: one row per person per leave type, columns employee, code, days. Map Vacation to UW, Sick leave to ZLA, Unpaid leave to NB, and flag anyone whose rows don't add up to their total."

The payroll export guide walks through the full monthly handoff, including a per-absence date-range variant for sick-leave documentation.

Start free and pull your first month in an afternoon, or poke at the numbers in the demo workspace first.

Related reading: accrued PTO is a debt your accountant wants a number for, and what actually happens when you run HR through an AI assistant.