Processen for adgang til optjent løn: fra tidsregistrering til modtagelse og afstemning

Processen for adgang til optjent løn begynder, når arbejdstiden registreres, og en leder godkender den. Systemet synkroniserer dataene, beregner den berettigede del af den allerede optjente løn, lader medarbejderen indsende en anmodning, udfører udbetalingen og afstemmer den derefter ind i lønperioden. Hver transaktion har brug for en identifikator, en status og en komplet log for at undgå overbetaling, dobbeltbetaling, forkert løn eller vanskeligheder, når arbejdet justeres.

Adgang til optjent løn er Nhan Kiets navn for dets Earned Wage Access (EWA)-løsning, som hjælper en medarbejder med at få adgang til en del af den løn, der svarer til allerede udført arbejde, før den sædvanlige lønningsdag. Dette er ikke en måde at udbetale hele lønnen efter hver arbejdsdag; virksomhedens beregnings- og betalingscyklusser opretholdes i henhold til den gældende politik (se yderligere sondringer i Hvordan adskiller et traditionelt lønforskud sig fra EWA?).

Samlet diagram over processen for adgang til optjent løn

Den centrale driftslivscyklus har syv trin:

1. Registrér arbejde.

2. Lederen bekræfter arbejdet.

3. Synkronisér data.

4. Beregn den berettigede allerede optjente løn.

5. Medarbejderen indsender en anmodning om penge.

6. Autentificér og udbetal.

7. Afstem ind i lønperioden.

Hvis onboarding-fasen medregnes, kan den fulde proces beskrives således:

Registrering/eKYC → Bekræftelse af vilkår eller e-underskrift → Tidsregistrering → Arbejdsgodkendelse → Beregning af grænse → Anmodning om penge → Udbetaling → Afstemning → Lønseddel.

Disse to proceslag er ikke i modstrid. De syv trin er den driftslivscyklus, der gentages hver periode; registrering og bekræftelse af vilkår er det forberedende trin, før medarbejderen foretager sin første transaktion.

Trin 0. Registrering, autentificering og fastlæggelse af brugsrettigheder

Før adgang til optjent løn kan bruges, skal medarbejderens profil matches korrekt med virksomhedens data. Som minimum skal følgende fastlægges:

• En unik medarbejderkode.

• Den virksomhed eller enhed, der aktuelt beskæftiger vedkommende.

• En gyldig, aktiv status for ansættelsesforholdet.

• Et verificeret telefonnummer eller en loginkonto.

• En modtagerkonto, der tilhører den korrekte modtager eller håndteres efter en godkendt politik.

• Den version af medarbejdervilkårene, der er bekræftet.

• Aktiveringstidspunktet og brugsomfanget.

Hvis der er eKYC eller e-underskrift, skal virksomheden tydeligt fastlægge, hvilke data der indsamles, formålet med brugen, opbevaringsperioden og håndteringen af mislykket autentificering. Lov om elektroniske transaktioner nr. 20/2023/QH15 er et af de grundlag, juraafdelingen bør gennemgå ved udformning af transaktionen og den elektroniske bekræftelse.

Nødvendige kontroller

• Aktivér ikke en profil, der ikke er korrekt matchet med en medarbejderkode.

• Tillad ikke en transaktion, hvis en opsigelses- eller suspenderingsstatus allerede er i kraft.

• Kræv yderligere autentificering ved ændring af modtagerkontoen.

• Gem versionen af vilkårene og beviset for samtykke.

• Adskil identitetsdata fra data, der kun bruges til at drive grænsen, hvor det er relevant.

Trin 1. Registrér arbejdstiden

De første data i adgang til optjent løn er ikke anmodningen om penge, men arbejdstiden. Dataene kan komme fra en stempeltavle, en app, en kundes arbejdsseddel, et HRM-system eller en anden kilde, som virksomheden anerkender.

En arbejdsregistrering kræver normalt disse felter:

