Bruidswarenhuis
De vraag of het budget klopt, is eigenlijk een andere vraag: staat er iets in dat er niet had moeten staan, of ontbreekt er iets dat er wel had moeten staan. Dat controleer je niet door het hele bedrag onderaan te bekijken, maar door te kijken of elke keuze die jullie hebben gemaakt ook echt een post is geworden.
Dat gebeurt namelijk automatisch. Zodra jullie op de startpagina van het dossier een blok invullen, gemeente, trouwlocatie, fotograaf, ringen, catering, of welk ander blok dan ook, wordt die keuze vanzelf een post in het budget. Met de leverancier erbij, de categorie waar hij onder valt en de vraag waarvoor het bedrag precies is. Kiezen jullie voor een trouwauto, dan staat er meteen een post trouwauto, met de naam van het verhuurbedrijf. Er is geen apart moment waarop je dat handmatig moet overtypen naar een budgetlijst. Als het blok bestaat, bestaat de post.
Dat betekent ook dat je het budget kunt controleren door het tegenovergestelde te doen: niet het budget doorlezen, maar het overzicht van blokken. Staat er een blok bruidskleding, maar geen post bruidskleding in het budget? Dan is er iets misgegaan, en dat zie je meteen, want het aantal blokken en het aantal posten horen gelijk te lopen. Andersom werkt het net zo. Een post zonder bijbehorend blok kan niet ontstaan, want posten komen uit blokken. Die twee kanten op controleren is de kern van het klopt of klopt niet.
Voorbeeld. Een stel heeft twee ceremonies gepland, een voor de gemeente en een kerkelijke, en heeft daarvoor zelf een tweede blok toegevoegd naast het standaardblok ceremonie. Wie dan alleen naar het totale budgetbedrag kijkt, ziet een getal en niets vreemds. Wie naar de blokken kijkt, ziet dat er twee ceremonieblokken zijn, en kan dus checken of er ook echt twee ceremonieposten in het budget staan. Is dat niet zo, dan is een van de twee ergens onderweg niet meegenomen, en weet je precies waar je moet zoeken. Niet in het budget als geheel, maar bij dat ene blok.
De tweede laag van controleren gaat niet over of een post bestaat, maar over of hij compleet is. Per post vullen jullie het bedrag in, de datum waarop het betaald moet worden, en apart daarvan de aanbetaling en de restbetaling. Dat zijn vier gegevens die elk hun eigen functie hebben, en die je dus ook apart kunt nalopen. Een post met een bedrag maar zonder betaaldatum vertelt je dat je wel weet wat de fotograaf kost, maar niet wanneer dat betaald moet zijn. Dat is iets anders dan een lege post, en het los je ook anders op: niet door een leverancier te bellen over de prijs, maar over de planning.
Het onderscheid tussen aanbetaling en restbetaling is daarbij niet decoratief. Veel leveranciers, van cateraars tot fotografen, werken met een aanbetaling bij het vastleggen en een restbedrag rond de bruiloft zelf. Als je die twee niet apart bijhoudt, kun je op papier denken dat een post is afgehandeld, terwijl er in werkelijkheid nog een tweede bedrag open staat dat over een paar maanden vervalt. Het systeem rekent uit wat er nog openstaat, maar dat rekenwerk is alleen betrouwbaar als aanbetaling en restbetaling ook echt apart zijn ingevuld, en niet allebei als één bedrag bij de aanbetaling zijn gepropt omdat dat sneller ging.
Een voorbeeld waarin dit misgaat. Een bruidspaar boekt de trouwlocatie en betaalt een aanbetaling van een deel van het totaalbedrag. Ze vullen bij de post alleen dat aanbetaalde bedrag in, omdat dat het bedrag is dat ze nu overmaken, en laten het restbedrag leeg omdat de locatie de einddatum daarvoor pas een half jaar later doorgeeft. Wie nu naar het budget kijkt, ziet een post trouwlocatie die volledig betaald lijkt, met een bedrag dat te laag is voor wat de locatie werkelijk gaat kosten. Dat klopt dus niet, niet omdat het systeem een fout maakt, maar omdat de post niet compleet is ingevuld. Controleren of het budget klopt betekent hier concreet: nagaan of elke post met een aanbetaling ook een verwacht restbedrag heeft staan, al is de precieze datum nog niet bekend. Een geschat bedrag met een voorlopige datum is beter te controleren dan een lege regel, want een lege regel valt niet op als iets dat nog moet gebeuren.
Zonder deze koppeling tussen blok en post zou controleren betekenen dat je twee losse lijsten naast elkaar legt: de lijst van wat jullie besloten hebben, en de lijst van wat er in het budget staat, en die met de hand vergelijkt. Bij een bruiloft met vijftien of twintig blokken, van gemeente tot bruidstaart tot entertainment, is dat een vergelijking die je makkelijk een keer overslaat, zeker naast een baan en met weinig tijd. Omdat de post hier vanzelf uit het blok ontstaat, verdwijnt die vergelijking. Wat overblijft is een kleinere en scherpere vraag: is elke post die er staat ook volledig ingevuld, met bedrag, datum, aanbetaling en restbetaling.
Dat is ook waarom je dit niet bij elk blok in dezelfde mate hoeft te doen. Een post waarvan de leverancier je een offerte heeft gestuurd met een vast bedrag en een vaste betaaldatum, hoef je niet opnieuw te controleren zodra je hem hebt ingevoerd. Het risico zit bij de posten waar nog onzekerheid in zit: een leverancier die pas laat een einddatum doorgeeft, een blok dat jullie zelf hebben toegevoegd via anders en waarvoor geen vaste afspraken bestaan, of een post waarbij alleen de aanbetaling bekend is. Daar loont het om terug te gaan en te kijken of het restbedrag inmiddels bekend is en is bijgewerkt. Bij een post die al maanden compleet en betaald in het budget staat, voegt herhaald controleren niets toe.
Het moment waarop dit controleren het meest oplevert, is niet vlak voor de bruiloft, maar rond de momenten waarop leveranciers vastgelegd worden. Direct na het boeken van een locatie of het tekenen van een contract met een cateraar is het bedrag en de betaaldatum vaak wel bekend, maar de exacte verdeling tussen aanbetaling en restbetaling soms nog niet scherp. Dat is het moment om de post te openen en te checken of alle vier de velden kloppen met wat er in het contract staat, in plaats van te wachten tot de rekening van het restbedrag in de bus valt en je er dan pas achter komt dat het bedrag in het budget nooit is bijgewerkt.