- Zahlungs- und Umsatzsysteme sind für die Monetarisierung unverzichtbar, aber als komplexe Kernsysteme, in die Finanzen, Produkt, Kundensupport, Recht, Compliance und Vertrieb hineinspielen, kann schon eine kleine Störung zu großen Betriebsproblemen führen
- Junge Unternehmen oder Teams mit neuen Produkten sehen Billing leicht als bloßes Engineering-Problem und bauen es selbst, tatsächlich gibt es aber drei Optionen: Eigenbau, Third-Party oder Hybrid
- Ein reales Billing-System muss gleichzeitig Idempotenz, Datumslogik, Usage Metering, Steuern, Rückerstattungen, Kundenhierarchien, individuelle Verträge, Preisänderungen und Umsatzrealisierung abbilden
- Manche Probleme sind nach einmaliger Lösung stabil, aber Steuerregeln, Kundenfehler, manuelle Korrekturen und länderspezifische Rechnungsanforderungen wachsen mit dem Unternehmenswachstum und der globalen Expansion weiter
- Am sichersten ist es, sich auf produktspezifische Usage-Updates und Customer-Lifecycle-Events zu konzentrieren und Abonnements, Billing, Buchhaltung und Umsatzrealisierung so weit wie möglich einem Standard-Billing-System und ERP zu überlassen
Warum Billing keine einfache Funktion ist
- Zahlungs- und Umsatzsysteme sind notwendig, damit ein Unternehmen überhaupt Einnahmen erzielen kann
- Wenn alles normal läuft, fallen sie kaum auf, tatsächlich handelt es sich aber um ein krakenartiges System, das gleichzeitig viele Organisationen und Funktionen berührt
- Finanzen
- Produkt
- User Experience
- Kundensupport
- Kunden
- Recht
- Compliance
- Vertrieb
- Wenn ein Teil ausfällt, können sich Probleme schnell auf angrenzende Bereiche ausweiten, und das passiert in der Praxis häufig
- Wenn Umsätze nicht rechtskonform und korrekt eingezogen werden können, steigen die Probleme, die das Business operativ tragen muss, massiv an
Drei Architekturmuster
- Für Billing-Systeme gibt es in der Regel drei Ansätze
- Eigenbau
- ein vollständiges Third-Party-System
- ein Hybrid aus Eigenbau und Third-Party
- Junge Unternehmen oder Teams, die ein neues Produkt starten, neigen dazu, es selbst zu bauen, weil sie Engineers haben und alles einfach halten wollen
- Wenn man Billing als „Problem betrachtet, bei dem man Rechnungsdateien in S3 legt und ein CRON-Job sie abholt und abbucht“, missversteht man Billing als reines Engineering-Problem
- So wie man Sicherheit oder Datumsverarbeitung nicht selbst von Grund auf implementiert, sollte man auch Billing nicht komplett selbst bauen
- Das beste Billing-System ist eines, das man nicht vollständig selbst bauen musste
Die 14 Schmerzen eines eigenen Billing-Systems
-
Idempotenz
- Jede Rechnung und jede Anfrage zum Zahlungseinzug muss eindeutig und idempotent sein
- Das Problem tritt auf, wenn man wegen API-Limits erneut versucht oder Instanzen des Zahlungssystems skaliert
- Ohne saubere Umsetzung besteht das Risiko von Doppelabrechnungen
-
Datumsverarbeitung
- Man muss entscheiden, ob alle 30 Tage oder jeden Monat relativ zum Anmeldedatum abgerechnet wird
- Bedingungen wie Schaltjahre oder Zeitzonen müssen ebenfalls verarbeitet werden
-
Proration und Restbeträge
- Man muss entscheiden, ob Proration nur bei Upgrades oder auch bei Downgrades gilt
- Optionen sind Rückerstattung, Gutschrift, Ignorieren oder das Blockieren von Upgrades und Downgrades
-
Usage Metering
- Es kann Dutzende Arten geben, Nutzung zu berechnen
- Je nach Kundentyp kann sich das unterscheiden oder häufig ändern
-
Rechnungsformat
- Wenn man nur in einem Land tätig ist, wirkt das vielleicht einfach
- Mit der Expansion müssen nicht nur Sales Tax, sondern auch VAT, GST und zusätzliche länderspezifische Abgaben verarbeitet werden
- Für einzelne Märkte können eigene Templates nötig werden
Wachsende Komplexität in B2B und globaler Expansion
-
Komplexe Kundenhierarchien
- Vor allem B2B-Kunden wollen möglicherweise Billing-Beziehungen mit Tochtergesellschaften und Partnern verwalten
- Dafür braucht man eine Möglichkeit, Nutzung dem tatsächlichen Zahler zuzuordnen und zu aggregieren
- Solche Anforderungen tauchen oft erst nach Wachstum und Expansion auf
- Wenn sich juristische Einheit oder Nutzungsort eines Kunden unterscheiden, können andere Steuern gelten
- Rechtlich kann es nötig sein, Billing und Invoice zu trennen
- Die zugehörigen Regeln können sich alle paar Monate ändern
-
Zahlungseinzug und Churn-Prävention
- Man muss entscheiden, wann bei fehlgeschlagenen Zahlungen keine weiteren Retries mehr erfolgen
- Bei Chargebacks muss entschieden werden, ob das Konto gekündigt, gesperrt oder rückerstattet wird
-
Pausieren und Fortsetzen
- Wenn ein Kunde sein Abonnement pausiert, muss festgelegt werden, welche Zugriffsebene weiterhin erlaubt ist
-
Gutschriften und Rückerstattungen
- Wenn nur vollständige Rückerstattungen vorkommen, ist es vergleichsweise einfach
- Bei Teilfehlern muss man sich eventuell zwischen teilweiser Rückerstattung und Store Credit entscheiden
- Auch ob Gutschriften verfallen, muss separat festgelegt werden
Steuern, Verträge und menschliche Fehler
-
Steuerbehandlung
- Schon unterschiedliche Steuersätze für verschiedene Positionen machen das Thema komplex
- Global ändern sich Steuersätze und Steuerregeln häufig
-
Individuelle Verträge
- Wenn man nur PLG macht, ist das möglicherweise kein Problem
- Sobald man beginnt, Verträge abzuschließen, entstehen schnell Ausnahmen und Sonderbedingungen, die sich mit bisherigen Annahmen nicht einfach konfigurieren lassen
-
Menschliche Fehler
- Kunden machen Fehler, die anschließend korrigiert werden müssen
- Auch intern können Kundeneinstellungen falsch konfiguriert werden und später Anpassungen erfordern
- Das Ausstellen von Gutschriften und das Neuerstellen von Rechnungen ist sehr zeitaufwendig
- Auch Änderungen an den rechtlichen Kundendaten müssen verarbeitet werden
- Adresse
- VAT ID usw.
-
Selektive Preisänderungen
- Preisänderungen gelten oft nicht für alle Kunden
- Wenn sie nur für Neukunden gelten, müssen verschiedene Preisversionen gepflegt werden, um bestehende Verträge einzuhalten
-
Umsatzrealisierung und abgegrenzte Umsätze
- Für die Regeln zur Umsatzrealisierung nach IFRS-15 gibt es eine 64-seitige PDF-Spezifikation
- Wenn man zusätzlich noch individuelle ERP-Integrationen selbst umsetzt, steigt die Komplexität weiter
Probleme, die einmalig sind, und Probleme, die weiter wachsen
- Manche Probleme ändern sich viel häufiger als erwartet, andere muss man nach einer einmaligen Lösung kaum noch anfassen
- Idempotenz ist ein Beispiel für ein Engineering-Problem, das nach der Lösung nur selten erneut Arbeit verursacht
- Steuerregeln ändern sich weltweit häufig
- Je mehr Länder man erschließt, desto mehr Steuerrecht muss verfolgt werden
- Kundenfehler treten relativ konstant auf
- Mit dem Wachstum steigt ihr Umfang
- Mehr Kundensupport und manuelle Korrekturen werden nötig
- Billing wirkt anfangs wie ein Engineering-Problem, ist in Wirklichkeit aber in einem komplexen Problemraum verwurzelt, der selbst für Branchenerfahrene schwer zu durchdringen ist
Bereiche, die man nicht selbst bauen muss
- Es ist besser, möglichst viele Billing-Probleme an externe Systeme auszulagern
- Empfohlen wird ein Ansatz, bei dem man möglichst viele Standardlösungen einkauft
- Einen großen Teil von Abonnement- und Billing-Funktionalität kann ein Zahlungssystem übernehmen
- Umsatzrealisierung und Buchhaltung sollten besser Funktionen überlassen werden, die bereits im eingesetzten ERP oder in anderen Systemen vorhanden sind
- Produktteams sollten sich nur auf produktspezifische Bereiche wie Usage-Updates und grundlegende Customer-Lifecycle-Events konzentrieren
1 Kommentare
Hacker-News-Meinungen
Ein guter Beitrag für Leute, die Entscheidungen zur Abrechnung treffen müssen, aber noch nicht viel Erfahrung haben; auch für Erfahrene als Referenz nützlich.
Allerdings musste ich über den Satz „Kann man die abzurechnenden Dateien nicht einfach in S3 ablegen und einen CRON-Job die Zahlungen einsammeln lassen?“ laut lachen. Aus Engineering-Sicht ist das in keiner Situation eine gute Idee.
Meine bevorzugte Entscheidung bei der Abrechnungsarchitektur ist, Abrechnung und Berechtigungen im System so weit wie möglich zu trennen. Bei Prepaid-Abos sollte man in den Berechtigungen selbst nur das Ablaufdatum und die Details der während des aktiven Zeitraums gewährten Rechte speichern; das Abrechnungssystem speichert das Abo und synchronisiert bei Bedarf in Richtung Berechtigungen. So wird es einfacher, manuell abzurechnen, temporäre Probleme zu debuggen und zu patchen oder eine Stripe-Integration anzubinden.
Natürlich sollte man zukünftige Erweiterungen offenhalten, aber diese Entscheidung schränkt das System an sich nicht stark ein. Es ist nicht meine originelle Idee, aber nachdem ich andere Ansätze mit weniger Erfolg ausprobiert hatte, habe ich sie besonders schätzen gelernt.
Viele Probleme entstehen aus dem Unterschied zwischen Zahlung und Abrechnung https://www.wingback.com/blog/saas-payment-vs-saas-billing. Wenn man die ersten Kunden gewinnt, muss man nur ein paar wiederkehrende Zahlungen entgegennehmen, daher kann man leicht mit Stripe oder manuellen Rechnungen starten.
Mit der Zeit kommen jedoch immer mehr Enterprise-Kunden hinzu, die komplexere Berechtigungen, mehrere Tarife, Bestandsschutz für bestehende Kunden sowie individuelle Abrechnungszyklen, Bedingungen und Berechtigungen benötigen. Abrechnung steht oft nicht im technischen Fokus, sodass sich kleine Hacks und Zusatzfunktionen ansammeln und am Ende ein Chaos entsteht, das Produktentwicklungsressourcen abzieht, den Vertrieb verlangsamt oder einschränkt, welche Produkte man verkaufen kann.
Die Komplexität von Abrechnung steckt voller versteckter Fallstricke und Ausnahmen; heute ist sie noch größer, weil die meisten Tarife mehrere Limits und nutzungsbasierte Komponenten enthalten und SaaS weltweit verkauft wird. In Unternehmen in späteren Phasen gibt es auch Engineering-Teams mit 15 oder mehr Personen, die sich ausschließlich um Abrechnung kümmern. Ich stimme zu: Wenn es nicht der Kern des Produkts ist, sollte man kein eigenes Abrechnungssystem bauen. Zur Einordnung: Ich bin CTO der SaaS-Abrechnungsplattform Wingback.
Jetzt will ich so ein System bauen, und ich fühle mich deutlich qualifizierter dafür, als ich gedacht hätte.
https://arnon.dk/why-you-should-separate-your-billing-from-e...
Kunden speichern Berechtigungen in unserem System und prüfen sie bei Bedarf; wenn beim Payment Provider ein Abo verlängert oder gelöscht wird, werden Regeln und Berechtigungen hinzugefügt. Das erleichtert die Arbeit mit einem oder mehreren Payment Providern und schafft eine klare Trennung der Zuständigkeiten. Dazu passen auch diese Beiträge, daher teile ich sie hier: https://warrant.dev/use-cases/pricing-tiers-and-entitlements..., https://arnon.dk/why-you-should-separate-your-billing-from-e...
Ein ideales Berechtigungssystem sollte dynamisch sein, das heißt: Regeln sollten in der Datenbank gespeichert werden, es sollte Einzelfälle wie Enterprise-Kunden abbilden können, und darüber sollte eine Policy-Schicht liegen. Es sollte nahezu alle Szenarien unterstützen können, etwa: Pro-Tarif bis zu 5 Seats, Growth-Tarif mit einer bestimmten Funktion bis zu N-mal pro Tag usw.
Eine UI, mit der nicht-technische Rollen kundenspezifische Änderungen ohne Engineering-Eingriff vornehmen können, ist ebenfalls ein großer Vorteil. In früheren Engineering-Rollen hat so etwas das Entwicklungsteam ständig ausgebremst.
Es gibt auch eine Menge von Berechtigungen, aber dazwischen liegt ein Policy-Mechanismus, der entscheidet, wann Berechtigungen angewendet werden oder nicht. Der Kernpunkt ist: Berechtigungen sind nicht nur ein Abrechnungsthema. Der Policy-Mechanismus ist der Klebstoff, der Berechtigungen mit allem anderen verbindet, sodass man zum Beispiel einem Executive des größten Kunden Berechtigungen geben kann, ohne sie mit der Abrechnung zu verknüpfen.
Ich habe früher einmal ein Abrechnungs- und Forderungssystem für eine kleine Apothekenkette gebaut, und Versicherer schickten uns ohne jede Vorwarnung ziemlich große Schecks.
Obwohl wir gar nichts abgerechnet hatten, kam per Post ein Scheck über 150.000 Dollar, und erst Monate später bemerkten sie den Fehler und baten um Rückzahlung. Für solches Geld gab es ein spezielles Konto namens magic money. Die Welt der Abrechnung ist wirklich ein verrücktes Pflaster.
Ob man es einfach magic money nannte und die Schulden auf den Privatkonten unverändert ließ.
Ich halte es nicht für sinnvoll, das Thema allein über die Schmerzen beim Bau eines eigenen Billing-Systems anzugehen. Wenn viele Unternehmen diesen Weg gehen wollen, sollte man sie das tun lassen.
Ich erkenne an, dass Billing-Systeme sehr komplex sind. Aber wenn Chargebee, Solvimon, Stripe, Recurly, Orb, Metronome, Lago, Togai usw. über dieses Wissen verfügen, könnte man dieses Wissen auch an einem Ort bündeln.
Die richtige Antwort ist am Ende der Ansatz, der zu einem selbst passt. Für ein abonnementbasiertes SaaS gibt es passende Lösungen, und für eine nutzungsbasierte API gibt es passende Billing-Lösungen.
Statt von der Praxis abzuraten, könnte man Wissen, Ansätze, Paradigmen, Programmiermuster, gute Praktiken und Best Practices an einem Ort sammeln. Es gibt auch Ausnahmen, etwa Unternehmen außerhalb der USA oder Europas, die Billing-Lösungen wie Stripe nicht nutzen können. Wenn man zum Beispiel ein Unternehmen in Venezuela ist und kein Stripe-Konto erstellen kann, muss man am Ende eine eigene Billing-Lösung bauen und sie an die schwer verständliche SOAP-XML API eines lokalen Payment-Gateways anbinden.
Nebenbei: „ein eigenes Billing-System bauen“ fühlt sich ähnlich an wie „ein eigenes SIEM bauen“ mit einer Elastic-+-Grafana-Konfiguration. Ich würde es nicht empfehlen, aber ich verstehe, warum IT-Sicherheitsabteilungen so oft diesen Weg gehen.
Billing-Systeme sind weniger komplex als vieles, womit Entwickler sonst arbeiten. Der Text stellt schwierige rechtliche Anforderungen als Hürden dar, aber in der Praxis bedeutet das auch, dass Spezifikationen leicht zu finden und gut dokumentiert sind. Manche Teile ändern sich häufig, aber diese sind gut gekennzeichnet und erklärt.
Ich stimme zu, dass abonnementbasierte SaaS-Produkte und nutzungsbasierte APIs jeweils passende Billing-Modelle brauchen. Entscheidend ist aber, ob man den Kunden erlauben will, die Verantwortung abzuwälzen, ob der Umsatz wichtig genug ist, um das zu validieren, und ob man Gebühren oder Verluste tragen kann.
Eines, das dieser Beitrag nicht behandelt, ist Affiliate-Vertrieb; je nachdem, wie tief man ihn implementiert, kann das ziemlich viel Arbeit werden.
Das ist ein System, mit dem andere für Verkäufe innerhalb der Plattform provisionsbasierte Auszahlungen erhalten können.
Man muss Affiliate-Codes bis zu Verkäufen und Nutzern nachverfolgen, Auszahlungen an den vom Affiliate festgelegten Zahlungsanbieter senden und, wenn man es richtig machen will, auch eine UI bereitstellen, in der Besucherkennzahlen, Conversion-Raten und Auszahlungshistorie einsehbar sind.
Zum Glück lässt sich das meiste schrittweise bauen. Man muss nur einen eindeutigen Code mit einem Nutzer verknüpfen und diesen Code mit Verkäufen zu einem bestimmten Provisionssatz verbinden; den Rest kann man manuell erledigen oder weglassen. Ich zahle Affiliates zum Beispiel einmal im Monat per Zelle oder PayPal aus, und das dauert keine 10 Minuten. Es gibt kein Frontend für Conversion-Tracking, und deswegen hat bisher niemand auf eine Affiliate-Partnerschaft verzichtet.
Wirklich beeindruckend fand ich die Notwendigkeit, diese ganze Rube-Goldberg-Maschine auch rückwärts laufen lassen zu können.
Eine „Bestellung“ möchte man möglichst statisch halten, und eine „Rechnung“ bringt sogar rechtliche Pflichten mit sich.
Angenommen, jemand kauft 5 Stück und erhält einen Rabatt, will dann aber nur 3 behalten, und in Name und Adresse waren Tippfehler. Kein Problem: Man storniert die Rechnung, erstellt eine neue Rechnung über denselben Betrag mit korrigiertem Namen und korrigierter Adresse, wartet, bis die Rücksendung eingetroffen und geprüft ist, stellt dann erneut eine Gutschrift aus und erstellt wieder eine neue Rechnung.
Die Rücksendung befindet sich eine Zeit lang in einem unklaren Zustand, der Kunde bestellt 5 weitere Stück, eines kommt beschädigt an, und er möchte keine Ersatzlieferung, sondern eine Rückerstattung. Die Lieferung verteilt sich auf 2 Versandtermine, sodass das System den Rabatt ab 5 Stück nicht anwendet. Was man zunächst für 2 einfache Bestellungen hielt, verwandelt sich schlagartig in eine Vielzahl von Transaktionen und Dokumenten. Der Kunde hat außerdem sein Passwort vergessen und mit einer anderen E-Mail-Adresse ein neues Konto erstellt. Wenn man ein Jahr später in die Logs schaut, ist schwer nachzuvollziehen, warum er einen Rabatt bekommen hat, obwohl er nur 3 Stück gekauft hat.
Bei diesem Rat bin ich mir nicht sicher. Die Hälfte der im Artikel genannten Funktionen braucht man vielleicht gar nicht, und wenn das Geschäft wächst, kann man sie durchaus schrittweise aufbauen.
Konzepte wie Rechnungen, Gutschriften, Steuerzeiträume und anteilige Änderungen muss man verstehen. Aber dieses Wissen ist nicht zwingend ein Grund, alles auszulagern oder zu kaufen, sondern Material, um die Build-vs.-Buy-Entscheidung besser zu treffen.
Die einzige externe API, die ein SaaS braucht, ist ein Kreditkarten-Prozessor; wenn man es schick machen will, vielleicht zwei. Natürlich fällt nach dem ersten Jahr viel manuelle Arbeit an, der Steuerberater wird einen auf dumme Fehler hinweisen, und man wird auch viel über Buchhaltung lernen.
Trotzdem: Wenn ich heute ein neues Geschäft starten würde, würde ich mir mehrere Lösungen ansehen, aber ich bin überzeugt, dass Selberbauen nicht so furchteinflößend ist.
Ein System zu bauen sieht immer einfach aus, und am ersten Tag ist es das tatsächlich auch. Aber bald verbringt man viel Zeit damit, dem Finanzverantwortlichen zu erklären, warum die Reports völlig durcheinander sind, und dem Support-Team, warum eine Rechnung fehlgeschlagen ist, warum ein Abo zum falschen Preis abgerechnet wurde und welche Sonderfälle es gibt, von deren Existenz man nicht einmal wusste.
Danach muss man geänderte Vorschriften einhalten, oder das gewählte Gateway unterstützt vielleicht die Region nicht, in der man gerade wächst.
Bevor man sagt „Dann bauen wir es eben besser“, sollte man bedenken, dass auch das Zeit kostet. Zeit, die nicht ins Produkt fließt, nicht in die Verbesserung des Preismodells und die man mit Auf-der-Stelle-Treten verbringt, statt das Geschäft wachsen zu lassen.
Alles andere kann man ignorieren, aber wenn man später keine Steuern berechnen kann oder gegen KYC-Gesetze verstößt, wird es wirklich unangenehm.
Außerdem heißt die Tatsache, dass ein System teurer ist und von vielen klug wirkenden Unternehmen genutzt wird, nicht, dass es zum Zweck passt. Schon gar nicht, dass es zu deinem gewünschten Zweck passt. Kaufen bedeutet nicht, dass man sich die Recherche sparen kann.
Das Ziel der Person, die sich um solche Abrechnung kümmert, ist simpel: Sie muss dem Vertrieb die passenden Optionen bereitstellen, damit dieser Deals abschließen kann. Man muss mit dem Vertrieb zusammenarbeiten und herausfinden, welcher Bereich „einfach zu implementieren und ausreichend zum Abschließen von Deals“ ist.
Das kann man gar nicht stark genug betonen. Der Vertrieb erzeugt tatsächlich Umsatz. Man sollte nicht herumjammern, nur weil das Abrechnungssystem nicht perfekt ist. Es mag schockierend sein, aber bei Themen, an denen Geschäftsbeziehungen hängen, muss man manchmal die Ärmel hochkrempeln und Dinge von Hand erledigen.
Es sollte so einfach wie möglich sein, aber zugleich ein System, das andere Teams im Unternehmen lesen und verstehen können und das sich leicht manuell anpassen lässt, selbst wenn Automatisierung läuft. Das ist zu 80 % der Grund, warum Stripe sich angenehm in der Nutzung anfühlt. Manuelle Anpassungen gehören zum Leben, und in manchen Unternehmen sind sie selten, aber irgendwann trotzdem nötig.
Anteilige Berechnung, unterschiedliche Abrechnungspläne, Testphasen, Tests neuer Preise, regionale Preise, regionale Steuern, Bundle-Angebote in mehreren Währungen und die Einführung neuer Preise werden plötzlich zu einer Kombination aus 6 Währungen × X Regionen × Y Produkten × Z Abrechnungsplänen × L Sprachen.
Dazu kommen neue Abos, das Zusammenführen von Abo-Tarifen, das Einstellen alter Tarife, während man Kunden sanft auf neue Alternativtarife migriert, und gute Kommunikation mit den Kunden. Bei SaaS muss fast alles gut automatisiert, als Self-Service verfügbar und getestet sein; sonst geht man in Kundensupport und Churn unter.
Das Ausrollen von Preisänderungen kann zwischen 3 Tagen und 2 Monaten dauern, und die Altlasten früher individueller Verträge zu behandeln ist ein Albtraum. Wenn es sich nicht leicht automatisieren lässt, können wir es nicht machen. Es kostet zu viel Zeit.
Hätten wir die Abrechnung auf etwas wie die hier erwähnten Produkte gestützt, könnten wir vermutlich deutlich besser individuelle Verträge nach Kundensegmenten und Preisänderungen ausrollen.
Zwei Probleme, die hier nicht behandelt wurden, mit denen ich aber selbst zu tun hatte:
Erstens der Monats- und Quartalsabschluss. Der Artikel spricht zwar vom Kontenbuch, aber sobald man mit börsennotierten Unternehmen zu tun hat, die Zahlen berichten müssen, gibt es strikte Abschlusszeitpunkte, und alles muss reibungslos laufen.
Zweitens Cash Accounting für Geld unterwegs. Der Artikel setzt voraus, dass der Zahlungsabwickler zu 100 % korrekt arbeitet und keinerlei Probleme macht. Ab einer gewissen Größe muss man jeden Geldeingang auf dem Bankkonto einer bestimmten Rechnung oder Rechnungsposition zuordnen können. Man muss auch Rechnungen finden, zu denen es keine entsprechende Zeile im Kontoauszug gibt, und umgekehrt mit eingehendem Geld umgehen, das keiner Rechnungsposition zugeordnet ist. Wichtig ist auch die Fähigkeit, Gutschriften auf dem Bankkonto zu behandeln, die nicht mit einer ausgestellten Rechnung verknüpft sind.
Man könnte all das als Problem der Buchhaltungsabteilung bezeichnen, aber es ist so eng mit dem System gekoppelt, dass beide Teams zusammenarbeiten müssen, damit es keine Abweichungen zwischen den Büchern gibt.
Echte Buchhalter müssen wegen des Abschlusses immer wieder bis Mitternacht bleiben, und Leute aus Technik und Business erleben, dass sie etwas vom Accounting-Team brauchen, dieses während der Abschlussphase aber wirkt, als sei es vom Erdboden verschwunden. Als Familienmitglied erlebt man es genauso.
Die interne Buchhaltung und das Bankkonto driften langsam auseinander, und der Steuerberater weiß nicht mehr, wo er mit der Fehlersuche anfangen soll.
Mich würde interessieren, was alle für Entitlement-Management verwenden. Ob ihr ein Feature-Flag-System nutzt, ein separates SaaS wie Stigg oder ein eigenes internes System
Ich bin heute Morgen auch deshalb auf HN, weil ich einen Beitrag darüber geschrieben habe, Feature Flags für Entitlements zu nutzen: https://prefab.cloud/blog/modeling-product-entitlements-with.... Inspiriert hat mich auch Arnons Beitrag zum SKU-Format
Feature Flags wirken nicht wie der perfekte Ort für Entitlement-Management, aber meiner Erfahrung nach waren sie bei solchen Aufgaben oft das beste Werkzeug, das gerade verfügbar war. Ich würde gern andere Meinungen hören
Diese Limits und Flags werden an einen „Plan“ gehängt, und ein Plan kann einem Account zugewiesen werden. Wenn Pläne kombiniert werden, nehmen numerische Werte den höheren Wert an, und Tags werden als Vereinigungsmenge zusammengeführt. Außerdem lassen sich Werte pro Account überschreiben oder ergänzen. Wenn ein Kunde also PlanX braucht, aber ein individuelles API-Kontingent benötigt, überschreiben wir nur diesen einen Wert direkt am Account
Nennt es gern altmodisch, aber ich sehe nicht, warum man so etwas an einen Drittanbieter auslagern sollte
Die grundlegende Lösung lässt sich mit Feature Flags umsetzen, aber Entitlements im Zusammenhang mit Billing und Pricing, etwa die Organisation und Änderung von Plänen und Editionen, werden mit der Zeit durch viele Randanforderungen komplex. Man denke an verschiedene Kombinationen aus Features, Seats, nutzungsbasierten und metered Strategien, Team-Abos, Plan-Migrationen, einmalige Enterprise-Pläne, Kunden mit mehreren Abonnements, Aktionszeiträume und gestaffelte Abos, Nutzungsaggregation, automatisches Upselling und so weiter
Wie im Beitrag zu sehen, lassen sich Limits zwar durch Flags mit numerischen Werten ausdrücken, aber die Infrastruktur zur Nutzungserfassung muss das Unternehmen weiterhin selbst implementieren. Man stelle sich stattdessen vor, diese Nutzung an einen Entitlement-Service zu exportieren, sodass nutzungsbasierte Entitlements auch teamübergreifend in Echtzeit aktualisiert werden. Außerdem könnten andere Entitlements, die davon abhängen, ebenfalls mit aktualisiert werden. Wenn man sich einem Limit nähert oder es überschreitet, kann man zwischen einem Soft Limit wählen, bei dem die Nutzung weiterläuft, aber das Vertriebsteam benachrichtigt wird, und einem Hard Limit, das einen Upgrade-Hinweis anzeigt
Ganz im Sinne des Originalbeitrags bauen wir Billing nicht neu, sondern arbeiten mit bestehenden Billing-Lösungen zusammen. Wir bootstrappen das Ganze nach einem früheren erfolgreichen Exit und arbeiten mit ersten Kunden; wer sich einfach nur zu dem Thema austauschen möchte, kann sich unter trent at planship.io melden
Beta-Rollouts, rollenbasierte Autorisierung, Billing-Entitlements, einmalige Kundenwünsche – all das kann man mit Feature Flags bauen. Die besten Feature Flags können optional auch Werte tragen, also können auch API-Plan-Limits Feature Flags sein
Ist das die beste Lösung? Für den jeweiligen Use Case vermutlich nicht. Aber wenn man es einmal gebaut hat, ist die Versuchung groß, es überall zu verwenden
Entitlements sollten klar mit kundensichtbaren Funktionen verknüpft sein und sind konzeptionell deutlich größere Funktionsblöcke. Die Schwierigkeit dieses Ansatzes liegt darin, dass man weiterhin viele Billing-bezogene Aspekte berücksichtigen muss. Der Umgang mit säumigen Kunden, Überziehungsgebühren beim Überschreiten bestimmter Limits, mehrere Preismodelle für dieselbe Funktion, das Zurücksetzen oder Übertragen von Nutzungscountern bei Planwechseln und Upgrades – all das bringt mit der Zeit erhebliche Komplexität mit sich
Deshalb haben wir uns bei Wingback entschieden, separate Feature-Entitlements anzubieten, die eng mit der Billing-Kette und Metering gekoppelt sind. Zur Einordnung: Ich bin dort CTO. Am Ende können meiner Ansicht nach beide Ansätze gut funktionieren, je nach Komplexität der Pläne und danach, wie viel bereits in Feature Flags investiert wurde. Kundenseitiges Feature-Gating macht das Provisioning von Kundenaccounts und das Anbieten individueller Pakete deutlich einfacher
Die allgemeine Argumentationsstruktur „System X ist sehr komplex, also baut es nicht selbst, sondern nutzt eine fertige Lösung“ überzeugt mich nur schwer
Die allgemeine Lösung für X kann extrem schwierig und komplex sein, aber mein Use Case braucht vielleicht nur einen bestimmten Teil dieser Komplexität. Also kann ich eine eigene Lösung bauen, die nur die benötigte Komplexität behandelt, und die kann viel einfacher sein als ein fertiges Tool
Diese Haltung vertrete ich bei Datum und Uhrzeit vollständig. Mein Ansatz für Datum und Uhrzeit braucht von einer Bibliothek nur zwei Funktionsaufrufe: eine Funktion, die Epoch-Zeit in einen ISO-formatierten Zeit-String einer bestimmten Zeitzone umwandelt, und die inverse Funktion. Den restlichen Library-Code fasse ich gar nicht an; alle weiteren Zeitmanipulationen erledige ich in meinem eigenen Code auf Basis dieser beiden Funktionen
Man muss von Anfang an verstehen, was man bei personenbezogenen Daten tun und lassen sollte, welche Zyklen und Lebensdauern verschiedene Billing-Optionen haben, welche Grenzen für Rückerstattungen gelten, wie Idempotenz unterstützt wird, wie man ein vernünftiges Datenbank-Transaktionsmanagement mit einem zum Problem passenden Modell aufsetzt, wie Rechnungen ausgestellt und Kunden angezeigt werden und so weiter
Nicht alles davon braucht man auf einmal, aber selbst für die erste funktionierende Implementierung braucht man mindestens die Hälfte
Es fühlt sich ein wenig an wie „Die 14 Leiden des Über-die-Straße-Gehens und warum ihr mein Buch kaufen und lesen solltet“
Viele Leute glauben, es sei eine gute Idee, mit geschlossenen Augen loszulaufen, und verletzen sich deshalb frühzeitig oder sterben
Die Regeln fürs Überqueren einer Straße unterscheiden sich von Land zu Land und sogar von Stadt zu Stadt. Vielleicht weiß man es noch nicht, aber man muss in beide Richtungen schauen. Viele Menschen wissen nicht, dass sie farbenblind sind, können Rot und Grün nicht unterscheiden und sterben oder werden verletzt. Du hast in beide Richtungen geschaut, aber hast du auch nach oben geschaut? In der Stadt fallen Dinge aus Fenstern, auf dem Land können Vögel über deinem Kopf fliegen, und auch Weltraumschrott fällt zunehmend auf die Erde. Objekte können aus vielen Richtungen kommen
Ich will nicht sagen, dass der Artikel so schlecht ist, aber als Methodik-Artikel wäre er besser gewesen. So einen Text würde ich deutlich lieber lesen als einen negativ aufgebauten
Es ist das Idealbild eines „Wie schwer kann das schon sein?“-Spaßprojekts, nur dass die Probleme alle real sind
Es gibt unzählige Beispiele, aber wenn man das Problem falsch angeht, landet man sehr schnell bei der Frage „Wie viel sollte der Kunde zahlen?“, gefolgt von „Warum haben wir diesen Betrag berechnet und nicht einen anderen?“. Wenn das zu oft passiert, kommt das Finance-Team und fragt, was man da getan hat, weil die Reports zur Unternehmenssteuerung – bis hin zu Berichten, die über Entlassungen entscheiden – nicht mehr verlässlich sind