Projektcontrolling im Scale-up und PE-Portfolio: Welche KPIs Investoren erwarten

Sie bereiten eine Funding-Runde, eine Akquisition oder ein Investor-Update vor und wissen, dass Ihr Projektreporting nicht investor-ready ist. Oder Sie wachsen in einem projektbasierten Geschäft und verlieren bei steigendem Volumen den Überblick über die Projektmarge. Beide Situationen sind die häufigsten Auslöser, Projektcontrolling neu aufzusetzen. Die meisten DACH-Inhalte zu Startup- und Mittelstand-Controlling sind für SaaS-Modelle geschrieben (Subskriptionsumsatz, MRR, ARR, Net Revenue Retention) und passen für projektbasierte Unternehmen nicht. Anlagen- und Maschinenbau, Cleantech-EPC (Solar, Wind, Battery Storage, Wärmepumpe-Installation), Defense-Tech und Dual-Use, Engineering Services und Systemintegration: in all diesen Modellen entstehen Marge und Cash anders als in einem Subskriptionsgeschäft. Vorlaufender Aufwand, lange Laufzeiten, ungleichmäßige Cash-Verläufe, Projektrisiken in jeder Marge. Wer das in einem klassischen SaaS-Reporting abbildet, verschleiert die wirtschaftliche Realität und verliert in der Investorenkommunikation Vertrauen. Dieser Artikel richtet sich an drei Zielgruppen mit demselben Pain: CFOs in VC-backed Scale-ups, CFOs in PE-Portfolio-Companies und Operating Partner oder Fund Manager, die Reporting-Standards über mehrere Portfolio-Companies hinweg bauen. Er zeigt, welche KPIs Investoren in Projektgeschäften tatsächlich lesen, wie Bilanzierung in DACH funktioniert und welche Fehler in der Investor-Kommunikation am häufigsten vorkommen.

Wenn Sie gerade in einer dieser Situationen sind

Vier akute Pain-Situationen, in denen Founder, CFOs und PE-Manager dieses Material in der Regel suchen:

• Series-A- oder Series-B-Vorbereitung in 8 bis 16 Wochen, kein belastbares Project P&L: der häufigste Trigger. Investor erwartet Projektmargen-Trend, Backlog mit Coverage Ratio und Cash-Profile pro Vertragstyp; bestehendes Reporting liefert nur Periodenrechnung. Lösung beginnt im Abschnitt Die vier Kerngrößen und der dortigen KPI-Architektur.
• Akquisition mit chaotischen Projekt-Daten: nach Closing zeigt sich, dass die Zielgesellschaft keine Projektmarge nachvollziehbar liefern kann. Investor (PE) erwartet Konsolidierung in das Holding-Reporting innerhalb von ein bis zwei Quartalen. Lösung beginnt mit der KPI-Definitions-Frage und dem ERP-Setup, behandelt im Abschnitt Operating-Partner-Sicht.
• Marge erodiert bei Wachstum, Ursache unklar: Umsatz steigt, EBITDA-Marge sinkt, niemand weiß, ob Mix-Effekt oder operative Verschlechterung. Lösung erfordert Projektmarge-Variance-Tracking und Senior-Junior-Mix-Analyse, je nach Branche.
• Investor verlangt Backlog-Forecast und Cash-Profil pro Vertragstyp: Standard-FiBu liefert das nicht. Antworten gehen über DSO hinaus und brauchen Working-Capital-Profil pro Projekt-Phase, behandelt im Abschnitt Cash Conversion Cycle.

Wichtig zu wissen: Sauberes Projektcontrolling lässt sich nicht in 8 bis 12 Wochen vor Term-Sheet-Frist neu aufbauen. Realistisch sind sechs Monate Vorlauf, um historische Projekt-Daten zu rekonstruieren, KPI-Definitionen zu verankern und das ERP-Setup so anzupassen, dass laufende Daten in der nötigen Granularität anfallen. Wer akuter dran ist, sollte mit einer Triage starten: welche drei KPIs in welcher Tiefe bis zum DD-Termin glaubhaft belegbar sein müssen.

Warum Projektcontrolling einer eigenen Logik folgt

Drei strukturelle Unterschiede prägen projektbasierte Geschäftsmodelle. Erstens: Umsatz und Aufwand fallen zeitversetzt an. Ein Projekt mit zwölf Monaten Laufzeit produziert in Monat 1 Vorleistung, in Monat 6 Teilrechnungen, in Monat 12 Schlussabnahme. Zweitens: Marge entsteht nicht laufend, sondern erst bei Projektabschluss oder Etappenfertigstellung. Drittens: Risiko verteilt sich asymmetrisch. Ein Projekt kann sechs Monate planmäßig laufen und im siebten Monat in einer technischen Komplikation 30 Prozent Marge verlieren.

