DAILY WAGEHired TodayPaid Today

Nyheder

Adgang til optjent løn for bemandings- og vikarvirksomheder: hvordan styrer man arbejdstimer på tværs af flere kunder?

For at implementere adgang til optjent løn i en bemandings- eller vikarvirksomhed skal hver medarbejder være præcist knyttet til den arbejdsgivende juridiske enhed, kunden, lokationen, kontrakten/opgaven, lønperioden og de godkendte arbejdstimer. Virksomheden skal fastlægge klart, hvilken kunde der registrerer arbejdstimer, hvem der har ret til at godkende, hvornår arbejdstimer bliver berettigede til at skabe en grænse, og hvilken part der håndterer udbetaling, payroll og afstemning. Når en medarbejder flyttes eller afslutter en opgave, skal retten til adgang til optjent løn ændre sig efter ikrafttrædelsesdatoen – ikke vente til slutningen af måneden.

> Bemærk: »Bemanding«, »HR-tjenester«, »outsourcing« og »arbejdsudleje« er ikke automatisk det samme juridiske forhold. Ansvarsomfang, arbejdsgiver og lønudbetalingsmekanisme skal fastlægges ud fra kontrakten og gældende lovgivning. Denne artikel er en generel forretnings- og teknisk ramme og erstatter ikke juridisk rådgivning for den enkelte model.

> Ordliste: adgang til optjent løn (at modtage løn efter allerede udførte arbejdsdage) · payroll (lønberegning) · assignment (opgave/tildeling hos kunden) · SLA (serviceniveauaftale) · HRIS (personaleinformationssystem) · ERP (virksomhedsressourceplanlægning) · cutoff (afskæringstidspunkt for en periode) · pilot (forsøgsimplementering) · UAT (brugeraccepttest) · KPI (nøgletal).

Hvorfor er en model med flere kunder mere kompleks end en enkelt fabrik?

I en almindelig produktionsvirksomhed hører medarbejderen, stempeluret, den godkendende leder og payroll typisk til samme organisatoriske system. I en bemandings- eller vikarvirksomhed kan en medarbejder:

  • indgå et ansættelsesforhold med én juridisk enhed, men arbejde på kundens lokation;

  • få tildelt vagter og få bekræftet sit fremmøde af kunden;

  • få arbejdstimer opgjort, løn beregnet og løn udbetalt af bemandingsvirksomheden;

  • blive flyttet mellem kunder eller lokationer inden for samme periode;

  • have flere forskellige tillæg, overarbejde eller bekræftelsesregler;

  • afslutte en opgave hos kunden uden at afslutte ansættelsesforholdet;

  • eller afslutte både opgaven og ansættelsesforholdet på to forskellige tidspunkter.

Adgang til optjent løn beregnes kun korrekt, når systemet forstår hele denne kontekst. Et korrekt medarbejder-id, der er koblet til den forkerte kunde, den forkerte opgave eller den forkerte periode, kan stadig skabe en forkert grænse.

1. Adskil forretningsmodellerne klart, før du integrerer

Bemanding/rekruttering af personale

En servicevirksomhed kan henvise til eller levere en kandidatpulje, som kunden selv indgår aftale med og forvalter ansættelsesforholdet for. I dette tilfælde er den part, der er ansvarlig for løn og adgang til optjent løn, måske ikke den enhed, der leverede kandidaterne.

Arbejdsudleje

Dette er en betinget aktivitet, der er reguleret af arbejdsretten. Det skal fastlægges korrekt, hvem der er udlejningsvirksomheden, indlejeren, den udlejede medarbejder, arbejdsomfanget, kontrakten og den enkelte parts ansvar.

Outsourcing af tjenester med brug af arbejdskraft

Kunden køber et resultat eller en ydelse; leverandøren organiserer udførelsen. Måden at forvalte, registrere arbejdstimer og udbetale løn på afhænger af serviceaftalen og det faktiske ansættelsesforhold.

