In projektgetriebenen Unternehmen entscheidet nicht allein der Umsatz darüber, ob Wachstum wirtschaftlich gesund ist. Entscheidend ist, was zwischen Auftrag, Delivery und Zahlung passiert: Welche Marge wurde verkauft? Wie entwickelt sich der erwartete Restaufwand? Welche Leistungen wurden bereits erbracht, aber noch nicht fakturiert? Und wie schnell wird aus operativer Leistung tatsächlich Cash?
Genau hier entstehen in Engineering-, IT- und Beratungsunternehmen häufig blinde Flecken. Sales kennt den Deal, Delivery kennt den Fortschritt, Projektleitung kennt Risiken und Finance kennt Ist-Kosten sowie Rechnungen. Wenn diese Informationen nicht in einem gemeinsamen Steuerungsmodell zusammenlaufen, wird Projektmarge zur rückblickenden Kennzahl statt zum aktiven Führungsinstrument.
Dieser Beitrag zeigt, wie Project Margin, WIP, Billing und Cash als zusammenhängende Steuerungskette gedacht werden sollten und welche Rolle Dynamics 365 Project Operations und Finance dabei übernehmen können.
Warum Projektprofitabilität früher beginnt als im Monatsabschluss
Die wirtschaftliche Qualität eines Projekts wird bereits vor Projektstart geprägt. Preis, Scope, Rollenmix, externe Leistungen, Vertragsmodell, Zahlungsplan und Annahmen bestimmen, welcher wirtschaftliche Korridor überhaupt erreichbar ist. Der Monatsabschluss zeigt später nur, wie viel davon realisiert wurde.
Für ein steuerbares Projektgeschäft braucht es deshalb eine durchgängige Logik von WIN → PLAN → DELIVER → PROFIT. Im Zealon Operating Model ist PROFIT nicht nur der letzte Prozessschritt. Die Profitabilitätslogik muss bereits in WIN und PLAN angelegt sein.
- WIN: Welche Marge wurde im Angebot verkauft und auf welchen Annahmen basiert sie?
- PLAN: Welche Ressourcen, Kosten und externen Leistungen werden tatsächlich benötigt?
- DELIVER: Wie verändern Fortschritt, Restaufwand, Changes und tatsächliche Kosten den Forecast?
- PROFIT: Welche Leistung ist fakturierbar, welche liegt im WIP und wann wird daraus Cash?
Die fünf Ebenen der wirtschaftlichen Projektsteuerung
1. Sold Margin: Welche Wirtschaftlichkeit wurde verkauft?
Die erste relevante Marge entsteht im Angebot. Ein Projekt mit einem attraktiven Umsatzvolumen kann wirtschaftlich schwach sein, wenn zu niedrige Preise, ein ungünstiger Senioritätsmix oder unrealistische Aufwandsschätzungen zugrunde liegen.
Deshalb sollte ein projektgetriebenes Unternehmen bereits im Sales-Prozess mindestens folgende Größen kennen: geplante Erlöse, geplante interne Kosten, externe Leistungen, erwartete Bruttomarge, kritische Annahmen und gegebenenfalls einen Risikopuffer. Besonders wichtig ist, dass diese Informationen beim Handover nicht verloren gehen.
2. Forecast Margin: Wie entwickelt sich die erwartete Marge?
Nach Projektstart ist die ursprüngliche Kalkulation nur noch eine Baseline. Für die Steuerung zählt der aktuelle Forecast. Dazu gehören tatsächliche Kosten, verbleibender Aufwand, erwartete externe Leistungen, offene Changes und der aktuelle Revenue Forecast.
Eine zentrale Kennzahl ist der Estimate to Complete: Welcher Aufwand wird voraussichtlich noch benötigt, um das Projekt zu beenden? Wird dieser Wert regelmäßig aktualisiert, kann Finance die erwartete Projektmarge deutlich früher erkennen als über reine Ist-Kosten.
Microsoft unterstützt in Dynamics 365 Project Operations und Finance unterschiedliche Forecast- und Cost-to-Complete-Logiken. Je nach Architektur und Revenue-Recognition-Modell können tatsächliche Kosten und Forecasts für die finanzielle Projektsteuerung zusammengeführt werden.
3. WIP: Welche Leistung steckt zwischen Delivery und Rechnung?
Work in Progress ist im Projektgeschäft eine der wichtigsten, aber häufig missverstandenen Größen. WIP kann unterschiedliche wirtschaftliche und buchhalterische Bedeutungen haben. Aus Managementsicht beschreibt es vor allem Leistung oder Kosten, die bereits entstanden sind, aber noch nicht vollständig in fakturierten Umsatz überführt wurden.
Ein hoher WIP-Bestand ist nicht automatisch problematisch. Bei langfristigen Festpreisprojekten oder vertraglich definierten Meilensteinen kann er strukturell entstehen. Kritisch wird WIP, wenn unklar ist, warum er wächst und wann er abgebaut wird.
- Zeiten wurden erbracht, aber noch nicht genehmigt.
- Leistungen sind genehmigt, aber noch nicht fakturierbar.
- Ein Meilenstein ist operativ erreicht, aber formal noch nicht abgenommen.
- Change Requests werden bereits geliefert, sind aber kaufmännisch nicht freigegeben.
- Rechnungen warten auf interne Prüfung oder kundenspezifische Nachweise.
Die relevante Managementfrage lautet deshalb nicht nur: „Wie hoch ist unser WIP?“ Sondern: Aus welchem Grund liegt Leistung im WIP und was verhindert die Umwandlung in fakturierbaren Umsatz?
4. Billing: Wie schnell wird Leistung fakturiert?
Zwischen wirtschaftlich erbrachter Leistung und Cash liegt der Billing-Prozess. In vielen Projektunternehmen ist dieser Prozess unnötig langsam: Zeiten kommen spät, Projektleiter prüfen manuell, Leistungsnachweise fehlen, Meilensteine sind nicht eindeutig dokumentiert oder Finance muss Informationen aus mehreren Systemen zusammentragen.
Ein sinnvoller KPI ist der Billing Lag: Wie viel Zeit liegt zwischen Leistungserbringung beziehungsweise Billing Event und Rechnungsstellung? Je nach Vertragsmodell sollte dieser KPI unterschiedlich interpretiert werden, aber seine Entwicklung zeigt sehr gut, ob operative Leistung schnell genug in Forderungen überführt wird.
5. Cash: Wann wird aus der Rechnung Liquidität?
Mit der Rechnung endet die Projektsteuerung nicht. Zahlungsbedingungen, Dispute, Rechnungskorrekturen, kundenspezifische Portale und fehlende Nachweise können den Cash-Eingang weiter verzögern. Für CFO und COO ist deshalb der gesamte Zyklus relevant: Delivery → Approval → Billing → Receivable → Cash.
Microsoft beschreibt „Manage project financials“ ausdrücklich als Teil des End-to-End-Prozesses „Project to profit“. Dazu gehören unter anderem Budget, Rechnungsstellung, Zahlungsstatus, Projekttransaktionen und Revenue Recognition. Der Nutzen liegt nicht in einer einzelnen Finance-Funktion, sondern in der Verbindung dieser Schritte.
Vertragsmodelle verändern die Finance-Logik
Ein häufiger Fehler ist, dieselbe Margen- und Billing-Logik auf alle Projekte anzuwenden. Time & Material, Festpreis und Meilensteinverträge erzeugen unterschiedliche Risiken und Steuerungsanforderungen.
Time & Material
Bei Time & Material ist die Verbindung zwischen Leistung, Zeiterfassung, Freigabe und Billing besonders direkt. Relevant sind unter anderem:
- Auslastung und fakturierbare Auslastung
- Rate Realization und Preisabweichungen
- vollständige und rechtzeitige Zeiterfassung
- nicht fakturierbare Leistungen
- Billing Lag
- unbilled Revenue beziehungsweise WIP
Dynamics 365 Project Operations unterstützt für Time-and-Material-Projekte unter anderem die Abrechnung auf Basis von Stunden, Spesen, Artikeln und Gebühren. Abhängig vom Accounting-Setup kann unbilled Sales Value auch als WIP und accrued Revenue im Ledger verarbeitet werden.
Festpreis
Bei Festpreisprojekten liegt das Risiko stärker im Verhältnis zwischen vereinbartem Erlös und tatsächlichem beziehungsweise erwartetem Aufwand. Deshalb werden Forecast, Estimate to Complete, Change Control und Fortschrittsmessung besonders wichtig.
Microsoft unterstützt für Fixed-Price-Projekte verschiedene Accounting- und Revenue-Recognition-Prinzipien, darunter Completed Contract und Percentage Completion. Welche Methode eingesetzt werden darf und sinnvoll ist, hängt von Accounting-Regeln, Vertragsstruktur und dem konkreten Szenario ab. Diese Entscheidung gehört in das Finance- und Solution-Design, nicht in eine nachgelagerte Systemkonfiguration.
Meilenstein- und leistungsbasierte Abrechnung
Bei Milestone Billing ist nicht jede erbrachte Stunde unmittelbar fakturierbar. Entscheidend ist, ob das vertraglich definierte Billing Event erreicht und nachweisbar ist. Deshalb müssen Projektfortschritt, Abnahme und Rechnungsvoraussetzungen eng verbunden werden.
Das Ziel ist eine transparente Billing Backlog-Sicht: Welche Meilensteine sind geplant, welche fachlich erreicht, welche freigegeben und welche fakturiert? Genau dort lassen sich Verzögerungen zwischen Delivery und Cash sichtbar machen.
Die wichtigsten KPIs für CFO und COO
Ein gutes Finance-Operating-Model erzeugt nicht möglichst viele Kennzahlen, sondern wenige Kennzahlen mit klarer Entscheidungsrelevanz. Für projektgetriebene Unternehmen sind insbesondere folgende Größen wertvoll:
- Sold Margin: Welche Bruttomarge wurde im Auftrag ursprünglich kalkuliert?
- Forecast Margin: Welche Marge erwarten wir heute auf Basis von Ist und Restaufwand?
- Margin Variance: Wie stark weicht die Forecast Margin von der Sold Margin ab?
- Estimate to Complete: Welcher Aufwand wird bis Projektende noch benötigt?
- WIP: Welche Leistung beziehungsweise welcher Wert ist noch nicht vollständig fakturiert oder ergebniswirksam verarbeitet?
- Unbilled Revenue: Welche fakturierbare oder abgrenzbare Leistung ist noch nicht in einer Kundenrechnung?
- Billing Backlog: Welche Rechnungsereignisse sind offen?
- Billing Lag: Wie lange dauert es von Leistung oder Meilenstein bis zur Rechnung?
- DSO: Wie lange dauert es nach Rechnungsstellung bis zum Zahlungseingang?
- Cash Conversion: Wie schnell wird erbrachte Projektleistung insgesamt in Cash überführt?
Wichtig ist, dass diese KPIs nicht isoliert betrachtet werden. Ein sinkender Billing Lag hilft wenig, wenn die Forecast Margin bereits deutlich gefallen ist. Eine hohe Auslastung kann sogar negativ sein, wenn zusätzliche Stunden in Festpreisprojekten nicht zu zusätzlichem Revenue führen.
Welche Managementfragen sollten jederzeit beantwortbar sein?
- Welche Projekte liegen bei Forecast Margin außerhalb des Zielkorridors?
- Wo ist der Restaufwand schneller gestiegen als der erwartete Revenue?
- Welche Change Requests beeinflussen bereits Kosten, sind aber noch nicht vertraglich abgesichert?
- Wo wächst WIP und aus welchem operativen Grund?
- Welche Leistungen könnten heute fakturiert werden, werden es aber noch nicht?
- Welche Kunden oder Projektarten verursachen systematisch lange Billing-Zyklen?
- Welche Business Unit erreicht hohe Auslastung, aber eine schwache Rate Realization?
- Welche Projekte liefern Umsatz, binden aber überproportional Cash?
- Welche Forecast-Abweichungen sind Einzelfälle und welche strukturell?
Wenn diese Fragen nur über manuell zusammengeführte Excel-Dateien beantwortet werden können, liegt das Problem meist nicht im Reporting. Es liegt in getrennten Prozess- und Datenmodellen zwischen Sales, Delivery und Finance.
Die Rolle von Dynamics 365 Project Operations und Finance
Dynamics 365 Project Operations verbindet projektbezogenen Sales, Ressourcen, Projektsteuerung und Finance-Prozesse. Für die wirtschaftliche Steuerung sind besonders Projektbudgets, Actuals, Kosten, Billing, Revenue Recognition und je nach Deployment-Modell die Integration in Dynamics 365 Finance relevant.
Microsoft dokumentiert für Project Operations unterschiedliche Project Cost and Revenue Profiles. Damit lassen sich Accounting-Regeln für Time & Material und Fixed Price definieren. Bei langfristigen Projekten können WIP-Mechanismen eingesetzt werden, während für andere Szenarien Kosten und Revenue direkt in Profit-and-Loss-Konten laufen.
Ein tieferer Überblick über Architektur, Deployment-Modelle und Funktionsumfang findet sich in unserem Dynamics 365 Project Operations Leitfaden 2026.
Die offizielle Microsoft-Dokumentation zu den Finance-Prozessen finden Sie unter Manage project financials sowie unter Configure accounting for billable projects.
Sieben typische Ursachen für Margin Leakage
1. Der Angebots- und Delivery-Forecast sind getrennt
Sales verkauft auf Basis anderer Annahmen als Delivery später plant. Schon beim Projektstart ist deshalb unklar, ob die verkaufte Marge realistisch erreichbar ist.
2. Estimate to Complete wird nicht regelmäßig gepflegt
Wenn nur Ist-Kosten gegen Budget betrachtet werden, werden Margenprobleme häufig zu spät sichtbar. Der Restaufwand muss Teil der laufenden Projektsteuerung sein.
3. Changes werden operativ vor kaufmännischer Freigabe geliefert
Zusatzaufwand erhöht Kosten sofort, Revenue aber erst nach erfolgreicher kommerzieller Absicherung. Fehlendes Change Control ist deshalb ein direkter Margin-Leak.
4. Zeit- und Spesenerfassung ist zu langsam
Verspätete Actuals verzerren Forecasts und verschieben Billing. Besonders bei T&M wird aus administrativer Disziplin unmittelbar ein Finance-Thema.
5. Billing Events sind nicht mit Delivery verbunden
Wenn Projektleitung und Finance unterschiedliche Sichtweisen auf Abnahme, Milestones und Fakturierbarkeit haben, wächst der Billing Backlog.
6. Projektstrukturen sind zu detailliert oder zu grob
Zu viel Granularität erzeugt administrativen Aufwand. Zu wenig Granularität verhindert wirtschaftliche Transparenz. Die Struktur muss so gewählt werden, dass Scope, Kosten, Progress, Changes und Billing sinnvoll steuerbar bleiben.
7. Finance wird als Reporting-Empfänger statt als Prozesspartner gesehen
Finance sollte Vertragslogik, Projektstruktur, Revenue Recognition, WIP und Billing nicht erst nach Go-live bewerten. Diese Themen gehören bereits in das Target Operating Model.
Ein sinnvolles Target Operating Model für Project Finance
Ein skalierbares Modell trennt Verantwortungen klar und verbindet sie über gemeinsame Daten und Entscheidungspunkte.
- Sales verantwortet belastbare kommerzielle Annahmen und einen sauberen Handover.
- Project Management verantwortet Fortschritt, Restaufwand, Risiken und Change Signals.
- Resource Management stellt Kosten- und Kapazitätsrealität für Staffing und Forecast bereit.
- Finance verantwortet Accounting-Regeln, WIP, Revenue Recognition, Billing und finanzielle Kontrolllogik.
- Management steuert über gemeinsame Zielkorridore für Marge, WIP, Billing und Cash.
Technologie wird anschließend so konfiguriert, dass diese Verantwortungen unterstützt werden. Die Reihenfolge ist wichtig: Erst Operating Model und Steuerungslogik, dann Systemdesign.
Von Project Finance zu einem skalierbaren Digital Backbone
Für wachsende Engineering-, IT- und Beratungsunternehmen reicht es nicht, Projektcontrolling zu verbessern. Mit mehreren Teams, Standorten oder Gesellschaften müssen dieselben Definitionen für Projektmarge, WIP, Billing und Forecast über das Unternehmen hinweg gelten.
Gerade bei internationalem Wachstum und PE / Buy & Build wird diese Standardisierung zum Integrationshebel. Ein neues Add-on lässt sich wirtschaftlich nur dann vergleichbar steuern, wenn Projektarten, Margendefinitionen, Revenue-Logik, Ressourcenmodelle und Finance-KPIs nicht jedes Mal neu erfunden werden.
Der passende Rahmen dafür ist ein ERP Core Template und Rollout-Modell, das einen verbindlichen Group Core mit begründeter lokaler Flexibilität verbindet.
Wie sollte eine Transformation starten?
Der beste Startpunkt ist nicht die Frage, welches Dashboard fehlt. Zuerst sollte geklärt werden, wo im heutigen Project-to-Cash-Prozess wirtschaftlicher Wert verloren geht.
- Baseline: Wie werden Sold Margin, Forecast Margin, WIP, Billing und Cash heute definiert?
- Breakpoints: An welchen Übergängen entstehen Verzögerungen oder Informationsverluste?
- Ownership: Wer verantwortet Forecast, Change, Billing Readiness und Finance Rules?
- Target Model: Welche Steuerungslogik soll künftig verbindlich gelten?
- Platform: Welche Rolle übernehmen Project Operations, Finance, Power Platform und bestehende Systeme?
- Value Releases: Welche Prozessverbesserungen liefern zuerst messbaren wirtschaftlichen Nutzen?
Das Digital Backbone Assessment setzt genau an diesen Übergängen zwischen Pipeline, Ressourcen, Projekten und Finance an. Wenn das Zielmodell bereits klarer ist, kann der Operating Model & Solution Blueprint Prozesse, Rollen, Daten und Plattformarchitektur konkretisieren.
Fazit: Profit entsteht nicht im Reporting
Project Margin, WIP, Billing und Cash sind keine vier getrennten Finance-Themen. Sie beschreiben denselben wirtschaftlichen Prozess aus unterschiedlichen Perspektiven. Eine schwache Sold Margin kann später kaum „wegkontrolliert“ werden. Ein schlechter Forecast macht Margenprobleme unsichtbar. Unklares WIP verdeckt operative Blockaden. Langsames Billing bindet Liquidität.
Projektprofitabilität wird deshalb dort steuerbar, wo Sales, Delivery und Finance mit denselben wirtschaftlichen Annahmen und Daten arbeiten. Dynamics 365 kann dafür eine starke Plattform sein. Entscheidend bleibt aber das Operating Model dahinter.
Wo verliert Ihr Projektgeschäft heute Marge oder Cash?
Das Digital Backbone Assessment zeigt, welche Brüche zwischen Pipeline, Ressourcen, Delivery und Finance heute den größten wirtschaftlichen Hebel bieten.


