Managementboekhouding voor een IT-agency: de drie cijfers die alles vertellen

"₴12M jaaromzet. 15 developers. Drie jaar winstgevend. En als ik eerlijk ben, kon ik niet zeggen welk project winstgevend was en welk een langzaam lek."

De oprichtster van een IT-servicebureau beschreef het moment van inzicht tijdens een leadership offsite. Haar bedrijf was drie jaar lang gegroeid. Omzet van ₴4M naar ₴12M. Personeelsbestand van 5 naar 15 developers. Winst zichtbaar aan het einde van het jaar. Op elke externe maatstaf — succesvol.

Toen stelde de COO een vraag: "Van onze 11 actieve projecten, welke twee zijn het meest winstgevend per ontwikkeluur?"

Ze kon geen antwoord geven. De boekhouding liet omzet per project zien (soms — wanneer projecten netjes werden gefactureerd). Er stonden geen ontwikkeluren per project in. Er stond geen effectief uurtarief in, na aftrek van downtime, feestdagen, intern werk. Er stond geen contributiemarge per projecttype in (T&M versus fixed-fee versus retainer).

Ze wist dat haar totale marge gezond was. Ze wist niet welke klanten die genereerden en welke stilzwijgend de groei van het bureau subsidieerden uit haar eigen marge.

Dit artikel gaat over de drie cijfers die een IT-agency-eigenaar nodig heeft om haar bedrijf te begrijpen — en waarom standaard boekhouding ze niet oplevert, hoe zorgvuldig de boekhouder ook is.

De paradox: ₴12M omzet betekent niet ₴12M aan beslissingen

De meeste agency-eigenaren letten op twee cijfers: omzet en nettowinst. Dit zijn de cijfers die hun boekhouder oplevert, de cijfers die ze noemen wanneer ze hun bedrijf voorstellen, de cijfers die ze maand na maand volgen.

Deze twee cijfers zijn te geaggregeerd om beslissingen te sturen. Een IT-agency met ₴12M omzet en 18% nettomarge (₴2,16M winst) oogt gezond. Maar:

• Als 60% van de omzet van twee klanten komt, heeft het bedrijf een verborgen concentratierisico
• Als het meest winstgevende project 38% marge levert en het minst winstgevende −4%, verbergt het totaal zowel een kans (meer van het winstgevende type) als een probleem (de verliesmaker)
• Als de bezettingsgraad van developers op 58% ligt terwijl de projectlijst "volledig bemand" oogt, is er jaarlijks ₴1,4M aan onbenutte factureerbare capaciteit
• Als het team 20% van de tijd van betaald klantwerk wordt gehaald voor onbetaald intern werk, ligt het effectieve uurtarief drastisch lager dan het gepubliceerde

De totaalcijfers zeggen "je bent winstgevend." De beslissingen moeten weten "waar, met wie, op wat, en hoe duurzaam." Managementboekhouding voor een IT-agency is specifiek zo opgezet dat het die vraag beantwoordt.

Het algemene kader — managementboekhouding als discipline — staat in het ankerartikel → Managementboekhouding uitgelegd.

De drie cijfers die managementboekhouding voor een IT-agency oplevert

Voor een IT-servicebureau doen drie cijfers het meeste werk bij het sturen van beslissingen. Cijfer één — bezettingsgraad per developer. Van de uren dat een developer per maand beschikbaar is om te werken (~160), hoeveel waren factureerbaar aan een klant? Het typische servicebedrijf gaat uit van 100%. Het eerlijke cijfer voor een IT-agency is 60–75% — de rest is sales-ondersteuning, interne tools, training, ziektedagen, wachttijd tussen projecten. Bezettingsgraad, per developer per maand bijgehouden, laat zien: wie betrouwbaar belast is, wie tussen projecten in zit, waar capaciteit zich verstopt, waar het bureau stilzwijgend overbemand is voor de huidige vraag.

Cijfer twee — effectief uurtarief per project. Gepubliceerde tarieven zijn ambitieus ("ons tarief voor een senior developer is ₴1.800/uur"). Effectieve tarieven zijn wat er werkelijk gebeurt na scope creep, kortingen om developers zonder werk bezig te houden, niet-gefactureerde interne uren en herwerk. Voor een gezonde IT-agency is het effectieve tarief 75–90% van het gepubliceerde. Onder 70% wijst op onderprijzing of scope-lekkage. Per project berekend, vertelt dit cijfer welke projecten betrouwbaar winstgevend zijn en welke stilzwijgend wegzakken.

Cijfer drie — contributiemarge per project (en per projecttype). Omzet minus directe leveringskosten (ontwikkeltijd tegen volledige kostprijs, onderaannemers, aan het project toegewezen tools) vóór toegerekende overhead. Per project berekend, is dit het belangrijkste strategische signaal: het zegt welk werk het waard is om meer van te doen, welk werk herprijsd moet worden, welke klanten je moet verdiepen, welke klanten je moet ontslaan.

Deze drie cijfers staan niet op een fiscaal geformatteerde winst-en-verliesrekening. Ze ontstaan door managementboekhouding te leggen bovenop nette boekhouding plus tijdregistratie. Artikel #2 → behandelt het onderscheid tussen boekhouding en managementboekhouding; artikel #4 → behandelt de operationele winst-en-verliesrekening waarmee dit samenhangt.

