R&D LAB Methode Im Einsatz Für die eigene Finanzplanung gebaut
Chronos Ledger
Liquiditäts- und Steuerprojektion für eine GmbH, deterministisch gerechnet
Wie viel Geld liegt an welchem Tag auf welchem Konto, und welche Steuern sind bis dahin fällig? Gerechnet nach deutschem Recht, ohne Sprachmodell.
- 0Laufzeitabhängigkeiten, nur Node und SQLite
- 1Zeilenliste, aus der jede Ansicht rechnet
- 12Ansichten auf dieselbe Projektion
- P10bis P90: Band um die Kurve, analytisch gerechnet
Alle Aufnahmen in diesem Artikel zeigen eine separate Demodatenbank mit erfundenen Werten für eine Beispiel GmbH. Personen erscheinen nur mit ihrer Rolle.
Publikationsgrund
Wir verkaufen Software und Automatisierung, auch dort, wo Regeln dicht und folgenreich sind. Chronos Ledger zeigt, wie wir Steuer- und Buchungsregeln in Code übersetzen: jede Regel an einer Stelle, die Steuerarithmetik durch einen Selbsttest abgesichert, die zentralen Summen von einem unabhängigen Prüfskript nachgerechnet. Die Anwendung ist zugleich ein Gegenbeispiel zu der Annahme, dass heute überall ein Sprachmodell hineingehört. Hier gehört keines hinein, weil eine Liquiditäts- oder Steuerzahl bei jedem Aufruf dieselbe sein und sich Schritt für Schritt nachprüfen lassen muss.
Buchhaltung schaut zurück: Sie hält fest, was geschehen ist. Für die Planung eines kleinen Unternehmens fehlt die andere Richtung. Chronos Ledger rechnet nach vorn und beantwortet, wie viel Geld an einem bestimmten Tag auf welchem Konto liegen wird und was bis dahin an Umsatzsteuer, Ertragsteuern und Gehältern fällig wird. Dafür führt die Anwendung Firmen- und Privatkonten nebeneinander, bildet die Umsatzsteuer nach Ist-Versteuerung mit Dauerfristverlängerung ab, rechnet Körperschaftsteuer, Solidaritätszuschlag und Gewerbesteuer, projiziert die Einkommensteuer nach § 32a EStG und verschiebt jede Frist nach § 108 AO auf den nächsten Werktag. Ein Zeitregler rechnet jede Zahl für jedes gewählte Datum neu. Sie läuft lokal mit Node und SQLite und reicht nichts ein.
Die Entscheidung
Eine Steuerzahl, die beim zweiten Aufruf anders ausfällt, ist keine
Für eine Planungsanwendung liegt es heute nahe, ein Sprachmodell einzubauen: eine Frage in Worten, eine Antwort in Worten. Chronos Ledger hat bewusst keines. Eine Liquiditätsprognose wird zur Grundlage von Entscheidungen über Gehälter, Anschaffungen und Steuerrücklagen. Dafür muss dieselbe Datenlage bei jedem Aufruf dieselbe Zahl ergeben, und jede Zahl muss sich auf die Buchungen zurückführen lassen, aus denen sie entstanden ist. Ein Frage-Panel stand zur Wahl und wurde nicht gebaut; es wäre der erste API-Aufruf dieser Anwendung nach außen gewesen.
Die zweite Entscheidung trägt die ganze Anwendung. Für jede Anfrage wird der Planungszeitraum genau einmal als flache Liste datierter Zeilen aufgebaut: gebuchte Bewegungen, aufgelöste Daueraufträge, Gehaltsläufe, die abgeleiteten Umsatzsteuer- und Ertragsteuerzahlungen, freigegebene Investitionen und erwartete Einkommensteuererstattungen. Jedes Diagramm und jede Tabelle wird aus dieser einen Liste berechnet. Zwei Ansichten sollen über denselben Tag nie verschiedener Meinung sein. Als Kopfzeile und Kurve es einmal doch waren, weil zwei Funktionen dieselben Zeilen getrennt durchliefen, hat das Prüfskript den Unterschied gefunden.
Die dritte betrifft die Steuern. Was eine Buchung ist, was die Umsatzsteuer-Voranmeldung von ihr sieht und was die Gewinnermittlung von ihr sieht, sind drei getrennte Spalten. Ein einziger Typ je Buchung kann eine Überweisung zwischen eigenen Konten nicht ausdrücken, die auf zwei Konten Geld bewegt und nirgends Umsatz ist. Kategorien setzen die drei Werte vor, jede Buchung behält aber ihre eigene Kopie.
Was dabei ausdrücklich nicht entsteht, ist eine Steuererklärung. Die Anwendung projiziert und bereitet vor, sie übermittelt nichts an ELSTER, und jede Steueransicht trägt den Hinweis, dass es sich um eine Schätzung handelt.
Eine Prognose, die sich nicht nachrechnen lässt, ist eine Meinung mit Nachkommastellen.
Vom Dauerauftrag zur Kurve
Wie eine Zahl für einen beliebigen Tag entsteht
- 01 Bewegungen und Serien Gebuchte und geplante Bewegungen stehen in derselben Tabelle, ein Status unterscheidet sie. Daueraufträge werden in datierte Einzeltermine aufgelöst und enden am Enddatum, nach einer festen Zahl von Zahlungen oder am Ende des Planungszeitraums. Eine Serie am 31. landet im Februar am 28. und im März wieder am 31.
- 02 Abgeleitete Steuerzahlungen Aus den Zeilen entsteht je Quartal die Zahllast nach Ist-Versteuerung, fällig mit Dauerfristverlängerung am 10. des zweiten Folgemonats und bei Wochenende oder Feiertag am nächsten Werktag. Ertragsteuern werden als Vorauszahlungen auf ihre gesetzlichen Termine gelegt. Ein Vorsteuerüberhang kommt nicht am Fälligkeitstag an, sondern 21 Tage danach.
- 03 Eine Liste Alles zusammen ergibt die eine Zeilenliste. Beträge sind ganze Cent, Datumsangaben ISO-Zeichenketten ohne Zeitzone. Nur der Einkommensteuertarif rechnet in Euro, weil das Gesetz seine Konstanten in Euro nennt.
- 04 Kurve und Band Aus der Liste entsteht die Liquiditätskurve je Konto und gesamt. Jede geplante Zeile ist ein Münzwurf mit ihrer eingetragenen Wahrscheinlichkeit; daraus folgen Erwartungswert, Streuung und ein P10/P50/P90-Band in geschlossener Form, ohne Zufallszahlen. Dieselben Daten zeichnen immer dasselbe Band.
- 05 Zeitregler Der Regler springt zwischen den Tagen, an denen sich tatsächlich Geld bewegt, und den Monatsenden. An jedem Punkt werden Kopfzeile, Kontostände und Forderungskonten neu gerechnet. Die Diagramme dagegen sind zeitlich skaliert, damit der Tiefpunkt dort erscheint, wo er im Kalender liegt.
Umsatzsteuer nach Zahlungsdatum, und nur danach
Unter Ist-Versteuerung entsteht die Umsatzsteuer in dem Zeitraum, in dem das Geld fließt. Die Anwendung speichert deshalb ein Zahlungsdatum und überhaupt kein Rechnungsdatum. Eine zweite Datumsspalte würde früher oder später für eine Summe benutzt, und dann stimmt die Voranmeldung nicht mehr.
Dieselbe Ansicht nennt, was nicht passiert: Ein vierteljährlicher Abgeber mit Dauerfristverlängerung leistet keine Sondervorauszahlung, weil das Elftel nur für monatliche Abgeber gilt. Bei Leistungen ausländischer Anbieter nach § 13b UStG wird die Steuer auf den Betrag gerechnet statt aus ihm heraus und auf beiden Seiten der Voranmeldung erfasst, ohne Wirkung auf Kasse und Zahllast.
An Geld, das keine Leistung ist, kann Umsatzsteuer gar nicht erst hängen. Gehälter, Überweisungen zwischen eigenen Konten, Steuerzahlungen und Darlehen sind in der Rechnung von der Vorsteuer ausgeschlossen, gleich was im Formular angekreuzt wurde.
Was hart im Code steht
Eine Anschaffung wird freigegeben, nicht aufgelistet
Eine geplante Investition bekommt zwei Bedingungen: einen Mindestgewinn nach Steuern im Geschäftsjahr und eine Liquiditätsuntergrenze, die über einen Prüfzeitraum nach der Auszahlung nicht unterschritten werden darf, laufende Monatskosten eingerechnet. Grün wird sie erst, wenn beide gelten.
Die Antwort ist kein Ja oder Nein, sondern ein Datum. Die Anwendung läuft die Kurve vorwärts und nennt den frühesten Tag, ab dem die Liquidität die Auszahlung trägt. Hat eine Investition ein spätestes Datum und wird es verfehlt, gilt sie als verpasst, damit sich eine erledigte Option nicht weiter als offene zeigt.
Szenarien wirken auf dieselbe Rechnung. Investitionen, Daueraufträge und Buchungen lassen sich einem Szenario zuordnen und mit ihm ein- und ausschalten. Wer eine Position aus einem Szenario nimmt, gibt sie an die Grundplanung zurück, statt sie zu löschen.
Nachprüfung
Drei Arten, der eigenen Zahl zu misstrauen
Ein Selbsttest sichert die Arithmetik: Geldbeträge, Fristen mit Verschiebung, Umsatzsteuer, Ertragsteuern, die Zonen des Einkommensteuertarifs, Serien, Ausgleichszeilen und das Unsicherheitsband. Wer einen Satz oder eine Tarifkonstante ändert, ändert im selben Schritt die zugehörige Prüfung. Eine stille Konstantenänderung ist genau der Fehler, den diese Anwendung nicht verkraftet.
Ein Prüfskript rechnet die zentralen Summen ein zweites Mal direkt aus den Rohtabellen, mit eigenem Code: Liquidität heute, Tiefpunkt, Ende des Zeitraums, Umsatzsteuer und Gewinngrundlage. Es meldet außerdem Buchungen, die in sich widersprüchlich sind, etwa einen Abfluss, der als Umsatz klassifiziert ist. Aufschlussreich war, woher die Abweichungen kamen: Mehrfach lag der Fehler im Prüfskript, weil es eine Regel noch nicht kannte, die die Engine schon hatte. Seitdem gehört zu jeder neuen Regel die Frage, ob das Prüfskript sie kennt.
Und die Anwendung zeichnet ihre eigenen Prognosen auf: einmal am Tag, nur Monatsenden, nie überschrieben. Später werden sie gegen das gewertet, was die Konten nach gebuchten Bewegungen tatsächlich hielten, nie gegen eine neuere Prognose. Der Fehler wird als Betrag gemittelt, damit sich ein zu hoher und ein zu niedriger Wert nicht gegenseitig aufheben.
Was es rechnet und was es bewusst nicht tut
Gerechnet
- Liquidität je Konto und gesamt, für jeden Tag im Planungszeitraum.
- Umsatzsteuer je Quartal mit Fristen, Verschiebung und Reverse Charge.
- Körperschaftsteuer, Solidaritätszuschlag, Gewerbesteuer und ihre Vorauszahlungstermine.
- Eine projizierte Einkommensteuer nach § 32a EStG mit erwarteter Erstattung.
- Den frühesten Tag, an dem eine Investition beide Bedingungen erfüllt.
- Ein P10/P50/P90-Band aus eingetragenen Wahrscheinlichkeiten.
Bewusst nicht
- Keine Übermittlung an ELSTER und keine Steuerberatung. Eingereicht wird woanders.
- Keine doppelte Buchführung. Die Anwendung projiziert, sie bucht nicht.
- Keine Lohnsteuer aus dem Brutto. Die Zahlen der Lohnabrechnung werden übernommen.
- Kein Sprachmodell, keine Simulation mit Zufallszahlen.
- Keine Korrelation zwischen Zahlungen im Band. Hängen Ausfälle zusammen, ist die echte Streuung größer, und das steht neben dem Band.
- Kein Verlustvortrag. Ein Verlust ergibt derzeit schlicht keine Steuer.
Personen und Tabelle, mit erfundenen Daten
Wofür diese Bauweise taugt
- Kleine Kapitalgesellschaften, die sehen wollen, ob Gehälter, Rücklagen und Steuertermine in den kommenden Monaten zusammenpassen.
- Entscheidungen über Anschaffungen, die an Gewinn und Liquidität geknüpft sind statt an ein Gefühl.
- Fachanwendungen mit dichten gesetzlichen Regeln, bei denen jede Zahl reproduzierbar und nachvollziehbar sein muss.
- Als Vorlage: ein Regelwerk als Code, mit Selbsttest und unabhängigem Prüfskript, auch jenseits von Steuern.
Publikationsgrund
Was das für Ihr Projekt heißt
Weiteres aus dem Lab
Methode Event Scout Ein Sprachmodell liest die Veranstaltungsseiten, alles andere ist festes Programm. Übrig bleibt eine kurze Liste, wo sich ein Tag vor Ort lohnt. 
Angewandte Forschung Vellum Kanten, Perspektive, Licht und Text werden auf dem Telefon berechnet. Ein Dokument verlässt das Gerät erst, wenn jemand es sendet. Haben Sie ein Regelwerk, das bisher in einer Tabellenkalkulation lebt und dessen Zahlen jemand nachprüfen können muss? Genau dafür gibt es einen Piloten.
Kontakt aufnehmen