En enkelt stempling beviser kun, at systemet modtog data. Den beviser ikke automatisk, at vagten er berettiget til lønberegning.

Trin 2. Lederen bekræfter arbejdet

Dette er trinnet, der afgør grænsens pålidelighed. En bemyndiget person kontrollerer vagten, overarbejdet, orloven og undtagelserne, før arbejdet flyttes til status godkendt.

Hvorfor bør kun godkendt arbejde bruges?

Ikke-godkendt arbejde kan ændre sig på grund af:

• En manglende ind- eller udstempling.

• Den forkerte vagt eller det forkerte sted.

• Overarbejde, der endnu ikke er bekræftet.

• En orlovsanmodning, der endnu ikke er opdateret.

• Duplikerede data eller en forkert indtastet medarbejderkode.

• Kunden har endnu ikke bekræftet de faktisk arbejdede timer.

Hvis systemet beregner grænsen på afventende arbejde, kan penge udbetales, før en uoverensstemmelse opdages. At tilbagesøge dem bagefter er normalt sværere end at forhindre en forkert transaktion fra starten.

Arbejdsgodkenderens ansvar

• Godkend den rigtige person, den rigtige dag, den rigtige vagt og den rigtige arbejdstype.

• Håndtér unormalt arbejde inden for den fastsatte frist.

• Registrér årsagen ved justering eller afvisning.

• Del ikke konti, og delegér ikke uden kontrol.

• Færdiggør arbejdet før skæringstidspunktet for grænsesynkronisering.

Virksomheden bør have en SLA for arbejdsgodkendelse og et dashboard, der viser antallet af ikke-godkendte personer, antallet af unormale registreringer og efterslæbstiden.

Trin 3. Synkronisér og kontrollér data

Efter at arbejdet er godkendt, sendes dataene til grænseberegningssystemet. Synkronisering kan ske via API i næsten realtid, en planlagt batchfil eller en kontrolleret handling i pilotfasen.

Systemet bør ikke kun kontrollere "om der er data", men også deres kvalitet:

• Findes medarbejderkoden, og er den stadig aktiv?

• Er lønperioden korrekt?

• Er arbejdet godkendt og endnu ikke låst/tilbagekaldt?

• Er det lønniveau eller den enhedssats, der bruges som grundlag, allerede i kraft?

• Er der allerede opstået en transaktion på den samme del af arbejdet?

• Er der en reserve eller justering, der skal indgå i formlen?

• Er modtagerkontoen verificeret?

Princippet, når data mangler

Gæt ikke enhedssatsen, vagttypen eller arbejdsstatus. Hvis et påkrævet datafelt mangler eller er modstridende, bør profilen flyttes til status ikke berettiget med en specifik årsag, så HR, lederen eller medarbejderen kan håndtere den.

Trin 4. Beregn den berettigede allerede optjente løn

Grænsen bør ikke svare til hele den foreløbige løn. Systemet skal bevare en sikkerhedsdel til justeringer, der kan opstå ved periodeafslutning.

Illustrativ formel

Den generelle formel kan udtrykkes således:

Resterende tilgængelig grænse = (Gyldig allerede optjent løn × Sikkerhedssats) − Allerede modtaget beløb − Reserve/justering

Hvor:

• Gyldig allerede optjent løn: den indkomst, der beregnes fra godkendt arbejde efter virksomhedens regler.

• Sikkerhedssats: den sats, virksomheden tillader at få adgang til, som ikke som standard er 100 %.

• Allerede modtaget beløb: summen af vellykkede transaktioner i perioden.

• Reserve/justering: den del, der tilbageholdes til forpligtelser og gyldige udsving, der kan påvirke den modtagne nettoløn.

Illustrativt eksempel

Antag, at på beregningstidspunktet:

• Allerede optjent løn fra godkendt arbejde: 4.000.000 VND.

• Antaget sikkerhedssats: 70 %.

• Beløb, medarbejderen allerede har modtaget tidligt: 1.500.000 VND.

