„Technologie ist dann am besten, wenn sie unsichtbar im Hintergrund für Sicherheit und Effizienz sorgt.“ In meiner Laufbahn habe ich viele Software-Projekte von 0 auf 100 skaliert und dabei gelernt: Gute Ideen scheitern selten am Konzept, sondern an der praktischen Umsetzung.
Die schönste SaaS-Oberfläche nützt dem Autohändler nichts, wenn am Jahresende der Steuerberater mit einem Stapel Fehlermeldungen in der Tür steht. Wir bei Autaxo bauen deshalb keine „Quick & Dirty“-Tools, sondern entlastende digitale Prozesse. Dieser Beitrag wirft einen Blick in unseren Tech-Stack und unsere technischen Prinzipien.
Kurzdefinition: Die Autaxo-Architektur im Überblick
Kurz zusammengefasst: Autaxo vereint steuerliche Fachlogik und effiziente IT. Shift-Left-Prüfungen bei Datenimporten, eine Security-by-Design-Architektur mit Generalumkehr statt Datenlöschung und intelligente DATEV-Übergaben ohne harte Festschreibung unterstützen einen nachvollziehbaren, an den GoBD ausgerichteten Workflow zwischen Autohaus und Steuerberater.
Kernaussagen (Key Facts)
- Shift-Left-Prinzip: Daten aus Vorsystemen werden sofort beim Import validiert, nicht erst am Monatsende.
- Fehlerprävention: Um finanzmathematische Rundungsfehler in der Cloud abzufangen, nutzen wir hochpräzise Bibliotheken wie
decimal.js. - API-Mapping: Unsaubere Daten externer Plattformen (wie mobile.de) werden vor Systemeingang in buchhalterisch saubere Logiken übersetzt (z. B. MwSt-Flags).
- Security-by-Design: Keine
DELETE-Befehle in der Datenbank für buchhalterische Vorgänge – alles läuft über die Generalumkehr (Storno). - DATEV-Übergabe: Bewusster Verzicht auf harte Festschreibekennzeichen, um dem Steuerberater seinen fachlichen Freiraum zu lassen.
Warum validieren wir Daten schon beim Import (Shift-Left-Prinzip)?
Wir validieren Daten aus Vorsystemen (wie internen DMS oder mobile.de) sofort beim Import, um administrative Fehler und Altlasten vor dem Jahresabschluss konsequent zu verhindern.
Wenn Daten in unsere Cloud-Infrastruktur fließen, wenden wir das sogenannte „Shift-Left“-Prinzip an. Wir prüfen und korrigieren alles so früh wie möglich – ganz links auf dem Zeitstrahl.
- GoBD ab Sekunde eins: Sobald in Autaxo ein Verwaltungsakt passiert, muss dieser vollständig und sauber abgeschlossen sein.
- Präzision: Um finanzmathematische Rundungsfehler, die bei Standard-Datentypen unweigerlich auftreten, zu vermeiden, setzen wir unter der Haube auf präzise Bibliotheken wie
decimal.js. - Open Source: Als SaaS-First-Unternehmen ist es für uns selbstverständlich, offene Technologien zu nutzen und die Projekte, die wir einsetzen, auch als Sponsoren zu unterstützen.
Wie löst Autaxo das Problem unsauberer API-Daten?
Fehlende oder unklare API-Daten externer Plattformen werden durch intelligente Mapping-Logiken automatisch in buchhalterisch korrekte Datensätze übersetzt, bevor sie das System kontaminieren.
Theorie ist gut, aber echte Architektur muss in der Praxis bestehen. Wer Marktplatz-APIs anbindet, weiß: Datenqualität ist dort oft Auslegungssache.
- Das MwSt-Problem: Ein klassisches Beispiel (Shoutout an unseren Experten Paul Bogdan) sind die MwSt-Flags bei Fahrzeugimporten. Ob Regelbesteuerung oder Differenzbesteuerung nach § 25a UStG – für den Händler ist das existenziell.
- Die Lösung: Wir haben in Autaxo spezifische Workarounds implementiert, die auch mangelhafte Datenpakete in eine saubere Logik gießen. Die Komplexität wird reduziert, der Nutzer merkt davon nichts.
Warum nutzt Autaxo die Generalumkehr statt Datenbank-Löschungen?
Um Nachvollziehbarkeit und die GoBD-Anforderungen technisch zu unterstützen, blockieren wir DELETE-Befehle für buchhalterische Vorgänge und korrigieren diese stattdessen über Stornorechnungen.
Als CTO verantworte ich bei Autaxo einen strikten Security-by-Design-Ansatz. Ein typischer Entwickler-Reflex bei falschen Einträgen ist oft ein simples DELETE-Statement in der Datenbank. Das gibt es bei uns nicht.
- Wir spiegeln die Realität: In einem echten Autohaus zerreißt man eine falsch ausgestellte Rechnung nicht einfach, sondern schreibt eine Stornorechnung.
- DATEV-Standards: Indem wir das Prinzip der Generalumkehr tief im Code verankern, bleibt jede Änderung lückenlos nachvollziehbar. Das unterstützt eine prüfbare Dokumentation gegenüber Wirtschaftsprüfern und Finanzverwaltung.
Warum übergeben wir DATEV-Exporte ohne Festschreibekennzeichen?
Wir übergeben Buchungssätze bewusst ohne harte Festschreibung, um dem Steuerberater als Fach-Experten den nötigen Freiraum für finale bilanzielle Korrekturen zu überlassen.
Trotz unserer End-to-End-Verantwortung und der konsequenten Ausrichtung an den GoBD haben wir uns bei der DATEV-Schnittstelle zu diesem bewussten Schritt entschieden. Auf den ersten Blick mag ein fehlender „Lock“ kontraintuitiv wirken, doch es ist eine Frage des Respekts und der Effizienz.
- Klare Rollen: Wir sind die Technik-Experten. Der Steuerberater ist der Profi für die Bilanz.
- Reibungsloser Workflow: Wir zwingen Kanzleien kein starres IT-Korsett auf. Das Vertrauen in die Expertise des Steuerberaters nimmt die Reibung aus der Zusammenarbeit zwischen Software, Mandant und Kanzlei.
FAQ zur Autaxo Architektur & Compliance
Was bedeutet das Shift-Left-Prinzip bei Autaxo? Daten aus Vorsystemen (z.B. DMS oder mobile.de) werden sofort beim Import validiert. Fehler werden behoben, bevor sie in die Buchhaltung einfließen. Das verhindert administrative Altlasten am Jahresabschluss.
Wie unterstützt Autaxo GoBD-konforme Prozesse?
Durch Security-by-Design und das Prinzip der Generalumkehr. In der Datenbank gibt es keine DELETE-Befehle für buchhalterische Vorgänge; Korrekturen erfolgen lückenlos dokumentiert über Stornorechnungen.
Warum verzichtet Autaxo auf das DATEV-Festschreibekennzeichen? Um dem Steuerberater den nötigen fachlichen Freiraum für finale bilanzielle Korrekturen zu überlassen. Autaxo liefert eine nachvollziehbare, an den GoBD ausgerichtete Basis, zwingt der Kanzlei aber kein starres IT-Korsett auf.
Über den Autor
Leonard Niehaus, Co-Founder & CTO bei Autaxo Leonard verantwortet bei Autaxo als CTO End-to-End die Technologie, Architektur und Sicherheit. Als erfahrener SaaS- & Cloud-Architekt hat er sich darauf spezialisiert, Plattformen von 0 auf 100 zu skalieren und komplexe Anforderungen in einfache digitale Prozesse zu übersetzen. Sein Fokus liegt auf modernen Web-Technologien, Cloud-Infrastrukturen und dem Prinzip „Security-by-Design“.
🔗 Leonard Niehaus auf LinkedIn vernetzen