Betriebsbuchhaltung für eine IT-Agentur: Die drei Zahlen, die Ihnen alles verraten

"₴12 Mio. Jahresumsatz. 15 Entwickler. Drei Jahre profitabel. Und ich konnte ehrlich gesagt nicht sagen, welches Projekt profitabel war und welches ein langsames Leck."

Die Gründerin einer IT-Dienstleistungsagentur beschrieb den Moment der Erkenntnis bei einem Führungsteam-Offsite. Ihr Unternehmen war drei Jahre lang gewachsen. Umsatz von ₴4 Mio. auf ₴12 Mio. Mitarbeiterzahl von 5 auf 15 Entwickler. Gewinn zum Jahresende sichtbar. Nach jedem äußeren Maßstab — erfolgreich.

Dann stellte die COO eine Frage: "Welche zwei unserer 11 aktiven Projekte sind pro Entwicklerstunde am profitabelsten?"

Sie konnte nicht antworten. Die Buchhaltung zeigte Umsatz pro Projekt (manchmal — wenn Projekte sauber abgerechnet wurden). Sie zeigte nicht die pro Projekt zugeteilten Entwicklerstunden. Sie zeigte nicht den effektiven Stundensatz nach Abzug von Leerlauf, Urlaub, interner Arbeit. Sie zeigte nicht den Deckungsbeitrag pro Projekttyp (T&M vs. Festpreis vs. Retainer).

Sie wusste, dass ihre aggregierte Marge gesund war. Sie wusste nicht, welche Kunden sie generierten und welche das Wachstum der Agentur still aus ihrer eigenen Marge subventionierten.

Dieser Artikel handelt von den drei Zahlen, die eine Inhaberin einer IT-Agentur braucht, um ihr Geschäft zu verstehen — und warum die Standardbuchhaltung sie nicht liefert, egal wie gewissenhaft der Buchhalter ist.

Das Paradoxon: ₴12 Mio. Umsatz bedeutet nicht ₴12 Mio. an Entscheidungen

Die meisten Agenturinhaber achten auf zwei Zahlen: Umsatz und Nettogewinn. Das sind die Zahlen, die ihr Buchhalter liefert, die Zahlen, die sie bei der Vorstellung des Unternehmens nennen, die Zahlen, die sie Monat für Monat beobachten.

Diese beiden Zahlen sind zu aggregiert, um Entscheidungen zu steuern. Eine IT-Agentur mit ₴12 Mio. Umsatz und 18% Nettomarge (₴2,16 Mio. Gewinn) sieht gesund aus. Aber:

• Wenn 60% des Umsatzes von zwei Kunden stammen, hat das Unternehmen ein verstecktes Konzentrationsrisiko
• Wenn das profitabelste Projekt 38% Marge liefert und das schwächste −4%, verbirgt das Aggregat sowohl eine Chance (mehr von der profitablen Art) als auch ein Problem (den Verlustbringer)
• Wenn die Entwicklerauslastung bei 58% liegt, die Projektliste aber "voll besetzt" aussieht, gibt es jedes Jahr ₴1,4 Mio. an ungenutzter abrechenbarer Kapazität
• Wenn das Team 20% der Zeit von bezahlter Kundenarbeit auf unbezahlte interne Arbeit abgezogen wird, ist der effektive Stundensatz drastisch niedriger als der veröffentlichte

Die aggregierten Zahlen sagen "Sie sind profitabel." Die Entscheidungen müssen wissen "wo, mit wem, womit und wie dauerhaft." Die Betriebsbuchhaltung für eine IT-Agentur ist genau dafür aufgebaut, das zu beantworten.

Das allgemeine Rahmenwerk — Betriebsbuchhaltung als Disziplin — finden Sie im Grundlagenartikel → Betriebsbuchhaltung erklärt.

Die drei Zahlen, die die Betriebsbuchhaltung einer IT-Agentur liefert