• Yderligere reserve: 300.000 VND.

Så gælder:

Resterende grænse = (4.000.000 × 70 %) − 1.500.000 − 300.000 = 1.000.000 VND.

Alle disse tal illustrerer kun, hvordan formlen fungerer; de er ikke politikken for adgang til optjent løn. Den reelle sats skal baseres på hver virksomheds lønstruktur, arbejdsstabilitet, fradrag og evne til at håndtere uoverensstemmelser.

Betingelser, der kan gøre grænsen nul

• Endnu intet godkendt arbejde.

• Profilen eller modtagerkontoen er endnu ikke gyldig.

• Medarbejderen har modtaget hele den berettigede del.

• Arbejdet er under tvist eller afventer justering.

• Lønperioden er låst.

• Ansættelsesstatus er suspenderet eller ophørt.

• Den samlede programgrænse eller midlerne har midlertidigt nået deres loft.

Skærmen bør forklare årsagen frem for kun at vise "kan ikke gennemføre transaktion".

Trin 5. Medarbejderen indsender en anmodning om penge

Når der er en grænse, vælger medarbejderen det beløb, vedkommende vil modtage. Før bekræftelsen bør systemet vise:

• Den aktuelle grænse.

• Det anmodede beløb.

• Servicegebyret og overførselsgebyret, hvis der er nogen.

• Det faktisk modtagne beløb.

• Det samlede beløb modtaget i perioden.

• Den forventede resterende løn efter transaktionen.

• Modtagerkontoen med delvist maskerede oplysninger.

• Den forventede behandlingstid.

• Vigtige vilkår og supportkanalen.

Kontroller lige før anmodningen registreres

Grænsen bør genberegnes eller genbekræftes for at undgå et tilfælde, hvor medarbejderen åbner skærmen på ét tidspunkt, men arbejds- eller transaktionsdataene har ændret sig, før vedkommende trykker på bekræft.

Hver anmodning skal have en unik transaktionskode. Hvis medarbejderen trykker flere gange, eller appen genindsender på grund af en mistet forbindelse, må systemet stadig kun oprette én gyldig transaktion.

Trin 6. Autentificering, kontrol og udbetaling

Før betalingsinstruksen sendes, har systemet brug for en sidste kontrol:

• Gyldig identitet og loginsession.

• Modtagerkontoen er ikke lige blevet ændret unormalt.

• Grænsen er stadig tilstrækkelig.

• Medarbejderen er stadig i en brugsberettiget status.

• Transaktionen er aldrig blevet behandlet.

• Midlerne og programmets samlede loft er stadig tilstrækkelige.

• Der er ingen svindeladvarsel eller pauseordre.

Foreslåede transaktionsstatusser

En farlig fejl er at se en langsom betalingsstatus og så automatisk genindsende en ny instruks. Den korrekte måde er at slå den gamle transaktion op med dens identifikator, før man beslutter, hvordan man går videre.

Trin 7. Afstem ind i lønperioden

Afstemning er trinnet, der beviser, at systemet har fuldført transaktionens livscyklus. Det samlede tidligt modtagne beløb kan ikke ligge uden for lønregnearket, lønsedlen og regnskabsbøgerne.

Virksomheden bør udføre tre lag:

1. Transaktionsafstemning

Sammenlign anmodningen i appen med det faktiske resultat fra banken eller betalingskanalen:

• Transaktionskode.

• Modtager.

• Anmodet beløb og faktisk modtaget beløb.

• Gebyr.

• Tidspunkt.

• Endelig status.

2. Lønafstemning

Sammenlign det samlede beløb modtaget i perioden med hver medarbejders løndata. Lønsedlen skal tydeligt vise den allerede optjente løn, det tidligt modtagne beløb, gebyret (hvis det hører til en mekanisme, der vises på sedlen) og den resterende løn, der skal udbetales.

3. Regnskabs- og pengeafstemning