Hvorfor er klassificeringen vigtig for adgang til optjent løn?

Den afgør:

  • hvem der er arbejdsgiver;

  • hvem der fastsætter og udbetaler lønnen;

  • hvem der har pålidelige data om arbejdstimer;

  • hvem der har ret til at godkende;

  • hvem der stiller midlerne til rådighed;

  • hvem transaktionen afregnes med;

  • hvem der er dataansvarlig eller databehandler ud fra den faktiske rolle;

  • hvem der håndterer klager og tvister.

Man bør ikke bruge én enkelt proces for adgang til optjent løn til alle kontrakter, blot fordi medarbejderne i alle tilfælde arbejder hos en kunde.

2. Dataarkitektur med flere parter

(Data- og integrationskrav: se Integration af adgang til optjent løn med tidsregistrering, payroll og ERP.)

Diagram over adgang til optjent løn for en bemandingsvirksomhed med medarbejdere, der arbejder hos flere kunder
flowchart TD
    A["HRIS hos bemandingsvirksomheden"] --> E["Standardiseret datalag"]
    B["Vagtplan og arbejdstimer hos kunden"] --> E
    C["Bekræftelse fra supervisor"] --> E
    D["Payroll og kontrakter"] --> E
    E --> F["Motor til grænser for adgang til optjent løn"]
    F --> G["Udbetaling"]
    G --> H["Afstemning af payroll, ERP og kunde"]

Princippet om én standardkilde for hvert domæne

Datadomæne

Anbefalet standardkilde

Bemærkning

Identitet og ansættelsesstatus

Bemandingsvirksomhedens HRIS

Hent ikke status fra en enkeltstående fremmødeliste

Kunde/opgave/lokation

Kontrakt- og dispositionssystem

Med ikrafttrædelsesdato

Vagtplan

Systemet hos kunden eller dispositionen

Endnu ikke faktiske arbejdstimer

Faktiske arbejdstimer

Tidsregistrering på arbejdsstedet

Undtagelser skal håndteres

Berettigede arbejdstimer

Godkendelsesworkflow for arbejdstimer

Fastlæg godkendelsesniveauet klart

Lønperiode og lønregler

Payroll

Kortlagt efter juridisk enhed/lønkategori

Transaktion for tidlig udbetaling

Platform for adgang til optjent løn

Med eget id og egen status

Overførselsresultat

Betalingspartner

Er den endelige kilde til udbetalingsstatus

Afstemning

Payroll/ERP og relaterede bilag

Ikke kun sammenligning af totalbeløb

3. Datamodellen »medarbejder – opgave – kunde – lønperiode«

Datamodel til styring af medarbejdere og tildelinger hos kunder for adgang til optjent løn

employee_id alene er ikke nok. En person kan have flere tildelinger i samme periode.

De vigtige nøgler

  • employee_id: medarbejderens id;

  • employerid eller legalentity_id: den juridiske enhed, der indgår ansættelsesforholdet;

  • client_id: kunden;

  • site_id: arbejdslokationen;

  • assignment_id: den konkrete opgave/tildeling;

  • contract_id: serviceaftalen eller en nødvendig reference;

  • payroll_group: gruppen af lønregler/lønperiode;

  • payperiodid: lønperioden;

  • effectivefrom, effectiveto: ikrafttrædelsesdatoer;

  • transaction_id: transaktionen for adgang til optjent løn;

  • payment_reference: betalingsreferencen.

Hvorfor er `assignment_id` vigtig?

Hvis en medarbejder arbejder 10 dage hos Kunde A og 12 dage hos Kunde B, skal systemet vide, hvilken opgave hver enkelt post over arbejdstimer tilhører, hvem der har godkendt den, og hvilke regler der gælder. Man bør ikke blot beholde den aktuelle kunde på medarbejderens profil og overskrive historikken.

