Pourquoi vos additions partagées ne tombent jamais juste
Un solde partagé qui ne tombe pas juste se ramène presque toujours à l'une de quatre choses : un centime arrondi, une seconde devise, une dépense modifiée ou un membre parti, et seule la première relève du calcul.
Vous regardez le solde d'un groupe, et il est faux. Peut-être de quelques centimes. Peut-être d'une addition entière. La question sous-jacente est discrète mais réelle : l'application se trompe-t-elle, ou est-ce vous ?
Voici la réponse posée. Quand vous partagez des additions avec d'autres, un solde qui ne tombe pas juste a presque toujours l'une de quatre causes, et une seule relève du calcul. Les trois autres sont une devise, une modification, et quelqu'un qui est parti. Nommez celle que vous avez, et la correction cesse d'être un mystère.
Les quatre causes
Commencez par la forme du problème. Un solde partagé est un cumul de qui a payé et de qui doit. Il devrait s'annuler à l'échelle du groupe : chaque euro dû à quelqu'un est un euro qu'un autre doit. Quand ce n'est pas le cas, quelque chose est entré dans le total que le total ne pouvait pas contenir.
Alors pourquoi les additions partagées ne tombent-elles pas juste ? En général pour l'une de quatre raisons. Un centime est allé quelque part d'inattendu quand une addition ne se divisait pas également. Deux devises ont été additionnées comme si elles n'en faisaient qu'une.
Une ancienne dépense a changé après que les gens avaient déjà payé leur part. Ou une personne a quitté le groupe en devant encore de l'argent. Trois de ces quatre causes n'ont rien à voir avec votre calcul. Pour une vue plus large de la façon dont un groupe solde vraiment ses dettes, lisez notre analyse sur le règlement des comptes d'un groupe.
Le tableau nomme chaque cause une fois, comment elle se manifeste, et ce qui la corrige. Tout ce qui suit en est la version longue.
Quatre raisons pour lesquelles un solde partagé ne tombe pas juste
| Cause | Comment elle se manifeste | Ce qui la corrige |
|---|---|---|
| Arrondi | Le solde est faux d'un centime ou deux, jamais plus | Une règle déterministe qui envoie toujours le centime en trop au même endroit |
| Une devise | Le total est faux d'un montant entier, ou se lit comme un seul nombre étrange | Tenir un solde distinct par devise et ne jamais les additionner entre elles |
| Une modification | Le solde a bondi après qu'une ancienne dépense a changé | Recalculer le partage de la dépense et inscrire la différence dans l'historique |
| Un départ | Le solde ne parvient pas à zéro quoi qu'il arrive | Décider qui absorbe ou annule la part du partant, puis l'enregistrer |
L'arrondi : le centime en trop, et pourquoi il doit être déterministe
Voici l'exemple, et chaque chiffre qu'il contient est à vous de recalculer. Lucas, Aiko et Sofia sortent. Le dîner coûte €100.00, et ils le partagent à parts égales. €100.00 divisé par trois donne €33.3333 et ainsi de suite sans fin, ce qu'aucune devise ne peut payer. Le partage devient donc €33.33, €33.33 et €33.34.
Réadditionnez : €33.33 plus €33.33 plus €33.34 font exactement €100.00. Les trois parts sont justes. L'une d'elles est plus grande d'un centime.
Ce centime en trop, c'est tout le problème en miniature. Quelqu'un doit le porter. C'est l'arrondi des dépenses partagées, et il a une seule tâche : placer le centime en trop à un endroit fixe plutôt qu'au hasard. Si l'application le réattribue à chaque fois, le même dîner peut donner €33.34 pour Aiko aujourd'hui et €33.34 pour Sofia demain, et le solde vacille d'un centime sans raison visible.
Nous rendons donc la règle déterministe. Le centime en trop va à celui qui a payé, à chaque fois. Lucas a payé, donc Lucas porte €33.34 et les deux autres portent €33.33 chacun. On doit à Lucas €100.00 moins ses propres €33.34, soit €66.66.
Aiko doit €33.33. Sofia doit €33.33. €33.33 plus €33.33 font €66.66. Le groupe s'annule à zéro. L'arrondi a utilisé les deux décimales de l'euro, l'unité mineure fixée pour lui dans la norme internationale des devises ISO 4217 ; le choix de remettre le centime à celui qui a payé est le nôtre, et sa seule vertu est de ne jamais changer.
Un calculateur de partage d'addition en ligne peut faire cette division pour un dîner. Le plus dur, c'est de la faire de la même façon pour le centième, ce qui est aussi la différence qui nous importe dans partager équitablement une addition au restaurant. Les comptables débattent depuis longtemps de la règle la plus juste ; la valeur par défaut courante en informatique, l'arrondi au pair le plus proche, est décrite dans la norme IEEE 754. Nous n'en avons pas besoin ici, car notre centime n'est pas une moitié.
Trois parts d'un tout laissent exactement un centime, et la seule question est de savoir qui le garde.
Deux devises dans un groupe, et pourquoi elles ne peuvent pas être additionnées
Une deuxième dépense entre maintenant dans le groupe. Aiko paie un taxi, qui coûte ¥6,000. La tentation, pour un total fatigué, est d'ajouter ¥6,000 à €100.00 et d'afficher un seul chiffre.
Ce chiffre ne veut rien dire. €100.00 et ¥6,000 ne sont pas de même nature, et les additionner revient à ajouter une distance à un poids. Le yen a zéro décimale comme unité mineure, l'euro en a deux, toujours selon ISO 4217. Ils ne s'arrondissent même pas de la même manière.
Nous tenons donc un solde par devise. En euros, rien n'a changé : Aiko doit €33.33 à Lucas, et Sofia doit €33.33 à Lucas. En yens, le taxi se partage en trois à ¥2,000 chacun. Aiko a payé ¥6,000, donc on doit à Aiko ¥6,000 moins ¥2,000, soit ¥4,000.
Lucas doit ¥2,000. Sofia doit ¥2,000. ¥2,000 plus ¥2,000 font ¥4,000. Deux soldes, chacun s'annulant à zéro, aucun ne se faisant passer pour l'autre. Si vous voulez les modes de défaillance plus poussés ici, nous les avons décrits dans les bugs d'argent entre devises.
La modification d'une ancienne dépense, et ce qui doit arriver à l'historique
Troisième mois. Quelqu'un se rend compte que le dîner a été mal enregistré : c'était €120.00, pas €100.00. Il le modifie. C'est là que des soldes qui semblaient réglés bougent soudain, et là que beaucoup d'applications se trompent en silence.
La correction naïve consiste à écraser l'ancien nombre et à tout recalculer de zéro. Mais les gens ont déjà payé selon l'ancien partage. Si l'historique est réécrit en silence, personne ne peut voir pourquoi il doit désormais plus. La modification doit donc recalculer le partage et inscrire la différence, sans effacer le passé. €120.00 divisé par trois donne €40.00 exactement, pas de centime en trop cette fois.
Chaque part devient €40.00. Lucas a payé €120.00, donc on doit à Lucas €120.00 moins €40.00, soit €80.00. Aiko doit €40.00. Sofia doit €40.00. €40.00 plus €40.00 font €80.00.
Le solde en euros est passé de €66.66 dû à €80.00 dû, et la différence, €13.34, se rattache exactement aux €20.00 dont le dîner a augmenté : les deux autres parts ont chacune augmenté de €6.67, et €6.67 plus €6.67 font €13.34. Nous gardons l'ancienne écriture et ajoutons la correction par-dessus. Pourquoi une modification doit recalculer son partage, plutôt que de prétendre que le dîner a toujours coûté €120.00, est une histoire à part dans une modification doit recalculer son partage.
Quelqu'un est parti, et ce qu'il advient de ce qu'il devait
La quatrième cause est une personne, pas un nombre. Disons que Sofia quitte le groupe en devant encore €40.00 en euros et ¥2,000 en yens. Le solde ne peut plus parvenir à zéro tout seul, car l'une des personnes dont il dépend est partie.
Ce n'est pas une erreur de calcul ; le calcul est bon. Le groupe a un trou de la taille de la part de Sofia.
Il n'y a que quelques options honnêtes, et toutes sont des décisions, pas des calculs. Le groupe peut annuler le montant, et noter qu'il a été annulé. Quelqu'un peut l'absorber, et noter qui. Ou Sofia peut régler avant de partir.
Ce qui compte, c'est que le choix soit consigné comme une écriture, pour que le solde affiche zéro parce que quelque chose s'est passé, non parce qu'une dette a été discrètement supprimée. Nous ne décidons jamais à votre place ; nous enregistrons le choix que vous faites. La même logique vaut pour un colocataire qui s'en va en cours de bail, ce que nous traitons dans partager le loyer entre colocataires.
Comment vérifier un solde vous-même quand vous partagez des additions
Vous pouvez tout vérifier à la main, et il vaut la peine de savoir comment. Prenez une devise à la fois, et ne les mélangez jamais. Pour cette devise, additionnez tout ce que chaque personne a payé. Additionnez tout ce que chaque personne devait, part par part.
Le solde d'une personne, c'est ce qu'elle a payé moins ce qu'elle devait. Faites cela pour chacun, puis additionnez tous les soldes. La somme doit être zéro. Si elle ne l'est pas, l'écart vous dit quelle cause vous avez.
Un écart d'un ou deux centimes, c'est l'arrondi ; regardez où le centime en trop a atterri et vérifiez qu'il a atterri au même endroit à chaque fois. Un écart de la taille d'une addition entière, ou un total qui paraît impossible, vient d'ordinaire d'une seconde devise repliée dedans. Un solde qui a changé depuis la dernière fois pointe vers une modification, alors ouvrez l'historique de la dépense.
Un solde qui ne se boucle pas du tout pointe vers quelqu'un qui est parti. Quand vous partagez des additions entre amis, le solde n'est jamais que du calcul, donc un écart tenace est une information, pas de la malchance. Si vous préférez voir les chiffres plutôt que nous croire sur parole, notre article statistiques sur le partage des additions montre à quelle fréquence chacune de ces causes se produit vraiment.
Ce qu'un registre en ajout seul fait face à ces quatre causes
Sous Dimesum se trouve un registre en ajout seul, à partie double, et il est public, si bien que rien de tout cela n'a à être pris sur la foi. La partie double signifie que chaque montant est enregistré deux fois, une fois comme une dette et une fois comme une créance, de sorte que les deux côtés s'équilibrent toujours ; le principe est plus ancien que le logiciel et est décrit simplement dans l'article sur la comptabilité en partie double. L'ajout seul signifie que nous n'écrasons jamais. Nous ne faisons qu'ajouter.
Cette seule conception gère les quatre causes. L'arrondi est déterministe parce que la destination du centime est inscrite dans la règle d'écriture, non décidée sur le moment. Les devises restent séparées parce que chaque écriture porte sa propre devise et que le registre refuse de les additionner entre elles. Une modification devient une nouvelle écriture correctrice qui recalcule le partage, si bien que l'ancienne vérité et la nouvelle survivent toutes les deux ; nous décrivons cette mécanique dans un registre en ajout seul pour les dépenses partagées.
Et une personne qui part devient une décision enregistrée, une écriture comme une autre, plutôt qu'une ligne manquante. Nous enregistrons tout cela. Nous ne détenons ni ne déplaçons jamais votre argent ; le registre est un enregistrement, et le règlement se fait directement entre vous, dans le moins de virements que nous puissions calculer. Si vous comparez les outils, nos notes sur les applications de partage d'additions comparées et les applications de partage de loyer comparées s'en tiennent à ce que chacune fait et ne fait pas.
Un solde qui ne tombe pas juste n'est pas un verdict sur votre amitié ni sur votre calcul. C'est l'un de quatre petits faits sur votre groupe. Ouvrez Dimesum et le registre vous dira lequel.
Questions fréquentes
Pourquoi mon solde de dépenses partagées ne tombe-t-il pas juste ?
Presque toujours pour l'une de quatre raisons : un centime qui a été arrondi, une seconde devise ajoutée par erreur, une ancienne dépense qui a été modifiée, ou un membre parti en devant de l'argent. Seule la première relève du calcul. Choisissez une devise, additionnez les paiements de chacun moins ses parts, et la taille de l'écart vous dit quelle cause vous avez.
Qui prend le centime en trop quand une addition ne se divise pas également ?
Celui que désigne la règle de l'application, du moment qu'elle dit la même chose à chaque fois. Un dîner de €100.00 partagé en trois donne €33.33, €33.33 et €33.34, et ce centime en trop doit atterrir à un endroit fixe. Dimesum l'envoie à celui qui a payé, si bien que le même dîner ne produit jamais deux fois un solde différent. La règle compte plus que le choix.
Peut-on additionner des soldes dans deux devises différentes ?
Non, et aucune application honnête ne le devrait. €100.00 et ¥6,000 sont de natures différentes, avec des unités mineures différentes, donc les additionner donne un nombre qui ne veut rien dire. Dimesum tient un solde distinct par devise et n'en replie jamais un dans l'autre. Vous réglez chaque devise séparément, et c'est pourquoi un groupe peut devoir en euros et en yens à la fois.
Que devient un solde quand une ancienne dépense est modifiée ?
Le partage est recalculé et la différence est inscrite comme une nouvelle correction, plutôt que le passé ne soit écrasé. Modifiez un dîner de €100.00 en €120.00 et chaque part égale passe de €33.33 à €40.00, donc le montant dû augmente de €13.34. L'ancienne écriture reste visible, la correction se pose par-dessus, et chacun peut retracer exactement pourquoi le solde a changé.
Que se passe-t-il quand quelqu'un quitte un groupe en devant de l'argent ?
Le calcul reste bon ; le groupe a simplement un trou de la taille de sa part impayée. Le solde ne peut pas parvenir à zéro tant que quelqu'un ne décide pas quoi faire. Le montant peut être annulé, absorbé par un autre membre, ou réglé avant le départ, et quelle que soit l'option, elle est enregistrée comme une écriture. Dimesum enregistre la décision que vous prenez ; il ne la prend jamais à votre place.
Articles populaires
- Le grand livre append-only qui garde les soldes exacts9 min de lecture
- Modifier une dépense partagée doit redéfinir le partage9 min de lecture
- Six bugs de devises dans le partage de dépenses10 min de lecture
- Solder les comptes d'un groupe en moins de virements5 min de lecture
- Partager une addition quand un plat n'a pas été partagé10 min de lecture