Sammenlign appens data med kontoudtog, bogføringsposter og afregningsforpligtelserne mellem virksomheden og driftsenheden/finansieringsenheden. Det skal være muligt at adskille de penge, medarbejderen modtager, servicegebyret, betalingsgebyret og eventuelle refusioner.

Principper for periodelukning

• Luk ikke perioden, mens der er transaktioner med en uafklaret endelig status.

• Enhver uoverensstemmelse skal have en årsag, en behandler og et bevis.

• Justeringer efter periodelåsningen skal gennem godkendelse.

• Oversigtsrapporten skal matche detaljen for hver medarbejder og hver transaktion.

Nødvendige minimale inputdata

Princippet er kun at bruge data, der er nødvendige til det definerede formål, tildele tilladelser efter den korrekte rolle og bevare et komplet spor. Loven om beskyttelse af persondata nr. 91/2025/QH15, i kraft fra 01.01.2026, er et aktuelt grundlag, der bør gennemgås for hele datalivscyklussen.

Roller og ansvar for hver part

Virksomheden bør udarbejde en specifik RACI for normale og undtagelsesvise situationer. Hvis en hændelse opstår, og det ikke kan fastslås, hvem der har beføjelse til at stoppe, rette eller refundere, er processen endnu ikke klar til idriftsættelse (go-live).

Obligatoriske kontroller før udbetaling

En transaktion bør kun sendes, når den passerer alle kontrolporte:

1. Medarbejderen er stadig gyldig og berettiget.

2. Arbejdet er godkendt af en bemyndiget person.

3. Indkomstdataene er gyldige i perioden.

4. Grænsen genberegnes på transaktionstidspunktet.

5. Det samlede anmodede beløb overstiger ikke grænsen og programloftet.

6. Modtagerkontoen er verificeret.

7. Transaktionen er ikke en dublet.

8. Der er ingen svindeladvarsel eller pausestatus.

9. Midlerne er stadig tilgængelige.

10. Medarbejderen har set gebyret og bekræftet det faktisk modtagne beløb.

Håndtering af undtagelsessituationer

Arbejde redigeret efter, at pengene er modtaget

Systemet skal genberegne den berettigede del, stoppe nye transaktioner om nødvendigt og flytte uoverensstemmelsen til en godkendt håndteringsproces. Det bør ikke automatisk oprette en forpligtelse uden for processen, mens medarbejderen ikke er blevet underrettet.

Medarbejderen siger op midt i perioden

Så snart opsigelsesstatus træder i kraft, skal retten til at oprette nye transaktioner låses. HR, Løn og Regnskab fastlægger det godkendte arbejde, de modtagne penge, den resterende løn og afregningsplanen efter det gældende dossier.

Bankkontoen er forkert eller lige blevet ændret

En endnu ikke udbetalt transaktion skal sættes på pause; en kontoændring kræver yderligere autentificering. Hvis den allerede er udbetalt forkert, gå straks til undersøgelses- og hændelsesprocessen; redigér ikke status manuelt for at få rapporten til at "matche".

En mislykket transaktion

Gendan kun grænsen efter et pålideligt endeligt resultat. Gebyrpolitikken for mislykkede transaktioner skal offentliggøres på forhånd og opdateres konsekvent på tværs af app, afstemning og regnskab.

En transaktion, der mistænkes for at være en dublet

Slå den op med den gamle transaktionskode, før der oprettes en ny instruks. Alle API'er, der opretter transaktioner, har brug for en mekanisme mod dubletter.

Tidsregistrerings- eller lønsystemet afbrydes

Når data ikke længere opdateres inden for den tilladte frist, skal grænsen midlertidigt låses eller skiftes til en manuel kontrolmekanisme. Man bør ikke fortsætte med at udbetale på grundlag af gamle data uden godkendelse.

Hvad bør SLA'en og revisionsloggen indeholde?

Drifts-SLA

Virksomheden skal aftale frister for:

• Arbejdsgodkendelse.

