DAILY WAGEHired TodayPaid Today

Nyheder

Hvordan adskiller Settlement og Reconciliation sig i EWA?

Settlement og Reconciliation er beslægtede lag med forskellige formål. I en EWA-arkitektur afslutter og registrerer Settlement det finansielle resultat af en transaktion eller afregningsperiode, mens Reconciliation sammenligner uafhængige kilder for at bekræfte, at arbejdsdata, banktransaktioner og lønsystem viser samme resultat.

Først: Begge handler om penge, men besvarer forskellige spørgsmål

Begreberne bruges ofte som synonymer, fordi de begge optræder efter oprettelsen af en transaktion.

De kan dog adskilles tydeligt:

  • Settlement: ”Hvordan bliver denne økonomiske forpligtelse endeligt afsluttet og registreret?”
  • Reconciliation: ”Registrerer uafhængige systemer det samme resultat?”
Sammenligning af Settlement og Reconciliation i et EWA-system

Hvis opgaverne lægges sammen, kan systemet antage, at et registreret resultat er korrekt, selv om der aldrig er udført en uafhængig afstemning.

Hvad betyder Settlement i denne artikel?

Ordet ”settlement” kan bruges forskelligt af banker, betalingsgateways og lønsystemer.

Her betyder Settlement det trin, der fastlægger det endelige finansielle resultat af en transaktion eller driftsperiode.

For en EWA-transaktion kan det eksempelvis være:

  • en anmodning oprettes;
  • banken bekræfter resultatet;
  • systemet fastslår, hvilket beløb der faktisk blev betalt;
  • transaktionsbogen registrerer det modtagne beløb;
  • den resterende løn opdateres.

På lønperiodeniveau omfatter Settlement også:

  • sammenlægning af bekræftede EWA-betalinger;
  • bogføring af det korrekte totalbeløb i lønsystemet;
  • fastlæggelse af det resterende beløb, der skal betales i perioden;
  • lukning af færdigbehandlede forpligtelser.

Settlement handler derfor om at afslutte en økonomisk forpligtelse.

Hvad betyder Reconciliation?

Reconciliation er processen med at sammenligne to eller flere uafhængige datakilder for at se, om de stemmer overens.

Eksempel:

  • EWA-bogen registrerer en betaling på 500.000 VND;
  • bankudtoget skal indeholde den tilsvarende transaktion;
  • lønsystemet ved periodens afslutning skal vise det allerede modtagne beløb;
  • lønsedlen må ikke trække beløbet to gange.

Hvis kilderne stemmer, anses transaktionen eller perioden for afstemt.

Hvis de ikke stemmer, skal forskellen placeres i en undtagelseskø.

Reconciliation opretter ikke transaktioner og bør ikke ændre tal alene for at få rapporter til at stemme.

Sammenligning af Settlement og Reconciliation

KriteriumSettlementReconciliation
HovedspørgsmålHvordan blev den økonomiske forpligtelse afsluttet?Stemmer bøgerne overens?
TidspunktUnder/efter transaktionsforløbet eller ved periodens slutningNår data fra flere kilder foreligger
Primære dataTransaktionsstatus, beløb, periodeEWA-bog, bank, lønsystem
ResultatBetalt/afregnet/resterende beløbMatch eller undtagelse
Opretter transaktion?Kan indgå i afslutningen af en transaktionNej
Finder forskelle?Muligvis, men det er ikke hovedformåletJa, det er hovedformålet
Lukker en periode?Kan bidrage til lukning af forpligtelserBekræfter data før lukning
Når noget er uklartBevar en passende statusSend til undtagelse/undersøgelse

Lagene skal forbindes, men kan ikke erstatte hinanden.

Hvordan passerer en transaktion gennem Settlement?

Et typisk forløb kan være:

  1. anmodningen opfylder betingelserne;
  2. Payment Orchestration opretter transaktionen;
  3. banken behandler den;
  4. den endelige status fastlægges;
  5. en gennemført transaktion bogføres i ”modtaget”-bogen;
  6. den tilknyttede værdi låses mod genbrug;
  7. transaktionsforpligtelsen anses for afsluttet.

Hvis bankstatussen er usikker, bør Settlement ikke drage sin egen konklusion.

Her gælder fail-closed-princippet: Er resultatet uklart, må det ikke lukkes som hverken succes eller fiasko.

Hvordan passerer en transaktion gennem Reconciliation?

Når uafhængige data er tilgængelige, sammenligner systemet:

  1. internt transaktions-id;
  2. bankkode eller -reference;
  3. beløb;
  4. modtager;
  5. tidspunkt;
  6. status;
  7. lønperiode;
  8. beløb bogført i lønsystemet.

Hvis alt stemmer, kan transaktionen markeres som afstemt.

Hvis ét felt afviger, opretter systemet en undtagelse.

Forløb fra transaktion gennem Settlement og Reconciliation i EWA

Det afgørende er, at Reconciliation bruger en uafhængig kilde til at kontrollere systemets registrerede resultat.

Hvorfor er et API-svar ikke tilstrækkeligt som afstemning?

En bank-API kan returnere ”success” under behandlingen.

Det er et vigtigt signal, men et finansielt system bør stadig udføre en uafhængig afstemning bagefter.

Årsagerne omfatter:

  • et realtidssvar kan være forkert eller gå tabt;
  • det interne system kan registrere en forkert status;
  • en transaktion kan registreres to gange;
  • et bankudtog kan vise en transaktion, som mangler internt;
  • lønsystemet kan bruge den forkerte periode.

