Payer beaucoup de monde à la fois, sans payer personne deux fois
Les versements en masse échouent dans deux directions : tout le fichier s’arrête à cause d’une ligne fautive, ou la reprise repaie les bonnes lignes. Valider d’abord et rendre compte ligne par ligne supprime les deux.
Payer deux cents personnes d’un coup comporte deux modes de défaillance classiques, et la plupart des systèmes parviennent à avoir les deux.
Défaillance une : tout ou rien
La ligne 147 contient un numéro de téléphone malformé. Le fichier est rejeté.
Personne n’est payé. Nous sommes le 28. Le responsable financier a désormais une soirée devant lui, et deux cents personnes en ont une pire.
Défaillance deux : la reprise
Le fichier réussit partiellement. Cent quatre-vingts personnes sont payées, vingt ne le sont pas, et le rapport dit terminé avec des erreurs.
Quelqu’un doit maintenant déterminer lesquelles des vingt. S’il se trompe et relance tout le fichier, cent quatre-vingts personnes sont payées deux fois — et récupérer un trop-payé auprès de quelqu’un qui l’a déjà dépensé n’est pas un problème technique, c’est une série de conversations difficiles.
Valider avant toute approbation
Le fichier est contrôlé au téléversement, avant l’approbation et avant que rien ne bouge.
Les erreurs sont signalées avec la ligne et le motif. Corrigez-les et téléversez à nouveau, ou continuez sans elles. C’est une correction de deux minutes à un bureau plutôt qu’un incident à vingt heures.
L’approbation est un acte distinct
Téléverser et approuver sont des actions différentes : personne ne paie deux cents personnes en cliquant une fois sur la mauvaise chose.
Pour la plupart des organisations, c’est aussi le contrôle qu’elles veulent réellement : la personne qui prépare la paie n’est pas celle qui la libère.
Des résultats par ligne
Chaque ligne rend compte de son propre résultat : payée, ou échouée avec un motif.
Relancer veut donc dire relancer les lignes qui ont échoué — pas le fichier. Le mode de défaillance du double paiement ne se présente simplement pas, parce que personne n’a de raison de renvoyer un lot en bloc.
Des événements, pas des boîtes de réception
Les résultats de lot sont publiés comme événements : un système de paie peut y réagir.
Personne ne devrait avoir à rafraîchir une page pour savoir si son personnel a été payé.
Ce que cela coûte
Les versements sont tarifés individuellement au tarif ordinaire du rail. Il n’y a aucune surcharge pour les envoyer ensemble.
Ce que vous pouvez vérifier
Ce sont des faits sur la plateforme en fonctionnement, pas des adjectifs. Chacun est visible dans le produit, dans la référence de l’API ou dans le grand livre.
- Le fichier est validé avant approbation : les erreurs sont trouvées alors que rien n’a bougé.
- Les résultats sont par ligne : un échec est attribuable à une ligne plutôt qu’au fichier.
- Approuver est distinct de téléverser : personne ne paie deux cents personnes en appuyant une fois sur le mauvais bouton.
- Un lot a un nombre de lignes borné et une disposition de colonnes documentée : un fichier est conforme ou rejeté avec un motif.
- Les événements de lot sont publiés : un système de paie peut réagir au résultat au lieu d’interroger une boîte de réception.
Ce que cela coûte
Les versements sont tarifés individuellement au tarif ordinaire du rail ; il n’y a aucun frais distinct pour les envoyer en lot.
Est-ce activé ?
La disponibilité dépend des autorisations en place et de ce que l’administrateur d’un déploiement donné a activé. Cela change, un article non — la réponse vivante est donc sur la page de la fonctionnalité, qui la lit dans la plateforme elle-même : Versements en masse sur la page des fonctionnalités.
À lire ensuite
- Retraits et versements — Retenu, exécuté, ou rendu. Jamais perdu entre les deux.
- Équipe et rôles — Déléguez le comptoir, pas l’entreprise.
- Notifications signées — Votre logiciel l’apprend avant votre client.
Frequently asked questions
Une ligne a échoué. Dois-je relancer le fichier ?
Non — et c’est l’erreur qui cause les doubles paiements. Les résultats sont rendus ligne par ligne : vous ne relancez que les lignes qui ont échoué. Le fichier n’est pas un objet tout ou rien.
Qui peut approuver un lot ?
Approuver est une action distincte du téléversement : la personne qui prépare la paie n’est pas forcément celle qui la libère. Pour la plupart des organisations, cette séparation est tout l’intérêt.
Que se passe-t-il si mon fichier est erroné ?
On vous dit quelles lignes et pourquoi, avant toute approbation et avant que le moindre argent ne bouge. Corrigez-les et téléversez à nouveau, ou continuez sans elles.
Send with a QR code, add money by card or mobile money, issue a virtual card. Sandbox balances let you explore before any real money moves.
Keep reading
Paying many people at once, without paying anybody twice
Bulk payouts fail in two directions: the whole file stops because of one bad row, or the retry pays the good rows again. Validating first and reporting per row removes both.
Une facturation récurrente dont on n’a pas à se battre pour sortir
Les abonnements échouent deux fois : un paiement qui rebondit perd un client qui voulait rester, et une résiliation qui ne marche pas en perd un pour toujours. Les relances corrigent la première ; une résiliation honnête évite la seconde.
Pourquoi le support ne devrait pas pouvoir corriger votre solde
Le moyen le plus rapide de résoudre une réclamation est de laisser un conseiller ajuster le chiffre. C’est aussi la façon dont les plateformes perdent la capacité de faire confiance à leurs propres livres. Un support qui peut tout lire et ne rien changer est la réponse la plus difficile et la meilleure.