Tidvis
← Back to the blog
August 26, 2026 · TidvisAuto-translated from Swedish

Time reporting and payroll in the same system or separate payroll systems – what suits assistance companies best?

For most assistance companies, a unified flow is best when many shifts, deviations, unsocial hours (OB), absences, and approvals must be checked before payroll. A separate payroll system can work well when the time flow is simpler, the integration is stable, and there is clear responsibility for checking, importing, and correcting data.

For most assistance companies, a unified flow is best when many shifts, deviations, unsocial hours (OB), absences, and approvals must be checked before payroll. A separate payroll system can work well when the time flow is simpler, the integration is stable, and there is clear responsibility for checking, importing, and correcting data.

Short answer: choose based on how much time needs to be checked before payroll

Choose a unified system when a lot of time needs to be reviewed, approved, and adjusted before the payroll run starts.

In personal assistance, the payroll basis is rarely just "number of hours." It often consists of scheduled shifts, actual worked time, unsocial hours (OB), absences, expenses, changed shifts, corrections, and approvals. Tidvis, for example, describes a flow where time, OB supplements, absences, and expenses are automatically retrieved from time reporting, and where payroll can be run directly in the system without exporting files or entering data twice. This reduces the need for double registration and manual reconciliations.

A separate payroll system, on the other hand, is not wrong in itself. It can be sufficient when time reporting is simple, when few deviations occur, or when the company already has a well-functioning payroll process with clear integration. Visma HR+, for example, describes a setup where external systems can generate files with time reports or transactions that are read into the payroll process, or via API. Fortnox also describes a connection where worked time and deviations can be transferred with one click to the payroll program's calendar.

The practical question is therefore not just which payroll system is best. The question is where the control should take place: continuously in the schedule and time flow, during transfer to payroll, or only after import when errors are discovered.

What does “the same system” mean in practice?

The same system means that the schedule, time reporting, approval, and payroll basis are built on the same time data.

In a unified flow, the payroll basis starts already in the schedule. When shifts are planned, changed, reported, and approved, the information follows along. If the assistant reports an absence, if a shift receives OB, or if an expense is to be included in the payroll, it becomes part of the same chain. Tidvis describes its solution as a business system where scheduling, time reporting, payroll, and documentation are gathered in one system.

For the payroll administrator, this primarily means fewer handovers. Instead of first checking the schedule in one system, the time report in another, deviations in Excel, and the payroll import in a fourth, the control can be done closer to the source. This is particularly valuable when several supervisors, assistants, and customers are involved in the same payroll period.

However, the same system does not always have to mean that all payroll processing must take place in exactly the same module. Tidvis describes both built-in payroll processing and the possibility of full sync to Crona or payroll files to Hogia, SD Worx, Flex, and Kontek. The important thing is that time data is structured and checked before it becomes the payroll basis.

What does a separate payroll system with integration entail?

A separate payroll system means that time data is moved from a business system to the payroll process through integration or a file.

This can happen at several levels. An automatic integration can transfer information directly between systems. A file import requires a file to be created, exported, imported, and checked. A manual process means someone interprets the documentation and registers the information again. The further down that scale you end up, the greater the risk of double work and errors.

There is good support for separate flows when they are set up correctly. Fortnox describes that users can keep track of worked time and deviations and then transfer registrations directly to the payroll program's calendar. Visma HR+ describes reading external time reports and transactions via file or API, and that incorrect entries can be corrected in a correction view without creating a new corrected file.

The decisive factor is the division of responsibility. Who checks that all shifts are approved? Who catches incorrect OB? Who corrects imported transactions? Who ensures the correct file version is used? If the answers are clear, a separate payroll system can work. If the answers are unclear, control often ends up in Excel, email threads, and late manual corrections.

Why assistance companies have higher demands on the time flow

Assistance companies need time data for payroll, external reporting, and internal control.

Time reporting is not just an internal payroll issue. Assistance providers need to submit continuous time reporting for performed assistance, and documents must be received by Försäkringskassan no later than the 5th of the second month after the assistance was performed. Försäkringskassan's regulations also state that time reporting must be submitted per personal assistant on form FK3059 or via an approved e-service, and that employers or clients and assistants have roles for signature or certification in the time reporting.

This makes approval more than just an internal formality. The approval is a checkpoint before payroll proceeds and before time is used in external reporting. If a deviation is discovered after the payroll run, it can affect pay, customer documentation, and administration retrospectively.

Working hours regulations also make the time flow sensitive. Arbetsmiljöverket specifies, among other things, rules for 40 hours of ordinary working time per week, 200 hours of overtime per calendar year, 11 hours of daily rest, and 36 hours of weekly rest according to ATL (Swedish Working Hours Act, Arbetstidslagen). When shifts are swapped, extended, or reported late, the deviation therefore needs to be caught before it becomes both a payroll item and a labor law problem.

How OB, absence, and deviations affect the payroll run

OB, absence, and deviations should be handled as payroll-based parts of the same time flow.

In everyday assistance, a shift can change at short notice. An assistant gets sick, a substitute steps in, a shift goes past midnight, or an absence entry needs to be adjusted. If these events are in separate systems, the payroll administration must ensure that every change follows through all the way.

When time reporting and payroll are linked, control can happen earlier. Does the shift have the right time? Is the absence registered? Is the OB in the right period? Is the entry approved? Tidvis describes that OB, absence, and expenses are automatically retrieved from time reporting, which means these details can be treated as parts of the same payroll basis as worked time.

In a separate flow, corresponding control must often occur during integration, file import, or after import. This can work but requires clear routines. Visma HR+, for example, describes that imported entries can be incorrect and are handled in Correct transactions. It is good that the correction option exists, but it also shows that error handling is part of the process and needs to be owned by someone.

Risks with multiple systems – and how they can be reduced

Multiple systems increase the risk when the same time entry must be interpreted, moved, and checked several times.

The most common risks are double registration, file handling, parallel Excel checks, and unclear traceability. Tidvis describes the problem as many businesses needing to switch between several tools, while the goal is to avoid exporting files and entering data twice.

The risks become particularly clear near the payroll run. If an approval is missing, an absence is incorrectly coded, or an OB entry was not included in the import, the payroll administrator needs to know whether the error should be corrected in the time reporting, in the integration file, or directly in the payroll system. If the correction is only made in one place, the next reconciliation may show different truths.

For a separate setup to work, the company should therefore have fixed checkpoints: cutoff dates for approval, a person responsible for deviation control, logs of imports, routines for incorrect transactions, and clear rules for where corrections should be made.

Recommendation: choose based on complexity, not system labels

The best choice is the one that provides the least manual control and the clearest responsibility before the payroll run.

Choose a unified flow if you have many assistants, many short or changed shifts, recurring OB, absences, substitutes, several levels of approval, or recurring corrections. In these cases, the gain is often that the payroll basis is ready earlier and fewer people need to move information between systems.

Choose a separate payroll system if the payroll function is already highly standardized, the integration is tested, and there are functioning routines for import, control, and correction. This may be particularly reasonable if the organization already has an established payroll system that handles employer declarations and other payroll administration. As an employer, one also needs to report paid compensation, deducted tax, and employer contributions per reporting period, which makes a stable payroll process important regardless of system choice.

A simple rule of thumb: the more time that must be reviewed before payroll, the more it speaks for a unified system. The more standardized and integrated the flow already is, the better a separate payroll system can function.

References

Ready to see Tidvis?

Book a no-obligation demo. We'll show you the system tailored to your operation, with no sales pressure.