Klassisches monatliches Reporting blendet diese Realität aus. Wer Projekte mit periodenbezogenen Umsatz- und Aufwandszuordnungen darstellt, sieht nicht, ob das Geschäft gesund ist. Investoren, die das verstanden haben, fragen nach Projekt-P&L pro Auftrag, nach Backlog-Konversion und nach Cash-Profilen je Vertragstyp. Wer diese Antworten nicht liefern kann, signalisiert, dass im Unternehmen niemand die Projektökonomie in der Tiefe versteht.

Die vier Kerngrößen, die Investoren tatsächlich lesen

Projektmarge (Bruttomarge auf Projekt-Ebene)

Die zentrale Größe. Sie zeigt, ob das Projektgeschäft selbst profitabel ist, unabhängig von Overhead und Wachstumsinvestitionen. Üblich ist eine Aufschlüsselung nach Projektkategorien (z.B. Standardprojekte versus Sonderanfertigungen, kleine versus große Volumina, regionale Cluster). Investoren wollen sehen, ob die Marge bei Skalierung stabil bleibt oder sich verschlechtert. Eine fallende Projektmarge bei steigendem Umsatz ist ein deutliches Warnsignal. Und in projektgetriebenen Geschäften häufiger als gedacht, wenn Wachstum durch margenärmere Großprojekte erzwungen wird.

Cash Conversion Cycle in Projektgeschäften

Der Zeitraum vom ersten Projektaufwand bis zum vollständigen Zahlungseingang. In typischen DACH-Projektgeschäften liegt dieser Zyklus zwischen 60 und 180 Tagen, im Anlagenbau und bei öffentlichen Auftraggebern oft deutlich länger. Wer mit 30 Prozent Anzahlung, 40 Prozent bei Etappenabnahme und 30 Prozent bei Schlussabnahme abrechnet, hat einen anderen Cash-Verlauf als ein Unternehmen mit Vorkasse-Modell. Investoren prüfen, ob der Cash Conversion Cycle bei Wachstum zunimmt, denn das bedeutet, dass jedes neue Projekt mehr Working Capital bindet als das vorherige. Skaliert ein Geschäftsmodell so, kann es ohne zusätzliche Kreditlinien an seine Liquiditätsgrenze stoßen, lange bevor das Geschäft selbst unprofitabel wird.

Wer den CCC nur über Kundenkonditionen denkt, übersieht allerdings die Hälfte. Der Zyklus ist das Ergebnis aus drei Hebeln: Forderungslaufzeit gegenüber Kunden (Days Sales Outstanding, DSO), gebundenes Material und Work-in-Progress (Days Inventory Outstanding, DIO) sowie Verbindlichkeitslaufzeit gegenüber Lieferanten und Subunternehmern (Days Payable Outstanding, DPO). In EPC, Anlagenbau und Engineering machen Material- und Fremdleistungsanteile häufig 50 bis 70 Prozent der Projektkosten aus, also ist die Lieferantenseite der quantitativ größere Hebel. In der Praxis verlangen neue Lieferanten häufig Vorkasse oder 14 Tage netto, etablierte Beziehungen liegen bei 30 bis 60 Tagen netto. Längere Fristen sind im B2B-Bereich vereinbar, gegenüber öffentlichen Auftraggebern eng begrenzt. Subunternehmer rechnen am Bau typischerweise nach VOB/B (Vergabe- und Vertragsordnung für Bauleistungen, Teil B) mit Abschlagszahlungen ab, oft binnen 21 Werktagen nach prüffähiger Rechnung, teils mit Sicherheitseinbehalt von rund 5 Prozent.

Der kritische Punkt ist das Timing-Match zwischen Kundenanzahlung, Materialeinkauf und Subunternehmer-Abrufen. Verlangt der Lieferant Vorkasse für Material, bevor die erste Kundenzahlung eingegangen ist, oder rechnet der Kunde ohne Anzahlung erst bei Etappenabnahme ab, entsteht eine negative Cash-Lücke, die das Projekt selbst bei voller Marge in eine Working-Capital-Krise ziehen kann. Belastbare Investor-Antworten gehen deshalb über DSO hinaus und zeigen das Working-Capital-Profil pro Projekt-Phase über die Zeit, also Anzahlung, Materialeinkauf, Produktion, Etappenrechnung, Subunternehmer-Abrufe, Schlussrechnung und Sicherheitseinbehalt-Auflösung. Verhandlungshebel auf der Lieferantenseite (Skontonutzung, Rahmenverträge, längere Zahlungsziele bei strategischen Partnern) gehören in jeden CCC-Verbesserungsplan, nicht nur die Kundenseite.

Backlog und Coverage Ratio

Backlog ist der Auftragsbestand: Aufträge, die unterzeichnet und noch nicht vollständig umsatzwirksam abgeschlossen sind. Die Coverage Ratio setzt diesen Backlog in Relation zum erwarteten Umsatz der nächsten Quartale. Eine Coverage Ratio von 0,8 für das nächste Quartal bedeutet: 80 Prozent des Umsatzplans sind bereits durch Aufträge gedeckt. Investoren lesen Backlog als Frühindikator. Ein wachsender Umsatz bei schrumpfender Coverage Ratio bedeutet, dass das Wachstum aus dem Bestand kommt, nicht aus Neugeschäft. Das ist ein präziser Auslöser für die Frage, ob die Vertriebsmaschine eigentlich funktioniert.

