Nacalculatie automatiseren: zo zie je per project of je winst maakt

Je hebt een offerte gemaakt, de klus is afgerond, de factuur is verstuurd. Maar heeft dit project nou geld opgeleverd, of draai je eigenlijk verlies? Bij veel bedrijven in bouw, installatie en hovenierswerk is het antwoord: dat weet je pas als de boekhouder aan het einde van het jaar de cijfers erbij pakt. Dan is het te laat om nog iets aan te passen.

Het probleem zit niet in de wil om het bij te houden. Het zit in waar de gegevens staan. Uren staan in een urenregistratie-app of op een briefje. Materiaalbonnen liggen in de auto of worden los ingescand. Inkoopfacturen van de leverancier komen via e-mail binnen en worden geboekt zonder projectcode. Drie plekken, drie systemen, en niemand telt ze structureel bij elkaar op per klus.

Nacalculatie – het vergelijken van wat een project werkelijk heeft gekost met wat er was begroot – vraagt dus geen nieuwe gegevens. De uren, het materiaal en de facturen worden toch al vastgelegd, deels omdat de wet dat vereist (zie hieronder). Het enige wat ontbreekt is de koppeling: alles onder dezelfde projectcode zetten, zodat je aan het eind één getal ziet in plaats van drie losse lijstjes.

Nacalculatie werkt alleen als drie dingen consequent gebeuren, voor elk project:

• Een vast projectnummer of -code, die overal wordt gebruikt: op de offerte, op de werkbon, in de urenregistratie en op de inkoopfactuur van de leverancier.
• Uren die aan die code hangen, niet aan een dag of een medewerker in het algemeen. Een monteur die op maandag drie klussen doet, moet zijn uren over die drie projectcodes kunnen verdelen.
• Materiaal en inkoop die aan diezelfde code hangen. Dat lukt alleen als de leverancier de projectcode op de factuur zet, of als iemand die er bij het boeken aan toevoegt.

Zonder die discipline blijft nacalculatie een schatting. Met die discipline is het een optelsom die je systeem voor je kan maken: begroot bedrag naast werkelijk bedrag, per project, automatisch bijgewerkt zodra er een uur of een factuur bijkomt.

De meeste boekhoudpakketten ondersteunen projectcodes of kostenplaatsen. Het werk zit niet in de software aanschaffen, maar in het proces: iedereen die uren schrijft of iets inkoopt, moet weten welke code erbij hoort, en dat moet ergens automatisch gecontroleerd worden in plaats van achteraf handmatig uitgezocht.

Er is nog een reden om uren, materiaal en facturen netjes per project te ordenen: het moet toch al, voor de Belastingdienst. Als ondernemer ben je verplicht een controleerbare administratie te voeren van al je inkomsten en uitgaven, inclusief in- en verkoopadministratie. Basisgegevens zoals debiteuren, crediteuren, de in- en verkoopadministratie en het grootboek moet je zeven jaar bewaren; voor onroerend goed en voor de OSS-regeling geldt tien jaar.

Ondernemersplein, het overheidsloket voor ondernemers, noemt dezelfde eis: al je inkomsten en uitgaven, verdeeld over categorieën, plus je debiteuren- en crediteurenadministratie, moeten controleerbaar zijn vastgelegd – ook je computerprogramma's en bestanden moeten bruikbaar blijven voor een eventuele controle.

Met andere woorden: de losse onderdelen (uren, bonnetjes, facturen) moet je toch al vastleggen en bewaren. Nacalculatie voegt daar geen nieuwe verplichting aan toe. Het enige verschil is dat je die gegevens, die je toch al moet hebben, ook gebruikt om te zien of een project geld heeft opgeleverd – in plaats van dat ze alleen ergens liggen voor het geval er een keer een controle komt.

De kern is: één plek waar iemand een projectcode kiest, en die code overal automatisch meegeeft. In de praktijk ziet dat er meestal zo uit:

• Urenregistratie-app waarin een medewerker per gewerkt uur een project kiest uit een lijst, in plaats van los op een briefje. De meeste apps laten zich koppelen aan een boekhoudpakket via een export of een directe koppeling.
• Werkbonnen die digitaal worden ingevuld met de projectcode erop, in plaats van op papier dat later wordt overgetypt.
• Inkoopfacturen die automatisch worden herkend en aan een project gekoppeld op basis van een referentie die de leverancier meekrijgt bij de bestelling, of die iemand er bij binnenkomst handmatig aan hangt – dat kost een paar minuten per factuur, maar wel telkens opnieuw.

Zodra die drie stromen dezelfde projectcode gebruiken, kan een rapport automatisch tonen: begroot versus werkelijk, per project, bijgewerkt zodra er iets bijkomt. Sommige bedrijven laten dat koppelen door hun boekhouder of software-leverancier regelen, andere laten het als maatwerk bouwen tussen de bestaande apps – dat laatste is wat Oarized voor klanten doet wanneer standaardkoppelingen niet aansluiten op hoe een bedrijf werkt.

Nacalculatie automatiseren loont niet voor elk bedrijf. Een paar signalen dat je beter kunt wachten, of het gewoon handmatig kunt blijven doen:

• Je draait weinig projecten per maand. Doe je vijf grote klussen per jaar met een doorlooptijd van maanden, dan kun je die prima met een spreadsheet nacalculeren. De tijdswinst van automatisering weegt dan niet op tegen de tijd die het kost om het proces in te richten.
• Je werkt met vaste prijzen zonder materiaalvariatie. Een hovenier die alleen gazon maait tegen een vaste prijs per beurt heeft weinig aan nacalculatie per klus – de kosten liggen al vast.
• Je hebt geen van de onderliggende systemen op orde. Als uren nog op papier worden bijgehouden en facturen los in een postvak binnenkomen, is koppelen niet de eerste stap. Eerst moet er iets zijn om te koppelen.

Andersom geldt: hoe meer projecten per maand, hoe wisselvalliger het materiaalgebruik, en hoe vaker een klus toch duurder blijkt dan begroot, hoe sneller dit zich terugverdient. Bij twijfel is een half jaar handmatig bijhouden in een spreadsheet een goedkope manier om te testen of het patroon dat je vermoedt – bepaalde type projecten lopen structureel uit – ook echt klopt, voordat je tijd in automatiseren steekt.