Facturatiescenario's uit de praktijk

Het factureringsleven van elke freelancer is rommeliger dan een schoon configuratiebestand suggereert. Klanten veranderen, contracten worden verlengd, fouten gebeuren, en soms doe je werk waarvoor je niet wilt factureren. Deze scenario’s beschrijven echte situaties en hoe Vibes to Bucks elk ervan afhandelt.

Scenario 1 — Contractverlenging: dezelfde klant, nieuw project

Wie: Anna, een freelance ontwikkelaar die werkt aan github.com/acme/website voor Klant Acme.

Wat gebeurde er: Anna factureert AI-kosten aan het Moneybird-project “Acme Website Q1–Q2” sinds januari. Op 1 juli begint een nieuw 6-maanden contract. Het Moneybird-project van de klant verandert naar “Acme Website Q3–Q4” — mogelijk met een ander uurtarief. De repository en branch blijven hetzelfde.

Wat Anna wil:

• Vanaf 1 juli moeten alle nieuwe AI-kosten synchroniseren met het nieuwe project.
• De zes maanden aan tijdregistraties die al in Moneybird onder het oude project staan, blijven precies waar ze zijn.
• De kosten van vandaag gaan naar het nieuwe project.

Het risico zonder begeleiding: Anna verandert haar factureringsregel en voert Sync Now uit. De extensie hergroepeert januari tot juni, ziet geen tijdregistraties voor die dagen onder het nieuwe project, en creëert 180 dubbele registraties in Moneybird — naast de registraties die al onder het oude project bestaan.

Hoe Vibes to Bucks het afhandelt: Wanneer Anna haar factureringsregel wijzigt naar het nieuwe project, vraagt de extensie wat er moet gebeuren met historische kosten. Ze kiest “Toepassen vanaf vandaag”. Verleden dagen behouden hun associatie met het oude project. Alleen vandaag en toekomstige dagen synchroniseren onder het nieuwe project. Geen duplicaten, geen opruiming nodig.

Scenario 2 — Klantwissel: verplaats een repo naar een andere klant

Wie: Ben, een ontwikkelaar die werkt aan github.com/org/platform.

Wat gebeurde er: Ben factureerde deze repo aanvankelijk aan Klant Alpha, die de R&D-fase financierde. Het platform is nu in productie en Klant Beta is de lopende klant. Ben moet de repository opnieuw toewijzen.

2a — Schone breuk

Wat Ben wil: Toekomstige kosten gaan naar Klant Beta. Verleden registraties gesynchroniseerd naar Klant Alpha blijven onaangeroerd. Niets retroactief.

Hoe Vibes to Bucks het afhandelt: Ben verandert de contactpersoon van de factureringsregel van Alpha naar Beta. De extensie vraagt wat er met de geschiedenis moet gebeuren. Hij kiest “Toepassen vanaf vandaag”. Alpha’s historische registraties blijven in Moneybird. Beta begint vanaf vandaag registraties te ontvangen.

2b — Volledige retroactieve correctie

Wat Ben wil: De Alpha-facturering was een fout — het had allemaal Beta moeten zijn vanaf het begin. Ben wil alles opnieuw synchroniseren onder Beta. Hij accepteert dat hij Alpha’s registraties handmatig in Moneybird moet opruimen.

Hoe Vibes to Bucks het afhandelt: Ben kiest “Toepassen op alle tijd”. De extensie waarschuwt hem dat bestaande registraties onder Alpha niet automatisch worden verwijderd — hij moet die in Moneybird verwijderen. Vervolgens worden er nieuwe registraties voor elke historische dag onder Beta aangemaakt.

2c — Synchroniseer alleen de kloof

Wat Ben wil: Ben stopte twee weken geleden met synchroniseren toen hij besefte dat de mapping verkeerd was. Hij heeft 14 dagen aan niet-gesynchroniseerde kosten in het grootboek. Hij wil dat die 14 dagen naar Beta gaan, maar de maanden die al naar Alpha zijn gesynchroniseerd moeten blijven.

Hoe Vibes to Bucks het afhandelt: Ben kiest “Toepassen alleen op niet-gesynchroniseerde dagen”. De extensie weet welke dagen al een tijdregistratie in provider_posts hebben en slaat ze over. Alleen de 14 niet-gesynchroniseerde dagen worden onder Beta aangemaakt.

