Reporting und KPIs

Finanzanalyse und Reporting: Ablauf und Best Practices

Finanzanalyse und Reporting an den wichtigen Zahlen erklärt: Rohertragsmarge, Working Capital und DSO, mit dem Power-BI-Modell, um sie zu bauen.

Sajagan Thirugnanam

·

Aktualisiert

Finanzanalyse und Reporting heißt, die Finanzdaten eines Unternehmens in KPIs wie Rohertragsmarge, Working Capital und DSO zu verwandeln und sie denen zu zeigen, die darauf handeln müssen, von der Abteilungsleitung bis zum Vorstand. In Power BI bedeutet das: Sie bauen ein Modell auf dem Hauptbuch und definieren jeden KPI einmal als Measure, statt ihn jedes Mal in einer Tabellenkalkulation neu zu berechnen, wenn jemand danach fragt. Dieser Leitfaden setzt voraus, dass Sie eine Hauptbuch-Tabelle und für den DSO eine Tabelle der Forderungen aus Lieferungen und Leistungen bereits in Ihr Power-BI-Modell geladen haben.

Die KPIs, die ein Finanzreport verfolgt

  • Gross Margin (Rohertragsmarge). Umsatz abzüglich der Herstellungskosten der verkauften Waren, meist als Prozentsatz des Umsatzes dargestellt.

  • Working Capital. Umlaufvermögen abzüglich kurzfristiger Verbindlichkeiten, ein Maß für die kurzfristige Liquidität.

  • Days Sales Outstanding (DSO). Die durchschnittliche Zahl der Tage, bis nach einem Verkauf die Zahlung eingeht.

  • Operating Expense. Kosten außerhalb der Herstellungskosten der verkauften Waren, etwa für Vertrieb, Marketing und Verwaltung.

  • EBITDA-Marge. Ergebnis vor Zinsen, Steuern und Abschreibungen, als Prozentsatz des Umsatzes.

Jede dieser Zahlen beantwortet eine andere Frage. Die Rohertragsmarge fragt, ob das Kerngeschäft profitabel ist. Working Capital und DSO fragen, ob das Geld schnell genug hereinkommt. Die EBITDA-Marge fragt, wie das Unternehmen dasteht, bevor Finanzierung und Bilanzierungsentscheidungen hinzukommen.

Das Datenmodell

Das meiste stammt aus dem Hauptbuch, dazu kommt für den DSO eine Tabelle der Forderungen:

Tabelle

Granularität

Schlüsselspalten

General Ledger (Fakt)

eine Zeile je Buchungszeile

EntryID, AccountKey, DateKey, CostCenterKey, Amount, DebitCredit

Chart of Accounts (Dimension)

eine Zeile je Konto

AccountKey, AccountName, AccountType, AccountGroup

Cost Center (Dimension)

eine Zeile je Kostenstelle

CostCenterKey, CostCenterName, Department

Date (Dimension)

eine Zeile je Tag

DateKey, Date, FiscalMonth, FiscalYear

Accounts Receivable (Fakt)

eine Zeile je Rechnung

InvoiceID, CustomerKey, InvoiceDate, DueDate, Amount, PaidDate

Die Spalten AccountType und AccountGroup in der Tabelle Chart of Accounts leisten die eigentliche Arbeit. Wenn Sie jedes Konto einmal als Revenue, COGS, Opex, Current Asset, Current Liability und so weiter kennzeichnen, kann jedes Measure unten auf dieses Kennzeichen filtern. Sie müssen keine Liste von Kontonummern fest eintragen, die beim nächsten Wechsel des Kontenplans angepasst werden muss.

Zentrale Measures in DAX

Revenue =
CALCULATE(
    SUM('General Ledger'[Amount]),
    'Chart of Accounts'[AccountType] = "Revenue"
)
COGS =
CALCULATE(
    SUM('General Ledger'[Amount]),
    'Chart of Accounts'[AccountType] = "COGS"
)
Gross Margin % =
DIVIDE([Revenue] - [COGS], [Revenue])
Working Capital =
VAR PeriodEnd = MAX('Date'[Date])
RETURN
CALCULATE(
    SUM('General Ledger'[Amount]),
    'Chart of Accounts'[AccountType] = "Current Asset",
    REMOVEFILTERS('Date'),
    'Date'[Date] <= PeriodEnd
) -
CALCULATE(
    SUM('General Ledger'[Amount]),
    'Chart of Accounts'[AccountType] = "Current Liability",
    REMOVEFILTERS('Date'),
    'Date'[Date] <= PeriodEnd
)
DSO =
VAR PeriodStart = MIN('Date'[Date])
VAR PeriodEnd = MAX('Date'[Date])
VAR PeriodDays = DATEDIFF(PeriodStart, PeriodEnd, DAY) + 1
VAR ReceivablesAtEnd =
    CALCULATE(
        SUM('Accounts Receivable'[Amount]),
        REMOVEFILTERS('Date'),
        'Accounts Receivable'[InvoiceDate] <= PeriodEnd,
        OR(
            ISBLANK('Accounts Receivable'[PaidDate]),
            'Accounts Receivable'[PaidDate] > PeriodEnd
        )
    )
