KI‑Angebotsrechner: Preislogik an einem Ort halten

Warum KI‑erstellte Angebotsrechner oft falsche Zahlen ausgeben

Ein Angebotsrechner ist das Formular (oder die tabellenähnliche Ansicht), das aus ein paar Eingaben einen Preis erzeugt: Plätze, Nutzung, Tarif, Einrichtungsgebühren, Rabatte, Steuern und die Endsumme. Menschen verlassen sich darauf aus einem Grund: die angezeigte Zahl sollte mit dem übereinstimmen, was sie später berechnet bekommen.

KI‑erstellte Rechner sehen in Demos oft korrekt aus, aber die Preisregeln landen verstreut. Ein Bildschirm wendet einen Rabatt an, ein anderer berechnet die Summen neu, und ein dritter „korrigiert“ die Rundung. Sobald dieselbe Rechnung an mehreren Stellen existiert, reicht eine vergessene Änderung, damit der Rechner aus dem Tritt gerät.

Die Fehler sind meist klein. Der Schaden nicht. Ein Fehler von 20 $ wird zu einem Vertrauensproblem. Außerdem entstehen peinliche Übergaben: Vertrieb sagt eine Summe, die Buchhaltung stellt etwas anderes in Rechnung, und der Kunde fühlt sich getäuscht — selbst wenn es ein ehrlicher Bug war.

Falsche Zahlen schleichen sich meist durch ein paar Muster ein:

• Regeln verteilt über UI, Backend‑Code und Datenbankeinstellungen
• Versteckte Defaults (Steuer an/aus, Währung, Mindestgebühren)
• Fehler in der Reihenfolge der Operationen (Rabatt vor Steuer vs. nach Steuer)
• Rundungsunterschiede zwischen einzelnen Positionen und der Endsumme
• Alte Regeln, die nach einem Preisupdate zurückbleiben

Ein einfaches Szenario: ein Kunde wählt Pro, fügt 12 Plätze hinzu und nutzt einen 15% Jahresrabatt. Die App zeigt eine rabattierte Summe, aber das Rechnungssystem wendet den Rabatt auf eine andere Zwischensumme an. Beide Seiten „folgen“ ihren Regeln, der Kunde hat den Ärger.

Die Lösung ist einfach: Preislogik an einem Ort halten und sie mit realen Beispielen und erwarteten Ergebnissen validieren.

Beginnen Sie damit, Eingaben, Ausgaben und Regeln aufzuschreiben

Bevor Sie ein KI‑Tool bitten, einen Angebotsrechner zu bauen, schreiben Sie das Spec in einfachen Worten. Wenn Sie das überspringen, bekommen Sie oft etwas, das richtig aussieht, aber bei echten Kundenkombinationen bricht.

Starten Sie mit den Fragen, die der Rechner stellen muss. Formulieren Sie sie kundenfreundlich: „Wie viele Plätze?“, „Monatlich oder jährlich?“, „Brauchen Sie Onboarding?“, „In welchem Land sind Sie?“ Wenn eine Eingabe optional ist, beschreiben Sie, was passiert, wenn sie leer bleibt.

Definieren Sie als Nächstes die Ausgaben und das Format. Ein Angebot ist nicht nur „ein Preis“. Entscheiden Sie, was der Rechner jedes Mal zurückgeben muss, zum Beispiel:

• Zwischensumme
• Rabattposition
• Steuerposition
• Endsumme

Entscheiden Sie auch, wie Geld angezeigt wird (Währung, Dezimalstellen und ob Cents gezeigt werden).

Ein Angebot braucht eine klare Definition von „gültig“. Schreiben Sie die Regeln auf, die zu Streitigkeiten führen:

• Währung: nur eine Währung oder nach Land wählen
• Steuern: im angezeigten Preis enthalten oder beim Checkout hinzugefügt
• Rundung: wann gerundet wird (pro Position vs. nur Endsumme) und auf wie viele Dezimalstellen
• Mindestwerte: kleinste erlaubte Menge, Preisboden und wann eine Eingabe abgelehnt wird
• Wirksamkeitsdaten: wann eine Preisänderung beginnt und wie mit alten Angeboten umgegangen wird

Hier ein einfaches „Pricing‑Regel‑Summary“, das ein nicht‑technischer Gründer absegnen kann:

„Wenn ein Nutzer 10 Plätze bei monatlicher Abrechnung wählt, kostet ein Platz 29 $. Bei jährlicher Abrechnung gilt 10% Rabatt auf die Zwischensumme. Onboarding ist eine einmalige Gebühr von 500 $. Steuern sind nicht enthalten. Die Endsumme wird auf 2 Dezimalstellen gerundet.“

