Pourquoi l’EWA doit-elle relier le pointage, la paie et la banque ?

L’EWA doit relier le pointage, la paie et la banque, car chaque système détient une partie différente de la vérité salariale. Le pointage indique le travail effectué et approuvé ; la paie définit la période, le taux et le règlement ; la banque confirme les fonds réellement transférés. Sans l’un de ces éléments, le montant disponible et la paie finale risquent de diverger.

Trois systèmes répondent à trois questions différentes

L’EWA ne peut ni créer seule les données de travail ni remplacer la paie.

Système	Question principale
Pointage	Quels jours ou postes ont été réalisés et approuvés ?
Paie	Comment déterminer la valeur du travail, la période et le règlement final ?
Banque	Quels paiements ont réellement été transférés et quel est leur statut final ?

L’EWA relie ces trois domaines dans une chaîne contrôlable.

Le pointage confirme le travail acquis

Sans données de pointage, l’EWA ignore la quantité de travail réellement effectuée.

Les données minimales comprennent :

• le travailleur ;
• le lieu de travail ;
• la date ;
• le poste ;
• les heures ou jours travaillés ;
• le statut d’approbation ;
• l’historique des modifications.

Le principe essentiel est que le temps enregistré n’est pas forcément approuvé.

Une sortie peut manquer, le poste peut être erroné ou la validation en attente. Seules les données ayant suivi le processus d’approbation approprié doivent entrer dans le calcul financier.

La paie apporte le contexte absent du pointage

Le pointage peut indiquer huit heures sans connaître :

• le taux applicable ;
• la période de paie ;
• la date d’effet d’une modification salariale ;
• le lieu associé au taux ;
• les règles de règlement ;
• le traitement des montants déjà reçus.

C’est le rôle de la paie.

Avant de calculer le montant disponible, l’EWA doit rattacher le travail à la bonne période et à la bonne configuration salariale.

Pour EWA :

Montant disponible = (jours approuvés × taux journalier) − montant déjà reçu dans la période − réserve prévue par l’employeur.

Le pointage et la paie doivent donc se rejoindre dans un même calcul.

La banque confirme ce qui s’est réellement passé avec l’argent

Créer une demande ne signifie pas que le travailleur a reçu l’argent.

Une transaction peut être :

• en cours ;
• réussie ;
• échouée ;
• de statut incertain ;
• en investigation.

Le registre EWA doit donc être relié aux preuves bancaires.

Si le système marque « reçu » dès l’envoi de la demande, la paie peut déduire une somme jamais reçue. À l’inverse, si la banque a payé sans que le système l’enregistre, la même somme peut être reversée.

Les trois systèmes doivent partager des clés de liaison utilisables

L’intégration ne se résume pas à « avoir une API ». Tous les systèmes doivent reconnaître la même entité.

Des clés stables sont requises pour :

• le travailleur ;
• le client ou lieu de travail ;
• le code de pointage ;
• la période de paie ;
• la transaction ;
• le compte bénéficiaire.

Pour une personne travaillant sur plusieurs sites, le nom seul peut mélanger heures et taux. Une bonne architecture utilise des clés métier claires et une table de correspondance gouvernée.

Que se passe-t-il si seuls le pointage et la banque sont reliés ?

Le système sait qu’une personne a travaillé et peut payer, mais sans la paie il ne peut pas :

• identifier la bonne période ;
• appliquer le bon taux ;
• affecter le montant reçu au bon règlement ;
• éviter de le repayer en fin de période.

Les fonds circulent, mais l’intégrité de la paie reste faible.

Que se passe-t-il si seules la paie et la banque sont reliées ?

La paie est périodique, alors que l’EWA doit connaître le travail acquis pendant la période ouverte.

Sans travail approuvé, le montant disponible devient une estimation ou une limite déconnectée du travail réel, ce qui ne correspond pas au modèle EWA décrit ici.

Que se passe-t-il si seuls le pointage et la paie sont reliés ?

L’entreprise peut calculer correctement, mais ignore ce que la banque a réellement transféré.

Il devient difficile de :

• empêcher les doubles paiements ;
• gérer les délais d’attente ;
• investiguer les transactions ;
• régler le bon total déjà reçu.

La banque est donc la source de vérité du mouvement de fonds exécuté.

Comment fermer la chaîne de données ?

Une chaîne idéale :

1. le pointage enregistre les données ;
2. une personne habilitée les approuve ;
3. l’Earned Wage Engine calcule le montant acquis ;
4. l’Eligibility Engine contrôle les conditions ;
5. Payment Orchestration crée la transaction ;
6. la banque la traite ;
7. le statut est confirmé ;
8. Reconciliation compare les registres ;
9. la paie enregistre le montant reçu ;
10. le bulletin indique le solde correct.

Chaque paiement peut ainsi être rattaché au travail effectué.

L’intégration n’exige pas une technologie unique

Les domaines peuvent être reliés par :

• des fichiers ;
• Google Sheets ;
• des API ;
• ou une combinaison.

L’essentiel est d’avoir :

• un schéma clair ;
• des clés stables ;
• une source de vérité définie ;
• des horodatages ;
• des statuts explicites ;
• une protection contre les doublons ;
• une piste d’audit ;
• un traitement des exceptions.

Une API temps réel sans idempotence ni auditabilité n’est pas forcément supérieure à un fichier batch bien gouverné.

Que faire si les trois systèmes ne concordent pas ?

Il ne faut pas choisir un chiffre simplement parce qu’il « semble raisonnable ».

Exemple :

• le pointage indique huit heures ;
• la paie en reçoit six ;
• l’EWA a payé huit heures.

Cette exception exige de :

1. préserver les données sources ;
2. identifier la version approuvée ;
3. vérifier la transaction exécutée ;
4. calculer l’impact ;
5. effectuer un ajustement traçable ;
6. refaire le rapprochement.

Un système financier ne doit pas masquer l’écart en modifiant manuellement le total final.

Qui doit être responsable de chaque domaine ?

La répartition peut être :

• opérations/client : source du pointage ;
• RH/Paie : périodes et règles ;
• finance : transactions et rapprochement ;
• IT/Engineering : intégration et fiabilité ;
• Product Operations : coordination du flux EWA.

Le RACI varie selon l’entreprise, mais chaque source doit avoir un responsable.

KPI d’intégration à suivre

On peut mesurer :

• le taux de pointages associés au bon travailleur ;
• le taux d’approbation dans les délais ;
• les doublons ;
• les erreurs de synchronisation ;
• les transactions en attente ;
• les transactions rapprochées avec les relevés ;
• les écarts de paie ;
• le délai de traitement des exceptions ;
• les corrections de mapping ;
• les périodes de rapprochement complètement closes.

L’objectif n’est pas seulement que « l’API fonctionne », mais que les données concordent de bout en bout.

Conclusion

L’EWA doit relier pointage, paie et banque car aucun système ne détient seul toute la vérité. Le pointage prouve le travail, la paie l’inscrit dans la bonne période et les bonnes règles, et la banque confirme les versements réels. Avec des clés communes, une piste d’audit et un rapprochement, l’EWA reste rapide tout en préservant l’intégrité de la paie.

Auteur : Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

Conseil EWA aux employeurs : Hotline 0937.022.655 · E-mail info@nhankiet.vn · Découvrir EWA pour les employeurs