Eksempel på tildelingsdata

{
  "employee_id": "EMP-000123",
  "employer_id": "NK-DEMO",
  "client_id": "CLIENT-DEMO-B",
  "site_id": "SITE-B02",
  "assignment_id": "ASN-2026-00871",
  "payroll_group": "MONTHLY-B",
  "effective_from": "2026-08-12",
  "effective_to": null,
  "status": "ACTIVE",
  "record_version": 3
}

Dette er fiktive illustrationsdata og ikke den officielle API-struktur for adgang til optjent løn.

4. Hvem registrerer arbejdstimer, og hvem godkender dem?

Proces hvor kunden bekræfter og bemandingsvirksomheden godkender arbejdstimer for adgang til optjent løn

(Grundbegreb: se Hvad er godkendte arbejdstimer?.)

Tre roller kan være forskellige:

  1. Den, der registrerer: stempeluret, appen, timesedlen eller supervisoren på stedet.

  2. Den, der bekræfter fremmøde/opgave: teamlederen eller lederen hos kunden.

  3. Den, der godkender til lønberegning: en bemyndiget person i bemandingsvirksomheden i henhold til processen.

Fire almindelige godkendelsesmodeller

Model

Flow

Fordel

Kontrolpunkt

Kunden godkender direkte

Tidsregistrering → lederen hos kunden godkender

Hurtig, tæt på virkeligheden

Rettigheder, oplæring, dataomfang

Kunden bekræfter, virksomheden godkender

Kunden bekræfter → supervisor i bemandingen godkender

Adskilt ansvar

Kan øge forsinkelsen

Virksomheden godkender ud fra dokumentation

System/rapport → HR/supervisor godkender

Central kontrol

Kræver pålidelige data på stedet

Automatisk godkendelse efter regler

Rene data → automatisk; undtagelser → menneskelig godkender

Kan skaleres

Kræver gode regler og kvalitetsovervågning

Adgang til optjent løn skal bruge netop den status, som politikken har godkendt. »Kunden har set det« er ikke automatisk det samme som »arbejdstimer godkendt til udbetaling«.

5. SLA for godkendelse af arbejdstimer skal designes sammen med kunden

Hvis kunden bekræfter arbejdstimer for sent, ser medarbejderen ingen grænse, selv om platformen fungerer normalt. Derfor skal SLA for godkendelse af arbejdstimer være en del af den fælles proces – ikke kun et internt HR-anliggende.

Foreslået KPI

Andel af arbejdstimer godkendt til tiden (%) = Poster godkendt før deadline ÷ Samlet antal poster til godkendelse × 100%

Følg den op efter:

  • kunde;

  • lokation;

  • vagt;

  • godkender;

  • type af undtagelse;

  • alder på ikke-godkendte arbejdstimer;

  • årsag til forsinkelse.

Man bør ikke kun rapportere én samlet andel for hele systemet. En langsom kunde kan blive skjult af mange kunder, der godkender godt.

Mekanismer til påmindelse og eskalering

  • påmindelser før og efter deadline;

  • en liste over undtagelser, der skal håndteres;

  • stedfortrædende bemyndigelse, når en godkender er fraværende;

  • eskalering efter postens alder;

  • advarsel, når en arbejdslokation mangler data;

  • rapportering til kontaktpersonen hos kunden og i virksomheden;

  • registrering af årsagen ved sen godkendelse.

6. Hvilke felter kræver arbejdstimer hos kunden?

Felt

Betydning

`employee_id`

Medarbejderen

`assignment_id`

Den gældende tildeling

`client_id`, `site_id`

Kunde og lokation

`work_date`, `shift_id`

Arbejdsdag og vagt

`regular_minutes`

Berettigede normaltimer

`overtime_minutes`

Overarbejde efter status

`attendance_status`

Til stede, fravær, manglende timer m.m.

`approval_status`

Afventer, bekræftet, godkendt, afvist, justeret, låst