Preislogik an einem Ort behalten (Single Source of Truth)

Der schnellste Weg zu falschen Angeboten ist, Preisregeln an mehreren Stellen zu kopieren: eine Formel in der UI, eine andere im Backend und ein ‚Quick‑Fix‘ in einem Webhook. Ihr Rechner braucht ein Zuhause für die Regeln, und alles andere sollte darauf zugreifen.

Wählen Sie einen einzigen Ort und halten Sie sich daran: eine Pricing‑Funktion, ein Modul oder eine Konfigurationsdatei, die die App als Autorität behandelt. Wenn Sie zwei Dateien bearbeiten müssen, um einen Preis zu ändern, haben Sie Drift.

Halten Sie die UI getrennt von der Preislogik. Die UI sollte Eingaben sammeln (Tarif, Plätze, Add‑ons, Land, Coupon) und Ergebnisse anzeigen. Sie sollte nicht entscheiden, wie Rabatte kombiniert werden, wie Steuern angewendet werden oder wie gerundet wird. Diese Trennung macht Änderungen sicherer, weil Sie nicht Buttons, Screens und Form‑Handler durchsuchen, um versteckte Mathematik zu finden.

Ein sauberes Muster ist: ein Aufruf rein, eine Antwort raus. Die UI sendet ein vollständiges Eingabeobjekt, und die Preisfunktion liefert ein strukturiertes Ergebnis mit einer menschenlesbaren Aufschlüsselung.

// pricing.js
export function priceQuote(input) {
  // Rules live here. Update this, not the UI.
  // Note: coupons apply before tax; tax is on discounted subtotal.
  return {
    subtotal: 120,
    discount: 20,
    tax: 10,
    total: 110,
    breakdown: [
      "Base: $120",
      "Coupon: -$20",
      "Tax: $10"
    ]
  };
}

Fügen Sie kurze Hinweise direkt neben Regeln ein, die später oft gebrochen werden: Stufen‑Grenzen, Stapelreihenfolge und ungewöhnliche Ausnahmen, die aus einem Grund bestehen. Kommentare müssen nicht lang sein. Sie sollten nur verhindern, dass jemand versehentlich umschreibt.

Eine einfache Preisstruktur, die lesbar bleibt

Die meisten Angebotsfehler entstehen, wenn Preisregeln zu einem Haufen verstreuter if‑Anweisungen werden. Halten Sie die Regeln leicht durchsuchbar und die Berechnungsfunktion langweilig.

Verwenden Sie Variablennamen, die Ihrer Geschäftssprache entsprechen. Wenn jemand nicht erklären kann, was discount_rate bedeutet, wird er es später falsch benutzen.

Ein Preismodell, das Sie in 30 Sekunden lesen können

Hier eine einfache Form, die verhindert, dass Logik im ganzen App verstreut wird:

const pricing = {
  base_price: 49,
  per_unit: 12,
  discount_rate: 0.10,
  discount_min_qty: 10,
  tax_rate: 0.07
};

function quote({ quantity }, pricing) {
  const subtotal = pricing.base_price + (quantity * pricing.per_unit);
  const discount = quantity >= pricing.discount_min_qty ? subtotal * pricing.discount_rate : 0;
  const taxable = subtotal - discount;
  const tax = taxable * pricing.tax_rate;
  const total = taxable + tax;

  return {
    total: Math.round(total * 100) / 100,
    breakdown: { subtotal, discount, taxable, tax }
  };
}

Zwei Gewohnheiten halten das stabil:

• Einmal am Ende runden (nicht mitten in den Berechnungen).
• Immer eine Aufschlüsselung zurückgeben.

Diese Aufschlüsselung zeigt Fehler schnell, zum Beispiel ob Steuer vor Rabatten angewendet wurde.

Schritt für Schritt: Den Rechner mit KI‑Tools bauen, ohne Chaos

Angebotsrechner gehen kaputt, wenn UI und Preisregeln zusammen in derselben Datei wachsen. Trennen Sie sie von Anfang an und Sie finden Fehler früher.

Eine saubere Aufbau‑Reihenfolge

Beginnen Sie damit, die Oberfläche ohne echte Mathematik funktionsfähig zu machen. Generieren Sie nur das Formular und die Anzeige: Eingaben (Tarif, Plätze, Add‑ons, Land) und Ausgaben (Zwischensumme und Endsumme). Wenn Sie Werte eingeben können und sie auf dem Bildschirm erscheinen, haben Sie eine gute Basis.

