P&L per bedrijfsonderdeel in een IT-bedrijf: ontwikkeling, support, staff augmentation

Een IT-bedrijf doet zelden maar één ding. Binnenin lopen meestal meerdere bedrijfsonderdelen tegelijk: productontwikkeling, outsourcing of staff augmentation, support, soms ook SEO, design of consulting erbovenop. Op bedrijfsniveau zien de cijfers er prima uit — er is omzet, er is winst aan het einde van het jaar. Maar dat is de gemiddelde temperatuur op de afdeling: het ene onderdeel kan zeer winstgevend zijn, terwijl een ander jarenlang stilletjes opeet wat het eerste verdiende.

Zolang je alleen naar de totale winst-en-verliesrekening kijkt, zie je dit niet. Een P&L per bedrijfsonderdeel is hetzelfde overzicht, maar uitgesplitst per onderdeel. Het beantwoordt de vraag die de strategie van een bedrijf bepaalt: waar verdienen we eigenlijk aan, en wat houden we in stand uit gewoonte?

Laten we stap voor stap doorlopen hoe je dit opbouwt, kijken naar een echt voorbeeld met cijfers, en zien welke beslissingen het mogelijk maakt. Als managementboekhouding nog nieuw voor je is, begin dan bij de basis in Management Accounting for an IT Company in Plain Words.

Waarom de totale P&L de waarheid verbergt

Stel je een bedrijf voor met UAH 12M jaaromzet en UAH 1,5M winst. Op het eerste gezicht is alles in orde: het bedrijf draait winst, de marge ligt rond de 12%. De eigenaar is gerust en blijft elk onderdeel in gelijke mate ontwikkelen.

Splitsen we datzelfde resultaat nu uit per onderdeel. Dan blijkt dat productontwikkeling +2,4M opleverde, staff augmentation +0,3M, en support — min 1,2M. Met andere woorden: de winstgevende onderdelen subsidiëren al jaren de verliesgevende, en het bedrijf groeit niet dankzij support, maar ondanks support. Op de totale P&L is hier helemaal niets van te zien — het verlies van het ene onderdeel verschuilt zich gewoon achter de winst van het andere.

Precies daarom is de totale winst een gevaarlijk getal om beslissingen op te baseren. Het zegt "over het geheel genomen gaat het goed", maar het zegt niet waar je moet investeren en wat je moet repareren. Een P&L per bedrijfsonderdeel haalt die middeling weg.

Stap 1. Bepaal je onderdelen op basis van hoe ze geld opleveren

Een bedrijfsonderdeel is geen afdeling of team — het is de manier waarop je geld verdient. Ontwikkeling tegen een vaste prijs, maandelijkse staff augmentation, support op abonnementsbasis, je eigen subscriptieproduct — dit zijn verschillende modellen met verschillende economie, en elk moet apart worden geteld.

Snijd niet te fijn. Aan het begin volstaan 3-5 onderdelen die merkbaar van elkaar verschillen in geld. De belangrijkste test is simpel: als twee onderdelen op een verschillende manier geld verdienen en je zou het ene kunnen stopzetten zonder het andere te raken, dan zijn het aparte onderdelen.

Stap 2. Ken inkomsten toe aan onderdelen

Label elke binnenkomende betaling met een onderdeel. Betaling voor een fixed-price project gaat naar "ontwikkeling", een maandelijkse factuur voor dedicated developers gaat naar "staff augmentation", een supportabonnement gaat naar "support". Het is de simpelste stap, maar wel de stap die de structuur van het hele rapport bepaalt.

Eén kanttekening: als een klant in één betaling voor meerdere diensten betaalt (bijvoorbeeld ontwikkeling + support), splits het bedrag dan over de onderdelen. Anders wordt het ene onderdeel kunstmatig opgeblazen ten koste van het andere.

Stap 3. Ken directe kosten toe — vooral salarissen en tijd