Project P&L vs. Period P&L

Eine handelsrechtliche GuV (Periodenrechnung) reicht im Projektgeschäft nicht aus. Investoren wollen zusätzlich eine Project P&L sehen: für jedes größere Projekt eine eigene Aufstellung mit Umsatz, direkten Kosten, Projektmarge und Status. Bei einem Portfolio von zehn bis fünfzig aktiven Projekten ist das ein eigenes Reporting-Workstream, häufig in einem dedizierten Tool gepflegt (Project-Controlling-Software, ERP-Modul oder strukturierte Tabellen). In gut geführten Unternehmen kennen Geschäftsführung und Investoren die fünf größten Projekte zu jedem Stichtag namentlich, mit Status-Ampel und kommerzieller Erwartung.

Branchenmuster: Welche KPI-Akzente wo besonders zählen

Die vier KPIs der vorherigen Sektion gelten in jedem Projektgeschäft. Die Akzente verschieben sich aber je nach Branche, und Investoren erwarten, dass Founder und CFO diese Akzente kennen.

Anlagen- und Maschinenbau

Mehrjährige Projekt-Laufzeiten, hoher Material- und Fremdleistungsanteil (häufig 60 bis 75 Prozent), Anzahlungs-getriebene Cash-Profile, Sicherheitseinbehalte über Garantiezeiträume von zwei bis fünf Jahren. KPI-Akzente: Backlog mit Coverage Ratio über 18 bis 36 Monate, Cash Conversion Cycle inklusive Sicherheitseinbehalts-Auflösung, Project Margin Variance pro Auftrag mit Trennung in Material-, Fremdleistungs- und Eigenleistungsanteil. Häufig unterschätzt: Engineering-Change-Orders (Vertragsänderungen während der Projektlaufzeit) als eigene KPI-Linie, weil sie die ursprüngliche Projektmarge verschieben können. Bei Hybrid-Modellen (Anlagengeschäft plus Wartungsverträge) lohnt sich eine getrennte Sicht: Projektmarge im Erstgeschäft, ARR-Charakteristik im Service-Anteil. Im Reporting an PE-Investoren häufig zusätzlich: EBITDA-Brücke vor und nach Projekt-Risikoabschlägen.

Cleantech-EPC: Solar, Wind, Battery Storage, Wärmepumpe-Installation

Häufiger Mix aus B2B-Großprojekten (Solarparks, Windparks, BESS-Anlagen, Wärmenetze) und kleinteiligem Privat- oder Gewerbegeschäft (Aufdach-PV, Wärmepumpe-Einbau). KPI-Akzente: Auftragsmix nach Segment, Installations-Cycle-Time pro Auftragstyp (von Vertragsabschluss bis Inbetriebnahme), Materialanteil bei volatilen Modul- und Komponenten-Preisen, Customer Acquisition Cost (CAC) im B2C-Segment, Förder- und Subventions-Pipeline als Backlog-Komponente. Pipeline-Tracking entlang der typischen Stages (Lead → Site Survey → Angebot → Auftrag → Installation → Abnahme → EVU-Anschluss) ist im Privatkunden-Geschäft entscheidend für Forecast-Treue. PE-Buy-and-Build im Cleantech-Installationsmarkt verlangt zusätzlich konsolidierte Project-P&L-Sicht über mehrere Tochtergesellschaften, was bei heterogenem ERP-Bestand operativ aufwendig ist.

Defense-Tech und Dual-Use

Mehrjährige Government-Verträge in mehreren Vertragsformen: Firm Fixed Price (FFP) bei klar definierten Liefergegenständen, Time-and-Material (T&M) bei offenem Scope, Cost-Plus-Varianten (CPFF, CPIF, CPAF) bei F&E-lastigen Vorhaben, Indefinite-Delivery-Indefinite-Quantity (IDIQ) als Rahmenvertrags-Konstrukt mit Einzelabrufen. Im DACH-Kontext relevant: Verträge mit dem Bundesamt für Ausrüstung, Informationstechnik und Nutzung (BAAINBw), NATO-Programme, Europäischer Verteidigungsfonds (EDF). KPI-Akzente: Backlog nach Vertrags-Phase (Bid, Awarded, In Execution, Closed) und Vertragstyp, Mix FFP versus T&M versus Cost-Plus, Earned Value Management (EVM) mit Cost Performance Index und Schedule Performance Index bei Cost-Plus- und Incentive-Verträgen (oft vertraglich vorgeschrieben), Compliance-Mehraufwände durch Exportkontrolle (Kriegswaffenkontrollgesetz, EU-Dual-Use-Regulation), Cash-Profile mit Anzahlungs-Strukturen pro Behörde. Reporting-Anforderungen ähneln dem klassischen Anlagengeschäft mehr als dem SaaS-Reporting.