RETURN
DIVIDE(ReceivablesAtEnd, [Revenue]) * PeriodDays

Zwei Dinge in diesen Measures gehen leicht schief:

  • Working Capital ist ein Bestand, keine Bewegung. Es addiert jede Buchung bis zum Ende des gewählten Zeitraums, nicht nur die Buchungen innerhalb davon. Deshalb entfernt das Measure den Datumsfilter und behält dann alles bis zum Periodenende.

  • Der DSO hängt von der Länge des Zeitraums ab. Er teilt die zum Periodenende noch offenen Forderungen durch den Umsatz der Periode und multipliziert dann mit der Zahl der Tage. Eine Auswahl von einem Monat und eine von einem Quartal liefern deshalb unterschiedliche Ergebnisse. Brauchen Leser eine stabile Zahl, legen Sie ein Standardfenster fest, etwa die letzten 90 Tage.

Die Measures gehen außerdem von einer einheitlichen Vorzeichenkonvention in Amount aus, etwa Umsatz als positive Zahl. Hauptbuch-Exporte speichern Habenbuchungen oft als negative Werte. Prüfen Sie das bei Ihren Daten und drehen Sie das Vorzeichen bei Bedarf um.

Aufbau des Reports

Ein Finanzreport verteilt sich meist auf drei Seiten, die jeweils eine andere Frage beantworten:

  1. Gewinn- und Verlustrechnung. Eine Matrix mit der Kontenhierarchie in den Zeilen und dem Monat in den Spalten, dazu Karten für Revenue, Gross Margin % und EBITDA-Marge.

  2. Bilanz und Working Capital. Umlaufvermögen und Verbindlichkeiten nach Kategorie, ein Verlauf des Working Capital über die Zeit und daneben das Measure DSO.

  3. Cashflow. Die von der operativen Tätigkeit erzeugten Mittel gegenüber den Mitteln, die in Finanzierung und Investitionen eingesetzt wurden, meist als Wasserfall, damit der Leser sieht, wo Geld hinein- und herausgeflossen ist.

Den Aufbau Schritt für Schritt beschreibt unser Leitfaden zum Erstellen eines Finanzreports. Wie sich diese Reports von anderen Report-Typen einer Finanzabteilung unterscheiden, lesen Sie unter Accounting-Reports: Definition und Typen.

Zwei Vorgehensweisen aus dem Reporting in Tabellenkalkulationen, die weiter gelten

Zwei Gewohnheiten aus dem Reporting in Tabellenkalkulationen gelten weiter, wenn der Report in Power BI liegt:

  • Passen Sie den KPI an die Branche an. Die Treiber des Cashflows unterscheiden sich bei einem Handelsunternehmen und einem Softwareunternehmen so stark, dass dieselbe Dashboard-Vorlage nicht für beide passt. Bauen Sie das Modell um die Konten, die für das beschriebene Unternehmen wirklich zählen.

  • Wissen Sie, wer den Report liest. Eine Vorstandspräsentation braucht drei oder vier Spitzenzahlen. Ein Controller, der den Abschluss prüft, braucht die komplette Kontenhierarchie. Beides aus einem Modell zu bauen, mit unterschiedlichen Seiten oder Report-Ansichten, ist einfacher, als zwei getrennte Dateien zu pflegen.

Eine vertriebsspezifische Version derselben Idee, angewandt auf Umsatz- und Pipeline-KPIs statt auf die GuV, steht in unserem Leitfaden zum Bau eines Sales-Dashboards.

Quellen

Finanzanalyse und Reporting heißt, die Finanzdaten eines Unternehmens in KPIs wie Rohertragsmarge, Working Capital und DSO zu verwandeln und sie denen zu zeigen, die darauf handeln müssen, von der Abteilungsleitung bis zum Vorstand. In Power BI bedeutet das: Sie bauen ein Modell auf dem Hauptbuch und definieren jeden KPI einmal als Measure, statt ihn jedes Mal in einer Tabellenkalkulation neu zu berechnen, wenn jemand danach fragt. Dieser Leitfaden setzt voraus, dass Sie eine Hauptbuch-Tabelle und für den DSO eine Tabelle der Forderungen aus Lieferungen und Leistungen bereits in Ihr Power-BI-Modell geladen haben.