`confirmed_by`, `confirmed_at`

Bekræftelse hos kunden

`approved_by`, `approved_at`

Godkendelse med payroll-bemyndigelse

`source_system`

Det system, hvor det opstod

`record_version`, `source_updated_at`

Sporing af ændringer

Hvis kunden sender en fil, skal der desuden være batch_id, antal poster, checksum, oprettelsestidspunkt og filversion.

7. Omflytning mellem kunder i samme periode

Dette er en situation, hvor der let opstår dobbelte eller manglende arbejdstimer.

Den proces, der bør være på plads

  1. afslut den gamle tildeling med en ikrafttrædelsesdato/-tid;

  2. åbn den nye tildeling;

  3. kontrollér, at der ikke er en regelstridig overlapning;

  4. bekræft de arbejdstimer, der stadig er udestående hos den gamle kunde;

  5. fastlæg den nye payroll-gruppe og politik for adgang til optjent løn;

  6. genberegn grænsen, hvis reglerne ændrer sig;

  7. underret medarbejderen, hvis grænsen påvirkes;

  8. tildel forvaltnings-/godkendelsesrettigheder efter den nye lokation;

  9. afstem allerede opståede transaktioner med den korrekte lønperiode.

Overskriv ikke den gamle kunde

Profilen skal have en historik over assignmentid. Hvis man kun ændrer den aktuelle clientid, kan tidligere rapporter tilskrive den nye kunde alle arbejdstimer og transaktioner.

8. At afslutte en opgave er ikke det samme som at fratræde

Tjekliste for håndtering af adgang til optjent løn, når en medarbejder flyttes eller afslutter en opgave

En person kan afslutte hos Kunde A, men afvente omflytning til Kunde B, eller fratræde helt.

Virksomheden skal have mindst to uafhængige statusser:

  • status for ansættelsesforholdet;

  • status for tildelingen/opgaven.

Vejledende håndteringsmatrix

Ansættelsesstatus

Opgavestatus

Håndtering af adgang til optjent løn til overvejelse

I ansættelse

Aktiv

Anvend normal politik

I ansættelse

Afsluttet, afventer omflytning

Vurdér grænsen midlertidigt ud fra godkendte data og politik

Suspenderet/på orlov

Har en gammel opgave

Slut ikke, at berettigelsen består; håndtér efter reglementet

Fratrådt

Har stadig en tildeling pga. forsinkede data

Stop efter ikrafttrædelsesdato, opret en datasag

I ansættelse

Flere gyldige tildelinger

Beregn korrekt fra hver kilde og undgå dobbelte arbejdstimer

De officielle regler skal godkendes af HR, Payroll og juridisk afdeling. Man bør ikke automatisk låse eller åbne alene på grundlag af én kundefil.

9. Flere lønperioder og politikker på tværs af flere kunder

Bemandingsvirksomheden kan udbetale løn efter samme periode, men kundedata afskæres på forskellige datoer. Nogle kunder har egne tillæg, overarbejde, fremmødebonus eller afrundingsregler.

Konfigurationstabel, der skal versionsstyres

Egenskab

Omfang

`pay_period_id`

Juridisk enhed/lønkategori

`client_cutoff`

Kunde/lokation

status for berettigede arbejdstimer

Kunde/politik

indkomstposter, der medregnes

Payroll-gruppe

sats/loft for grænsen

Program/berettiget gruppe

tidspunkt for låsning af adgang til optjent løn

Lønperiode

regler for håndtering af sent rettede arbejdstimer

Kontrakt/proces

Man bør ikke hardkode politikker efter kundenavn i kildekoden. Konfigurationen skal have ikrafttrædelsesdato, godkender og ændringshistorik.

10. Overarbejde og variable indkomstposter

Overarbejde hos kunden kan gå gennem flere trin: registrering, udførelse, kundens bekræftelse, virksomhedens godkendelse og payroll-låsning.