Fügen Sie dann eine einzige Preisfunktion hinzu und verbinden Sie alles damit. Halten Sie es einfach: eine Funktion nimmt ein plain Objekt mit Eingaben und gibt plain Ergebnisse zurück. Verstecken Sie Berechnungen nicht in Button‑Handlern oder UI‑Komponenten.

Eine Reihenfolge, die ordentlich bleibt:

• Zuerst die UI mit Platzhalterzahlen bauen.
• Eine Preisfunktion erstellen und aus der UI aufrufen.
• Die Funktion eine vollständige Aufschlüsselung zurückgeben lassen: Zwischensumme, Rabatt, Steuer, Endsumme.
• Basisvalidierung für fehlende Felder und negative Werte hinzufügen, mit klaren Fehlermeldungen.
• Regeln in eine einzige Rules‑Datei legen und diese als einzige Änderungsquelle behandeln.

Wenn die Funktion eine Aufschlüsselung liefert, wird die UI im guten Sinne ‚dumm‘: sie rendert nur die Positionen. Reviews werden einfacher, weil Sie die Aufschlüsselung mit einer manuellen Rechnung vergleichen können.

Reale Beispiel‑Eingaben hinzufügen, um Fehler früh zu finden

Der schnellste Weg, Bugs zu übersehen, ist mit erdachten Zahlen zu testen. Reale Angebote haben Kombinationen, an die Sie nicht denken: ein sehr kleiner Auftrag mit Mindestgebühr, ein Auftrag, der eine Stufen‑Grenze überschreitet, oder ein Rabatt, der vor der Steuer gelten soll.

Sammeln Sie 10–20 reale Beispiel‑Eingaben aus Ihrer Preistabelle, früheren Rechnungen oder Angeboten, die Sie schon verschickt haben. Mischen Sie gängige Bestellgrößen mit einigen, bei denen Rabatte, Add‑ons oder Sonderkonditionen genutzt wurden.

Bevor Sie etwas codieren, schreiben Sie neben jedes Beispiel die erwartete Summe. Machen Sie das als menschliche Überprüfung nach denselben Regeln, die Sie dem Rechner gesagt haben. Wenn zwei Personen sich nicht auf die erwartete Summe einigen können, sind Ihre Regeln unklar — nicht Ihre Mathematik.

Hier ein einfaches Set, das Sie als wiederholbare Tabelle behalten können:

Behalten Sie diese Tabelle im Projekt und führen Sie sie nach jeder Änderung erneut aus. Fehlschläge sollten offensichtlich sein: Erwartet vs. Tatsächlich, plus welche Regel ausgelöst hat (Stufe, Rabatt, Steuer, Rundung). Wenn der Rechner nicht erklären kann, warum eine Zahl sich geändert hat, ist er nicht sicher zum Ausliefern.

Schnelle Prüfungen bevor Sie eine Preisänderung ausliefern

Kleine Preisänderungen brechen Rechner öfter, als man denkt. Ein umbenannter Schalter, ein neuer Rabatt‑Toggle oder „nur noch eine Gebühr“ können die Mathematik heimlich ändern.

Eine 10‑Minuten‑Pre‑Ship‑Checkliste

Führen Sie diese Prüfungen aus, wenn Sie Preise, Stufen, Rabatte, Steuern oder das Angebotslayout anfassen:

• Ändern Sie nur UI‑Text (Labels, Hilfetext, Währungssymbol) und bestätigen Sie, dass die Zahlen unverändert bleiben.
• Rechnen Sie 3–5 Angebote von Hand nach und vergewissern Sie sich, dass der Rechner exakt übereinstimmt.
• Bestätigen Sie, dass die Rundungsregeln konsistent sind: pro Position runden oder nur die Endsumme?
• Testen Sie leere Felder, Nullen und negative Werte. Leere Felder sollten „nicht angegeben“ bedeuten, nicht NaN.
• Prüfen Sie, dass die itemisierte Aufschlüsselung zur Endsumme addiert, ohne fehlende Gebühren oder doppelt verrechnete Rabatte.

Nach der Checkliste machen Sie einen „Geruchstest“ mit realistischen Eingaben (z. B.: 3 Plätze, Monatsplan, 10% Rabatt plus Steuer). Wenn Steuer oder Rabatt komisch aussehen, sieht man es meist sofort.

Halten Sie ein kleines Set „Goldener Angebote"

Wählen Sie ein paar repräsentative Angebote und notieren Sie ihre erwarteten Summen. Wenn Sie Preise ändern, führen Sie dieselben Angebote erneut aus und vergleichen.