Die KPIs, die ein Finanzreport verfolgt

  • Gross Margin (Rohertragsmarge). Umsatz abzüglich der Herstellungskosten der verkauften Waren, meist als Prozentsatz des Umsatzes dargestellt.

  • Working Capital. Umlaufvermögen abzüglich kurzfristiger Verbindlichkeiten, ein Maß für die kurzfristige Liquidität.

  • Days Sales Outstanding (DSO). Die durchschnittliche Zahl der Tage, bis nach einem Verkauf die Zahlung eingeht.

  • Operating Expense. Kosten außerhalb der Herstellungskosten der verkauften Waren, etwa für Vertrieb, Marketing und Verwaltung.

  • EBITDA-Marge. Ergebnis vor Zinsen, Steuern und Abschreibungen, als Prozentsatz des Umsatzes.

Jede dieser Zahlen beantwortet eine andere Frage. Die Rohertragsmarge fragt, ob das Kerngeschäft profitabel ist. Working Capital und DSO fragen, ob das Geld schnell genug hereinkommt. Die EBITDA-Marge fragt, wie das Unternehmen dasteht, bevor Finanzierung und Bilanzierungsentscheidungen hinzukommen.

Das Datenmodell

Das meiste stammt aus dem Hauptbuch, dazu kommt für den DSO eine Tabelle der Forderungen:

Tabelle

Granularität

Schlüsselspalten

General Ledger (Fakt)

eine Zeile je Buchungszeile

EntryID, AccountKey, DateKey, CostCenterKey, Amount, DebitCredit

Chart of Accounts (Dimension)

eine Zeile je Konto

AccountKey, AccountName, AccountType, AccountGroup

Cost Center (Dimension)

eine Zeile je Kostenstelle

CostCenterKey, CostCenterName, Department

Date (Dimension)

eine Zeile je Tag

DateKey, Date, FiscalMonth, FiscalYear

Accounts Receivable (Fakt)

eine Zeile je Rechnung

InvoiceID, CustomerKey, InvoiceDate, DueDate, Amount, PaidDate

Die Spalten AccountType und AccountGroup in der Tabelle Chart of Accounts leisten die eigentliche Arbeit. Wenn Sie jedes Konto einmal als Revenue, COGS, Opex, Current Asset, Current Liability und so weiter kennzeichnen, kann jedes Measure unten auf dieses Kennzeichen filtern. Sie müssen keine Liste von Kontonummern fest eintragen, die beim nächsten Wechsel des Kontenplans angepasst werden muss.

Zentrale Measures in DAX

Revenue =
CALCULATE(
    SUM('General Ledger'[Amount]),
    'Chart of Accounts'[AccountType] = "Revenue"
)
COGS =
CALCULATE(
    SUM('General Ledger'[Amount]),
    'Chart of Accounts'[AccountType] = "COGS"
)
Gross Margin % =
DIVIDE([Revenue] - [COGS], [Revenue])
Working Capital =
VAR PeriodEnd = MAX('Date'[Date])
RETURN
CALCULATE(
    SUM('General Ledger'[Amount]),
    'Chart of Accounts'[AccountType] = "Current Asset",
    REMOVEFILTERS('Date'),
    'Date'[Date] <= PeriodEnd
) -
CALCULATE(
    SUM('General Ledger'[Amount]),
    'Chart of Accounts'[AccountType] = "Current Liability",
    REMOVEFILTERS('Date'),
    'Date'[Date] <= PeriodEnd
)
DSO =
VAR PeriodStart = MIN('Date'[Date])
VAR PeriodEnd = MAX('Date'[Date])
VAR PeriodDays = DATEDIFF(PeriodStart, PeriodEnd, DAY) + 1
VAR ReceivablesAtEnd =
    CALCULATE(
        SUM('Accounts Receivable'[Amount]),
        REMOVEFILTERS('Date'),
        'Accounts Receivable'[InvoiceDate] <= PeriodEnd,
        OR(
            ISBLANK('Accounts Receivable'[PaidDate]),
            'Accounts Receivable'[PaidDate] > PeriodEnd
        )
    )
RETURN
DIVIDE(ReceivablesAtEnd, [Revenue]) * PeriodDays