Für eine IT-Dienstleistungsagentur leisten drei Zahlen den größten Teil der entscheidungsrelevanten Arbeit. Zahl eins — Auslastungsrate pro Entwickler. Von den Stunden, die ein Entwickler im Monat verfügbar ist (~160), wie viele waren einem Kunden in Rechnung stellbar? Ein typisches Dienstleistungsunternehmen geht von 100% aus. Die ehrliche Zahl für eine IT-Agentur liegt bei 60–75% — der Rest ist Vertriebsunterstützung, interne Tools, Schulung, Krankheitstage, Bankzeit zwischen Projekten. Eine pro Entwickler und Monat erfasste Auslastung zeigt: wer zuverlässig ausgelastet ist, wer zwischen Projekten steckt, wo sich Kapazität versteckt, wo die Agentur für die aktuelle Nachfrage still überbesetzt ist.

Zahl zwei — Effektiver Stundensatz pro Projekt. Veröffentlichte Sätze sind ambitioniert ("unser Senior-Dev-Satz beträgt ₴1.800/Stunde"). Effektive Sätze sind das, was tatsächlich passiert, nach Scope Creep, Bankzeit-Rabatten, um Entwickler beschäftigt zu halten, nicht abgerechneten internen Stunden und Nacharbeit am Projekt. Bei einer gesunden IT-Agentur liegt der effektive Satz bei 75–90% des veröffentlichten. Unter 70% bedeutet Unterpreisung oder Scope Leakage. Pro Projekt berechnet, zeigt diese Zahl, welche Projekte zuverlässig profitabel sind und welche still abdriften.

Zahl drei — Deckungsbeitrag pro Projekt (und pro Projekttyp). Umsatz minus direkte Erbringungskosten (Entwicklerzeit zu vollen Kosten, Subunternehmer, dem Projekt zugeordnete Tools) vor zugeteiltem Overhead. Pro Projekt berechnet, ist dies das wichtigste strategische Signal: Es sagt, welche Arbeit sich zu verfolgen lohnt, welche Arbeit neu bepreist werden sollte, welche Kunden vertieft und welche entlassen werden sollten.

Diese drei Zahlen erscheinen nicht in einer steuerlich formatierten GuV. Sie entstehen, wenn man Betriebsbuchhaltung über eine saubere Buchführung plus Zeiterfassung legt. Artikel #2 → behandelt die Unterscheidung Buchführung vs. Betriebsbuchhaltung; Artikel #4 → behandelt die operative GuV, mit der das verbunden ist.

Wie diese Zahlen Preisgestaltung, Einstellungen und Kundenmix verändern

Wenn die drei Zahlen vorliegen, werden vier Arten von Entscheidungen strukturiert statt instinktiv getroffen.

Preisgestaltung. Statt "lassen wir die Sätze gleich, weil Kunden nicht widersprochen haben" wird Preisgestaltung zu: "unser effektiver Satz bei diesem Kunden liegt bei 67% des veröffentlichten — wir verlieren 33 Punkte an Scope Leakage. Entweder den Scope straffen oder den Satz um 30% erhöhen." Konkret. Vertretbar.

Einstellungen. Statt "wir fühlen uns ausgelastet, lasst uns einen weiteren Entwickler einstellen" wird Einstellung zu: "die Teamauslastung lag drei Monate lang bei 76%, wird angesichts der Pipeline voraussichtlich dort bleiben. Ein zusätzlicher Senior würde sofort 65% Auslastung absorbieren und bis Monat drei 75% erreichen. Im Basisfall leistbar, im Abwärtsszenario knapp." Modelliert. Begründbar. Artikel #5 → behandelt das Finanzmodell, das diese Szenarien durchrechenbar macht.

Kundenmix. Statt "alle Kunden sind ungefähr ähnlich" wird der Kundenmix gesteuert: die zwei Kunden mit negativem Deckungsbeitrag abstoßen, die drei mit überdurchschnittlicher Marge vertiefen, den zwei Kunden in der Mitte, deren effektiver Satz still unter der Schwelle liegt, eine Preisanpassung vorschlagen.

Entscheidungen zur Leistungslinie. Wenn der Deckungsbeitrag pro Projekttyp gemessen wird (Festpreis-Entwicklung vs. T&M vs. laufender Retainer), lernt die Agentur, welche Modelle am profitabelsten sind, und verschiebt den Vertriebsmix entsprechend. Viele Agenturen entdecken, dass ihre margenschwächste Arbeit die Arbeit ist, die ihnen historisch am meisten Spaß gemacht hat — und handeln danach.

