Real-World Billing Scenarios

Every freelancer’s billing life is messier than a clean config file suggests. Clients change, contracts renew, mistakes happen, and sometimes you do work you don’t want to charge for. These scenarios describe real situations and how Vibes to Bucks handles each one.

Scenario 1 — Contract renewal: same client, new project

Who: Anna, a freelance developer working on github.com/acme/website for Client Acme.

What happened: Anna has been billing AI costs to Moneybird project “Acme Website Q1–Q2” since January. On July 1st, a new 6-month contract kicks in. The client’s Moneybird project changes to “Acme Website Q3–Q4” — possibly with a different hourly rate. The repository and branch are the same.

What Anna wants:

• From July 1st onward, all new AI costs sync to the new project.
• The six months of time entries already in Moneybird under the old project stay exactly where they are.
• Today’s cost goes to the new project.

The risk without guidance: Anna changes her billing rule and runs Sync Now. The extension re-aggregates January through June, sees no time entries for those days under the new project, and creates 180 duplicate entries in Moneybird — alongside the ones that already exist under the old project.

How Vibes to Bucks handles it: When Anna edits her billing rule to point to the new project, the extension asks her what should happen to historical costs. She picks “Apply from today onward”. Past days retain their association with the old project. Only today and future days sync under the new project. No duplicates, no cleanup needed.

Scenario 2 — Client switch: move a repo to a different client

Who: Ben, a developer working on github.com/org/platform.

What happened: Ben initially billed this repo to Client Alpha, who funded the R&D phase. The platform is now in production and Client Beta is the ongoing customer. Ben needs to remap the repository.

2a — Clean break

What Ben wants: Future costs go to Client Beta. Past entries synced to Client Alpha stay untouched. Nothing retroactive.

How Vibes to Bucks handles it: Ben changes the billing rule’s contact from Alpha to Beta. The extension asks what should happen to history. He picks “Apply from today onward”. Alpha’s historical entries remain in Moneybird. Beta starts receiving entries from today.

2b — Full retroactive correction

What Ben wants: The Alpha billing was a mistake — it should all have been Beta from the start. Ben wants to re-sync everything under Beta. He accepts that he’ll need to clean up Alpha’s entries manually in Moneybird.

How Vibes to Bucks handles it: Ben picks “Apply to all time”. The extension warns him that existing entries under Alpha won’t be automatically deleted — he’ll need to remove those in Moneybird. It then creates new entries for every historical day under Beta.

2c — Sync only the gap

What Ben wants: Ben stopped syncing two weeks ago when he realized the mapping was wrong. He has 14 days of unsynced cost sitting in the ledger. He wants those 14 days to go to Beta, but the months already synced to Alpha should stay.

How Vibes to Bucks handles it: Ben picks “Apply only to unsynced days”. The extension knows which days already have a time entry in provider_posts and skips them. Only the 14 unsynced days are created under Beta.

Scenario 3 — Project split: redistribute work across sub-projects

Who: Clara, a developer working on a monorepo for Client Gamma.

