ES
ERVIS SEFERI
Finance · Business · Technologie
← Retour · Je partage mes connaissances
IA & Automatisation · Power BI

Le moins qui manque à l'addition

Sans normalisation du signe comptable, une mesure DAX qui somme Débit moins Crédit rend un compte de produit négatif — et casse l'addition d'un compte de résultat. Comment poser la colonne qui corrige ça, et la hiérarchie qui va avec.

Le modèle construit dans l'article précédent tient debout : quatre tables, trois relations à sens unique, une table de dates marquée. Un premier test le fait pourtant vaciller. Une mesure aussi simple que SUM(Fait_Ecritures[Debit]) - SUM(Fait_Ecritures[Credit]), déposée sur le compte de ventes 701000, renvoie un nombre négatif. Le chiffre d'affaires ne devrait jamais s'afficher en négatif.

Comparaison avant/après de la normalisation du signe sur des comptes de charge et de produit
Même écriture, même montant : seul le sens du calcul change selon qu'on lit un compte de charge ou un compte de produit.

Le problème, en une phrase

Un compte de charge est normalement débiteur : Débit moins Crédit donne un nombre positif. Un compte de produit est normalement créditeur : c'est l'inverse, Crédit moins Débit, qui donne un nombre positif. Une seule formule appliquée aveuglément aux deux familles de comptes donne systématiquement le mauvais signe à l'une des deux. Et un compte de résultat qui additionne un chiffre d'affaires négatif à des charges positives ne ressemble à rien de connu.

SigneAttendu : la colonne qui décide du sens

La dimension du plan comptable porte, dans ce modèle, une colonne SigneAttendu : 1 pour un compte de charge, -1 pour un compte de produit. Elle ne sert à rien seule. Elle devient utile au moment où on l'utilise pour orienter un calcul ligne par ligne dans Power Query — pas dans une mesure DAX, parce que ce calcul ne dépend d'aucun contexte de filtre : il donne toujours le même résultat pour la même ligne, qu'on le fasse une fois au chargement ou à chaque clic.

Construire la colonne, étape par étape

  1. Dans l'éditeur Power Query, sélectionner la requête de la table de faits.
  2. Fusionner les requêtes avec la dimension du plan comptable, jointure gauche sur la colonne Compte, pour récupérer temporairement SigneAttendu.
  3. Ajouter une colonne personnalisée nommée Montant Net :
Fenêtre Power Query Colonne personnalisée avec la formule if SigneAttendu encadrée en rouge
La condition porte sur SigneAttendu, jamais sur le numéro de compte : la règle reste valable si le plan comptable change.
  1. Supprimer la colonne SigneAttendu importée par la fusion — elle a servi, elle n'a plus besoin de rester dans la table de faits.
  2. Fermer et appliquer.
SigneAttendu reste disponible pour toute autre mesure qui en aurait besoin, via la relation de modèle vers la dimension. Le retirer de la table de faits n'efface rien : ça évite seulement de porter deux fois la même information.

Vérifier avant de construire quoi que ce soit d'autre

Énoncé

Créer une mesure temporaire Total Montant Net = SUM(Fait_Ecritures[Montant Net]), la déposer dans une Carte filtrée d'abord sur les charges, puis sur les produits, et confirmer que les deux totaux sortent positifs.

Solution

Filtrer par Dim_PlanComptable[CategoriePL] = "Charges" : la carte affiche un total positif. Changer le filtre sur "Produits" : la carte affiche également un total positif. Si l'un des deux reste négatif, la colonne Montant Net porte encore une erreur de signe — revenir à l'étape 3 avant de continuer.

Résultat attendu

FiltreTotal Montant Net
CategoriePL = Charges121 350,40
CategoriePL = Produits46 260,00

Une hiérarchie, pour ne pas réécrire la mesure à chaque niveau

Le plan comptable porte trois niveaux de lecture : le résultat net au sommet, le résultat d'exploitation et le résultat financier au milieu, puis les catégories fines — chiffre d'affaires, charges de personnel, charges d'exploitation, charges et produits financiers. Les trois colonnes réunies en une hiérarchie Power BI permettent un drill-down dans une Matrice sans dupliquer aucune mesure : Power BI applique la même formule à chaque niveau, seul le contexte de filtre change.

Arbre de la hiérarchie P&L à trois niveaux, du résultat net aux catégories fines
Une seule mesure Résultat net, déposée une seule fois : le niveau affiché dans la Matrice décide seul de la profondeur du calcul.

Énoncé

Écrire les mesures nécessaires pour afficher un compte de résultat complet, utilisable à n'importe quel niveau de la hiérarchie.

Solution

  1. Chiffre d'affaires = CALCULATE(SUM(Fait_Ecritures[Montant Net]), Dim_PlanComptable[Niveau3] = "Chiffre d'affaires")
  2. Charges d'exploitation = CALCULATE(SUM(Fait_Ecritures[Montant Net]), Dim_PlanComptable[Niveau2] = "Résultat d'exploitation", Dim_PlanComptable[CategoriePL] = "Charges")
  3. Résultat d'exploitation = [Chiffre d'affaires] - [Charges d'exploitation]
  4. Résultat financier : la différence entre les produits financiers et les charges financières, chacun isolé par son Niveau3.
  5. Résultat net = [Résultat d'exploitation] + [Résultat financier]

Résultat attendu

MesureValeur
Chiffre d'affaires46 260,00
Charges d'exploitation121 350,40
Résultat d'exploitation-75 090,40
Résultat financier-1 615,00
Résultat net-76 705,40
Le résultat sort négatif sur ce jeu d'écritures : ce n'est pas la performance d'une entreprise réelle, seulement un échantillon d'exercice où les charges de personnel dominent un très petit volume de ventes. La formule de Résultat d'exploitation ci-dessus ignore les autres produits d'exploitation parce qu'ils sont à zéro sur cette période — un commentaire dans le fichier de mesures doit le signaler, pour la période où ce ne sera plus vrai.

Le compte de résultat tient, mais il tient seul : rien ne garantit encore qu'il corresponde à ce qu'un système comptable indépendant calculerait sur les mêmes écritures. La suite réconcilie le modèle avec un export de contrôle, et trouve un écart de 850 euros que personne n'avait signalé : L'écart que le modèle ne voit pas.

Versions : article rédigé d'après Power BI Desktop, mise à jour d'août 2026 (interface en français). Les fonctions DAX utilisées (CALCULATE, SUM) sont disponibles dans les versions actuelles ; les noms de menus peuvent changer au fil des mises à jour mensuelles.