Abrechnungsszenarien aus der Praxis

Das Abrechnungsleben eines jeden Freelancers ist chaotischer, als es eine saubere Konfigurationsdatei vermuten lässt. Kunden wechseln, Verträge werden erneuert, Fehler passieren, und manchmal erledigst du Arbeiten, die du nicht berechnen möchtest. Diese Szenarien beschreiben reale Situationen und wie Vibes to Bucks jede davon handhabt.

Szenario 1 — Vertragsverlängerung: gleicher Kunde, neues Projekt

Wer: Anna, eine freiberufliche Entwicklerin, arbeitet an github.com/acme/website für den Kunden Acme.

Was passiert ist: Seit Januar rechnet Anna AI-Kosten über das Moneybird-Projekt “Acme Website Q1–Q2” ab. Am 1. Juli beginnt ein neuer 6-Monats-Vertrag. Das Moneybird-Projekt des Kunden wechselt zu “Acme Website Q3–Q4” — möglicherweise mit einem anderen Stundensatz. Das Repository und der Branch bleiben gleich.

Was Anna möchte:

• Ab dem 1. Juli sollen alle neuen AI-Kosten mit dem neuen Projekt synchronisiert werden.
• Die sechs Monate an Zeiteinträgen, die bereits unter dem alten Projekt in Moneybird sind, sollen unverändert bleiben.
• Die heutigen Kosten sollen dem neuen Projekt zugeordnet werden.

Das Risiko ohne Anleitung: Anna ändert ihre Abrechnungsregel und führt “Jetzt synchronisieren” aus. Die Erweiterung aggregiert die Zeit von Januar bis Juni neu, sieht keine Zeiteinträge für diese Tage unter dem neuen Projekt und erstellt 180 doppelte Einträge in Moneybird — neben den bereits vorhandenen unter dem alten Projekt.

Wie Vibes to Bucks es handhabt: Wenn Anna ihre Abrechnungsregel bearbeitet, um auf das neue Projekt zu verweisen, fragt die Erweiterung, was mit den historischen Kosten geschehen soll. Sie wählt “Ab heute anwenden”. Vergangene Tage behalten ihre Zuordnung zum alten Projekt. Nur heute und zukünftige Tage werden unter dem neuen Projekt synchronisiert. Keine Duplikate, kein Aufräumen nötig.

Szenario 2 — Kundenwechsel: Ein Repo zu einem anderen Kunden verschieben

Wer: Ben, ein Entwickler, arbeitet an github.com/org/platform.

Was passiert ist: Ben hat dieses Repo ursprünglich an Kunde Alpha abgerechnet, der die F&E-Phase finanziert hat. Die Plattform ist jetzt in Produktion und Kunde Beta ist der laufende Kunde. Ben muss das Repository neu zuordnen.

2a — Sauberer Schnitt

Was Ben möchte: Zukünftige Kosten sollen an Kunde Beta gehen. Vergangene Einträge, die an Kunde Alpha synchronisiert wurden, bleiben unberührt. Nichts rückwirkend.

Wie Vibes to Bucks es handhabt: Ben ändert den Kontakt der Abrechnungsregel von Alpha zu Beta. Die Erweiterung fragt, was mit der Historie geschehen soll. Er wählt “Ab heute anwenden”. Alphas historische Einträge bleiben in Moneybird. Beta beginnt ab heute Einträge zu erhalten.

2b — Vollständige rückwirkende Korrektur

Was Ben möchte: Die Abrechnung an Alpha war ein Fehler — alles hätte von Anfang an Beta sein sollen. Ben möchte alles unter Beta neu synchronisieren. Er akzeptiert, dass er Alphas Einträge manuell in Moneybird bereinigen muss.

Wie Vibes to Bucks es handhabt: Ben wählt “Auf alle Zeiten anwenden”. Die Erweiterung warnt ihn, dass bestehende Einträge unter Alpha nicht automatisch gelöscht werden — er muss diese in Moneybird entfernen. Es werden dann neue Einträge für jeden historischen Tag unter Beta erstellt.

2c — Nur die Lücke synchronisieren

Was Ben möchte: Ben hat vor zwei Wochen aufgehört zu synchronisieren, als er merkte, dass die Zuordnung falsch war. Er hat 14 Tage ungesyncte Kosten im Ledger. Diese 14 Tage sollen an Beta gehen, aber die Monate, die bereits an Alpha synchronisiert wurden, sollen bleiben.

Wie Vibes to Bucks es handhabt: Ben wählt “Nur auf ungesyncte Tage anwenden”. Die Erweiterung weiß, welche Tage bereits einen Zeiteintrag in provider_posts haben, und überspringt sie. Nur die 14 ungesyncten Tage werden unter Beta erstellt.