Engineering Services und Systemintegration

Personalintensiv (Personalkosten 50 bis 70 Prozent), Auslastung als zentraler Margen-Hebel. KPI-Akzente: Billable Utilisation Rate (Branchen-Benchmarks: 70 bis 85 Prozent in Engineering-Häusern, 55 bis 65 Prozent in Strategie-Beratung), Average Daily Rate (ADR) und Effective Rate (Billable Rate × Auslastung), Project Margin nach Senior-Junior-Mix, Backlog in Mannmonaten zusätzlich zu EUR. Senior-Junior-Mix als Margenhebel: Junior-Stunden mit höherer Marge je Stunde (typisch 80 bis 140 Prozent), Senior-Stunden niedrigere Marge bei höherem absoluten Beitrag (typisch 50 bis 90 Prozent). Verschiebungen im Mix können die Projekt-Marge um 10 bis 20 Prozentpunkte bewegen, ohne dass sich Tagessätze ändern. Bench Time (nicht-fakturierte Auslastung) gehört in jedes monatliche Reporting. PE-Roll-up-Strategie ist im Markt häufig: Konsolidierung mehrerer mittelständischer Engineering-Häuser, Cross-Portfolio-Utilisation-Tracking und einheitliche ADR-Definition sind die zentrale operative Herausforderung der ersten 24 Monate nach Plattform-Akquisition.

Bilanzierung: PoC, Completed Contract und IFRS 15

Bei längerlaufenden Projekten stellt sich die Bilanzierungsfrage. Im HGB gilt das Realisationsprinzip nach § 252 Abs. 1 Nr. 4 HGB: Gewinne werden erst realisiert, wenn sie durch einen Umsatzakt entstanden sind. Standardfall bei langfristiger Auftragsfertigung ist deshalb die Completed-Contract-Methode mit Ergebnisrealisierung erst bei Projektabschluss. Echtes Percentage-of-Completion ist im HGB grundsätzlich nicht zulässig, weil bei Werkverträgen die Erlösrealisierung erst mit der Abnahme erfolgt. Möglich ist eine Teilgewinnrealisierung, wenn vertraglich selbständig abrechenbare Teilleistungen mit Teilabnahme vereinbart sind. Das ist technisch kein PoC, sondern Erlösrealisierung pro Teilumsatz. Unter IFRS 15 (in Kraft seit 2018, ersetzt IAS 11) erfolgt die Erlösrealisierung über das Modell der Leistungsverpflichtungen, entweder zeitpunktbezogen ("at a point in time") oder zeitraumbezogen ("over time"). Die Over-time-Realisierung entspricht in der Wirkung der früheren PoC-Logik aus IAS 11. In Investorengesprächen werden "PoC" und "over time" meist synonym verwendet. IFRS-Reporting wird für VC-backed Scale-ups typischerweise ab Series B relevant, in der Regel als Vertragspflicht aus dem Investorenvertrag, nicht als gesetzliche Pflicht. PE-Portfolio-Companies werden je nach Holding-Struktur und Exit-Horizont auf parallele HGB- und IFRS-Sicht gefahren, häufig spätestens 18 bis 24 Monate vor einem geplanten Sell-Side-Exit.

Praktische Konsequenz: Wer im HGB nach Completed Contract bilanziert und gleichzeitig in einem internen Reporting nach PoC-Logik berichtet, muss die Brücke transparent zeigen. Investoren akzeptieren, dass es zwei Sichten gibt, eine handelsrechtliche und eine betriebswirtschaftliche. Sie akzeptieren nicht, wenn die beiden Sichten in unterschiedlichen Reports ohne Erklärung auftauchen. Die Standardregel: HGB-GuV als Primärrechnung, ergänzt um eine Management-Sicht mit PoC-Erfolgsrealisation, klar gekennzeichnet als nicht-handelsrechtliche Management-Sicht. Die zugrundeliegende Buchungsmechanik -- Bestandsveränderungen, unfertige Leistungen nach §255 HGB und die monatliche BWA-Darstellung -- erklärt Bestandsveränderungen im Projektgeschäft: Bilanz, BWA und Umsatzrealisierung nach HGB.

KPI-Architektur für projektgetriebene Geschäftsmodelle

Eine belastbare KPI-Struktur deckt vier Ebenen ab: Auftragseingang, Projektabwicklung, Profitabilität, Working Capital. Pro Ebene reichen zwei bis vier KPIs.

Eine ergänzende Project-P&L-Aufstellung für die fünf bis zehn größten Projekte gehört in jedes ernsthafte Board-Pack. Details zu Reporting-Strukturen für Boards in Board Reporting Guide.

Die operative Voraussetzung: Wie Projektkosten erfasst werden