Poster som vagttillæg, fremmøde, produktion eller bonus fastlægges måske først ved periodens slutning. Virksomheden skal klassificere:

  • den del, der er sikker og godkendt;

  • den del, der er foreløbig beregnet, men kan blive justeret;

  • den del, der først fastlægges ved periodens slutning;

  • den del, der ikke indgår i adgang til optjent løn.

Hvis en variabel post medregnes i grænsen, kræver det en bufferordning, versionering og en forklaring til medarbejderen. Man bør ikke bruge forventet omsætning fra kunden som direkte grundlag for den enkelte medarbejders ret til løn.

11. Ansvar, når kunden retter arbejdstimer for sent

Arbejdstimer kan blive rettet, efter at adgang til optjent løn allerede har genereret en transaktion. Processen skal besvare:

  1. inden for hvilket tidsrum kunden må rette;

  2. hvem der godkender ændringen;

  3. om værdien før/efter gemmes;

  4. hvilke transaktioner der bruger den gamle version;

  5. hvordan den aktuelle grænse genberegnes;

  6. i hvilken periode differencen håndteres;

  7. hvem der kontakter medarbejderen;

  8. hvordan kunde og virksomhed afstemmer;

  9. hvordan en gentagen fejl udbedres.

Man bør ikke slette den gamle post. Der skal være en justeringshændelse eller en version, så grænsen på transaktionstidspunktet kan genskabes.

12. Finansieringskilde og pengestrøm i en model med flere parter

Før implementeringen skal det fastlægges:

  • hvilken part der overfører penge til medarbejderen;

  • hvem kildekontoen tilhører;

  • hvornår transaktionen betragtes som en forpligtelse mellem parterne;

  • hvornår bemandingsvirksomheden og kunden afregner;

  • hvilken part der bærer gebyrerne;

  • hvordan mislykkede, uafklarede eller tilbagebetalte transaktioner håndteres;

  • hvordan medarbejderens rettigheder og parternes forpligtelser ser ud, når kunden betaler for sent;

  • hvilken kontrakt tilgodehavender og bogføringsposter afspejler.

Adgang til optjent løn bør ikke designes ud fra en antagelse om, at kunden med sikkerhed betaler til tiden, hvis kontrakten og den faktiske pengestrøm ikke garanterer det. Finansafdelingen skal opstille pengestrømsscenarier og fastsætte grænser for programmet.

13. Femvejsafstemning

Afstemning af arbejdstimer, adgang til optjent løn, udbetaling, payroll, ERP og kundedokumentation"

(Detaljer om afstemning: se Afstemning af transaktioner for adgang til optjent løn med payroll og regnskab.)

I en model med flere kunder kan afstemning kræve fem veje:

  1. bekræftede/godkendte arbejdstimer;

  2. grænse og transaktioner for adgang til optjent løn;

  3. udbetalingsresultatet;

  4. payroll/ERP;

  5. dokumentation for bekræftelse/afregning med kunden, hvor det er relevant.

flowchart TD
    A["Kundens arbejdstimer"] --> F["Afstemning"]
    B["Transaktion for adgang til optjent løn"] --> F
    C["Udbetalingsresultat"] --> F
    D["Payroll og ERP"] --> F
    E["Kundedokumentation"] --> F
    F --> G["Match eller afvigelsessag"]

Almindelige afvigelser

  • kunden har bekræftet, men virksomheden har ikke godkendt;

  • arbejdstimer på den forkerte assignment_id;

  • en person, der er flyttet, har stadig arbejdstimer på den gamle lokation;

  • adgang til optjent løn lykkedes, men mangler i payroll;

  • betalingen lykkedes, men adgang til optjent løn har ikke modtaget callback;

  • transaktionen er bogført på den forkerte juridiske enhed eller periode;

  • kunden har rettet arbejdstimer efter cutoff;

  • totalen pr. kunde stemmer, men er forkert pr. medarbejder;

  • gebyr eller afregningspost er knyttet til den forkerte kontrakt.