Szenario 3 — Projektaufteilung: Arbeit auf Teilprojekte verteilen

Wer: Clara, eine Entwicklerin, arbeitet an einem Monorepo für Kunde Gamma.

Was passiert ist: Clara hat alle AI-Arbeiten einem Sammelprojekt “Allgemeine Entwicklung” zugeordnet. Gamma möchte nun die Kosten nach Funktionsbereich aufschlüsseln. Clara erstellt branchbasierte Abrechnungsregeln: feature/auth/* → “Auth Modul” und feature/billing/* → “Billing Modul”.

3a — Nur vorwärts gerichtete Aufteilung

Was Clara möchte: Zukünftig sollen die Kosten dem richtigen Teilprojekt zugeordnet werden. Vergangene Kosten, die bereits unter “Allgemeine Entwicklung” synchronisiert wurden, bleiben dort.

Wie Vibes to Bucks es handhabt: Wenn Clara die neuen Branch-Regeln hinzufügt, fragt die Erweiterung nach der Historie für jede. Sie wählt “Ab heute anwenden” für beide. Historische Einträge unter “Allgemeine Entwicklung” bleiben unberührt.

3b — Historische Genauigkeit

Was Clara möchte: Sie möchte tatsächlich vergangene Kosten rückwirkend den richtigen Teilprojekten zuordnen. Sie akzeptiert, dass sie die alten Einträge “Allgemeine Entwicklung” manuell in Moneybird löschen muss.

Wie Vibes to Bucks es handhabt: Clara wählt “Auf alle Zeiten anwenden” für die neuen Regeln. Die Erweiterung warnt vor bestehenden Einträgen unter dem alten Projekt und erstellt korrekte Einträge pro Teilprojekt pro Tag. Clara bereinigt die alten Einträge in Moneybird.

Szenario 4 — Unberechenbare Gefälligkeit

Wer: David, ein Freelancer, arbeitet an Client Deltas Repo.

Was passiert ist: David wird in eine interne Code-Überprüfung und einige Experimente hineingezogen, die nicht zum Umfang von Delta gehören — aber er hält Cursor in ihrem Repo offen. Er möchte nicht, dass die nächsten 2 Stunden AI-Kosten Delta berechnet werden.

Was David möchte:

• Die Delta-Abrechnungsregel auf “unberechenbar” umschalten. Ein sichtbarer Indikator in der Statusleiste bestätigt, dass die Regel unberechenbar ist.
• AI-Kosten werden weiterhin verfolgt und auf dem Dashboard sichtbar — er möchte sehen, was ihn diese Gefälligkeit kostet — aber als nicht zur Abrechnung gekennzeichnet.
• Jede Stunde eine Erinnerungsbenachrichtigung: “Delta-Abrechnungsregel ist seit 2 Stunden unberechenbar. Immer noch unberechenbar arbeiten?”
• Wenn er wieder auf abrechenbar umschaltet, wird die normale Synchronisierung fortgesetzt.
• Die unberechenbaren Kosten werden auf dem Dashboard unter Delta angezeigt, aber klar von den abrechenbaren Kosten unterschieden.

Warum per Mapping, nicht global: David könnte Multitasking betreiben. Wenn er zu Client Betas Repo wechselt, während Delta unberechenbar ist, sollte Beta weiterhin normal abgerechnet werden. Unberechenbar ist eine pro-Kunde-Gefälligkeitsentscheidung: “Diese Kosten, die ich mache, sind nicht die Anfrage des Kunden — ich mache das als Gefälligkeit für sie.”

Wie Vibes to Bucks es handhabt: David öffnet das Einstellungsfenster und schaltet Deltas Abrechnungsregel auf unberechenbar. Ein Dialog fragt zwei Dinge: wann soll unberechenbar beginnen (jetzt oder rückdatiert) und wann soll es enden. David wählt “Ab jetzt” und “Ende des Tages” — die Abrechnung wird morgen automatisch fortgesetzt. Die Statusleiste zeigt $4.23 heute · Delta [unberechenbar bis Ende des Tages], während er in Deltas Repo arbeitet. Unberechenbare Kosten werden weiterhin als nicht abrechenbare Zeiteinträge in Moneybird synchronisiert (sichtbar in den Aufzeichnungen, aber von der Kundenabrechnung ausgeschlossen). Das Dashboard zeigt sowohl abrechenbare als auch unberechenbare Kosten für Delta, klar getrennt.

Wenn David erwartet, dass die Gefälligkeit länger dauert, kann er “Bestimmtes Datum” wählen (z.B. unberechenbar bis Freitag) oder “Bis ich manuell fortsetze” mit einem Erinnerungsintervall (alle 30 Minuten, 1 Stunde, 2 Stunden usw.), damit er nicht vergisst, die Abrechnung wieder einzuschalten.

Variante — rückwirkend unberechenbar

Was David möchte: Er hat vergessen, vor dem Start umzuschalten. Er möchte die letzten 90 Minuten nachträglich als unberechenbar markieren.

Wie Vibes to Bucks es handhabt: David öffnet das Einstellungsfenster, schaltet Delta auf unberechenbar und wählt im Abschnitt Start “Rückdatieren” mit einer Zeit von vor 90 Minuten. Kosten ab diesem Zeitpunkt werden als unberechenbar gekennzeichnet. Wenn der heutige Zeiteintrag bereits mit Moneybird synchronisiert wurde, berechnet die Erweiterung neu und aktualisiert ihn, um den reduzierten abrechenbaren Betrag widerzuspiegeln. Rückdatierung ist auf heute begrenzt — für mehrtägige Korrekturen bietet das Sync Ledger Rückgängig- und Resync-Steuerungen.

Szenario 5 — Einen falschen Sync rückgängig machen

Wer: Eve, eine Freelancerin, die eine Zuordnung geändert und sofort “Jetzt synchronisieren” ausgeführt hat.

Was passiert ist: Eve hat eine Abrechnungsregel bearbeitet (das Projekt geändert) und “Jetzt synchronisieren” ausgeführt, ohne über die Konsequenzen nachzudenken. Die Erweiterung hat 3 Monate neue Zeiteinträge unter dem falschen Projekt in Moneybird erstellt, neben den bereits vorhandenen korrekten Einträgen unter dem alten Projekt.

Was Eve möchte:

• Sehen, was gerade synchronisiert wurde — eine Zusammenfassung, die zeigt, wie viele Einträge erstellt oder aktualisiert wurden, für welche Tage, unter welchem Projekt.
• Rückgängig machen: Entweder löscht die Erweiterung die falsch erstellten Einträge oder sie teilt ihr klar mit, welche Eintrags-IDs sie manuell bereinigen muss.

Wie Vibes to Bucks es handhabt: Nach jedem Sync zeigt die Erweiterung eine Benachrichtigung: “Mit Moneybird synchronisiert — 87 erstellt, 2 aktualisiert, 14 übersprungen.” Ein Klick auf “Details anzeigen” öffnet das Sync Ledger — eine spezielle Ansicht, die jeden synchronisierten und ausstehenden Eintrag zeigt, filterbar nach Kunde, Projekt und Datum. Eve kann genau sehen, welche Einträge gerade erstellt wurden, die falschen auswählen und auf “Sync rückgängig machen” klicken. Die Erweiterung löscht diese Einträge aus Moneybird und markiert sie erneut als ausstehend, damit sie nach der Korrektur der Regel korrekt neu synchronisiert werden können.

Szenario 6 — Temporäre Projektabrechnung

Wer: Frank, ein Entwickler, arbeitet an github.com/acme/api.

Was passiert ist: Frank rechnet normalerweise das Projekt “API Maintenance” ab. Für zwei Wochen im März ist er in einem speziellen Sprint, der dem Projekt “API v2 Migration” zugeordnet ist. Nach dem Sprint wechselt er zurück.

Was Frank möchte:

• Die Abrechnungsregel am 10. März auf “API v2 Migration” ändern.
• Am 24. März wieder auf “API Maintenance” ändern.
• Nur das Zeitfenster vom 10.–23. März wird mit “API v2 Migration” synchronisiert.
• Alles vor dem 10. März und nach dem 23. März wird mit “API Maintenance” synchronisiert.
• Kein rückwirkendes Chaos in beide Richtungen.

Wie Vibes to Bucks es handhabt: Beide Male, wenn Frank die Abrechnungsregel ändert, wählt er “Ab heute anwenden”. Am 10. März beginnt die Regel, mit “API v2 Migration” abzurechnen. Am 24. März wechselt sie zurück zu “API Maintenance”. Die Einträge jeder Periode bleiben bei dem Projekt, das zu der Zeit aktiv war.

Szenario 7 — Abrechnung stoppen, Tracking beibehalten

Wer: Gina, eine Freelancerin, die mit Client Eta abschließt.

Was passiert ist: Der Vertrag ist beendet, aber Gina macht noch kleinere Wartungsarbeiten an Etas Repo. Sie möchte die AI-Kosten in ihrem Dashboard sehen — um zu beurteilen, ob ein neuer Vertrag lohnenswert wäre — aber sie möchte keine Zeiteinträge synchronisieren.

Was Gina möchte:

• Die Abrechnungsregel als dauerhaft unberechenbar markieren (kein temporärer Schalter — eine dauerhafte Einstellung).
• Das Dashboard zeigt weiterhin Kosten, die Client Eta zugeordnet sind.
• Die Synchronisierung überspringt diese Abrechnungsregel vollständig.
• Wenn Eta mit einem neuen Vertrag zurückkommt, schaltet sie es wieder auf abrechenbar und synchronisiert nur ab diesem Zeitpunkt — nicht die Lücke.

Wie Vibes to Bucks es handhabt: Gina deaktiviert “Abrechenbar” in Etas Abrechnungsregel. Kosten werden weiterhin verfolgt und erscheinen im Dashboard unter Eta, aber es werden keine Zeiteinträge erstellt. Wenn ein neuer Vertrag kommt, aktiviert sie die Abrechnung wieder und wählt “Ab heute anwenden”. Die unberechenbare Lücke bleibt unberechnet.

Szenario 8 — Anbieterwechsel

Wer: Hugo, ein Freelancer, der seit 6 Monaten mit Moneybird synchronisiert.

Was passiert ist: Hugos Buchhaltungsfirma wechselt ihn zu Harvest. Er ändert destination: harvest in seiner Konfiguration und richtet neue Harvest-Abrechnungsregeln ein.

Was Hugo möchte:

• Zukünftig soll die Synchronisierung zu Harvest gehen.
• Die 6 Monate an Moneybird-Einträgen bleiben unberührt.
• Keine rückwirkenden Einträge, die in Harvest für den historischen Zeitraum erstellt werden.

Wie Vibes to Bucks es handhabt: Wenn Hugo den Abrechnungsanbieter wechselt, erkennt die Erweiterung, dass Harvest keine Synchronisationshistorie hat. Ohne Anleitung würde sie versuchen, Einträge für jeden historischen Tag zu erstellen. Stattdessen erscheint derselbe Drei-Optionen-Dialog: “Ab heute neu starten”, “Alle Historie synchronisieren” oder “Nur ungesyncte Tage synchronisieren.” Hugo wählt “Ab heute neu starten.” Die Erweiterung setzt ein Migrationsstichtagsdatum, sodass die Synchronisierungs-Engine alle Tage vor heute überspringt. Nur heute und zukünftige Tage erstellen Harvest-Einträge. Seine Moneybird-Einträge bleiben unberührt.

Szenario 9 — Unabsichtliches Löschen einer Regel

Wer: Ivan, ein Freelancer, der Client Kappas Repo abrechnet.

Was passiert ist: Ivan wollte seine Abrechnungsregel bearbeiten, um den Stundensatz zu ändern, hat sie aber versehentlich gelöscht. Er bemerkt es sofort und erstellt die Regel mit den korrekten Einstellungen neu.

Was Ivan möchte:

• Die Regel neu erstellen, ohne Monate an doppelten Zeiteinträgen in Moneybird zu verursachen.
• Vergangene Einträge, die bereits synchronisiert wurden, sollen unberührt bleiben.
• Die Abrechnung soll nahtlos fortgesetzt werden, als wäre nichts passiert.

Das Risiko ohne Anleitung: Ivan erstellt die neue Regel. Die Erweiterung sieht ein Repo mit historischen Kostendaten und keiner passenden Abrechnungsregelhistorie. Ein naiver Sync würde jeden vergangenen Tag als “nie unter dieser Regel synchronisiert” behandeln und Einträge für die gesamte Historie erstellen.

Wie Vibes to Bucks es handhabt: Wenn Ivan eine Abrechnungsregel für ein Repo erstellt, das bereits historische Kostendaten im Ledger hat, erkennt die Erweiterung dies und präsentiert denselben Drei-Optionen-Dialog. Ivan wählt “Ab heute anwenden” — vergangene Einträge bleiben, wie sie waren, und die Abrechnung wird ab heute fortgesetzt. Keine Duplikate, keine Lücke, keine Panik.

Der gemeinsame Faden

Jedes der oben genannten Szenarien läuft auf eine Frage hinaus: Was soll mit der Vergangenheit geschehen, wenn du eine Abrechnungsregel änderst?

Vibes to Bucks trifft diese Entscheidung nie für dich. Jedes Mal, wenn du eine Abrechnungsregel bearbeitest — den Kunden, das Projekt, den Satz oder den Abrechnungsstatus änderst — fragt die Erweiterung dich, zu wählen:

Diese geführte Wahl erscheint in einem klaren Dialog, wann immer eine Änderung der Abrechnungsregel die Handhabung historischer Kosten beeinflussen würde. Keine Überraschungen, keine stille rückwirkende Neuabrechnung, keine verwaisten Duplikate.