Reporting financier automatisé : un flux à faire tourner, pas un fichier

Pourquoi le reporting fait à la main est faux avant d'être en retard

Le reporting mensuel repose sur deux états : la balance, qui donne les soldes par compte, et le grand livre, qui donne le détail des écritures. Tant qu'ils sont exportés à la main, deux choses se produisent. L'export est fait une fois, à une date : toute écriture passée après (une OD de cut-off, un lettrage corrigé, une pièce retrouvée) n'est pas dans le tableau. Et chaque colonne du classeur a été construite par une personne, avec des SOMME.SI sur des numéros de comptes qui pointent sur l'onglet du mois précédent. Au premier compte ouvert en cours d'année (un 6241, un nouvel auxiliaire en 411), la formule ne le voit pas.

Résultat : le temps du reporting sert à vérifier que le total du tableau retombe sur celui de la balance, au lieu de lire ce que les chiffres disent. Le compte 471 est le symptôme le plus courant. Un solde qui traîne en compte d'attente à la date de l'export, c'est de la charge ou du produit que le reporting range dans une ligne « divers », ou nulle part. Le tableau est juste arithmétiquement et faux comptablement.

Trois choses sortent du logiciel, et une seule est un chiffre

La balance donne les soldes, le grand livre le détail. Le FEC donne les deux dans un format normalisé : pour les exercices clos depuis 2013, toute entreprise qui tient sa comptabilité de façon informatisée doit pouvoir le présenter en cas de contrôle, dans une structure fixée par l'article A. 47 A-1 du livre des procédures fiscales, avec des champs nommés (JournalCode, EcritureDate, CompteNum, Debit, Credit, EcritureLet, entre autres) et des dates au format AAAAMMJJ. Ce format a une vertu que personne n'a prévue pour votre reporting : il est le même chez Pennylane, Sage, Cegid ou ACD. Un script qui lit un FEC lit tous les FEC.

En pratique, le FEC n'est pas toujours le meilleur point de départ pour un mensuel : certains logiciels ne le produisent qu'à la clôture. Les exports natifs sont alors la voie. Pennylane, par exemple, exporte le grand livre en Excel ou en PDF sur des dates personnalisées, et propose un complément Excel qui rafraîchit balance et grand livre depuis le classeur, réservé au plan Premium. Les autres éditeurs ont des exports comparables, chacun dans son format. Le point commun : ces exports sont manuels par défaut. Quelqu'un doit cliquer.

La troisième chose qui sort du logiciel n'est pas un chiffre, c'est l'état d'avancement de la tenue. La balance du 3 du mois n'a pas les FNP. Celle du 6 les a, mais pas l'extourne. Un reporting automatisé qui ignore où en est la tenue livre des chiffres exacts à une date que personne n'a choisie. D'où la règle : vérifier que les OD de cut-off (408 pour les FNP, 418 pour les FAE, 486 pour les CCA, 487 pour les PCA) sont passées sur la période avant de considérer le mois comme lisible. Le module FAE et FNP de Pennylane, par exemple, les génère à une date de situation intermédiaire, avec extourne automatique au lendemain. Il reste à vérifier qu'il a tourné.

Le flux : export chaque nuit, tableaux par script, écarts par un humain

Chaque nuit, un script sort la balance et le grand livre de la période depuis le logiciel de comptabilité, en format natif ou en FEC, et les dépose dans un dossier daté sur votre serveur ou votre poste. Rien n'est ressaisi. Le fichier de la nuit remplace celui de la veille, l'ancien est archivé.