Alle KPIs auf den vorherigen Seiten sind wertlos, wenn die zugrunde liegenden Daten nicht sauber erfasst sind. Die operative Grundlage von Projektcontrolling ist, dass jeder Aufwand und jede Rechnung beim Entstehen einer Projektkostenstelle zugeordnet wird, nicht nachträglich. Wer Marge erst Wochen später per Bauchgefühl auf Projekte verteilt, baut Reporting auf Vermutungen, und Investoren erkennen das in der Regel innerhalb der ersten Due-Diligence-Stunde.

Pflichtfeld Projekt bei jeder Bestellung

Die Standard-Schnittstelle Einkauf zu Finanzen läuft über den Procure-to-Pay-Prozess: Bestellanforderung, Genehmigung, Bestellung, Wareneingang, Rechnungseingang, Drei-Wege-Abgleich, Buchung. Der Drei-Wege-Abgleich ist die automatisierte Prüfung, ob Bestellung, Wareneingang und Rechnung in Menge, Preis und Konditionen übereinstimmen; erst bei Match wird die Rechnung zur Zahlung freigegeben. Jeder dieser Schritte muss eine Projektkennzeichnung tragen. Der häufigste Fehler in der Praxis: Der Einkauf bestellt ohne Projektzuordnung, weil das Tool kein Pflichtfeld erzwingt. Die Rechnung läuft Tage bis Wochen später durch die Buchhaltung, niemand weiß zuverlässig, zu welchem Projekt sie gehört, und sie wird nach Erinnerung oder pauschal allokiert. Die Projektmarge ist von diesem Moment an eine Schätzung, keine Tatsache. Die saubere Lösung: ERP-System oder P2P-Tool so konfigurieren, dass keine Bestellanforderung ohne Projektzuordnung gespeichert werden kann. Das ist eine technische Konfiguration, keine Disziplinfrage.

Pflichtfeld absolut für jede Bestellung ist allerdings Overkill. Sinnvoll ist eine Schwellwert-Logik: ab einem definierten Bestellwert (in der Praxis häufig 500 oder 1.000 EUR) plus für definierte Materialgruppen wird das Projekt zur Pflicht, darunter laufen kleinere Bestellungen (Bürobedarf, Standardverbrauch) auf Sammelkostenstellen. Wichtig ist außerdem die saubere Behandlung nicht-projektspezifischer Kosten: Lagermaterial, Werkstattbedarf, IT-Lizenzen, Reinigung oder Mieten gehören nicht auf Projektkostenstellen. Wer das ignoriert, verschmutzt die Projektmarge. Solche Gemeinkosten werden über Sammelkostenstellen erfasst und bei Bedarf über Allokationsschlüssel (Maschinenstunden, Mannstunden, Fläche) auf Projekte umgelegt, klar gekennzeichnet als Umlage.

Stunden- und Reisekostenerfassung

In personalintensiven Projektgeschäften wie Engineering, Implementierung oder professionellen Dienstleistungen machen Personalkosten oft fünfzig bis siebzig Prozent der Projektkosten aus. Wer diese Stunden nicht pro Projekt erfasst, hat keine belastbare Projektmarge. In der Frühphase funktioniert ein Best-of-Breed-Stack noch: ein Personalmanagement-System (Human Resources Information System, HRIS) für Stammdaten, ein dediziertes Time-Tracking-Tool mit Projekt-Tagging und ein Spend-Management-Tool für Spesen mit Pflichtfeld Projekt. Die Daten fließen über API- oder CSV-Brücken in die Buchhaltung.

Bei Skalierung kippt diese Architektur. Jeder Tool-Übergang wird zur Datenlücken-Quelle: manuelle CSV-Exporte, Mapping-Fehler zwischen Kostenstellen, verlorene oder umbenannte Projekt-Tags, Spesen ohne Bezug zur Stundenliste, fehlende Approvals. Mit zwanzig parallelen Projekten und vierzig Mitarbeitern in der Leistungserbringung sind die Brüche nicht mehr per Excel zu reparieren. Der Weg führt entweder zu einem integrierten ERP mit nativen Modulen für Stunden, Spesen und Projekt-Allokation oder zu echten API-Integrationen zwischen den Best-of-Breed-Tools, nicht CSV-Hin-und-Her. Welche Stufe wann sinnvoll ist, hängt von Volumen, Projektkomplexität und Reifegrad der Buchhaltung ab.

Cost-Centre-Architektur ohne Über-Granularität

Eine belastbare Projektkostenstellen-Struktur folgt einer klaren Hierarchie: Geschäftsbereich, Projektgruppe oder Kunde, Einzelprojekt, optional Projektphase. Aggregation muss im ERP automatisch funktionieren. Der häufigste Fehler ist Über-Granularität: Wer pro Projekt fünfzehn Phasen-Kostenstellen anlegt, erzeugt einen administrativen Overhead, der weder vom Einkauf noch von Mitarbeitenden bei der Stundenerfassung mitgetragen wird. Drei bis fünf Ebenen reichen. Wichtig ist die saubere Trennung von Projektkosten und Overhead-Kosten, sonst landet Marketing-Aufwand auf Projektkostenstellen und die Projektmarge wirkt schlechter, als sie ist.

