Cashflow-apps: de volledige gids

Een ondernemer die zijn boekhouding op orde heeft, weet hoe het vorig kwartaal ging. Wat hij vaak niet weet, is of hij over vijf weken de btw kan betalen. Dat verschil tussen achteruitkijken en vooruitkijken is waar een cashflow-app voor is.

Een cashflow-app beantwoordt één vraag: hoeveel staat er over een, vier en twaalf weken op de bank, en waarom.

Het antwoord komt uit drie bronnen. De bank: het saldo van nu en de vaste afschrijvingen die elke maand terugkomen. De debiteuren: de facturen die openstaan en wanneer ze waarschijnlijk worden betaald. De crediteuren: de facturen die u moet betalen en wanneer u dat gaat doen. Daarbovenop komt wat nog niet is gefactureerd maar wel gaat komen: de lonen, de btw, de huur, de order die volgende week de deur uitgaat.

De toepassingen lopen uiteen. Een aannemer met grote projecten wil zien of de termijnfacturen op tijd komen om de onderaannemers te betalen. Een webshop wil de seizoenspiek in de inkoop kunnen financieren uit de piek in de verkoop, en weten hoeveel er tussen zit. Een adviesbureau met maandfacturen wil weten wanneer een grote klant die laat betaalt, een probleem wordt. Een groeiend bedrijf wil de bank laten zien dat de kredietaanvraag onderbouwd is.

Wat het niet is: een boekhoudpakket, een facturatietool of een dashboard over het afgelopen kwartaal. Die bestaan, en de cashflow-app leest eruit. Het is ook geen winstprognose; winst en cash lopen uit elkaar door afschrijvingen, voorraad, btw en betaaltermijnen, en precies dat verschil is waar de app over gaat.

Het banksaldo over twaalf weken is één getal, maar het bestaat uit delen met heel verschillende zekerheid. Een app die ze bij elkaar optelt zonder onderscheid, geeft een getal dat precies lijkt en dat niet is.

Vast

het saldo van nu, de vaste lasten, de btw-aangifte, de lonen, de aflossingen

Gepland

openstaande facturen, in en uit, met een verwachte betaaldatum per partij

Verwacht

orders die nog gefactureerd worden, projecten in uitvoering, de seizoensomzet

Scenario

wat er gebeurt als de grote klant een maand later betaalt of de order niet doorgaat

De eerste laag is de makkelijkste en de belangrijkste. Vaste lasten, lonen, btw en aflossingen zijn bekend en komen op een vast moment. Alleen die laag tegenover het banksaldo laat al zien in welke week het krap wordt, en dat is vaak de week vóór de btw-aangifte of de week waarin lonen en huur samenvallen.

De tweede laag is waar de meeste fouten zitten. Een openstaande factuur met vervaldatum over veertien dagen wordt zelden op dag veertien betaald. De app moet per klant weten hoe lang die er gemiddeld over doet, en daarmee rekenen. Een klant die structureel op dag vijfenveertig betaalt, staat in de prognose op dag vijfenveertig, niet op dag dertig. Dat is de grootste verbetering ten opzichte van een spreadsheet, en hij vraagt alleen de betaalhistorie uit de boekhouding.

De derde laag is uw aanname, en daar hoort het label bij. Een order die volgende week getekend wordt, staat erin als verwacht, in een andere kleur, en de app laat zien wat het saldo is mét en zónder. Wie de aannames verstopt in het totaal, bedriegt zichzelf op het moment dat het misgaat.

De bank is de bron van de eerste laag, en de bank is ook het onderdeel met de meeste regels. Hoe de app het saldo en de transacties ophaalt, bepaalt of hij mag bestaan.

Naast de bank leest de app uit de boekhouding: openstaande debiteuren en crediteuren, met factuurdatum, vervaldatum en de betaalhistorie per relatie. De meeste boekhoudpakketten hebben daarvoor een koppelvlak. Wat zelden in een pakket staat, is wat er nog niet is gefactureerd: de orderportefeuille, de projecten in uitvoering, de contracten die maandelijks factureren. Die komen uit het CRM, het projectsysteem, of, eerlijk gezegd, uit het hoofd van de ondernemer. Bouw daar een eenvoudig scherm voor waarin hij ze invoert met een datum en een zekerheid.