Reconciliation giver den endelige kontrol.

Hvordan adskiller Settlement ved periodeslutning sig fra Settlement pr. transaktion?

Der kan være to niveauer.

Transaktionsniveau

Fastslå, om en bestemt betaling er foretaget, beløbets størrelse og bogføringen i transaktionsbogen.

Lønperiodeniveau

Saml alle transaktioner i perioden og fastlæg:

  • det samlede allerede modtagne beløb;
  • tilbageførsler eller justeringer;
  • beløbet, der skal vises i lønsystemet;
  • den resterende løn.

Begge niveauer kræver sporbare data.

Hvorfor ikke ”afstemme ved at ændre tallet, indtil det passer”?

En farlig fejl er manuelt at ændre den ene bog, når to bøger ikke stemmer, så sluttotalerne bliver ens.

Det ødelægger beviset for årsagen.

Den korrekte proces er at:

  1. bevare kildedata;
  2. oprette en undtagelse;
  3. finde årsagen;
  4. fastslå, hvilken bog der er forkert;
  5. foretage en sporbar forretningsmæssig justering;
  6. få godkendelse;
  7. afstemme igen.

Alle justeringer skal have et revisionsspor.

Almindelige undtagelser mellem Settlement og Reconciliation

Systemet viser succes, men bankudtoget gør ikke

Undersøg transaktionen og bankdokumentationen.

Udtoget viser en udbetaling, men systemet viser pending

API-svaret kan være gået tabt. Send ikke en ny betalingsordre.

Transaktionen lykkedes, men lønsystemet viser den ikke

Det allerede modtagne beløb kan blive betalt igen ved periodens slutning.

Lønsystemet trækker beløbet, men transaktionen mislykkedes

Medarbejderens løn kan blive reduceret, selv om pengene ikke blev modtaget.

Transaktionen tilhører den forkerte periode

Kontrollér cut-off-reglen og den relevante lønperiode.

Der findes en dublettransaktion

Bevar begge registreringer, find årsagen og håndter den gennem den korrekte proces.

Hvem bør eje disse to lag?

Det behøver ikke være samme team.

Ansvaret kan fordeles således:

  • Payment Operations: overvåger Settlement pr. transaktion;
  • Regnskab/Afstemning: afstemmer med banken;
  • Lønteam: Settlement og afstemning ved lønperiodens slutning;
  • Engineering: sikrer statusbehandling, idempotens og logs;
  • Product Operations: koordinerer undtagelser.

Ansvaret skal være klart, når en forskel opstår.

Hvilke data forbinder de to lag?

Som minimum bør følgende gemmes:

  • transaktions-id;
  • medarbejder-id;
  • modtagerkonto;
  • beløb;
  • tidspunkt;
  • kunde;
  • lønperiode;
  • transaktionsstatus;
  • bankreference;
  • beløb bogført i lønsystemet.

Afstemning bør ikke primært baseres på navne eller fritekst i overførselsbeskrivelser.

Hvornår kan en periode betragtes som ”lukket”?

En periode bør ikke lukkes alene, fordi lønkørslen er gennemført.

Før lukning bør virksomheden vide, at:

  • arbejdsdata har endelige statusser;
  • gennemførte transaktioner er samlet;
  • pending transaktioner har en håndteringsplan;
  • bankbogen og den interne bog er afstemt;
  • lønsystemet viser det korrekte beløb;
  • resterende undtagelser har ansvarlige;
  • brorapporten er gemt.

Ikke alle undtagelser behøver forsvinde straks, men alle åbne undtagelser skal være identificeret og kontrolleret.

KPI'er, der bør følges særskilt for Settlement og Reconciliation

Settlement

  • tid til fastlæggelse af endelig status;
  • antal pending transaktioner;
  • andel af transaktioner, der kræver indgriben;
  • antal transaktioner, der forsøges igen;
  • antal dublettransaktioner.

Reconciliation

  • automatisk matchprocent;
  • antal undtagelser;
  • undtagelsernes alder;
  • antal bankforskelle;
  • antal lønforskelle;
  • tid til lukning af afstemning.

Hvis alt samles i ét KPI, er det svært at se, om problemet ligger i transaktionsbehandlingen eller sammenligningen af bøger.

Konklusion

Settlement og Reconciliation er forskellige led i samme kontrolkæde. Settlement afslutter og registrerer en økonomisk forpligtelse; Reconciliation bruger uafhængige kilder til at bevise, at resultatet er konsistent. Adskillelsen gør pending transaktioner, forskelle, cut-offs og løn lettere at håndtere og bevarer sporbarheden fra transaktion til lønseddel.

Forfatter: Do Huy Le — Tổng Giám Đốc, 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 Settlement det samme som Reconciliation?

Nej. Settlement fastlægger og registrerer det finansielle resultat; Reconciliation kontrollerer, om resultatet stemmer på tværs af kilder.

Skal en transaktion stadig afstemmes, hvis API'en viser succes?

Ja. En uafhængig afstemning bør bekræfte, at intern bog, bank og lønsystem stemmer overens.

Kan en pending transaktion afregnes?

Den bør ikke behandles som endelig, når status ikke er tilstrækkeligt sikker.

Må Reconciliation automatisk ændre kildedata?

Nej. Den identificerer forskelle; rettelser skal følge en kontrolleret og revisionsbar justeringsproces.

← Nyheder