Die IT-spezifischen Komplikationen

Einige IT-Agentur-Realitäten machen Betriebsbuchhaltung schwieriger als bei anderen Dienstleistungsunternehmen — und wertvoller, wenn sie umgesetzt wird. Disziplin bei der Zeiterfassung. Ohne Stundenerfassung pro Entwickler und Projekt lassen sich Auslastung und effektiver Satz nicht messen. Die meisten Agenturen beginnen mit einem Tool (Toggl, Harvest, Clockify), und die Disziplin entsteht über 60–90 Tage. Die Disziplin selbst deckt Probleme auf: Ein Entwickler, der 14 Stunden/Tag protokolliert, deutet auf falsch eingeschätzten Scope hin; ein Entwickler, der 4 Stunden/Tag als "intern" protokolliert, offenbart Unterauslastung.

Bankzeit. Zwischen Projekten kosten Entwickler die Agentur, ohne abzurechnen. Das ist kein totes Kapital — es ist Vorbereitung, Schulung, Vertriebsunterstützung. Aber es muss erfasst und budgetiert werden. Eine gesunde Agentur fährt mit ~10–15% Bankzeit. Über 25% ist ein Problem der Vertriebspipeline, kein Lieferproblem.

FX-Exposition. Viele ukrainische IT-Agenturen rechnen in USD oder EUR ab, zahlen aber in UAH. Wechselkursbewegungen wirken sich auf die Marge aus. Betriebsbuchhaltung, die alles zu den richtigen Kursen in eine einzige Berichtswährung umrechnet, legt die reale Marge offen — und zeigt, wann FX die Erklärung für eine Margenverschiebung ist, nicht ein operativer Wandel.

Mix der Projekttypen. Festpreis, T&M (Time and Materials), Retainer, dediziertes Team — jedes hat eine andere Margendynamik, ein anderes Risiko, ein anderes Cashflow-Timing. Die Aggregation des Umsatzes über alle Typen hinweg verbirgt, welche Modelle an Anteil gewinnen und welche an Marge verlieren.

Wie man Betriebsbuchhaltung in 90 Tagen einführt

Die Agenturinhaberin aus der Einleitung tat dies über ein Quartal. Drei Phasen.

Phase 1 — Fundament (Wochen 1–4). Zeiterfassung einführen. Alle Entwicklerstunden kategorisieren in: abrechenbar für bestimmten Kunden/Projekt, intern (Vertriebsunterstützung, Schulung, Tools), Bankzeit (zwischen Projekten), administrativ. Jeden Entwickler dazu bringen, Stunden konsequent zu protokollieren. Der erste Monat an Daten ist unvollständig — das ist zu erwarten.

Phase 2 — Mapping (Wochen 5–8). Jedes aktive Projekt abbilden: Umsatz, erwartetes Enddatum, vollständig belastete Entwicklerkosten (Gehalt + Benefits + Overhead-Zuteilung), direkte Kosten (Subunternehmer, Tools). Deckungsbeitrag pro Projekt für das vorherige Quartal berechnen. Die Zahlen werden überraschen. Artikel #4 → behandelt die operative GuV, mit der das verbunden ist.

Phase 3 — Entscheidungsintegration (Wochen 9–12). Mit drei Monaten Auslastungsdaten und Deckungsbeitrag pro Projekt trifft die Inhaberin drei Entscheidungen: (1) einen Kunden neu bepreisen, (2) einen Kunden abstoßen, (3) eine Einstellungsentscheidung gegen drei Szenarien modellieren. Nach diesen Entscheidungen ist die Praxis etabliert. Der monatliche Rhythmus übernimmt.

Artikel #12 → behandelt das Rhythmus-Framework.

📌 Sehen Sie, wie Betriebsbuchhaltung für eine IT-Dienstleistungsagentur aussieht — Auslastung, effektiver Satz, Deckungsbeitrag pro Projekt — in einer einzigen integrierten Ansicht. Buchen Sie eine 20-minütige Finmap-Demo. Wir gehen ein reales Beispiel einer Agentur-Einrichtung durch und zeigen, wie die drei Zahlen Entscheidungen sichtbar machen. [Finmap-Demo buchen →]