Zwei Dinge in diesen Measures gehen leicht schief:

  • Working Capital ist ein Bestand, keine Bewegung. Es addiert jede Buchung bis zum Ende des gewählten Zeitraums, nicht nur die Buchungen innerhalb davon. Deshalb entfernt das Measure den Datumsfilter und behält dann alles bis zum Periodenende.

  • Der DSO hängt von der Länge des Zeitraums ab. Er teilt die zum Periodenende noch offenen Forderungen durch den Umsatz der Periode und multipliziert dann mit der Zahl der Tage. Eine Auswahl von einem Monat und eine von einem Quartal liefern deshalb unterschiedliche Ergebnisse. Brauchen Leser eine stabile Zahl, legen Sie ein Standardfenster fest, etwa die letzten 90 Tage.

Die Measures gehen außerdem von einer einheitlichen Vorzeichenkonvention in Amount aus, etwa Umsatz als positive Zahl. Hauptbuch-Exporte speichern Habenbuchungen oft als negative Werte. Prüfen Sie das bei Ihren Daten und drehen Sie das Vorzeichen bei Bedarf um.

Aufbau des Reports

Ein Finanzreport verteilt sich meist auf drei Seiten, die jeweils eine andere Frage beantworten:

  1. Gewinn- und Verlustrechnung. Eine Matrix mit der Kontenhierarchie in den Zeilen und dem Monat in den Spalten, dazu Karten für Revenue, Gross Margin % und EBITDA-Marge.

  2. Bilanz und Working Capital. Umlaufvermögen und Verbindlichkeiten nach Kategorie, ein Verlauf des Working Capital über die Zeit und daneben das Measure DSO.

  3. Cashflow. Die von der operativen Tätigkeit erzeugten Mittel gegenüber den Mitteln, die in Finanzierung und Investitionen eingesetzt wurden, meist als Wasserfall, damit der Leser sieht, wo Geld hinein- und herausgeflossen ist.

Den Aufbau Schritt für Schritt beschreibt unser Leitfaden zum Erstellen eines Finanzreports. Wie sich diese Reports von anderen Report-Typen einer Finanzabteilung unterscheiden, lesen Sie unter Accounting-Reports: Definition und Typen.

Zwei Vorgehensweisen aus dem Reporting in Tabellenkalkulationen, die weiter gelten

Zwei Gewohnheiten aus dem Reporting in Tabellenkalkulationen gelten weiter, wenn der Report in Power BI liegt:

  • Passen Sie den KPI an die Branche an. Die Treiber des Cashflows unterscheiden sich bei einem Handelsunternehmen und einem Softwareunternehmen so stark, dass dieselbe Dashboard-Vorlage nicht für beide passt. Bauen Sie das Modell um die Konten, die für das beschriebene Unternehmen wirklich zählen.

  • Wissen Sie, wer den Report liest. Eine Vorstandspräsentation braucht drei oder vier Spitzenzahlen. Ein Controller, der den Abschluss prüft, braucht die komplette Kontenhierarchie. Beides aus einem Modell zu bauen, mit unterschiedlichen Seiten oder Report-Ansichten, ist einfacher, als zwei getrennte Dateien zu pflegen.

Eine vertriebsspezifische Version derselben Idee, angewandt auf Umsatz- und Pipeline-KPIs statt auf die GuV, steht in unserem Leitfaden zum Bau eines Sales-Dashboards.

Quellen

Zeigen Sie uns Ihren Report, dem niemand traut.

1 · Ein Gespräch von 30 Minuten.

2 · Wir sehen uns gemeinsam Ihre aktuellen Reports an.

3 · Wir sagen Ihnen, was wir tun würden.

Zeigen Sie uns Ihren Report, dem niemand traut.

1 · Ein Gespräch von 30 Minuten.

2 · Wir sehen uns gemeinsam Ihre aktuellen Reports an.

3 · Wir sagen Ihnen, was wir tun würden.

Zeigen Sie uns Ihren Report, dem niemand traut.

1 · Ein Gespräch von 30 Minuten.

2 · Wir sehen uns gemeinsam Ihre aktuellen Reports an.

3 · Wir sagen Ihnen, was wir tun würden.

CaseWhen ist eine BI-Beratung aus Berlin. Wir bauen Reporting, dem die Geschäftsführung vertraut, auf dem Microsoft-Stack: Power BI, Fabric und Azure.

Berlin, Deutschland

© CaseWhen Consulting GmbH

Deutsch

CaseWhen ist eine BI-Beratung aus Berlin. Wir bauen Reporting, dem die Geschäftsführung vertraut, auf dem Microsoft-Stack: Power BI, Fabric und Azure.

Berlin, Deutschland

© CaseWhen Consulting GmbH

Deutsch

CaseWhen ist eine BI-Beratung aus Berlin. Wir bauen Reporting, dem die Geschäftsführung vertraut, auf dem Microsoft-Stack: Power BI, Fabric und Azure.

Berlin, Deutschland

© CaseWhen Consulting GmbH

Deutsch