Déclarez les rôles de flux de trésorerie dans votre grand livre : une ligne de métadonnées remplace l'estimation

Chaque état des flux de trésorerie repose sur une décision silencieuse prise une fois par compte : ce compte fait-il partie de la trésorerie que vous expliquez, ou s'agit-il d'une activité opérationnelle, d'investissement ou de financement ? Si cette décision est correcte, l'état vous indique où votre argent est réellement allé. Si elle est erronée, l'état est trompeur en toute confiance.

Jusqu'à présent, le rapport de flux de trésorerie de Beancount.io prenait cette décision pour vous avec des heuristiques — le type racine du compte, plus une estimation basée sur le nom pour déterminer quels actifs comptent comme de la trésorerie. Pour la plupart des grands livres, l'estimation était correcte la plupart du temps, et silencieusement erronée le reste du temps. Un compte de courtage nommé d'une mauvaise manière se retrouvait dans la mauvaise section. Un fonds monétaire qui est de la trésorerie dans tous les sens pratiques se retrouvait dans les activités d'investissement parce que son nom ne le disait pas.

À partir d'aujourd'hui, vous pouvez rendre la classification explicite. Une ligne de métadonnées beancount standard sur la directive open du compte :

2000-01-01 open Assets:US:Brokerage
  cash-flow-role: "investing"
 
2000-01-01 open Assets:US:Marcus:Savings
  cash-flow-role: "cash"

Une clé, quatre valeurs — cash, operating, investing, financing — et c'est toute la configuration. Il n'y a pas de page de paramètres, pas de fichier JSON, pas de boîte de dialogue d'options par rapport. La prochaine fois que le rapport de flux de trésorerie se charge, les flux du compte de courtage apparaissent sous les activités d'investissement, le compte d'épargne rejoint la pile de trésorerie dont le changement est expliqué par l'état, et tous les autres comptes continuent de fonctionner exactement comme avant.

Ce que signifie chaque rôle​

Un état des flux de trésorerie trie chaque compte dans l'une de deux fonctions, et cash-flow-role répond aux deux avec un seul mot :

• "cash" — le compte appartient à la pile de trésorerie et équivalents de trésorerie. Les comptes de trésorerie n'apparaissent jamais comme des postes ; l'état explique le changement de leur solde combiné, et les transferts entre deux comptes de trésorerie s'annulent, comme il se doit lorsqu'on déplace de l'argent du compte courant vers l'épargne.
• "operating" / "investing" / "financing" — le compte n'est pas de la trésorerie, et son changement de période apparaît comme un poste sous cette section d'activité.

Par défaut, le rapport traite les comptes d'actifs dont les noms contiennent Cash, Checking, Savings ou Bank comme des équivalents de trésorerie. Déclarer un rôle remplace cela dans les deux sens. cash-flow-role: "cash" intègre un compte que la règle de nom ne détecte pas — un fonds monétaire, un portefeuille de stablecoin. Et cash-flow-role: "investing" sur Assets:US:Bank:CD fait deux choses avec une seule ligne : il exclut le CD de la trésorerie et le classe sous les investissements, même si son nom aurait correspondu à la règle de trésorerie.

Nous avons délibérément utilisé une seule clé au lieu de deux. « Ce compte est-il de la trésorerie ? » et « à quelle section d'activité appartient-il ? » n'ont jamais été des questions indépendantes — un compte fait soit partie de la pile de trésorerie, soit appartient à exactement une section d'activité. Deux clés auraient permis des états absurdes, comme un compte de trésorerie avec un rôle d'activité. Une seule clé rend les états illégaux non représentables, et la spécification complète tient dans un tweet.

La classification que vous déclarez est la classification utilisée par toutes les vues. Le graphique Par activité empile les flux opérationnels, d'investissement et de financement de chaque mois ; déplacez le rôle d'un compte, et ses flux se déplacent vers la bonne couche du graphique, la bonne section de l'état, et la bonne ligne de l'export, tout à la fois.

Déclaré l'emporte sur déduit — et le rapport montre son travail​

La classification se résout désormais dans un ordre strict : vos métadonnées d'abord, l'heuristique intégrée ensuite. Et le rapport est honnête sur ce qu'il a fait. L'état se termine par un panneau « Trésorerie et équivalents de trésorerie dans ce rapport » listant exactement quels comptes il a traités comme de la trésorerie lors de la construction des chiffres, puis les rapproche : trésorerie au début de la période, trésorerie à la fin de la période, et le changement net que les sections d'activité expliquent.

Le rapport distingue également les classifications que vous avez déclarées de celles qu'il a déduites, et cette distinction se retrouve dans les exports CSV et Markdown : un état entièrement construit sur des rôles déclarés ne porte plus la mention « classification déduite », car à ce stade la classification n'est pas une inférence — elle fait partie de vos livres.

