Je vooruitontvangen omzet staat in één tabblad dat één iemand bijhoudt, en het wordt zelden nagerekend. Een schema dat door je P&L, je balans en je cashflow loopt, lost dat op, want zo'n schema controleert zichzelf.
Daarom kun je het bouwen inmiddels aan AI overlaten. De uitkomst hoef je niet op zijn woord te geloven; de vorm van het schema bewijst of het klopt.
Vooruitontvangen omzet raakt je P&L, je balans en je cashflow in één beweging
Eerst even scherp wat ik met een schema bedoel. Het is de uitgewerkte onderbouwing onder je balanspost vooruitontvangen omzet: een tabel met per contract (of per contractregel) een rij en per maand een kolom.
Elke rij laat vier dingen zien: wat er aan het begin van de maand nog openstond, wat je die maand factureerde, wat er vrijviel naar de omzet en wat er aan het eind als schuld blijft staan. Tel je de rijen op, dan heb je de balanspost; tel je de vrijval op, dan heb je de omzetregel. In Engelstalige stukken heet dit een deferred revenue schedule.
Je factureert een jaarcontract vooruit. Het geld staat binnen, de prestatie moet nog komen.
Dus staat het bedrag als schuld op je balans en zakt het maand voor maand in je omzet. Elke regel in je schema raakt daarmee drie plekken tegelijk: de factuur loopt door je kasstroom en je debiteuren, het restant staat op je balans, het vrijgevallen deel staat in je omzet.
En precies daarom is elke fout zichtbaar. De mutatie op je balans is per definitie gelijk aan wat je factureerde min wat er vrijviel.
Rekenvoorbeeld. Een MKB-groep met onderhoudscontracten staat op 1 maart met 184.000 vooruitontvangen omzet op de balans. In maart factureert ze 96.500 aan nieuwe en verlengde contracten, en valt er 71.200 vrij naar de omzet. Het eindsaldo hoort dan 209.300 te zijn. Staat er iets anders, dan is er een regel in het schema die in de P&L of op de balans niet is geland.
Die controle doe je zonder één contract open te slaan. Dat is wat dit schema zo bruikbaar maakt in een maandafsluiting waarin je al te weinig tijd hebt.
Een deelmaand, een implementatiefee en een tussentijdse opzegging breken elk standaardschema
Vraag een AI-assistent om zo'n schema en je krijgt een lineaire verdeling over hele maanden. Dat is een redelijke gok. Het is zelden wat er in je contracten staat.
De verslaggevingsregels vragen hier ook iets van je. De herziene RJ 270 over opbrengstverantwoording geldt voor boekjaren die beginnen op of na 1 januari 2022, en de Raad voor de Jaarverslaggeving voegde daar juist extra uitleg en voorbeelden aan toe omdat de oude tekst zo summier was (SRA over de ontwerprichtlijn). Wanneer welke prestatie geleverd is, blijft een keuze die jij maakt.
Vier gevallen waarin de lineaire gok misgaat:
Een contract dat op 18 maart live gaat, terwijl het model maart als volle maand rekent.
Een implementatiefee die bij oplevering verdiend is en dus niet over de looptijd hoort.
Een opzegging per 1 juli, waarbij het restant wordt terugbetaald.
Een prijsindexatie halverwege de looptijd.
Rekenvoorbeeld. Bij datzelfde contract hoort een implementatiefee van 8.400, verdiend op de dag dat de klant live gaat. Een lineaire verdeling over twaalf maanden zet daar 700 van in maart en schuift 7.700 omzet vooruit die je al verdiend hebt. Op het totaal van de groep valt dat weg. In de maandcijfers van die ene BV zie je het meteen.
Het model kan die regels niet uit je data halen, want ze staan er niet in. De eerste stap van dit werk zit dus in je contractmap: schrijf per contracttype op wanneer de omzet verdiend is, en geef die regel mee als instructie.
Dat kost een half uur. Daarna bouwt een AI-assistent in minuten een schema dat je anders een middag had gekost.
Drie aansluitingen zeggen meer over je schema dan hoe overtuigend het eruitziet
Een door AI gebouwd schema ziet er altijd verzorgd uit. Hoe het eruitziet zegt niets over of het klopt.
De balansmutatie is de harde controle: beginsaldo plus gefactureerd min vrijval is het eindsaldo. De P&L-regel is de tweede: de vrijval in je omzet is de som van de contractregels in je schema, per entiteit en per maand. De kasstroom is de derde: wat je ontving sluit aan op wat je factureerde, gecorrigeerd voor de mutatie in je debiteuren.
Let op het verschil tussen het saldo en de mutatie. Een eindsaldo dat klopt bewijst weinig, omdat twee fouten in dezelfde maand elkaar kunnen opheffen. De mutatie legt dat bloot.
Vraag het model daarom om de drie aansluitingen in hetzelfde bestand te zetten, als regels die je zelf kunt narekenen.
Een schema dat zichzelf kan tegenspreken, is het enige dat je kunt vertrouwen
Het verschil tussen een model dat je gebruikt en een model dat je na een maand wegklikt, zit in de controle die erin gebouwd zit. AI maakt het bouwen van die controle vrijwel gratis.
Zet maandag dus niet alleen het schema neer, maar ook de drie aansluitingen eronder.
Over meerdere entiteiten heen wordt dit vooral een kwestie van één plek waar het schema en die aansluitingen staan, in plaats van vier tabbladen bij vier controllers. Dat is precies het soort werk waar we bij Smartbooks aan bouwen.
Tot volgende week,
Jaap