What happened: Clara has been billing all AI work to one catch-all project “General Development”. Gamma now wants costs broken down by feature area. Clara creates branch-based billing rules: feature/auth/* → “Auth Module” and feature/billing/* → “Billing Module”.

3a — Forward-only split

What Clara wants: Going forward, costs route to the correct sub-project. Past costs already synced under “General Development” stay there.

How Vibes to Bucks handles it: When Clara adds the new branch rules, the extension asks about history for each. She picks “Apply from today onward” for both. Historical entries under “General Development” are untouched.

3b — Historical accuracy

What Clara wants: She actually wants to retroactively move past costs to the correct sub-projects. She accepts that she’ll manually delete the old “General Development” entries in Moneybird.

How Vibes to Bucks handles it: Clara picks “Apply to all time” for the new rules. The extension warns about existing entries under the old project and creates correct entries per sub-project per day. Clara cleans up the old entries in Moneybird.

Scenario 4 — Unbillable courtesy work

Who: David, a freelancer working on Client Delta’s repo.

What happened: David gets pulled into an internal code review and some experimentation that isn’t part of Delta’s scope — but he keeps Cursor open on their repo. He doesn’t want the next 2 hours of AI cost charged to Delta.

What David wants:

• Toggle the Delta billing rule to “unbillable” mode. A visible indicator in the status bar confirms the rule is unbillable.
• AI costs are still tracked and visible on the dashboard — he wants to see what this courtesy work costs him — but flagged as not for billing.
• Every hour, a reminder notification: “Delta billing rule has been unbillable for 2 hours. Still working unbillable?”
• When he toggles back to billable, normal syncing resumes.
• The unbillable costs show on the dashboard under Delta but are clearly distinguished from billable costs.

Why per-mapping, not global: David might be multitasking. If he switches to Client Beta’s repo while Delta is unbillable, Beta should still bill normally. Unbillable is a per-client courtesy decision: “this cost I’m making is not the client’s ask — I’m doing this for them as a courtesy.”

How Vibes to Bucks handles it: David opens the Settings panel and toggles Delta’s billing rule to unbillable. A dialog asks two things: when should unbillable start (now, or backdated), and when should it end. David picks “From now” and “End of today” — billing resumes automatically tomorrow. The status bar shows $4.23 today · Delta [unbillable till end of day] while he works in Delta’s repo. Unbillable costs still sync to Moneybird as non-billable time entries (visible in records but excluded from client invoicing). The dashboard shows both billable and unbillable costs for Delta, clearly separated.

If David expects the courtesy work to last longer, he can pick “Specific date” (e.g. unbillable until Friday) or “Until I resume manually” with a reminder interval (every 30 minutes, 1 hour, 2 hours, etc.) so he doesn’t forget to turn billing back on.

Variation — retroactive unbillable

What David wants: He forgot to toggle before starting. He wants to mark the last 90 minutes as unbillable after the fact.

How Vibes to Bucks handles it: David opens the Settings panel, toggles Delta to unbillable, and under the Start section picks “Backdate” with a time of 90 minutes ago. Costs from that point forward are flagged as unbillable. If today’s time entry was already synced to Moneybird, the extension recalculates and updates it to reflect the reduced billable amount. Backdating is capped to today — for multi-day corrections, the Sync Ledger provides undo-and-resync controls.

Scenario 5 — Undo an incorrect sync

Who: Eve, a freelancer who changed a mapping and immediately ran Sync Now.

What happened: Eve edited a billing rule (changed the project) and ran Sync Now without thinking about the consequences. The extension created 3 months of new time entries under the wrong project in Moneybird, alongside the existing correct entries under the old project.

What Eve wants:

• See what was just synced — a summary showing how many entries were created or updated, for which days, under which project.
• Roll back: either the extension deletes the incorrectly created entries, or it clearly tells her which entry IDs to clean up manually.

How Vibes to Bucks handles it: After every sync, the extension shows a notification: “Synced to Moneybird — Created 87, updated 2, skipped 14.” Clicking “Show details” opens the Sync Ledger — a dedicated view showing every synced and pending entry, filterable by client, project, and date. Eve can see exactly which entries were just created, select the incorrect ones, and click “Undo sync.” The extension deletes those entries from Moneybird and marks them as pending again so they can be re-synced correctly after she fixes the rule.

Scenario 6 — Temporary project billing

Who: Frank, a developer working on github.com/acme/api.

What happened: Frank normally bills to project “API Maintenance”. For two weeks in March, he’s on a special sprint billed to “API v2 Migration”. After the sprint, he switches back.

What Frank wants:

• Change the billing rule to “API v2 Migration” on March 10.
• Change it back to “API Maintenance” on March 24.
• Only the March 10–23 window syncs to “API v2 Migration”.
• Everything before March 10 and after March 23 syncs to “API Maintenance”.
• No retroactive mess in either direction.

How Vibes to Bucks handles it: Both times Frank changes the billing rule, he picks “Apply from today onward”. On March 10, the rule starts billing to “API v2 Migration”. On March 24, it switches back to “API Maintenance”. Each period’s entries stay with the project that was active at the time.

Scenario 7 — Stop billing, keep tracking

Who: Gina, a freelancer wrapping up with Client Eta.

What happened: The contract is over, but Gina still does minor maintenance on Eta’s repo. She wants to see the AI costs in her dashboard — to gauge whether a new contract would be worthwhile — but she doesn’t want to sync any time entries.

What Gina wants:

• Mark the billing rule as permanently unbillable (not a temporary toggle — a lasting setting).
• The dashboard still shows costs attributed to Client Eta.
• Sync skips this billing rule entirely.
• If Eta comes back with a new contract, she switches it back to billable and only syncs from that point forward — not the gap period.

How Vibes to Bucks handles it: Gina unchecks “Billable” on Eta’s billing rule. Costs continue to be tracked and appear on the dashboard under Eta, but no time entries are created. When a new contract arrives, she re-enables billing and picks “Apply from today onward”. The unbillable gap stays unbilled.

Scenario 8 — Provider migration

Who: Hugo, a freelancer who has been syncing to Moneybird for 6 months.

What happened: Hugo’s accounting firm switches him to Harvest. He changes destination: harvest in his config and sets up new Harvest billing rules.

What Hugo wants:

• Going forward, sync goes to Harvest.
• The 6 months of Moneybird entries stay untouched.
• No retroactive entries created in Harvest for the historical period.

How Vibes to Bucks handles it: When Hugo switches the billing provider, the extension detects that Harvest has no sync history. Without guidance it would try to create entries for every historical day. Instead, the same three-option dialog appears: “Start fresh from today”, “Sync all history”, or “Sync only unsynced days.” Hugo picks “Start fresh.” The extension sets a migration cutoff date so the sync engine skips all days before today. Only today and future days create Harvest entries. His Moneybird entries are untouched.

Scenario 9 — Accidental rule deletion

Who: Ivan, a freelancer billing Client Kappa’s repo.

What happened: Ivan meant to edit his billing rule to change the hourly rate, but accidentally deleted it instead. He notices immediately and recreates the rule with the correct settings.

What Ivan wants:

• Recreate the rule without causing months of duplicate time entries in Moneybird.
• Past entries that were already synced should remain untouched.
• Billing should continue seamlessly as if nothing happened.

The risk without guidance: Ivan creates the new rule. The extension sees a repo with historical cost data and no matching billing rule history. A naive sync would treat every past day as “never synced under this rule” and create entries for the entire history.

How Vibes to Bucks handles it: When Ivan creates a billing rule for a repo that already has historical cost data in the ledger, the extension recognizes this and presents the same three-option dialog. Ivan picks “Apply from today onward” — past entries stay as they were, and billing resumes from today. No duplicates, no gap, no panic.

The common thread

Every scenario above comes down to one question: when you change a billing rule, what should happen to the past?

Vibes to Bucks never makes that decision for you. Each time you edit a billing rule — change the client, project, rate, or billable status — the extension asks you to choose:

This guided choice appears in a clear dialog whenever a billing rule change would affect how historical costs are handled. No surprises, no silent retroactive re-billing, no orphaned duplicates.