Hoe die cijfers prijsstelling, aanwerving en klantenmix veranderen

Wanneer de drie cijfers bestaan, worden vier soorten beslissingen gestructureerd in plaats van instinctief.

Prijsstelling. In plaats van "laten we dezelfde tarieven aanhouden omdat klanten niet hebben tegengesputterd," wordt prijsstelling: "ons effectieve tarief bij deze klant is 67% van het gepubliceerde — we verliezen 33 punten aan scope-lekkage. Beperk de scope of verhoog het tarief met 30%." Concreet. Verdedigbaar.

Aanwerving. In plaats van "we voelen ons druk, laten we nog een developer aannemen," wordt aanwerving: "de bezettingsgraad van het team ligt al drie maanden op 76%, en blijft naar verwachting zo gezien de pipeline. Eén extra senior zou de bezetting meteen naar 65% brengen en tegen maand drie naar 75% stijgen. Betaalbaar in het basisscenario, krap in het pessimistische scenario." Gemodelleerd. Onderbouwd. Artikel #5 → behandelt het financiële model waarmee deze scenario's doorgerekend kunnen worden.

Klantenmix. In plaats van "alle klanten zijn min of meer gelijk," wordt klantenmix beheerd: de twee klanten met negatieve contributiemarge laten vallen, de drie met bovengemiddelde marge verdiepen, een tariefaanpassing voorstellen aan de twee klanten in het midden wier effectieve tarief stilzwijgend onder de drempel ligt.

Beslissingen over servicelijnen. Wanneer contributiemarge per projecttype wordt gemeten (fixed-fee ontwikkelwerk versus T&M versus doorlopende retainer), leert het bureau welke modellen het meest winstgevend zijn en past het de salesmix daarop aan. Veel bureaus ontdekken dat hun werk met de laagste marge historisch juist het werk is dat ze het leukst vonden — en handelen daarnaar.

De IT-specifieke complicaties

Een aantal IT-agency-realiteiten maakt managementboekhouding lastiger dan bij andere servicebedrijven — en waardevoller wanneer het wel gebeurt. Discipline in tijdregistratie. Zonder urenregistratie per developer per project kunnen bezettingsgraad en effectief tarief niet gemeten worden. De meeste bureaus beginnen met een tool (Toggl, Harvest, Clockify) en de discipline ontstaat na 60–90 dagen. De discipline zelf onthult problemen: een developer die 14 uur/dag logt suggereert een verkeerd ingeschatte scope; een developer die 4 uur/dag als "intern" logt onthult onderbenutting.

Wachttijd ("bench time"). Tussen projecten in kosten developers het bureau geld zonder te factureren. Dit is geen dood kapitaal — het is voorbereiding, training, sales-ondersteuning. Maar het moet worden bijgehouden en begroot. Een gezond bureau draait ~10–15% wachttijd. Boven 25% is dat een probleem in de sales-pipeline, geen probleem in de levering.

Valutarisico. Veel Oekraïense IT-agency's factureren in USD of EUR terwijl ze in UAH betalen. Wisselkoersbewegingen beïnvloeden de marge. Managementboekhouding die alles omrekent naar één rapportagevaluta tegen de juiste koersen legt de werkelijke marge bloot — en onthult wanneer valuta de verklaring is voor een margeverschuiving, niet een operationele verandering.

Mix van projecttypes. Fixed-fee, T&M (tijd en materiaal), retainer, dedicated team — elk heeft een andere margedynamiek, ander risico, andere timing van cashflow. Omzet over alle types heen aggregeren verbergt welke modellen groeien in aandeel en welke marge inleveren.

Hoe je managementboekhouding in 90 dagen invoert

De agency-eigenaar uit de opening deed dit binnen één kwartaal. Drie fasen.

Fase 1 — Fundament (week 1–4). Voer tijdregistratie in. Categoriseer alle uren van developers in: factureerbaar aan specifieke klant/project, intern (sales-ondersteuning, training, tools), wachttijd (tussen projecten), administratief. Zorg dat elke developer consequent uren logt. De eerste maand data is onvolledig — dat is te verwachten.

Fase 2 — In kaart brengen (week 5–8). Breng elk actief project in kaart: omzet, verwachte einddatum, volledige kostprijs van de developer (salaris + secundaire arbeidsvoorwaarden + toegerekende overhead), directe kosten (onderaannemers, tools). Bereken contributiemarge per project voor het voorgaande kwartaal. De cijfers zullen verrassen. Artikel #4 → behandelt de operationele winst-en-verliesrekening waarmee dit samenhangt.

Fase 3 — Integratie in besluitvorming (week 9–12). Met drie maanden aan bezettings- en contributiemargedata per project neemt de eigenaar drie beslissingen: (1) één klant om te herprijzen, (2) één klant om te laten vallen, (3) één aanwervingsbeslissing gemodelleerd tegen drie scenario's. Na deze beslissingen is de praktijk gevestigd. Een maandelijks ritme neemt het over.

Artikel #12 → behandelt het ritmekader.

📌 Bekijk hoe managementboekhouding eruitziet voor een IT-servicebureau — bezettingsgraad, effectief tarief, contributiemarge per project — in één geïntegreerd overzicht. Boek een demo van 20 minuten bij Finmap. We lopen samen door een echte voorbeeldopzet voor een agency en laten zien hoe de drie cijfers beslissingen naar boven halen. [Boek een Finmap-demo →]