Een prognose die drie weken geleden is bijgewerkt, is gevaarlijker dan geen prognose: ze geeft zekerheid over een situatie die niet meer bestaat. Drie patronen komen steeds terug.

Het tweede patroon is het gevaarlijkst. Aannames verouderen stil. De order die 'volgende week' zou komen, staat drie maanden later nog in de prognose, en het saldo ziet er daardoor beter uit dan het is. Geef elke aanname een houdbaarheidsdatum: na die datum telt hij niet meer mee tenzij iemand hem verlengt. Dat is een kleine regel die het grootste risico wegneemt.

Het derde patroon is de prognose als noodinstrument. Wie het scherm alleen opent als het krap is, heeft geen prognose maar een thermometer. De waarde zit in het wekelijkse kwartier: klopt de komende vier weken, welke klant moet worden gebeld, welke betaling kan een week wachten. Bouw de app zo dat dat kwartier kort is: één scherm, de afwijking ten opzichte van vorige week bovenaan.

De prognose zegt wat er waarschijnlijk gebeurt. Het scenario zegt wat er gebeurt als het tegenzit, en dat is de vraag waarvoor de ondernemer de app opent.

Scenario's zijn alleen nuttig als ze goedkoop zijn om te maken. Een spreadsheet waarin u een kopie maakt en drie cellen aanpast, wordt na twee keer niet meer gebruikt. In de app is een scenario de prognose met één regel anders: deze klant op dag zestig in plaats van dag dertig, deze order eruit, deze medewerker erbij vanaf mei. Het resultaat staat naast de basisprognose, in één grafiek.

Waarschuwingen zijn de omgekeerde beweging: de app rekent elke nacht en meldt als het saldo in een van de komende weken onder een grens komt die u heeft gezet. Niet als het al gebeurd is, maar zodra de prognose het voorziet. Dat is het moment waarop een telefoontje naar een klant of een afspraak met een leverancier nog iets uitmaakt.

Een klein bedrijf en een groot bedrijf hebben dezelfde prognose. Wat de prijs drijft, is uit hoeveel systemen de app leest en hoe slim hij met de betaalhistorie omgaat.

Bank

een koppeling via een vergunde partij is bekend werk; de partij zelf rekent doorgaans per rekening

Pakket

één boekhoudpakket met een koppelvlak is eenvoudig; meerdere administraties of een pakket zonder koppelvlak niet

Verwacht

een invoerscherm voor orders en projecten is licht; een koppeling met het CRM of projectsysteem is een stuk werk

Leren

rekenen met de vervaldatum is simpel; per klant het werkelijke betaalgedrag afleiden vraagt historie en logica

Wat meestal meevalt: de prognose zelf. Saldo plus in min uit, per week, in een grafiek: dat is bekend werk. Wat tegenvalt: de gegevens waarop hij rekent. Debiteuren zonder betaalhistorie, crediteuren die niet in de boekhouding staan tot de factuur binnen is, vaste lasten die niemand ooit heeft opgeschreven. Dat verzamelen is werk voor u, en het is de helft van de waarde.

Vraag ook wat uw boekhoudpakket al kan. Veel pakketten hebben een liquiditeitsoverzicht op basis van openstaande posten. Als dat voor u volstaat, hoeft u niets te bouwen. Zelf bouwen wordt interessant als u wilt rekenen met het werkelijke betaalgedrag, als het verwachte werk erbij moet, als u scenario's wilt, of als meerdere administraties bij elkaar moeten.

De volgorde hieronder begint niet bij een koppeling maar bij een lijst die u waarschijnlijk nog niet heeft: alles wat er elke maand vast uitgaat, met de datum.

1. Maak de lijst met vaste lastenHuur, lonen, aflossingen, abonnementen, btw-momenten. Met de dag van de maand waarop ze vallen.
2. Koppel de bankVia een vergunde partij, alleen lezen. Saldo en transacties van de afgelopen twaalf maanden.
3. Koppel de boekhoudingOpenstaande debiteuren en crediteuren, en de betaalhistorie per relatie.
4. Bouw de prognose in drie lagenVast, gepland, verwacht. Apart zichtbaar, met een houdbaarheidsdatum op elke aanname.
5. Voeg het verwachte werk toeEen invoerscherm voor orders en projecten, of een koppeling als het CRM dat aankan.
6. Meet de afwijkingElke week: wat was voorspeld, wat gebeurde. Stel de betaalgedragregels bij waar het structureel afwijkt.