Retyping hours into payroll: how to connect it to Nmbrs

Short answer. You do not have to retype worked hours into Nmbrs by hand every month. You connect your time tracking through a direct integration or a custom building block that pulls in the hours, converts them into the right payroll format and stages them for processing. That way the numbers add up, with less manual work and fewer mistakes.

The same ritual dance every month. Someone exports the worked hours from the scheduling or time tracking system, pastes them into Excel, adds up overtime and allowances and retypes the result line by line into payroll. That is exactly the kind of process I keep running into in practice, and it is exactly the kind of process I redesign.

Why this retyping keeps going wrong

Moving data from one system to another by hand is error-prone by definition. A shifted row, a forgotten allowance, a typo in a number of hours. The difference only shows up when an employee checks their payslip, and by then you are already a correction and a lot of irritation further along. Nmbrs itself counts the manual processing of hours, overtime and irregularity allowances among the time-consuming payroll processes you can automate.

But the real goal is not just saving time. The goal is control. Numbers that add up because they were not retyped through human hands. A payroll run you trust without anyone having to run spot checks afterwards. Less manual work is the pleasant side effect of that, not the whole story.

Review the process first, then build

Before I build a single connection, I lay out the entire journey from clock to payslip in front of me. Because much of what happens manually right now grew that way and only still exists because it was always done like that.

A few questions I ask as standard:

• Which hour types actually go into payroll? Regular, overtime, leave, allowances. And which of those calculations is someone doing by hand right now while the system can do it too?
• Are hours "cleaned up" in Excel first before they go into the payroll system? That is usually a step you can drop by setting up the source better.
• How many corrections happen after the fact each month, and where do they come from?

It regularly turns out that half of the manual work disappears as soon as you clean up the process. That is a deliberate step, not a reason to build nothing. It makes sure I build the right solution later instead of automating a messy process that stays messy.

The connection that actually fits your situation

For many standard situations there is an off-the-shelf connection. Time tracking packages like Keeping, Werktijden.nl, Dyflexis and Yoobi have a direct integration with Nmbrs that lets you push worked hours through in a few clicks. If that fits your situation, it is often the smartest starting point and I will just say so.

In practice, though, things are far from always standard. I regularly see situations where a standard connection does not cut it:

• Hours come from an in-house system, an industry-specific package or a combination of sources for which no off-the-shelf Nmbrs connection exists.
• The conversion into payroll components is full of company-specific or collective-agreement rules that a standard integration does not know.
• You work with multiple administrations or entities and have to consolidate hours before they enter the payroll run.

That is where I build the solution. A workflow that pulls the hours from the source, applies the logic that applies to you, converts the result into the import format Nmbrs expects and stages the batch, often through the Nmbrs API or a controlled import. With validation and a log alongside it, so you can see afterwards what was processed and why. That distinction between buying what fits and building what is missing is exactly where the gains are.