Modèles d'écran de rapprochement qui aident les équipes opérations à repérer les divergences, vérifier les preuves, appliquer des corrections contrôlées et conserver une piste d'audit claire.
Un écran de rapprochement doit répondre à une question pratique : lorsque deux sources divergent, quelle est la vérité que nous allons déclarer et utiliser ?
Généralement, vous comparez une « source » (flux bancaire, processeur de paiements, POS, sous-grand livre, système d'entrepôt) à votre « livre de référence » (souvent le grand livre). L'écran n'est pas qu'une vue comparée. C'est l'endroit où les décisions sont prises et enregistrées.
Les divergences surviennent pour des raisons banales, et c'est une bonne nouvelle parce que l'interface peut les anticiper. Vous verrez des différences causées par des délais d'enregistrement, des éléments manquants, des doublons, des problèmes de mappage (mauvais compte, client, devise), et des correspondances partielles où un enregistrement d'un côté correspond à plusieurs de l'autre.
Le rôle de l'utilisateur, dans une bonne configuration d'interface d'écran de rapprochement, est de faire passer chaque exception de « incertain » à « résolu » sans deviner. Ce travail se décompose typiquement en quelques actions répétables :
Le plus grand risque n'est pas une correspondance incorrecte. C'est un changement silencieux. Si l'écran permet d'éditer des valeurs sans montrer ce qui a changé, qui a fait la modification et quels enregistrements ont été affectés, vous perdez la confiance et vous perdez du temps lors des audits.
Concevez l'écran pour que chaque résolution produise un résultat traçable : valeurs avant/après, enregistrements sources liés, horodatage, utilisateur et code raison. Si des approbations sont nécessaires, l'UI doit rendre l'état « nécessite approbation » évident afin que le travail ne disparaisse pas dans une zone grise.
Si vous construisez cela dans un outil comme AppMaster, traitez la piste d'audit comme un modèle de données de première classe, pas comme une note secondaire. Votre clôture de fin de mois future vous remerciera.
Un écran de rapprochement fonctionne mieux quand il donne l'impression d'une checklist calme, même quand les données sont désordonnées. La manière la plus simple d'y parvenir est une mise en page claire en trois parties : Récap en haut, une file de travail à gauche (ou au centre), et les Détails à droite.
Le Récap est votre réponse « sommes-nous proches ? ». Affichez les totaux pour chaque côté (nombre et montant), puis le delta dans les deux unités. Les gens doivent voir, en un coup d'œil, s'ils ont un écart de 3 éléments, 124,18 $, ou les deux. Si possible, incluez une petite tendance comme « delta amélioré depuis la dernière sauvegarde » pour que les réviseurs sachent que leur travail fait avancer les choses.
La file de travail est là où l'échelle se manifeste. Gardez la recherche et les filtres visibles en permanence pour que les utilisateurs n'aient pas à ouvrir des panneaux supplémentaires pour le travail de base. Une simple liste de lignes avec une pastille de statut (Nouveau, En revue, Corrigé, Nécessite approbation) suffit souvent.
Voici une structure claire utilisée dans de nombreux écrans de rapprochement :
Par défaut, choisissez la fenêtre temporelle la plus petite utile. Par exemple, commencez par les 7 derniers jours pour que la file soit courte et réactive, puis laissez les utilisateurs étendre d'un clic quand ils ont besoin du mois complet. Cela réduit le bruit et aide les nouveaux réviseurs à prendre confiance.
Si vous construisez cela dans un outil comme AppMaster, maintenez la mise en page cohérente entre le web et le mobile : les mêmes trois zones, simplement empilées sur les écrans plus petits, pour que la formation et la mémoire musculaire restent valides.
Une bonne vue des divergences répond à trois questions en quelques secondes : qu'est-ce qui cloche, à quel point c'est grave, et que dois-je faire ensuite. Si l'écran oblige à ouvrir trois modaux juste pour comprendre une différence, les utilisateurs hésiteront, devineront, ou laisseront des notes pour plus tard.
Commencez par utiliser un petit ensemble cohérent de types de divergences dans tout le produit. Cette cohérence compte plus que le mot exact, car les réviseurs développent une mémoire musculaire. La plupart des équipes couvrent 90 % des cas avec quatre étiquettes : élément manquant, élément en extra, montant différent, et date différente. Placez le type au début de la ligne pour que les gens ne le cherchent pas.
La gravité doit être évidente mais sobre. Préférez des libellés simples comme « Élevé », « Moyen », « Faible » (ou « Bloque la clôture », « Nécessite revue », « Pour information ») avec des couleurs mesurées. Utilisez la couleur comme indice, pas comme message. Réservez le rouge vif aux cas qui bloquent réellement la clôture, et gardez le reste neutre.
Les réviseurs ont aussi besoin du « pourquoi », mais pas en jargon interne. Affichez une ligne de raison courte qui référence ce que le système a trouvé, par exemple « Apparié par référence, montant différent » ou « Aucun écrit de grand livre trouvé pour la transaction bancaire ». Si des règles sont impliquées, affichez le nom de la règle seulement si cela aide, et incluez les différences de champs clés en termes humains.
Gardez les valeurs brutes et normalisées visibles ensemble. La normalisation (arrondi, conversion de devise, suppression d'espaces, changements de fuseau horaire) est courante, et la cacher crée de la méfiance. Une mise en page pratique est une comparaison en deux colonnes à l'intérieur de chaque ligne de divergence :
Si vous construisez cela avec un outil comme AppMaster, modélisez le type de divergence et la gravité comme des énumérations dans la couche de données, afin que chaque liste, filtre et panneau de détails reste cohérent dans le flux de revue des divergences.
Quand le volume est élevé, une file de rapprochement doit se comporter plus comme une boîte de réception que comme un rapport. Les personnes doivent comprendre chaque ligne en une seconde, décider de la suite, et continuer sans perdre le contexte.
Commencez avec des colonnes qui répondent à « qu'est-ce que c'est » avant « qu'est-ce que ça veut dire ». Si possible, gardez l'écran initial sur l'essentiel et poussez les détails dans un panneau latéral.
Le tri doit correspondre à la logique des réviseurs. Un bon défaut est « plus gros delta en premier » car cela met en avant le risque le plus élevé rapidement. Ajoutez des bascules rapides pour les plus récents, les plus anciens en attente, et « touchés récemment » pour faciliter les transferts.
Les vues enregistrées permettent d'étendre la file à travers des rôles. Un analyste peut vouloir « ouvert + auto-match échoué », un approbateur peut vouloir « attente d'approbation uniquement », et un auditeur peut vouloir « résolus ce période avec éditions manuelles ». Gardez les vues évidentes et nommées en langage clair pour éviter que chacun crée ses propres tableaux.
La sélection en masse peut faire gagner beaucoup de temps, mais seulement avec des garde-fous. Indiquez clairement les limites (par exemple, max 50 éléments), montrez quels champs seront modifiés, et avertissez quand les actions sont irréversibles. Une étape de prévisualisation simple évite les erreurs massives.
Les indicateurs de progression gardent l'équipe alignée. Affichez les comptes par état en haut et rendez-les cliquables comme filtres. Mieux encore, affichez la propriété (non assigné vs assigné à moi) pour éviter les doublons.
Ces modèles d'écran de rapprochement sont simples à construire avec un outil visuel comme AppMaster : un tableau de file, des filtres enregistrés basés sur les rôles, et des pastilles de statut donnent aux équipes financières de la vitesse sans sacrifier le contrôle.
Un bon flux de rapprochement ne dépend pas des visuels sophistiqués mais d'empêcher les gens de sauter partout. L'objectif des modèles d'interface est simple : guider le réviseur de « Qu'est-ce qui a changé ? » à « Qu'a-t-on fait à ce sujet ? » sans perdre le contexte.
Commencez par rendre l'étape 1 incontournable : choisir une période de rapprochement et les sources de données exactes. Placez-les en haut de la page et gardez-les visibles après sélection (période, source A, source B, dernière actualisation). La plupart des retours sont dus au fait qu'on révise des divergences sur un extrait incorrect.
L'étape 2 est le scan de 30 secondes. Affichez le delta total, le nombre d'éléments non rapprochés, et les catégories de divergences principales (transaction manquante, différence de montant, décalage de date, doublon). Chaque catégorie doit être cliquable pour filtrer la liste de travail.
L'étape 3 est là où la rapidité compte : ouvrez un élément et comparez les champs côte à côte. Alignez les champs clés (montant, date, référence, contrepartie, devise, compte) et affichez les preuves immédiatement : ligne d'import brute, écriture du grand livre, et tout document joint. Évitez de cacher les preuves derrière des onglets supplémentaires.
L'étape 4 est le point de décision. L'UI doit présenter un petit ensemble d'actions avec des résultats clairs :
L'étape 5 est la responsabilité. Exigez une courte note pour tout sauf un rapprochement propre, et déclenchez une approbation seulement lorsque les règles l'exigent (par exemple, avoirs au-delà d'un seuil ou tout ajustement sur un sous-grand livre clôturé). Affichez qui approuvera avant la soumission, pour éviter les devinettes.
L'étape 6 boucle le processus. Après la soumission, confirmez ce qui a changé (« Rapproché au Grand Livre #48321 », « Ajustement rédigé ») et affichez immédiatement l'entrée d'audit : horodatage, utilisateur, action, champs avant/après, et statut d'approbation. Un réviseur ne doit jamais se demander si son clic a été pris en compte.
Les corrections sont là où les erreurs et le risque de fraude apparaissent, donc l'UI doit rendre les actions les plus sûres les plus faciles. Une bonne règle : laissez avancer le travail sans changer d'abord les montants, puis exigez plus d'intention lorsque l'on modifie réellement les chiffres.
Commencez par des actions « sûres » qui n'altèrent pas les soldes. Elles réduisent les allers-retours et gardent les décisions visibles :
Quand un utilisateur doit créer un ajustement, utilisez un formulaire guidé plutôt qu'une zone de texte libre. Le formulaire doit rendre difficile l'oubli des éléments de base et facile la révision ultérieure. Pour les modèles d'interface de rapprochement, c'est aussi l'endroit où l'on empêche les « corrections rapides » qui créent des problèmes plus graves à la clôture.
Maintenez les actions destructrices derrière des permissions et une confirmation claire. Par exemple, « Supprimer un ajustement » doit être rare, basé sur les rôles et nécessiter une raison. Préférez les actions qui créent un nouvel enregistrement plutôt que d'éditer l'historique.
La validation doit se faire avant l'enregistrement, et le message doit expliquer comment corriger. Une simple checklist fonctionne bien :
Rendez le comportement d'annulation explicite. Les utilisateurs doivent savoir s'ils peuvent rouvrir l'élément, inverser l'ajustement ou créer une contre-écriture. Exemple : un réviseur lie la mauvaise ligne bancaire, puis réalise que le rapprochement appartient à un autre paiement. Un « Délier » clair (avec note) est plus sûr que d'éditer la transaction originale, et il préserve l'historique de ce qui s'est passé et pourquoi.
Une piste d'audit n'aide que si elle répond rapidement aux questions : qui a touché cet élément, qu'est-ce qui a changé, et pourquoi. L'astuce est de la rendre visible quand il le faut, sans bloquer le flux normal de revue.
Ajoutez une timeline compacte dans le panneau de détails de l'élément. Chaque entrée doit montrer l'acteur, l'horodatage, l'action et un court résumé du changement. Gardez-la scannable et cohérente, pour que les réviseurs repèrent le dernier événement significatif (comme « montant corrigé » ou « approuvé ») en un coup d'œil.
Quand un champ est corrigé, stockez et affichez à la fois les valeurs avant et après. Montrez-les en ligne dans l'entrée de la timeline (par exemple : « Montant bancaire : 1 250,00 -› 1 205,00 »), et aussi dans l'historique du champ si quelqu'un ouvre « Détails des modifications ». Cela évite l'erreur commune de ne garder que la valeur finale.
Pour les actions à plus haut risque (solder, override manuel, rapprochement forcé), exigez une raison. Utilisez un petit menu déroulant plus une note optionnelle, afin que le réviseur avance vite tout en laissant une explication claire.
Le modèle maker-checker fonctionne mieux quand il est basé sur des états, pas sur des messages. Utilisez des états simples comme Brouillon, Soumis, Besoin d'infos, Approuvé, Rejeté, Escaladé, et affichez l'état courant près du titre de l'élément. Gardez l'UI d'approbation concise :
Enfin, joignez les preuves à l'élément de rapprochement lui-même : fichiers, références email ou chat, IDs externes et notes. Un réviseur ne doit pas devoir fouiller dans d'autres systèmes pour justifier une décision. Dans des outils comme AppMaster, cela se mappe proprement à un enregistrement « Reconciliation Item » avec des entités liées « Evidence » et « Approval Events », pour que l'UI reste simple tandis que les données restent complètes.
La plupart des écrans fonctionnent jusqu'à ce que les données réelles arrivent. Les points de rupture sont prévisibles, donc il est utile d'en tenir compte tôt.
Les correspondances partielles sont le premier piège. Une table propre un-à-un s'effondre quand un virement bancaire paie trois factures, ou cinq règlements carte se regroupent en une écriture de grand livre. Traitez-les comme des cas de première classe : laissez les réviseurs créer un rapprochement groupé avec un total visible, un indicateur « montant non alloué » et un libellé de groupe clair (par exemple, « 3 éléments -> 1 écriture »). Rendre le groupe extensible permet de confirmer les parties sans perdre le résumé.
Les doublons sont le second piège. Les gens « corrigent » souvent les doublons en rapprochant les mauvais éléments. Ajoutez des indices doux comme « possible doublon » basés sur le montant, la fenêtre de date et la contrepartie, mais restez prudent : les réviseurs doivent pouvoir ouvrir une vue comparative, choisir l'enregistrement correct, et marquer l'autre en doublon avec une raison. Si vous proposez une fusion, rendez-la réversible et conservez toujours les IDs originaux.
Les différences de devise et d'arrondi sont courantes et ne doivent pas être traitées comme des erreurs. Affichez le calcul exact (taux, frais, arrondi) et permettez des seuils configurables (par devise, compte ou type de transaction). L'UI doit indiquer « dans la tolérance » vs « nécessite action », pas seulement « apparié/non apparié ».
Les enregistrements postés tardivement peuvent perturber la clôture. Lorsqu'un élément se résout après la clôture, ne réécrivez pas l'historique. Affichez-le comme « résolu après clôture » avec la date de résolution, et exigez une note ou une approbation s'il modifie les chiffres d'une période close.
Enfin, des pannes et sources manquantes arrivent. Ajoutez des statuts qui facilitent la reprise :
Si vous construisez ceci dans AppMaster, modélisez ces états dans le Data Designer et forcez les transitions autorisées dans le Business Process Editor, pour que la gestion des cas limites reste cohérente et auditable.
C'est la fin du mois. Votre relevé bancaire montre 248 930,12 $ d'activité pour avril, mais votre grand livre interne totalise 249 105,12 $. L'écran de rapprochement s'ouvre avec un Récap qui répond rapidement à trois questions : combien d'éléments correspondent, combien sont divergents, et combien d'argent reste non résolu.
Dans le panneau Récap, l'utilisateur voit : 1 284 éléments rapprochés, 3 divergences, et une différence non résolue de 175,00 $. Un petit encart indique « 2 éléments nécessitent une action » car une divergence est informative seulement.
La table de divergences regroupe les problèmes par type et rend la prochaine étape évidente :
Quand l'utilisateur clique sur une ligne, les Détails de l'élément s'ouvrent à droite. Pour le frais de 25,00 $, les Détails montrent la ligne bancaire (date, description, montant) à côté du côté grand livre (aucune écriture correspondante trouvée) ainsi qu'une brève correction suggérée : « Créer écriture de charge : Frais bancaires ». L'utilisateur choisit une raison de correction, ajoute une note et joint la ligne du relevé bancaire en preuve.
Pour le paiement en double de 150,00 $, les Détails montrent deux écritures du grand livre rapprochées à un paiement bancaire. L'utilisateur marque une écriture dugrand livre comme doublon, choisit « Contre-passation », et l'écran crée une transaction de contre-passation proposée. Parce que cela modifie les livres, cela passe en approbation : le statut devient « En attente d'approbation », et la divergence ne compte plus comme « Non revue ».
Le décalage de calendrier est différent. La banque montre un paiement initié le 30 avril, mais qui est réglé le 1er mai. L'utilisateur définit l'état de résolution sur « Différence de timing », choisit la date de règlement prévue, et l'élément passe en « Report ouvert » pour la période suivante.
Plus tard, un auditeur doit pouvoir confirmer, sans deviner :
La clôture d'une période est l'endroit où de petits écarts d'UI deviennent de gros problèmes. Une bonne checklist de clôture doit être visible sur l'écran, facile à vérifier et difficile à contourner par accident.
Commencez par les totaux. Affichez à la fois le compte et le montant par source pour la période, et rendez évident quel chiffre cause l'écart (par exemple « 3 éléments, 1 240,00 $ » de chaque côté). Si les totaux correspondent mais que les comptes ne correspondent pas, signalez-le clairement pour que les réviseurs ne supposent pas que tout est fini.
Avant la clôture, chaque exception doit avoir un statut final et une raison qu'une autre personne comprendra des semaines plus tard. « Résolu » ne suffit pas sans une note comme « charge en double annulée » ou « différence de timing, se réglera le mois prochain ». C'est l'un des modèles d'interface qui empêche le travail répété.
Utilisez une courte checklist pré-clôture et bloquez la clôture si l'un des éléments échoue :
La vérification ponctuelle est simple mais puissante. Ouvrez cinq éléments résolus au hasard et vérifiez trois choses : la preuve (ligne de relevé, reçu, log système), l'action de correction (ce qui a changé) et la note (pourquoi c'était valide). Si l'une de ces choses manque, votre interface enseigne la mauvaise habitude.
Enfin, rendez la période reproductible. Proposez un « instantané » qui fige les totaux clés, les statuts d'exception, les notes et les approbations. Dans AppMaster, cela peut être un enregistrement « Period Close » dédié généré par un Business Process, afin que la vue d'audit ultérieure corresponde à ce que les réviseurs ont vu au moment de la clôture.
Commencez par les données, pas par la mise en page. Un écran de rapprochement devient chaotique quand le système ne sait pas clairement expliquer ce qu'est un enregistrement et comment il se relie aux autres. Définissez un petit modèle que vous pourrez étendre plus tard : vos fichiers/flux source, les transactions individuelles, les groupes de correspondance qui relient les éléments entre sources, et les ajustements que vous créez pour corriger les différences. Ajoutez les champs nécessaires pour la revue (montant, devise, dates, texte de référence) plus les champs ennuyeux mais critiques (statut, propriétaire, horodatages).
Ensuite, verrouillez les rôles tôt. La plupart des équipes ont au moins trois rôles : un analyste qui peut proposer des rapprochements et corrections, un approbateur qui peut valider les ajustements, et un auditeur qui peut tout voir mais ne rien modifier. Si vous attendez pour définir les permissions, vous finirez par reconstruire des actions de base (éditer, annuler, rouvrir) quand le premier contrôle aura lieu.
Puis prototypez les trois surfaces qui font le vrai travail :
Définissez les transitions de statut comme des règles, pas des habitudes. Par exemple, un groupe ne devrait pas passer à « Rapproché » sauf si la différence restante est zéro (ou dans une tolérance définie), tous les champs requis sont présents, et les approbations sont complètes. Autorisez toujours des exceptions, mais forcez un code raison et un commentaire pour garder la piste d'audit propre.
Pour construire rapidement, utilisez une plateforme no-code comme AppMaster : modélisez la base de données dans un Data Designer postgreSQL-backed, assemblez la file et les panneaux avec le constructeur d'interface web, et implémentez les règles de flux dans l'éditeur visuel Business Process. Gardez la première version étroite (une paire de sources, quelques statuts), testez-la avec de vrais cas de fin de mois, et itérez en fonction des divergences que votre équipe rencontre réellement.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