14. Giv kunden adgang uden at afsløre unødvendige data

(Sikkerhedsramme: se Datasikkerhed og privatliv ved implementering af adgang til optjent løn.)

Brugere hos kunden bør kun se de medarbejdere og data, der ligger inden for det, de skal bekræfte. Man bør ikke som standard lade kunden se:

  • hele historikken over tidlige udbetalinger;

  • den enkeltes transaktionsbeløb;

  • data fra andre kunder;

  • fuldstændige bankkontooplysninger;

  • lønbilag uden for ansvarsområdet;

  • detaljerede svindeladvarsler;

  • personaledata, der ikke er nødvendige for tidsregistrering.

Adgangskontrol

  • tildel rettigheder efter clientid, siteid og rolle;

  • rettigheder skal have en udløbsdato;

  • gennemgå ved ændring af kontrakt eller kontaktperson;

  • MFA for godkendere;

  • brug ikke fælles konti;

  • log visning, redigering, godkendelse og eksport af data;

  • separat godkendelse ved masseudtræk af data;

  • underret og tilbagekald straks, når en bruger hos kunden fratræder/skifter job.

15. Trepartssupport

Medarbejderen bør ikke selv skulle gætte, om fejlen ligger hos kunden, bemandingsvirksomheden eller udbyderen af adgang til optjent løn.

Fordeling efter problemtype

Problem

Primær kontakt

Samarbejdspart

Manglende/for få arbejdstimer

Supervisor/HR Operations

Kunden

Forkert tildeling/lokation

Disposition/HRIS

Kunden

Ser ingen grænse

Operations for adgang til optjent løn

HR/Payroll/IT

Transaktion under behandling

Support for adgang til optjent løn/betaling

Betalingspartner

Forkert afregning af lønperiode

Payroll

Adgang til optjent løn/Finance

Mistanke om kontokapring

Security/Risk

Adgang til optjent løn/betaling/HR

Klage over politik

HR/Juridisk

Udbyder/kunde, hvor det er relevant

En sag skal have ét gennemgående id og en status, som medarbejderen kan følge. Man bør ikke bede dem starte forfra med hver enkelt part.

16. KPI'er for en bemandingsvirksomhed

Ledende KPI'er

  • andel af medarbejdere med en gyldig tildeling;

  • andel af arbejdstimer, kunden sender til tiden;

  • andel af arbejdstimer godkendt til tiden;

  • gennemsnitlig/median alder på arbejdstimer, der afventer godkendelse;

  • andel af tildelingsændringer, der opdateres til tiden;

  • aktualitet af grænsedata.

KPI'er for oplevelse og drift

  • aktiveringsrate pr. kunde;

  • andel af vellykkede transaktioner;

  • tid til modtagelse af penge;

  • sager pr. 1.000 transaktioner;

  • andel af automatisk behandling;

  • andel af automatisk afstemning;

  • afvigelser pr. kunde/årsag;

  • justering af arbejdstimer efter cutoff.

KPI'er for personale og forretning

  • tiltrædelses- og fremmøderate i den tidlige fase;

  • fratrædelse pr. kohorte;

  • opfyldelsesgrad for bemanding;

  • manuelle forskudsanmodninger;

  • niveau af kendskab og tilfredshed;

  • driftsvolumen pr. kunde.

Man bør ikke konkludere, at adgang til optjent løn har forårsaget en personaleændring, alene ud fra en før/efter-sammenligning. Man skal se på sæson, ordrer, lønniveau, ledelse, lokation og andre politikker.

17. Hvilken kunde bør man vælge til piloten?

(Standardforløb: se 90-dages pilotplan for adgang til optjent løn for virksomheder.)

