Le centime manquant
Vous additionnez les lignes, la comptabilité du client additionne les lignes, et les deux totaux diffèrent d'un centime. Personne ne s'est trompé. Deux causes — un arrondi effectué à un autre moment et la façon dont les ordinateurs stockent les fractions décimales — et toutes deux s'évitent.
L'argent n'est pas un décimal, c'est un entier de centimes
Les ordinateurs stockent 0,1 et 0,2 comme des fractions binaires très proches mais inexactes : 0,1 plus 0,2 ne donne pas 0,3 dans la plupart des langages. Sur une ligne, personne ne le voit. Sur quarante lignes et un calcul de taxe, l'écart s'accumule en un centime visible. L'application ne conserve jamais un montant en décimal : chaque prix devient un nombre entier de **centimes** dès la saisie, tout le calcul se fait sur des entiers, et la conversion inverse n'a lieu que pour l'affichage.
Arrondir une fois, à un seul endroit
La seconde cause est plus subtile. Prenez trois lignes de 3 unités à 0,335. Arrondissez d'abord chaque ligne : 1,01 trois fois, soit 3,03. Additionnez d'abord et arrondissez une fois : 3,02. Aucun n'est faux arithmétiquement ; ce sont des réponses à deux questions. Ce qui est faux, c'est de faire les deux dans le même document — afficher des lignes arrondies mais totaliser les valeurs non arrondies — ce qui produit une facture dont les lignes visibles ne font pas le total visible. L'application arrondit une fois par ligne puis additionne les lignes arrondies.
Où la remise cache un centime
Une remise en pourcentage sur le total ne se divise pas également entre les lignes. Dix pour cent de trois lignes à 3,33 font 0,999 — un tiers de centime par ligne, impossible à imprimer. En arrondissant chaque part vers le bas, il manque un centime au total ; vers le haut, il y en a un de trop. L'application calcule la remise sur le sous-total, la répartit et place le reste sur une ligne, de sorte que la somme des lignes remisées égale exactement le sous-total remisé.
Les devises sans centimes
Toutes les devises n'ont pas deux décimales. Le yen japonais n'en a aucune : un montant est un nombre entier de yens, sans sous-unité à arrondir. Un système qui fige deux décimales produit des prix comme ¥1 250,00 — ce n'est pas ainsi qu'on écrit le yen — et arrondit au centième d'une unité qui n'existe pas. L'application stocke le nombre de décimales **par devise**.
Questions fréquentes
Pourquoi ma facture diffère-t-elle d'un centime de mon tableur ?
En général parce que l'un arrondit chaque ligne et l'autre seulement le total. Les deux se défendent ; les mélanger dans un même document non.
Arrondir par ligne ou sur le total ?
Par ligne, puis additionner les lignes arrondies : les lignes imprimées font alors visiblement le total imprimé.
0,1 + 0,2 ne fait vraiment pas 0,3 ?
En flottant binaire, non : 0,30000000000000004. D'où la gestion en centimes entiers.
Pourquoi une remise en pourcentage laisse-t-elle un reste ?
Parce qu'un pourcentage d'un total se divise rarement en centimes entiers entre les lignes. Le reste doit tomber sur une ligne.
Comment l'application traite-t-elle le yen ?
Comme une devise sans décimale : yens entiers, pas de sous-unité, pas d'arrondi au centime.
Puis-je corriger le total à la main ?
Non. Un total qui n'égale pas la somme des lignes se remarque immédiatement. Corrigez la règle d'arrondi.
Des factures dont le total tombe juste. Invoice Maker crée factures, proformas, devis et reçus dans le navigateur, calcule en centimes entiers pour que la ligne de TVA ne dérive pas, et exporte un PDF. Rien n'est téléversé.
Créer une facture dans le navigateur