Urenfacturatie: de volledige gids

De meeste dienstverleners hebben een urenregistratie en een facturatiepakket. Wat ze vaak niet hebben, is het stuk ertussen: de regels die bepalen welk uur op welke factuur komt en wat het kost. Dat stuk zit in een spreadsheet, in het hoofd van de projectleider, of nergens.

Urenfacturatie beantwoordt per geschreven uur drie vragen: is dit factureerbaar, tegen welk tarief, en op welke factuur.

Die drie vragen klinken eenvoudig, maar ze hebben veel antwoorden. Een uur is factureerbaar, tenzij het intern was, of binnen een vaste prijs valt, of boven het afgesproken maximum zit. Het tarief hangt af van de klant, van de rol van degene die het uur schreef, van de afspraak in de offerte en soms van het tijdstip. En de factuur is per project, per maand, per opdrachtgever of per inkooporder, afhankelijk van wat de klant wil.

Voor wie geldt dit? Voor adviesbureaus, ontwikkelbureaus, advocaten, accountants, detacheerders, installatiebedrijven die op regie werken, en freelancers met meer dan een paar klanten. Overal waar tijd het product is en de afspraken per klant verschillen.

Wat het niet is: een knop in de urenregistratie die alle uren van de maand op een factuur zet. Dat werkt bij één klant met één tarief. Bij de tweede klant met een andere afspraak begint het handwerk, en daar ontstaan de fouten.

Voordat een uur een bedrag wordt, passeert hij een reeks regels. Die regels staan meestal in de offerte of het contract, en ze moeten letterlijk in het systeem, per klant, anders rekent iemand ze elke maand opnieuw uit.

Tarief

per klant en per rol; een senior en een junior op hetzelfde project hebben elk een eigen tarief

Afronding

per kwartier, per half uur of op de minuut; per klant afgesproken en op de factuur uitlegbaar

Maximum

een budgetplafond of een aantal uren per maand waarboven eerst overleg nodig is

Vaste prijs

regels die binnen een afgesproken bedrag vallen, en dus wel geschreven maar niet gefactureerd worden

Afronding is de bron van de meeste kleine discussies. Per kwartier afronden naar boven is gebruikelijk bij advocaten en ongebruikelijk bij ontwikkelaars; een klant die het niet verwacht, ziet het als opgeplust. Spreek het af, zet het in de offerte en laat het systeem het uitvoeren zoals afgesproken, niet zoals de standaardinstelling het doet.

Vaste prijs en nacalculatie lopen op hetzelfde project door elkaar: het ontwerp voor een vast bedrag, het meerwerk op regie. Het systeem moet per regel weten welke afspraak geldt, zodat de uren binnen de vaste prijs wel worden geschreven (voor de interne rekensom) maar niet gefactureerd, en het meerwerk wel. Wie dat in één kolom probeert, factureert de vaste prijs twee keer of het meerwerk nooit.

Het maximum is de regel die relaties redt. Een klant met een budgetplafond wil niet verrast worden door een factuur die erboven zit. Het systeem hoort te waarschuwen als het plafond in zicht komt, vóór de uren zijn gemaakt, niet erna op de factuur.

De grootste winst van een goed systeem zit niet in de snelheid van factureren, maar in wat er daarna niet gebeurt: geen mail met 'waar is dit van', geen creditnota, geen telefoontje over drie uur op een vrijdag.

Goedkeuring door de klant vraagt een scherm waar hij inlogt of een link die hij per mail krijgt. Dat is een klein klantportaal, en het is vaak de eerste keer dat een klant inzicht krijgt in wat er voor hem gebeurt. Bureaus die dit invoeren, merken dat de discussie verschuift van de factuur naar het werk zelf, en dat is waar hij hoort.

De omschrijving bij het uur is waar het staat of valt. 'Overleg' zegt niets; 'overleg met inkoop over de leveringsvoorwaarden' wel. Het systeem kan een omschrijving verplicht maken en een minimumlengte afdwingen, maar de gewoonte moet van het team komen. Een specificatie vol 'diversen' roept meer vragen op dan geen specificatie.