Tool-Stack für Projektcontrolling

Vier Komponenten müssen integriert sein, damit Projektcontrolling operativ funktioniert:

• ERP-Projekt-Modul als Single Source of Truth: ein Light-ERP, Mid-Market-ERP oder eine branchenspezifische Lösung für anlagenintensive Geschäfte. Die Projektkostenstellen-Struktur lebt hier, nicht in einer Excel-Tabelle. Die Anbindung an DATEV für Steuer- und Jahresabschluss-Schnittstellen läuft über etablierte Konnektoren.
• Procure-to-Pay-Layer (P2P) für den Einkauf: Bestellanforderung, mehrstufige Genehmigung, Bestellungs-Erstellung (Purchase Order, PO) mit Projekt-Pflichtfeld. Bei Light-ERPs oft im ERP integriert, bei Mid-Market häufig ein dediziertes P2P-Tool mit Schnittstelle zum ERP und zur DATEV-Buchhaltung.
• Stunden- und Reisekostenerfassung mit Projekt-Tagging: Pflicht-Integration mit dem ERP, sonst entstehen Brüche. Time-Tracking und Spesen-Tools mit definierten Schnittstellen.
• BI-Layer für Projekt-P&L und Aggregationen: ein BI-Tool mit Anbindung an die ERP-Datenbasis. Dashboards für aktive Projekte mit Status, Plan-Ist-Vergleich, Kostenstellen-Drill-down.

Einkauf wird Datenlieferant, nicht nur Beschaffer

Der kulturelle Wandel hinter all dem: Der Einkauf in einem projektbasierten Geschäft ist nicht mehr nur dafür verantwortlich, das richtige Material zum richtigen Preis zu bekommen. Er ist Teil der Datenkette, die am Ende die Projektmarge produziert. Das erfordert Schulung, klare Pflichtfelder, automatisierte Validierung und einen direkten Kommunikationsweg zwischen Einkauf und Finance. In der Praxis sitzen die größten Reibungsverluste genau hier: Einkauf priorisiert Schnelligkeit, Finance priorisiert Datenqualität. Die Lösung ist nicht, dass eine Seite gewinnt, sondern dass das ERP-System die Spielregeln erzwingt und beide Seiten innerhalb dieser Regeln effizient arbeiten können.

Das DATEV-Dilemma im wachsenden Projektgeschäft

Fast jedes deutsche Startup beginnt mit DATEV, nicht weil eine Tooling-Entscheidung getroffen wurde, sondern weil der Steuerberater DATEV einsetzt. DATEV hat im deutschen Steuerberater-Markt eine dominante Stellung. Wer einen Steuerberater hat, hat in der Regel auch DATEV im Datenstrom. Daraus entsteht ein Setup, das in der Frühphase pragmatisch funktioniert: DATEV Unternehmen Online für die Belegerfassung, DATEV Mittelstand oder das Auftragswesen für Rechnungsstellung, der Steuerberater übernimmt Jahresabschluss, Lohn und Steuern auf derselben Datenbasis.

Der Bruchpunkt kommt, sobald das Geschäft projektgetrieben skaliert. DATEV bietet Kostenstellen und Kostenträger und ist auf klassische Kostenrechnung mit Bereichen, Standorten und Produktgruppen ausgelegt. Genau das ist das Problem im Projektgeschäft. Es fehlen Project-P&L-Logik, Backlog- und Coverage-Tracking, Drei-Wege-Abgleich auf Projektkostenstellen-Ebene, integriertes Time-Tracking pro Projekt, Earned-Value-Berechnungen und BI-tauglicher Daten-Output über mehrstufige Projekt-Hierarchien. DATEV ist auf Buchhaltung und Steuern optimiert, nicht auf operative Projektsteuerung. Wer dort Projektcontrolling abbilden will, baut Workarounds aus zusätzlichen Excel-Tabellen, manuellen Allokationen und parallelen Listen, die spätestens beim nächsten Wachstumsschub kollabieren.

Die häufige Fehlreaktion: DATEV komplett ablösen wollen. Das löst zwei Probleme nicht. Erstens braucht der Steuerberater weiterhin eine DATEV-fähige Datenanbindung, sonst entstehen Doppelarbeit oder ein StB-Wechsel. Zweitens geht mit der DATEV-Historie eine Datenkonsistenz von oft fünf bis zehn Jahren verloren, die in der nächsten Due Diligence schmerzhaft wird.

Die richtige Antwort ist Co-Existenz. Das ERP wird operatives Backbone für Bestellungen, Wareneingänge, Rechnungen, Stunden, Projekt-P&L und Reporting. DATEV bleibt FiBu-Layer und Schnittstelle zum Steuerberater. Buchungsdaten fließen aus dem ERP nach DATEV, entweder über die moderne DATEVconnect-REST-API, den DATEV-Buchungsdatenservice oder im klassischen Fall über CSV-Export im EXTF-Format. Ergebnis: Der Steuerberater arbeitet weiter in seiner gewohnten DATEV-Umgebung, das Unternehmen steuert sein Projektgeschäft im ERP.