En egnet pilotkunde har typisk:

  • et klart behov og tydelig opbakning;

  • en kontaktperson med bemyndigelse;

  • forholdsvis stabile data om arbejdstimer;

  • repræsentative vagt- og overarbejdsprocesser;

  • nok personer/transaktioner til at teste;

  • vilje til at godkende arbejdstimer til tiden;

  • samarbejde om kommunikation og support;

  • ingen samtidig udskiftning af et stort tidsregistreringssystem.

Man bør ikke vælge en kunde alene på grund af en god relation, hvis deres processer er for forskellige fra resten.

Det piloten bør dække

  • én runde af onboarding/aktivering;

  • normale vagter, overarbejde og undtagelsestimer;

  • omflytning eller afslutning af en tildeling;

  • vellykkede, mislykkede, uafklarede og tilbagebetalte transaktioner;

  • daglig afstemning;

  • én komplet lønperiode;

  • kundens bekræftelse/afregning, hvis det er inden for omfanget;

  • klager og hændelser.

18. UAT-tjekliste for flere kunder

Medarbejder og tildeling

  • [ ] En person med én aktiv tildeling.

  • [ ] En person med to gyldige tildelinger i perioden.

  • [ ] Omflytning mellem kunder.

  • [ ] Afslutning af en opgave uden fratrædelse.

  • [ ] Fratrædelse, hvor kundefilen stadig indeholder arbejdstimer.

  • [ ] Forkert juridisk enhed eller kundeid.

Arbejdstimer og godkendelse

  • [ ] Kunden sender arbejdstimer til tiden.

  • [ ] Arbejdstimer, der afventer bekræftelse, og arbejdstimer, der er godkendt.

  • [ ] Afviste arbejdstimer.

  • [ ] Arbejdstimer rettet efter godkendelse.

  • [ ] Dobbelte, manglende eller fejlrækkefølgede filer.

  • [ ] En godkender er fraværende, og der er en stedfortræder.

Grænse og transaktion

  • [ ] Kun berettigede data skaber en grænse.

  • [ ] En tildelingsændring træder i kraft på den korrekte dato.

  • [ ] Genfremsendelse med samme nøgle skaber ikke en dobbelt transaktion.

  • [ ] En timeout skaber en uafklaret status.

  • [ ] En tilbagebetalt transaktion håndteres korrekt.

Payroll og afstemning

  • [ ] Transaktionen bogføres på den rette person, juridiske enhed, kunde og periode.

  • [ ] Payroll blokerer en dobbelt transaktion.

  • [ ] Afstemning pr. transaktion, ikke kun total.

  • [ ] En afvigelse skaber en sag med en ejer.

  • [ ] En justering har værdi før/efter og en godkendelse.

Rettigheder og sikkerhed

  • [ ] En bruger hos kunden ser kun sit eget omfang.

  • [ ] Kunden ser ikke unødvendig personlig historik for adgang til optjent løn.

  • [ ] Rettigheder udløber og tilbagekaldes korrekt.

  • [ ] Dataeksport logges.

  • [ ] Scenarier for lækket fil eller kontokapring afprøves.

19. Juridisk ramme, der skal tages i betragtning

Arbejdsloven nr. 45/2019/QH14 trådte i kraft den 1. januar 2021. Dekret 145/2020/NĐ-CP trådte i kraft den 1. februar 2021 og fastsætter detaljer og retningslinjer for en række bestemmelser i arbejdsloven om arbejdsvilkår og arbejdsforhold, herunder indhold om arbejdsudleje.

Virksomheden skal fastlægge den korrekte juridiske model, driftsbetingelserne, parternes rettigheder og forpligtelser, ansvaret for lønudbetaling og de gældende bilag. Man bør ikke bruge udtrykket »bemanding« som erstatning for at klassificere det faktiske forhold.