Eine praktische Auswahl: die kleinste Bestellung, eine typische Bestellung und eine große Bestellung nahe einer Stufen‑Grenze. Fügen Sie ein Beispiel mit Rabatt und eines mit Steuer hinzu. Wenn sich eine Summe unerwartet ändert, hat sich die Preislogik irgendwo ungewollt verändert.

Häufige Fehler, die falsche Angebote produzieren

Der schnellste Weg, Vertrauen zu verlieren, ist, wenn zwei Personen dieselben Details eingeben und unterschiedliche Summen bekommen.

Eine der Hauptursachen ist das Duplizieren von Preisregeln. Sie fügen im Checkout einen 10% Rabatt hinzu, aber die Admin‑Vorschau nutzt eine ältere Formel. Kunden sehen eine Zahl, Rechnungen eine andere.

Ein weiteres häufiges Problem ist, dass Steuern, Rabatte und Rundungen in unterschiedlicher Reihenfolge in verschiedenen Teilen der App ausgeführt werden. Eine kleine Reihenfolgeänderung kann die Summen verschieben, besonders bei Stufen.

Gleitkomma‑Mathematik erzeugt außerdem Cent‑Unterschiede. Wenn Ihre App erwartet, dass 0.1 + 0.2 exakt 0.3 ergibt, können sich kleine Abweichungen summieren, wenn viele Positionen addiert werden.

Die Muster hinter den meisten „mystery math“ Bugs:

• Preisregeln dupliziert über Screens, API‑Routen oder Background‑Jobs
• Rabatte und Steuern in unterschiedlicher Reihenfolge in verschiedenen Teilen der App
• Inkonsistente Rundung statt einer festen, dokumentierten Regel
• Preisänderungen in einer Stelle, aber nicht in gespeicherten Angebots‑/Rechnungslogiken
• Keine klare Aufschlüsselung, sodass nicht sichtbar ist, wo die Zahl sich geändert hat

Zeigen Sie immer eine Aufschlüsselung: Basispreis, Stufen‑Anpassungen, Rabattbetrag, steuerbare Zwischensumme, Steuer und Endsumme. Wenn etwas falsch aussieht, zeigt die Aufschlüsselung, wo Sie suchen müssen.

Edge‑Cases: Stufen, Rabatte, Steuern und Rundung

Die meisten Angebotsfehler verstecken sich in den „kleinen“ Regeln. Ein Rechner kann bei Happy‑Path‑Eingaben richtig aussehen und beim ersten Kauf von 11 Einheiten, der Verwendung eines Coupons oder Zahlung aus einer anderen Region versagen.

Stufen und Caps: wo Summen driften

Stufenpreise brauchen klare Grenzen. Beispiel: „erste 10 Einheiten zu 20 $, jede weitere zu 15 $.“ Entscheiden Sie, was bei genau 10, genau 11 und bei 0 passiert.

Entscheiden Sie außerdem die Reihenfolge der Operationen, wenn Sie Stufen mit Mindestmengen, Caps und Einmalgebühren mischen. Wenn eine Stelle die Obergrenze vor einer Einrichtungsgebühr anwendet und eine andere danach, erhalten Sie bei gleichen Eingaben unterschiedliche Summen.

Rabatte, Steuern und Rundung: wählen Sie eine Reihenfolge und bleiben Sie dabei

Coupons sind eine Falle, weil „10% Rabatt“ nicht dasselbe ist wie „10 $ Rabatt“, und Stapelregeln die Summen schnell ändern. Wenn Coupons ablaufen können, sollte das Angebot zeigen, ob der Coupon akzeptiert wurde und warum.

Steuern variieren nach Region, aber die wichtigste Frage ist einfach: Wird die Steuer vor oder nach Rabatten berechnet? Viele Teams nehmen das eine an und bauen das andere.

Bei Rundung entscheiden Sie, ob Sie pro Position (jede Stufe, jede Gebühr) runden oder nur bei der Endsumme, und wie mit halben Cents umgegangen wird.

Entscheidungen, die es wert sind, festgeschrieben zu werden:

• Sind Stufengrenzen inklusiv (1–10) oder „erste N“‑Logik?
• Stapeln Coupons? In welcher Reihenfolge (Fixbetrag dann Prozent oder umgekehrt)?
• Gilt Steuer auf Einrichtungsgebühren und wird sie vor oder nach Rabatten berechnet?
• Welche Rundungsregel verwenden Sie und wo runden Sie?
• Wenn Sie mehrere Währungen unterstützen, welche Wechselkursquelle und welchen Zeitstempel nutzen Sie?