Konkret heißt das für das interne Finance-Team: Tagesgeschäft läuft im ERP. Kreditoren-Buchhaltung (Accounts Payable, AP), Debitoren-Buchhaltung (Accounts Receivable, AR), Belegverarbeitung, Monatsabschluss, Project P&L, Cashflow-Forecast und Reporting passieren im ERP. DATEV läuft im Hintergrund als Daten-Senke: Buchungsdaten kommen automatisiert aus dem ERP, der Steuerberater greift in seiner gewohnten DATEV-Umgebung darauf zu. Auch wenn die Buchhaltung intern statt beim StB erfolgt, sitzt sie im FiBu-Modul des ERP, nicht in DATEV selbst. Indikator für einen unvollendeten Übergang: Wenn das interne Team weiter Belege in DATEV erfasst, dort manuelle Buchungen anlegt oder Berichte aus DATEV zieht, ist die Architektur nur halb vollzogen und die meisten Vorteile bleiben liegen.

Best Practices für den Übergang

• Steuerberater früh einbinden, nicht nachträglich überraschen. Die Architektur-Entscheidung gehört zu den Themen, die Steuerberater und CFO gemeinsam besprechen. Ein guter StB sieht in einer sauberen ERP-Anbindung weniger Arbeit für sich, nicht mehr.
• Kontenrahmen abstimmen. SKR03 oder SKR04 muss zwischen ERP und DATEV identisch sein. Abweichungen erzeugen Mapping-Aufwand bei jedem Datentransfer. Wenn das ERP einen anderen Kontenrahmen voreinstellt, am ersten Tag aufräumen.
• Kostenstellen-Hierarchie sauber mappen. Projekte und Projektphasen leben im ERP mit voller Hierarchie. Für die DATEV-Sicht werden sie auf eine flache Kostenstellen-Liste gemappt, die für klassische FiBu-Auswertungen reicht. Diese beiden Sichten dürfen nicht durcheinandergehen.
• DATEV-Schnittstelle vor ERP-Auswahl prüfen. Nicht jedes ERP hat eine zertifizierte DATEVconnect-Anbindung. Im DATEV-Marktplatz lässt sich filtern. ERPs ohne native Schnittstelle sind in DACH schwerer einzuführen, weil der Steuerberater die Datenmigration übernehmen muss oder der CFO Brücken bauen.
• HGB-Konformität des ERP-Finance-Moduls prüfen. Internationale ERPs sind nicht automatisch HGB-fähig. SKR-Kontenrahmen, Belegnummernkreise nach GoBD, Verfahrensdokumentation und elektronische Aufbewahrung sollten geklärt sein, bevor der Vertrag unterschrieben wird.
• Phasen-Migration statt Big-Bang. Erst ERP mit DATEV-Anbindung im Parallel-Betrieb einführen. Dann schrittweise die operative Last (Bestellwesen, Faktura, Projektabwicklung) ins ERP verlagern. DATEV bleibt durchgehend stabiler FiBu-Layer. Migrationsphase typisch sechs bis neun Monate, je nach Volumen und Datenqualität.
• Steuerberater wechseln, falls Schnittstellen-Ablehnung. Steuerberater, die in 2026 Schnittstellen-Buchungen aus dem ERP ablehnen und auf manuelle DATEV-Erfassung bestehen, sind für ein wachsendes Projektgeschäft die falsche Wahl. Das ist kein technisches Problem, sondern ein Mindset-Problem.

Was Projektcontrolling im Reporting nicht ist

Drei Verwechslungen, die in der Praxis regelmäßig auftauchen:

• Projektcontrolling ist kein Projektmanagement. Projektmanagement steuert den operativen Ablauf, Termine, Ressourcen, Stakeholder. Projektcontrolling steuert die wirtschaftliche Performance: Marge, Cashflow, Risiko, Forecast-Treue. Beide Funktionen arbeiten zusammen, ersetzen sich aber nicht.
• Projektcontrolling ist keine Buchhaltung. Buchhaltung erfasst die Vergangenheit nach handelsrechtlichen Regeln. Projektcontrolling steuert die laufenden und zukünftigen Projekte mit Management-Sicht. Wer Projektmarge nur aus der Buchhaltung ableitet, hat ein verzögertes und oft falsches Bild.
• Projektcontrolling ist keine SaaS-Übersetzung. Der Versuch, Projektgeschäft in MRR oder ARR zu pressen, verbessert weder die Investor-Kommunikation noch das interne Verständnis. Projektgeschäft hat eigene KPIs und verdient eigene Sprache.

Der häufigste Fehler: Projektgeschäft als ARR verkaufen