Le même script applique un plan de mapping : chaque compte de la balance est rattaché à une ligne du reporting (chiffre d'affaires, achats consommés, charges externes, masse salariale, EBE, résultat). Ce mapping est un tableau à deux colonnes que vous tenez vous-même : numéro de compte, ligne de destination. Un compte que le mapping ne connaît pas fait échouer le traitement avec un message clair, plutôt que de tomber en silence dans « autres charges ».

Le script contrôle ensuite ce qui doit l'être : total débit égal total crédit, solde du 471 nul ou justifié, pointage des comptes 512 contre le dernier état de rapprochement, OD de cut-off présentes. Puis il remplit les tableaux : compte de résultat du mois et cumulé, comparaison au budget et à l'exercice précédent, trésorerie à date. Le classeur que vous ouvrez le matin est déjà rempli. Power Query permet le même geste côté Excel, avec une requête pointée sur le dossier des exports et une actualisation à l'ouverture du classeur.

Ce qui reste à une personne : le commentaire. Pourquoi les charges externes dépassent le budget ce mois-ci, si le pic de chiffre d'affaires est un effet de facturation ou de volume, si le solde qui reste en 471 est un problème. Aucun script ne le sait. Le flux lui donne le temps de le chercher, et un tableau dont les totaux sont ceux de la balance, sans exception.

Entre le modèle Excel gratuit et la BI : la place du script

Le marché propose deux réponses. Le modèle Excel gratuit, à remplir à la main chaque mois : il apprend la structure d'un reporting, il ne le produit pas. L'outil de BI en abonnement annuel : il produit le reporting, à condition d'accepter que la balance et le grand livre partent chez un tiers et que le mapping se fasse dans son interface.

Entre les deux, une troisième voie que les fiches produit ne décrivent pas : un script, écrit une fois, qui tourne sur votre poste ou votre serveur. Il lit vos exports, applique votre mapping, remplit votre classeur. Vos données ne sortent pas de chez vous. Pas d'abonnement : du code que vous possédez et que n'importe quel développeur peut relire.

Cette voie a ses conditions. Un poste ou un serveur allumé la nuit. Quelqu'un dans l'équipe qui accepte de tenir le fichier de mapping. Un logiciel de comptabilité qui permet l'export sans clic humain, ce qui n'est pas le cas de tous, et qui se vérifie avant d'écrire une ligne. Quand la réponse est non, le script peut tourner sur un export déposé à la main par le collaborateur : le flux perd la nuit, il garde tout le reste. Ce que cela donne sur un mois réel, contrôles compris, est décrit dans le cas d'usage [reporting financier mensuel](/cas-usage/reporting-financier-mensuel/).

Consolider plusieurs sociétés sans copier-coller

Dès qu'il y a une holding et deux filiales, le reporting mensuel devient une consolidation, même si le groupe est dispensé de comptes consolidés. Pour mémoire, l'article L233-17 du code de commerce dispense les groupes qui ne sont pas des grands groupes au sens de l'article L230-2 : deux des trois seuils de l'article D230-2 (30 millions d'euros de bilan, 60 millions de chiffre d'affaires, 250 salariés) dépassés sur deux exercices consécutifs. Mais un dirigeant veut voir le groupe chaque mois, dispense ou pas.

Fait à la main, cela veut dire trois balances copiées dans trois onglets, un onglet de somme, et des éliminations intra-groupe faites de tête : les frais de siège facturés par la holding, le compte courant entre filiales, le loyer de la SCI. Si l'une des balances est sortie un jour après les autres, le groupe ne retombe pas, et personne ne sait sur quelle société.

En flux, chaque société a son export nocturne, son mapping (les plans de comptes ne sont jamais identiques d'un dossier à l'autre) et sa date d'arrêté. Le script agrège, applique une table d'éliminations que vous tenez (compte, contrepartie, société), et sort trois choses : le reporting par société, le reporting groupe, et la liste des écritures intra-groupe qui ne se neutralisent pas. Cette dernière liste vaut le reste : c'est elle qui dit que la filiale B a comptabilisé la facture de la holding sur un autre mois. Le cas d'usage [consolidation multi-établissements](/cas-usage/consolidation-multi-etablissements/) détaille ce que cela demande quand les dossiers sont tenus dans des logiciels différents.

Par quoi commencer, avec ou sans nous

Ouvrez votre dernier reporting et la balance du même mois. Listez les comptes de la balance qui ne figurent nulle part dans le tableau. C'est votre écart réel, et c'est souvent votre 471.

Écrivez le fichier de mapping. Deux colonnes, tous les comptes, sans exception. C'est l'étape qu'aucun outil ne fait correctement à votre place, parce que c'est une décision de gestion : le 6226, dans les honoraires ou dans les charges externes ? Vérifiez ensuite comment votre logiciel exporte sans clic : demandez au cabinet ou à l'éditeur, la réponse décide de la suite. Puis fixez la règle de lecture du mois : quelles OD doivent être passées pour que le reporting soit lisible, et qui les passe.

Un script ne remplacera pas l'expert-comptable pour la révision, ne décidera pas d'une provision, ne commentera pas un écart. Il sort, il contrôle, il remplit. C'est ce genre de script, sur vos machines, que construit OSERIA.

Pour aller plus loin sur ce site

• Cas d’usage : le reporting financier mensuel
• Cas d’usage : la consolidation multi-établissements