Konkreter Test: 11 Einheiten, Stufen wie oben, 50 $ Setup, 10% Coupon, 8.25% Steuer nach Rabatt, nur am Ende runden. Wenn Ihr Rechner nicht bei jedem Lauf dieselbe Zahl reproduzieren kann, sind die Regeln noch nicht spezifisch genug.

Ein realistisches Beispielangebot (mit Zahlen) zum Testen Ihrer Logik

Hier ein konkreter Test, den Sie in Ihren Rechner kopieren können. Es ist eine kleine Agentur, die einen Website‑Build mit einigen typischen Add‑ons anbietet.

Nutzen Sie diese Beispiel‑Eingaben (und schreiben Sie die Regeln daneben):

• Basispaket: 2.000 $ (inkl. 5 Seiten)
• Gewünschte Seiten: 8 (3 Extra‑Seiten zu je 150 $)
• Add‑on: CMS‑Einrichtung 300 $
• Rush: 15% Rush‑Gebühr
• Rabattcode: SAVE10 (10% auf Basis + Seiten + Add‑ons, nicht auf Rush)
• Steuer: 8% auf alles (inklusive Rush)

Jetzt die erwartete Aufschlüsselung:

• Basis + Extra‑Seiten + Add‑ons: 2.000 $ + (3 x 150 $) + 300 $ = 2.750 $
• Rabatt (10% von 2.750 $): -275,00 $ -> rabattierte Zwischensumme 2.475,00 $
• Rush‑Gebühr (15% von originalen 2.750 $): +412,50 $ -> steuerbare Zwischensumme 2.887,50 $
• Steuer (8% von 2.887,50 $): +231,00 $
• Endsumme: 3.118,50 $

Hier verbergen sich die üblichen Fehler: die Rush‑Gebühr nicht besteuern oder den Rabatt in der falschen Reihenfolge anwenden (Rabatt nach Steuer oder Rabatt auf Rush, obwohl der Promo das nicht erlaubt).

Wenn die Preislogik in einer Funktion (Single Source of Truth) lebt, können Sie dieses Beispiel als automatisierten Test fixieren. Ändern Sie einen Preis oder fügen Sie eine Regel hinzu, sollten dieselben Eingaben weiterhin 3.118,50 $ ergeben. Wenn sich die Zahl ändert, erkennen Sie die Regression sofort.

Nächste Schritte, wenn Ihr KI‑gebauter Rechner repariert werden muss

Wenn Ihr Rechner in der Demo gut aussah, aber im echten Kundenbetrieb bricht, behandeln Sie es wie einen Produkt‑Bug, nicht als „kleine Rechenanpassung“. Preislogik wird leicht beschädigt, wenn sie sich über UI‑Code, Datenbank‑Trigger und Hilfsfunktionen verteilt.

Anzeichen, dass es mehr als ein kurzer Patch ist

Einige Muster deuten darauf hin, dass der Code eine gründliche Aufräumarbeit braucht:

• Summen ändern sich nach einem Seiten‑Reload oder nach dem Editieren eines Felds
• Unterschiedliche Summen für dieselben Eingaben (oft Rundung oder Steuerreihenfolge)
• Neue Preisregeln fühlen sich „zu riskant“ an, weil alles springen könnte
• Angebote lassen sich nicht speichern oder versenden, weil Auth oder State‑Handling wackelig ist

Wie man Regeln übergibt, damit die Mathematik schnell überprüfbar ist

Sie müssen nicht technisch sein, aber die Regeln müssen testbar übergeben werden. Eine gute Übergabe enthält:

• Eine einseitige Regelzusammenfassung (Eingaben, Formeln, Steuern/Gebühren, Rundungspolicy)
• 5–10 reale Beispielangebote mit erwarteten Summen (inkl. mindestens einem Edge‑Case)
• Was sich kürzlich geändert hat und wann die falschen Summen angefangen haben
• Einschränkungen (Währung, Regionen, Rechnungsanforderungen, Rabattgrenzen)

Wenn der Prototyp zu verknotet ist, kann ein sauberer Neuaufbau des Rechners oft billiger sein, als ihn ewig zu patchen.

Wenn Sie eine KI‑generierte App geerbt haben und jemanden brauchen, der duplizierte Preislogik (und verwandte Produktionsprobleme wie kaputte Auth oder exponierte Secrets) entwirrt, hilft FixMyMess at fixmymess.ai dabei, KI‑gebaute Prototypen produktionsreif zu machen. Ein kurzer Code‑Audit reicht oft, um genau zu zeigen, wo Summen auseinanderlaufen.