In Pitch Decks von DACH-Scale-ups und in Reporting Packages von PE-Portfolio-Companies taucht regelmäßig die ARR-Zeile auf, obwohl das Geschäftsmodell projektbasiert ist. Die Logik dahinter ist nachvollziehbar: VCs verstehen ARR, das Pitch klingt vertrauter, die Bewertungsmultiples für ARR sind höher. Im PE-Kontext hilft eine ARR-Story zusätzlich beim Multiple-Arbitrage zwischen Buy- und Sell-Side. Das Problem: ARR setzt voraus, dass Umsatz wiederkehrt, ohne dass dafür neue Vertriebsleistung erforderlich ist. Projektgeschäft erfüllt diese Definition fast nie.

Erfahrene Investoren erkennen die ARR-Konstruktion in projektbasierten Modellen sofort und werten sie als Glaubwürdigkeitsproblem. Die saubere Alternative: Projekt-Backlog, geplanter Auftragseingang, wiederkehrende Umsatzanteile (Wartung, Service, SaaS-Komponente bei Hybridmodellen) sauber getrennt ausweisen. Wenn ein Teil des Geschäfts tatsächlich wiederkehrend ist (z.B. Wartungsverträge nach Anlagenverkauf), darf dieser Teil als ARR ausgewiesen werden, aber klar abgegrenzt vom Projektumsatz. Diese Differenzierung wirkt im Pitch ehrlicher und führt zu besseren Bewertungsgesprächen, nicht zu schlechteren.

Operating-Partner-Sicht: Reporting über das Portfolio

Operating Partner und Fund Manager bei DACH-PE-Häusern haben einen spezifischen Pain im Projektgeschäft. Sie steuern fünf bis fünfzehn Portfolio-Companies, oft mit unterschiedlichen ERPs, unterschiedlichen Kontenrahmen und unterschiedlichen KPI-Definitionen. Vergleichbarkeit über das Portfolio ist Wunschtraum, nicht Realität. Vier Hebel adressieren das Problem an der Wurzel:

• KPI-Definitions-Standard: Was zählt als Projektmarge, wie wird Backlog gemessen, wie Coverage Ratio berechnet, in einem Reporting Package festgeschrieben, das alle Portfolio-Companies beim Onboarding erhalten. Ohne diesen Standard ist jede Quartals-Konsolidierung ein Apples-zu-Oranges-Vergleich.
• Buy-and-Build-Integration: Roll-up-Strategien (Solar-Aggregator, SHK-Plattform, Engineering-Holding) bringen mit jeder Akquisition eigene ERP-Strukturen mit. Konsolidiertes Project-P&L pro Deal sechs bis zwölf Monate Arbeit. Pragmatischer Weg: Standardisierungs-Roadmap mit Ziel-ERP und einheitlicher Kostenstellen-Hierarchie, nicht jeder Add-on eigenständig.
• Value Creation Plan Tracking auf Projekt-Ebene: Monatliches Reporting, das Project Margin nach Initiative aufschlüsselt (Pricing, Lieferanten-Konsolidierung, Auslastung, Fixkostendegression), statt nur EBITDA-Brücke gegen Plan. Ohne diese Sicht ist nicht erkennbar, ob VCP-Initiativen wirken oder ob die Margenverbesserung nur Mix-Effekt ist.
• Pre-Exit-Cleanup als VCP-Initiative ab Tag eins: Sell-Side-Quality-of-Earnings verlangt drei bis fünf Jahre historische Projekt-Daten. Nachträgliche Rekonstruktion 18 Monate vor Exit kostet sechsstellig in Beratung und führt zu Discount-Diskussionen mit Käufern.

Wenn ein Operating Partner für eine Portfolio-Company kurzfristig externe Kapazität braucht (typische Auslöser: neue Akquisition mit unklarer Projektmarge-Historie, Reporting-Gap zur PE-Holding, Sell-Side-DD-Vorbereitung, 100-Tage-Plan nach Closing), ist die Profil-Frage Fractional CFO oder Interim CFO. Setup-Optionen in Fractional CFO vs. Interim CFO.

Fazit

Projektcontrolling in projektbasierten Geschäften ist keine zusätzliche Reporting-Disziplin neben der Buchhaltung, sondern die Arbeitsgrundlage, auf der die Projektökonomie überhaupt erst sichtbar wird. Drei Bausteine machen den Unterschied: Datenerfassung am Entstehungsort über einen Tool-Stack, der bei Skalierung nicht bricht; eine Architektur aus ERP als operatives Backbone und DATEV als Schnittstelle zum Steuerberater; und KPIs, die zur projektbasierten Realität passen statt zur SaaS-Schablone. Was sich von Audience zu Audience unterscheidet, ist die Reporting-Frequenz und Tiefe, nicht die zugrunde liegenden Daten. VC-Investoren lesen Quartal, PE-Investoren Monat, Operating Partner über das Portfolio. Wer das Fundament richtig baut, bedient alle drei. Für kapitalintensive Projektgeschäfte, die neben dem operativen Controlling auch Projektfinanzierung, Bankability und Capital Stack aufbauen müssen, steht ein eigener Leitfaden in Infrastrukturfinanzierung für kapitalintensive Scale-ups.