Med hensyn til data trådte loven om beskyttelse af personoplysninger nr. 91/2025/QH15 og dekret 356/2025/NĐ-CP i kraft den 1. januar 2026. Deling af data mellem bemandingsvirksomheden, kunden, udbyderen af adgang til optjent løn og betalingspartneren skal gennemgås efter rolle, formål, omfang og de faktiske beskyttelsesforanstaltninger.

Konkrete juridiske konklusioner om produkt, forskud, afregning og fradrag skal bygge på kontrakten, reglementet og den faktiske pengestrøm og ikke udledes alene af betegnelsen adgang til optjent løn.

Konklusion

Adgang til optjent løn har et stort potentiale i bemandings- og vikarvirksomheder, fordi den imødekommer behovet hos en spredt arbejdsstyrke og hjælper med at digitalisere forskud. Men kompleksiteten er også større: data om arbejdstimer opstår hos kunden, payroll ligger hos bemandingsvirksomheden, transaktionen går gennem udbyderen af adgang til optjent løn, og udbetalingen skal kobles sammen på en ensartet måde.

Betingelsen for succes er korrekt styring af modellen medarbejder – tildeling – kunde – lønperiode, godkendelse af arbejdstimer til tiden, adskillelse af opgaveafslutning fra fratrædelse, minimal rettighedstildeling og afstemning helt ned til den enkelte transaktion. Læs mere om adgang til optjent løn for virksomheder for at drøfte modellen for adgang til optjent løn for en arbejdsstyrke, der arbejder hos flere kunder og lokationer.

Kilder

---

Forfatter: Nguyen Minh Khang — Specialist i strategiafdelingen, Nhan Kiet Manpower Supply Co., Ltd.

Rådgivning om adgang til optjent løn for virksomheder: Hotline 0937.022.655 · E-mail info@nhankiet.vn · Adgang til optjent løn for virksomheder

FAQ

Er det kunden eller bemandingsvirksomheden, der godkender arbejdstimer til adgang til optjent løn?

Det afhænger af modellen og processen. Kunden kan bekræfte fremmødet, mens bemandingsvirksomheden godkender de berettigede data til payroll. RACI og status skal fremgå tydeligt.

Kan en medarbejder, der skifter kunde midt i måneden, fortsat bruge adgang til optjent løn?

Ja, hvis ansættelsesforholdet og programbetingelserne stadig er gyldige, men systemet skal lukke den gamle tildeling, åbne den nye efter ikrafttrædelsesdato og genberegne grænsen efter den korrekte politik.

Er det at afslutte en opgave hos kunden det samme som at fratræde?

Ikke nødvendigvis. Man skal adskille opgavestatus og status for ansættelsesforholdet. Derfor bør man ikke låse adgang til optjent løn alene ud fra en liste over dem, der forlader kundens lokation.

Skaber arbejdstimer, kunden endnu ikke har bekræftet, en grænse?

Det afhænger af politikken, men ubekræftede data indebærer risiko for ændring. Berettigelsesstatus skal aftales i driftskontrakten og payroll-processen.

Må kunden se en medarbejders historik over tidlige udbetalinger?

Ikke som standard. Der leveres kun de data, der er nødvendige for opgaven, og efter korrekt bemyndigelse. Personlige transaktionsdata skal rettighedsstyres og beskyttes.

Hvad sker der, hvis kunden retter arbejdstimer, efter at medarbejderen har foretaget en transaktion?

Systemet skal bevare versionen, genberegne konsekvensen, oprette en afvigelsessag og håndtere det efter den godkendte politik. Man må ikke slette sporet eller selv udlede medarbejderens forpligtelse.

Kan man bruge én konfiguration for adgang til optjent løn til alle kunder?

Det bør man ikke, hvis kunderne er forskellige med hensyn til vagter, cutoff, godkendelsesstatus, indkomstposter og ansvar. Brug hellere en versioneret konfiguration pr. politikgruppe end at skrive særlig, svært kontrollerbar logik for hvert sted.

Nyheder

Read more articles