In IT is de grootste kostenpost mensen, en precies daar zit de hele waarheid over je onderdelen verborgen. Als een developer volledig op een staff-augmentationproject werkt, valt zijn salaris volledig onder staff augmentation. Als een teamlead de helft van zijn tijd aan het product besteedt en de helft aan support, moet zijn salaris fifty-fifty over de onderdelen worden verdeeld.

Zonder tijd toe te wijzen werkt een P&L per bedrijfsonderdeel niet: alle salarissen belanden op één hoop, en het verliesgevende onderdeel ziet er prima uit omdat de werkelijke kosten "uitgesmeerd" worden over het hele bedrijf. Je hoeft geen tijdregistratie tot op de minuut in te voeren — aan het begin volstaat een eerlijke inschatting van welk percentage van hun tijd elke sleutelpersoon aan elk onderdeel besteedt.

In hetzelfde mandje horen ook de overige directe kosten van een onderdeel: freelancers, licenties en diensten voor specifieke projecten, cloud voor het product, zakenreizen. Alles wat precies vanwege dat onderdeel bestaat.

Stap 4. Verdeel gedeelde kosten

Wat overblijft zijn kosten die niet bij één specifiek onderdeel horen: kantoor, boekhouding, managementsalarissen, sales, marketing. Ook die moeten worden verdeeld, anders wordt de winst van de onderdelen te hoog voorgesteld. De eenvoudigste verdeelsleutels zijn de omzet van een onderdeel of het aantal mensen erin.

Maak het niet te ingewikkeld: zelfs een grove maar consistente verdeling geeft een beeld dat een aantal keer nauwkeuriger is dan "gedeelde kosten leven op zichzelf". Het belangrijkste is om één regel op elk onderdeel op dezelfde manier toe te passen.

Voorbeeld: een P&L per bedrijfsonderdeel in cijfers

Laten we teruggaan naar het bedrijf met UAH 12M omzet. We splitsen het voor het jaar op in drie onderdelen.

Ontwikkeling: inkomsten 6M, teamsalarissen 2,8M, freelancers 0,4M, aandeel gedeelde kosten 1,2M → winst +1,6M (marge ~27%).

Staff augmentation: inkomsten 4M, salarissen van dedicated developers 3,0M, gedeelde kosten 0,8M → winst +0,2M (marge ~5%).

Support: inkomsten 2M, salarissen supportteam 2,3M, gedeelde kosten 0,6M → winst −0,9M (marge −45%).

Samen komt het uit op ongeveer dezelfde +0,9M, maar nu is het belangrijkste zichtbaar: ontwikkeling voedt het bedrijf, staff augmentation houdt zich nauwelijks drijvende, en support is structureel verliesgevend. Dit is niet langer "over het geheel genomen een plus" — dit zijn concrete beslissingen die op tafel liggen.

Welke beslissingen een P&L per bedrijfsonderdeel mogelijk maakt

Als je de onderdelen apart ziet, hoort bij elk onderdeel een duidelijk scenario. Winstgevende ontwikkeling — schaal het op: meer projecten zoals dit, meer mensen. Staff augmentation met een marge van 5% — herzie je tarieven, want het draait bijna op break-even en elke stilstand duwt het in het rood (zoals in de case 20 developers, an hourly rate, and no idea how much the project earned).

Verliesgevende support — zet het niet blindelings stop, maar duik erin: misschien is het onderprijsd en moeten de abonnementstarieven omhoog, of misschien houdt het klanten vast voor winstgevende ontwikkeling en is het een bewuste investering. Het punt is dat het nu een bewuste beslissing is, geen ongeluk. Dezelfde aanpak toegepast op klanten in plaats van onderdelen vind je in P&L by Client: Who Actually Brings the Money, en een vergelijking tussen onderdelen, locaties en kanalen in Margin by Business Line, Location and Channel.

Een P&L per bedrijfsonderdeel handmatig opbouwen in Excel kan, maar elke maand is het uitputtend werk om salarissen en gedeelde kosten te verdelen. In Finmap koppel je transacties eenmalig aan onderdelen, en wordt de winst per onderdeel voor je berekend — probeer het 7 dagen gratis.