Les fautes de frappe sont traitées comme un outil en texte brut devrait les traiter. cash-flow-role: "invsting" n'est ni accepté silencieusement ni ignoré silencieusement : le compte revient à l'heuristique par défaut, et le panneau d'état le signale — « valeur de cash-flow-role inconnue, utilisation du défaut » — pour que l'erreur soit visible là où vous regardez, et non enterrée dans un journal.

Si vous ne changez rien, rien ne change​

Les comptes non annotés utilisent les mêmes défauts publiés qu'avant : Revenus et Dépenses correspondent à l'opérationnel, les actifs non-trésorerie à l'investissement, Passifs et Capitaux propres au financement, et les équivalents de trésorerie correspondant par nom forment la pile de trésorerie. Un grand livre existant se rend identiquement avant et après cette version. La plupart des utilisateurs annoteront une poignée de comptes — ceux où le défaut est incorrect — et ne penseront jamais au reste.

La portabilité reste également intacte. Les métadonnées sur les directives open sont une syntaxe beancount de base, analysée par tous les outils v2/v3 et ignorée par tout ce qui ne cherche pas cette clé spécifique. bean-check passe, Fava hausse les épaules, et votre grand livre reste pleinement utilisable en dehors de Beancount.io.

Chaque vue de votre trésorerie est d'accord avec toutes les autres​

Un résolveur partagé produit le rôle final pour chaque compte, et chaque consommateur en lit :

• Le rapport de flux de trésorerie construit ses sections d'activité et sa ligne de conclusion — changement net de trésorerie et équivalents — à partir des rôles résolus.
• Les exports CSV, Markdown et impression portent les mêmes chiffres, avec la mention de classification déduite uniquement là où une heuristique a réellement été utilisée.
• Le diagramme Sankey de l'aperçu lit les mêmes déclarations, donc un compte que vous avez marqué comme trésorerie cesse d'apparaître comme nœud de flux, et vos rôles d'activité déclarés sont honorés pour les comptes non-revenus.
• Le panneau d'état du compte cesse de lister un compte déclaré comme « actif non classifié ».

Il n'y a aucun moyen pour l'état et le diagramme d'être en désaccord sur ce qu'est votre trésorerie, car il n'y a qu'une seule réponse sur laquelle être en désaccord.

Pourquoi le grand livre, et non une page de paramètres​

C'est la partie de cette version à laquelle nous tenons le plus. Nous avons envisagé une interface de paramètres et l'avons rejetée, pour trois raisons :

1. Le grand livre est la source de vérité. Une classification qui vit ailleurs peut être en désaccord avec les livres qu'elle décrit. Une classification qui vit sur la directive open voyage avec le compte — à travers les renommages, les déplacements de dépôt, chaque client qui lit le fichier.
2. Le texte brut est diffable, greppable et révisable. Si vous gardez votre grand livre dans git — et si vous utilisez Beancount.io, c'est le cas — la règle de classification devient quelque chose que vous pouvez grep, diff et blame, et quelque chose qu'un réviseur peut voir dans une demande de tirage. Une page de paramètres n'est rien de tout cela.
3. Cela fonctionne hors ligne et partout. N'importe quel éditeur peut déclarer un rôle. N'importe quel client futur qui lit le grand livre obtient la classification gratuitement, avec zéro paramètre par client à synchroniser.

Pour la même raison, les classifications sont délibérément non datées. La métadonnée décrit la nature du compte, qui change rarement ; quand elle change, vous modifiez la directive open, et votre historique git enregistre ce qui a changé et quand. Cet historique est la piste d'audit.

Essayez-le sur votre grand livre​

La fonctionnalité est déployée sur tous les grands livres maintenant. Déclarer un rôle ne nécessite qu'un éditeur de texte :

1. Ouvrez le fichier où se trouve la directive open du compte.
2. Ajoutez cash-flow-role: "cash" (ou "operating", "investing", "financing") comme ligne de métadonnée en retrait en dessous.
3. Rechargez le rapport de flux de trésorerie. Votre déclaration l'emporte immédiatement sur l'heuristique.

Commencez par les comptes où l'estimation par défaut est incorrecte — le CD qui n'est pas vraiment de la trésorerie, le fonds monétaire qui l'est vraiment, le compte de courtage que vous voulez proprement sous les activités d'investissement. Laissez le reste tranquille. La spécification complète — valeurs acceptées, précédence, classifications par défaut, et comment les valeurs invalides sont traitées — se trouve dans la référence des rôles de flux de trésorerie.

Le rapport de flux de trésorerie fait partie de chaque grand livre Beancount.io, aux côtés du compte de résultat et du bilan. Si vous rattrapez votre retard sur ce qui d'autre a été livré cet été — des imports plus intelligents, un assistant IA capable d'actions, et une application mobile reconstruite — les notes de version 3.6 couvrent le reste.

Vos livres savaient déjà quels comptes sont des investissements et lesquels sont des dépenses quotidiennes. Maintenant, l'état des flux de trésorerie le sait aussi.