Scenario 3 — Projectopsplitsing: werk herverdelen over subprojecten

Wie: Clara, een ontwikkelaar die werkt aan een monorepo voor Klant Gamma.

Wat gebeurde er: Clara factureerde al het AI-werk aan één overkoepelend project “Algemene Ontwikkeling”. Gamma wil nu dat de kosten worden opgesplitst per functiegroep. Clara maakt branch-gebaseerde factureringsregels: feature/auth/* → “Auth Module” en feature/billing/* → “Billing Module”.

3a — Alleen vooruit opsplitsen

Wat Clara wil: Voortaan moeten de kosten naar het juiste subproject worden gerouteerd. Verleden kosten die al onder “Algemene Ontwikkeling” zijn gesynchroniseerd blijven daar.

Hoe Vibes to Bucks het afhandelt: Wanneer Clara de nieuwe branch-regels toevoegt, vraagt de extensie naar de geschiedenis voor elk. Ze kiest “Toepassen vanaf vandaag” voor beide. Historische registraties onder “Algemene Ontwikkeling” blijven onaangeroerd.

3b — Historische nauwkeurigheid

Wat Clara wil: Ze wil eigenlijk dat de verleden kosten retroactief naar de juiste subprojecten worden verplaatst. Ze accepteert dat ze de oude “Algemene Ontwikkeling” registraties handmatig in Moneybird moet verwijderen.

Hoe Vibes to Bucks het afhandelt: Clara kiest “Toepassen op alle tijd” voor de nieuwe regels. De extensie waarschuwt voor bestaande registraties onder het oude project en creëert correcte registraties per subproject per dag. Clara ruimt de oude registraties in Moneybird op.

Scenario 4 — Niet-factureerbaar hoffelijkheidswerk

Wie: David, een freelancer die werkt aan de repo van Klant Delta.

Wat gebeurde er: David wordt betrokken bij een interne code review en wat experimenten die niet binnen Delta’s scope vallen — maar hij houdt Cursor open op hun repo. Hij wil niet dat de volgende 2 uur aan AI-kosten aan Delta worden gefactureerd.

Wat David wil:

• De Delta-factureringsregel naar “niet-factureerbaar” modus schakelen. Een zichtbare indicator in de statusbalk bevestigt dat de regel niet-factureerbaar is.
• AI-kosten worden nog steeds bijgehouden en zichtbaar op het dashboard — hij wil zien wat dit hoffelijkheidswerk hem kost — maar worden gemarkeerd als niet voor facturering.
• Elk uur een herinneringsmelding: “Delta factureringsregel is al 2 uur niet-factureerbaar. Nog steeds niet-factureerbaar aan het werk?”
• Wanneer hij terugschakelt naar factureerbaar, wordt de normale synchronisatie hervat.
• De niet-factureerbare kosten worden op het dashboard onder Delta getoond, maar duidelijk onderscheiden van factureerbare kosten.

Waarom per-mapping, niet globaal: David kan multitasken. Als hij overschakelt naar de repo van Klant Beta terwijl Delta niet-factureerbaar is, moet Beta nog steeds normaal worden gefactureerd. Niet-factureerbaar is een hoffelijkheidsbeslissing per klant: “deze kosten maak ik niet op verzoek van de klant — ik doe dit als een gunst voor hen.”

Hoe Vibes to Bucks het afhandelt: David opent het Instellingen-paneel en schakelt Delta’s factureringsregel naar niet-factureerbaar. Een dialoog vraagt twee dingen: wanneer moet niet-factureerbaar beginnen (nu, of met terugwerkende kracht), en wanneer moet het eindigen. David kiest “Vanaf nu” en “Einde van vandaag” — facturering wordt morgen automatisch hervat. De statusbalk toont $4,23 vandaag · Delta [niet-factureerbaar tot einde van de dag] terwijl hij in Delta’s repo werkt. Niet-factureerbare kosten synchroniseren nog steeds naar Moneybird als niet-factureerbare tijdregistraties (zichtbaar in records maar uitgesloten van klantfacturering). Het dashboard toont zowel factureerbare als niet-factureerbare kosten voor Delta, duidelijk gescheiden.

Als David verwacht dat het hoffelijkheidswerk langer duurt, kan hij “Specifieke datum” kiezen (bijv. niet-factureerbaar tot vrijdag) of “Tot ik handmatig hervat” met een herinneringsinterval (elke 30 minuten, 1 uur, 2 uur, enz.) zodat hij niet vergeet de facturering weer aan te zetten.

Variatie — retroactief niet-factureerbaar

Wat David wil: Hij vergat om te schakelen voordat hij begon. Hij wil de laatste 90 minuten achteraf als niet-factureerbaar markeren.

Hoe Vibes to Bucks het afhandelt: David opent het Instellingen-paneel, schakelt Delta naar niet-factureerbaar, en kiest onder het Start-gedeelte “Terugdateren” met een tijd van 90 minuten geleden. Kosten vanaf dat moment worden gemarkeerd als niet-factureerbaar. Als de tijdregistratie van vandaag al naar Moneybird was gesynchroniseerd, herberekent en actualiseert de extensie deze om het verminderde factureerbare bedrag weer te geven. Terugdatering is beperkt tot vandaag — voor correcties over meerdere dagen biedt het Sync Ledger ongedaan maken en opnieuw synchroniseren.

Scenario 5 — Een onjuiste synchronisatie ongedaan maken

Wie: Eve, een freelancer die een mapping heeft gewijzigd en onmiddellijk Sync Now heeft uitgevoerd.

Wat gebeurde er: Eve heeft een factureringsregel bewerkt (het project gewijzigd) en Sync Now uitgevoerd zonder na te denken over de gevolgen. De extensie creëerde 3 maanden aan nieuwe tijdregistraties onder het verkeerde project in Moneybird, naast de bestaande correcte registraties onder het oude project.

Wat Eve wil:

• Zien wat er zojuist is gesynchroniseerd — een samenvatting die laat zien hoeveel registraties zijn aangemaakt of bijgewerkt, voor welke dagen, onder welk project.
• Terugdraaien: ofwel verwijdert de extensie de onjuist aangemaakte registraties, of het vertelt haar duidelijk welke registratie-ID’s ze handmatig moet opruimen.

Hoe Vibes to Bucks het afhandelt: Na elke synchronisatie toont de extensie een melding: “Gesynchroniseerd naar Moneybird — Aangemaakt 87, bijgewerkt 2, overgeslagen 14.” Door op “Details weergeven” te klikken, opent het Sync Ledger — een speciale weergave die elke gesynchroniseerde en in behandeling zijnde registratie toont, filterbaar op klant, project en datum. Eve kan precies zien welke registraties zojuist zijn aangemaakt, de onjuiste selecteren en op “Synchronisatie ongedaan maken” klikken. De extensie verwijdert die registraties uit Moneybird en markeert ze opnieuw als in behandeling zodat ze correct kunnen worden gesynchroniseerd nadat ze de regel heeft aangepast.

Scenario 6 — Tijdelijke projectfacturering

Wie: Frank, een ontwikkelaar die werkt aan github.com/acme/api.

Wat gebeurde er: Frank factureert normaal gesproken aan het project “API Onderhoud”. Voor twee weken in maart werkt hij aan een speciale sprint die wordt gefactureerd aan “API v2 Migratie”. Na de sprint schakelt hij terug.

Wat Frank wil:

• De factureringsregel wijzigen naar “API v2 Migratie” op 10 maart.
• Terugschakelen naar “API Onderhoud” op 24 maart.
• Alleen het venster van 10–23 maart synchroniseert naar “API v2 Migratie”.
• Alles voor 10 maart en na 23 maart synchroniseert naar “API Onderhoud”.
• Geen retroactieve rommel in beide richtingen.

Hoe Vibes to Bucks het afhandelt: Beide keren dat Frank de factureringsregel wijzigt, kiest hij “Toepassen vanaf vandaag”. Op 10 maart begint de regel met factureren aan “API v2 Migratie”. Op 24 maart schakelt het terug naar “API Onderhoud”. Elke periode’s registraties blijven bij het project dat op dat moment actief was.

Scenario 7 — Stoppen met factureren, blijven volgen

Wie: Gina, een freelancer die afrondt met Klant Eta.

Wat gebeurde er: Het contract is afgelopen, maar Gina doet nog steeds klein onderhoud aan Eta’s repo. Ze wil de AI-kosten op haar dashboard zien — om te beoordelen of een nieuw contract de moeite waard zou zijn — maar ze wil geen tijdregistraties synchroniseren.

Wat Gina wil:

• De factureringsregel permanent als niet-factureerbaar markeren (geen tijdelijke schakelaar — een blijvende instelling).
• Het dashboard toont nog steeds kosten toegeschreven aan Klant Eta.
• Synchronisatie slaat deze factureringsregel volledig over.
• Als Eta terugkomt met een nieuw contract, schakelt ze het terug naar factureerbaar en synchroniseert alleen vanaf dat moment — niet de tussenliggende periode.

Hoe Vibes to Bucks het afhandelt: Gina vinkt “Factureerbaar” uit op Eta’s factureringsregel. Kosten worden nog steeds bijgehouden en verschijnen op het dashboard onder Eta, maar er worden geen tijdregistraties aangemaakt. Wanneer er een nieuw contract komt, schakelt ze facturering weer in en kiest “Toepassen vanaf vandaag”. De niet-factureerbare kloof blijft onbetaald.

Scenario 8 — Provider migratie

Wie: Hugo, een freelancer die al 6 maanden naar Moneybird synchroniseert.

Wat gebeurde er: Hugo’s accountantskantoor schakelt hem over naar Harvest. Hij verandert destination: harvest in zijn configuratie en stelt nieuwe Harvest-factureringsregels in.

Wat Hugo wil:

• Voortaan gaat de synchronisatie naar Harvest.
• De 6 maanden aan Moneybird-registraties blijven onaangeroerd.
• Geen retroactieve registraties aangemaakt in Harvest voor de historische periode.

Hoe Vibes to Bucks het afhandelt: Wanneer Hugo de factureringsprovider wijzigt, detecteert de extensie dat Harvest geen synchronisatiegeschiedenis heeft. Zonder begeleiding zou het proberen registraties aan te maken voor elke historische dag. In plaats daarvan verschijnt dezelfde dialoog met drie opties: “Start vers vanaf vandaag”, “Synchroniseer alle geschiedenis”, of “Synchroniseer alleen niet-gesynchroniseerde dagen.” Hugo kiest “Start vers.” De extensie stelt een migratie-afsnijdatum in zodat de synchronisatie-engine alle dagen voor vandaag overslaat. Alleen vandaag en toekomstige dagen creëren Harvest-registraties. Zijn Moneybird-registraties blijven onaangeroerd.

Scenario 9 — Per ongeluk regel verwijderen

Wie: Ivan, een freelancer die de repo van Klant Kappa factureert.

Wat gebeurde er: Ivan wilde zijn factureringsregel bewerken om het uurtarief te wijzigen, maar verwijderde deze per ongeluk. Hij merkt het meteen op en maakt de regel opnieuw aan met de juiste instellingen.

Wat Ivan wil:

• De regel opnieuw aanmaken zonder maanden aan dubbele tijdregistraties in Moneybird te veroorzaken.
• Verleden registraties die al gesynchroniseerd waren, moeten onaangeroerd blijven.
• Facturering moet naadloos doorgaan alsof er niets is gebeurd.

Het risico zonder begeleiding: Ivan maakt de nieuwe regel aan. De extensie ziet een repo met historische kostengegevens en geen bijpassende factureringsregelgeschiedenis. Een naïeve synchronisatie zou elke vorige dag behandelen als “nooit gesynchroniseerd onder deze regel” en registraties voor de hele geschiedenis aanmaken.

Hoe Vibes to Bucks het afhandelt: Wanneer Ivan een factureringsregel aanmaakt voor een repo die al historische kostengegevens in het grootboek heeft, herkent de extensie dit en presenteert dezelfde dialoog met drie opties. Ivan kiest “Toepassen vanaf vandaag” — verleden registraties blijven zoals ze waren, en de facturering wordt vanaf vandaag hervat. Geen duplicaten, geen kloof, geen paniek.

De gemeenschappelijke draad

Elk scenario hierboven komt neer op één vraag: wat moet er gebeuren met het verleden als je een factureringsregel wijzigt?

Vibes to Bucks neemt die beslissing nooit voor je. Elke keer dat je een factureringsregel wijzigt — de klant, het project, het tarief of de factureerbare status verandert — vraagt de extensie je om te kiezen:

Deze begeleide keuze verschijnt in een duidelijke dialoog telkens wanneer een wijziging in de factureringsregel invloed zou hebben op hoe historische kosten worden behandeld. Geen verrassingen, geen stille retroactieve herfacturering, geen verweesde duplicaten.