• Datasynkronisering.

• Behandling af anmodninger om penge.

• Returnering af transaktionsresultater.

• Undersøgelse af transaktioner med en uklar status.

• Rettelse af arbejdsfejl og genberegning af grænsen.

• Håndtering af klager.

• Refusion af penge eller justering af gebyrer.

SLA'en skal skelne systemets behandlingstid fra tid, der afhænger af banken, kunden eller manuel godkendelse.

Revisionslog

Loggen skal kunne besvare:

• Hvem eller hvilket system udførte handlingen?

• Hvornår fandt handlingen sted?

• Hvad var dataene før og efter ændringen?

• Hvilken regel- eller formelversion blev anvendt?

• Hvem godkendte undtagelsen?

• Hvilken betalingsinstruks svarer til den?

• I hvilken periode blev transaktionen afstemt?

Operatøren bør ikke have lov til at redigere transaktionshistorikken direkte uden at efterlade et spor.

Virksomhedens tjekliste før tilslutning af processen

• [ ] Der er en konsistent medarbejderkode på tværs af HR, tidsregistrering, løn og EWA.

• [ ] Kun godkendt arbejde bruges til at beregne grænsen.

• [ ] Der er en frist for arbejdsgodkendelse og en stedfortræder, når lederen er fraværende.

• [ ] Grænseformlen er godkendt af Løn, Økonomi og Jura.

• [ ] Der er en reservedel i stedet for at tillade, at hele den foreløbige løn modtages.

• [ ] Modtagerkontoen er verificeret og kontrolleret ved ændring.

• [ ] Hver transaktion har en unik kode og en mekanisme mod dubletter.

• [ ] Der er komplette statusser for mislykket, undersøgelse, refusion og afstemning.

• [ ] En fuld cyklus til lønseddel, regnskab og kontoudtog er testet.

• [ ] Der er en proces til at låse fratrådte medarbejdere i næsten realtid.

• [ ] Der er et scenarie for, når tidsregistrering, løn eller betaling afbrydes.

• [ ] Medarbejderen ser tydeligt gebyret og den forventede resterende løn.

• [ ] Der er et supportkontaktpunkt og en SLA for klagehåndtering.

• [ ] Persondata er tilladelseskontrolleret, beskyttet og livscyklusstyret.

• [ ] En pilot er kørt, og mindst én lønperiode er fuldført før opskalering.

Konklusion

Kerneværdien af adgang til optjent løn er ikke kun overførselshastigheden. Et pålideligt system skal kunne bevise hele kæden:

Den rigtige person → det rigtige godkendte arbejde → den rigtige grænse → den rigtige konto → præcis én gang → den rigtige status → den rigtige lønperiode → det rigtige afstemningsregnskab.

Hvis ét trin ikke kan spores, kan virksomheden endnu ikke være sikker på, at transaktionen var korrekt. Derfor skal en pilot køre gennem mindst én komplet lønperiode, håndtere undtagelser fuldt ud og lukke alle væsentlige uoverensstemmelser før opskalering (se også risiciene ved at indføre EWA).

En virksomhed, der ønsker at vurdere sine data og sin parathed til at implementere, kan tilmelde sig en demo af processen for adgang til optjent løn, fra tidsregistrering til afstemning, på Adgang til optjent løn for virksomheder.

> Bemærk: Denne artikel giver generel information og erstatter ikke juridisk, finansiel, regnskabsmæssig, sikkerheds- eller systemdesignrådgivning for en specifik virksomhed.

Kilder

• Arbejdsloven nr. 45/2019/QH14

• Lov om elektroniske transaktioner nr. 20/2023/QH15

• Lov om beskyttelse af persondata nr. 91/2025/QH15

• Dekret 52/2024/NĐ-CP om ikke-kontant betaling

• Banking Review: Den juridiske karakter af tjenester for adgang til allerede optjent løn og forslag til lovjustering i Vietnam

---

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

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