Elk bureau kent de maandafsluiting waarin blijkt dat de helft van de uren nog niet is geschreven, een tarief nog van vorig jaar is en een project twee keer is gefactureerd. Het systeem lost dat niet allemaal op, maar het maakt het zichtbaar.

Het tariefprobleem is subtiel omdat het lang onzichtbaar blijft. Een tariefverhoging die in de mail aan de klant staat maar niet in het systeem, kost elke maand een percentage van de omzet, en niemand merkt het tot de jaarcijfers. Tarieven horen met ingangsdatum in het systeem, en een factuur die een oud tarief gebruikt na die datum, hoort een waarschuwing te geven.

Het te laat schrijven is een gewoonteprobleem, maar het systeem kan helpen: een overzicht per persoon van dagen zonder uren, een herinnering, en een projectleider die ziet wie achterloopt voordat de maand sluit. Uren die een week later worden gereconstrueerd, zijn minder, vager en vaker betwist.

Het systeem zit letterlijk tussen andere systemen in, en dat maakt de koppelingen de kern. Wat het zelf bewaart, zijn de afspraken per klant en de status per uur.

De koppeling met de urenregistratie is de eerste. Als uw team al uren schrijft in een tool, leest het systeem daaruit; het vervangt de tool niet. Als uren nu in spreadsheets staan, is het verstandiger eerst een urenregistratie te kiezen en pas daarna de facturatie eraan te hangen. Zie de gids over urenregistratie-apps.

De koppeling met de offerte is de meest onderschatte. De tarieven en afspraken staan al in de offerte die de klant heeft geaccepteerd; als die offerte in een systeem staat, kunnen de regels daaruit komen in plaats van opnieuw te worden ingevoerd. Dat voorkomt het verschil tussen wat is afgesproken en wat wordt gefactureerd.

Vijf of vijftig medewerkers maakt voor de bouw weinig uit. Wat de prijs drijft, is hoeveel verschillende afspraken het systeem moet kennen en of de klant meekijkt.

Afspraken

één tarief per klant is eenvoudig; rollen, staffels, maxima en vaste prijzen per project zijn regels

Goedkeuring

een intern akkoord is klein; een klantscherm met goedkeuring is een portaal

Koppelingen

urenregistratie, offerte en boekhouding; elk een eigen koppelvlak

Historie

bestaande projecten met oude tarieven en al gefactureerde uren moeten mee

Wat meestal meevalt: de factuur en de specificatie. Dat zijn bekende onderdelen, en de factuur zelf hoort thuis in uw boekhoudpakket. Wat tegenvalt, is het benoemen van de afspraken per klant. Die staan nu in offertes, mails en hoofden, en het bij elkaar brengen is werk voor u dat vóór de bouw moet gebeuren.

Vraag u eerst af of uw urenregistratie of uw facturatiepakket dit al kan. Veel tools hebben een facturatiefunctie met tarieven per project. Als uw afspraken daarin passen, gebruik die. Bouwen heeft zin als de afspraken afwijken, als de klant moet goedkeuren, of als uren uit meerdere bronnen komen die één factuur moeten worden.

De volgorde begint bij wat u met elke klant heeft afgesproken, niet bij de factuur. Wie bij de factuur begint, bouwt een snellere manier om het verkeerde tarief te gebruiken.

1. Verzamel de afspraken per klantUit offertes, contracten en mails: tarief per rol, afronding, maximum, vaste prijs. Eén lijst per klant.
2. Zet ze in het systeem met ingangsdatumTarieven met een datum vanaf wanneer ze gelden. Oude projecten houden hun oude tarief.
3. Koppel de urenregistratieDe geschreven uren komen binnen met persoon, project en omschrijving. Test of alles aankomt.
4. Bouw de status per uurGeschreven, gecontroleerd, goedgekeurd, gefactureerd. Een uur kan maar op één factuur.
5. Laat de klant meekijkenEen link of een scherm met de uren van de maand, vóór de factuur. Begin met één klant die het waardeert.
6. Factureer via de boekhoudingDe factuur met specificatie als verkoopboeking in het pakket. Vergelijk de eerste maand met de oude spreadsheet.