Bruidswarenhuis
Een bruiloft van één dag heeft één budget met posten die allemaal naar dezelfde datum toe lopen. Zodra jullie bruiloft over meerdere dagen loopt, verandert dat. Niet omdat het systeem dan anders werkt, maar omdat er ineens meer momenten zijn waarop iets betaald moet worden, geleverd moet worden, of gebeurt. Een welkomstborrel op donderdag, de ceremonie op vrijdag en een afsluitende brunch op zaterdag zijn geen drie momenten in dezelfde bruiloft, maar drie momenten met elk hun eigen leveranciers, hun eigen bedragen en hun eigen betaaldata. Dat is de kern van wat er verandert.
In het dossier zet je op de startpagina een blok neer voor elke keuze die je maakt. Bij een bruiloft van meer dagen betekent dat vaak dat je bepaalde blokken dubbel of driedubbel neerzet. Niet omdat het systeem dat oplegt, maar omdat de praktijk dat vraagt. Een cateraar voor de vrijdagavond is een andere post dan een cateraar voor de brunch op zaterdag, ook al is het misschien dezelfde leverancier. Jullie zetten er dan zelf een tweede blok bij, met een eigen naam zodat je ze uit elkaar houdt. Op dezelfde manier geldt dat voor een locatie: de zaal waar de ceremonie is, is niet automatisch de zaal waar het diner de avond ervoor plaatsvindt. Twee blokken, twee data, twee bedragen.
Waarom dit voor het budget belangrijk is, zit in wat er met elke keuze gebeurt. Elk blok dat je aanmaakt wordt vanzelf een post in het budget, met de naam van de leverancier, waarvoor de post is en in welke categorie hij valt. Bij een bruiloft van meer dagen loop je zonder die koppeling het risico dat je het overzicht per dag verliest, en dus ook het overzicht over het geheel. Stel dat de welkomstborrel op donderdag wordt geleverd door een cateringbedrijf dat drie weken vooraf een aanbetaling wil, terwijl de brunch op zaterdag door een ander bedrijf pas een week vooraf gefactureerd wordt. Dat zijn twee verschillende ritmes, die in een bruiloft van één dag niet zouden bestaan, maar die hier naast elkaar lopen. Omdat elke post zijn eigen bedrag, zijn eigen betaaldatum, en apart de aanbetaling en de restbetaling heeft, zie je die twee ritmes gewoon naast elkaar staan zonder dat je ze zelf in een schema hoeft te zetten.
Een voorbeeld maakt dit concreet. Jullie plannen een bruiloft over drie dagen: vrijdag een diner voor de naaste familie, zaterdag de ceremonie met feest, zondag een afsluitende lunch. Voor vrijdag boeken jullie een restaurant, met een aanbetaling van een derde die twee maanden vooraf moet, en de rest op de avond zelf. Voor zaterdag komt er een cateraar bij de trouwlocatie, met een aanbetaling die zes weken vooraf moet en een restbedrag dat een week na de bruiloft gefactureerd wordt. Voor zondag huren jullie een aparte ruimte met lunch, waarbij het hele bedrag in één keer vooraf betaald moet worden. Drie posten, drie bedragen, drie betaalmomenten, drie categorieën die er hetzelfde uitzien in het overzicht maar in de praktijk niets met elkaar te maken hebben. Zonder die opsplitsing per post zou je zelf moeten onthouden welk bedrag bij welke dag hoort, en welke aanbetaling al gedaan is en welke nog moet. Met de opsplitsing rekent het systeem uit wat er nog openstaat, per post en dus ook per dag.
Dat is meteen ook waar de besparing zit. Niet in tijd die het systeem voor je wegneemt door dingen te doen, maar in het feit dat je niet zelf een schaduwboekhouding hoeft te maken om te weten wat er die week, die maand, of die dag van de bruiloft nog betaald moet worden. Bij een bruiloft van meer dagen is dat verschil groter dan bij een bruiloft van één dag, omdat de betaalmomenten zich nu over een langere periode uitspreiden en soms zelfs na de bruiloft zelf doorlopen, zoals bij het restbedrag van de cateraar die pas een week later factureert. Wie dat niet per post bijhoudt, ontdekt soms pas na de bruiloft dat er nog een rekening open staat waarvan niemand meer wist hoe hoog die precies was.
Het is ook nodig om te weten wanneer dit uitsplitsen juist niet nodig is. Niet elke bruiloft van meer dagen heeft evenveel losse posten nodig. Als de cateraar voor het diner op vrijdag en het feest op zaterdag hetzelfde bedrijf is, met één offerte en één betaalafspraak voor het hele weekend, dan is één blok en één post voldoende. Je maakt het jezelf dan alleen maar onnodig ingewikkeld door dat kunstmatig op te splitsen in twee posten die toch dezelfde datum en dezelfde aanbetaling hebben. Het uitsplitsen heeft alleen zin zodra er verschillende leveranciers, verschillende bedragen of verschillende betaaldata in het spel zijn. Is dat niet het geval, dan blijft één post het overzicht juist duidelijker dan meerdere posten die elkaar overlappen.
Dit sluit aan bij hoe de blokken op de startpagina werken: elke keuze die je maakt is een blok, en elk blok wordt een post. Bij een bruiloft van meer dagen is de vraag dus niet of het systeem daar apart rekening mee houdt, maar hoeveel blokken jullie zelf neerzetten. Dat is een keuze die bij het plannen van de dagen zelf hoort, niet bij het budget. Zodra de blokken er staan, doet het budget de rest: het verzamelt de bedragen, de betaaldata, de aanbetalingen en de restbetalingen, en laat zien wat er per post nog openstaat.
Wie dit combineert met sparen, waarbij elke maand wordt nagevraagd of het opzij gezette bedrag ook echt gelukt is, merkt bij een bruiloft van meer dagen dat de spreiding van betaalmomenten net iets minder grillig aanvoelt dan bij een bruiloft van één dag met alles rond dezelfde datum. Een gemiste maand wordt over de resterende maanden verdeeld, en omdat de betaaldata bij een bruiklooft van meer dagen vaak al wat verder uit elkaar liggen, valt zo'n herverdeling soms makkelijker te dragen. Dat is geen garantie, alleen een gevolg van hoe de posten dan al gespreid stonden.
De kern blijft dat het budget zelf niet verandert van vorm zodra de bruiloft meer dagen duurt. Het blijft posten verzamelen op basis van de blokken die jullie aanmaken. Wat verandert, is hoeveel blokken en dus hoeveel posten er nodig zijn, en hoe verspreid de betaaldata in het overzicht komen te staan. Wie dat vooraf beseft, zet de blokken bewust per dag neer in plaats van achteraf te ontdekken dat één post drie verschillende betaalmomenten moest dragen die niet samen te vatten waren in één bedrag en één datum.