GoBD-Compliance in der App-Entwicklung: Was wir bei ladekosten.app gelernt haben

Eine Lade-App bauen kann jeder. Eine GoBD-konforme nicht.

Als wir mit ladekosten.app angefangen haben, war die Idee simpel: Ladekosten für E-Autos dokumentieren, damit Selbstständige ihre Heimladungen steuerlich absetzen können. Klingt nach einem Wochenendprojekt. Wurde es nicht.

Denn sobald eine App steuerlich relevante Daten verarbeitet, gelten die GoBD - die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form. Und die ändern alles.

Was die GoBD von einer App verlangen

Die meisten Entwickler kennen GoBD vom Hörensagen. "Irgendwas mit Aufbewahrungspflicht." In Wirklichkeit sind es sechs Prinzipien, die sich direkt auf Ihre App-Architektur auswirken:

Nachvollziehbarkeit. Jede Buchung muss von der Entstehung bis zur Auswertung lückenlos nachvollziehbar sein. In einer App bedeutet das: Jeder Ladeeintrag braucht einen vollständigen Audit Trail.

Nachprüfbarkeit. Ein sachverständiger Dritter muss die Daten in angemessener Zeit prüfen können. Ihre Datenstruktur muss also nicht nur funktionieren - sie muss lesbar sein.

Unveränderbarkeit. Das ist der Punkt, an dem die meisten App-Projekte scheitern. Einmal erfasste Daten dürfen nicht verändert werden. Keine Updates auf bestehende Datensätze. Keine "mal eben korrigieren".

Vollständigkeit. Alle Geschäftsvorfälle müssen lückenlos erfasst werden. Keine fehlenden Einträge, keine Lücken in der Nummerierung.

Richtigkeit. Die Erfassung muss den tatsächlichen Vorgang abbilden. Klingt banal, hat aber massive Auswirkungen auf die UX.

Zeitgerechtheit. Buchungen müssen zeitnah erfasst werden. Nicht nächsten Monat. Nicht "wenn ich dran denke".

Wie wir das technisch gelöst haben

Unveränderbarkeit ohne Cloud

Die größte Herausforderung: ladekosten.app funktioniert zu 100% offline. Keine Cloud, keine Server, alle Daten bleiben auf dem Gerät. Das war eine bewusste Entscheidung - Datenschutz ist für unsere Nutzer nicht verhandelbar.

Aber wie garantiert man Unveränderbarkeit ohne zentrale Instanz?

Unsere Lösung: Jeder Ladeeintrag wird einmal geschrieben und nie überschrieben. Korrekturen erzeugen einen neuen Datensatz, der den alten referenziert. So entsteht eine lückenlose Änderungshistorie - ähnlich wie bei einer Blockchain, nur ohne den Overhead.

Das klingt simpel. Die Implementierung war es nicht. Jede UI-Interaktion, die intuitiv nach "bearbeiten" aussieht, ist im Backend ein "neu anlegen mit Referenz". Der Nutzer sieht einen Bearbeiten-Button. Das System erstellt einen Korrekturbuchung.

DATEV-Export: Die Brücke zum Steuerberater

Eine GoBD-konforme App nützt nichts, wenn die Daten nicht beim Steuerberater ankommen. Also haben wir einen DATEV-CSV-Export gebaut.

DATEV-CSV klingt harmlos. Ist es nicht. Das Format hat Eigenheiten, die nirgendwo vernünftig dokumentiert sind. Feldlängen, Zeichencodierung, Pflichtfelder die je nach Kontext optional sind - wir haben drei Iterationen gebraucht, bis der Export zuverlässig in jeder DATEV-Version importiert werden konnte.

Lektion gelernt: Wenn Ihre App mit Steuerberatern oder Buchhaltungssystemen zusammenarbeiten soll, planen Sie für den Export genauso viel Zeit ein wie für die Kernfunktion. Mindestens.

Die 34-Cent-Pauschale und ihre Tücken

Für Heimladungen von E-Dienstwagen gibt es eine Pauschale: 34 Cent pro kWh. Das Finanzamt akzeptiert diesen Wert ohne Einzelnachweis - solange die Dokumentation stimmt.

Klingt einfach? Ist es auch. Bis Sie die Randfälle entdecken:

• Was passiert bei einem Stromtarifwechsel mitten im Monat?
• Wie dokumentiert man gemischte Ladungen (privat und dienstlich)?
• Was, wenn die Wallbox die kWh-Daten nicht sauber übergibt?

Jeder dieser Fälle erfordert eine Entscheidung: Automatisch lösen oder den Nutzer fragen? Zu viel Automatik und Sie riskieren falsche Buchungen. Zu viele Nachfragen und die App wird unbenutzbar.

Wir haben uns für einen Mittelweg entschieden: Automatisch erfassen, manuell bestätigen. Die App schlägt vor, der Nutzer nickt ab. So bleibt die Richtigkeit gewahrt, ohne dass die UX leidet.

Was das für Ihr App-Projekt bedeutet

Sie müssen keine Lade-App bauen, um von unseren Erfahrungen zu profitieren. Die Prinzipien gelten für jede App, die mit regulierten Daten arbeitet:

1. Compliance ist Architektur, nicht Feature

GoBD-Compliance lässt sich nicht nachträglich einbauen wie ein Dark Mode. Die Unveränderbarkeit von Daten muss von Tag eins in der Datenbankstruktur verankert sein. Wer das nachträglich umbaut, schreibt die App im Grunde neu.

Praktisch heißt das: Bevor Sie eine einzige Zeile Code schreiben, klären Sie die regulatorischen Anforderungen. Sprechen Sie mit einem Steuerberater. Lesen Sie die relevanten BMF-Schreiben. Ja, das ist langweilig. Ja, das ist notwendig.

2. Offline-First und Compliance schließen sich nicht aus

"Für GoBD brauchen Sie eine Cloud-Lösung." Diesen Satz haben wir oft gehört. Er ist falsch.

ladekosten.app beweist, dass revisionssichere Datenhaltung auch lokal funktioniert. Der Schlüssel ist ein sauberes Datenmodell mit Append-Only-Logik und kryptographischen Prüfsummen. Keine Raketenwissenschaft - aber auch nichts, was man mal eben am Freitagnachmittag implementiert.

3. UX und Compliance sind Verhandlungssache

Die größte Gefahr bei regulierten Apps: Sie bauen die App für den Prüfer, nicht für den Nutzer. Jedes Pflichtfeld, jede Bestätigung, jeder zusätzliche Schritt kostet Sie Nutzer.

Bei ladekosten.app haben wir jeden Compliance-Flow dreimal überarbeitet. Nicht um die Anforderungen aufzuweichen, sondern um sie unsichtbar zu machen. Der Nutzer soll Ladekosten dokumentieren - nicht das Gefühl haben, eine Steuererklärung auszufüllen.

4. Testen Sie mit echten Daten und echten Steuerberatern

Unit Tests reichen nicht. Wir haben den DATEV-Export mit fünf verschiedenen Steuerberaterkanzleien getestet. Jede hatte eine andere DATEV-Version, andere Import-Workflows, andere Erwartungen an das Format.

Erst als alle fünf bestätigt haben, dass der Import reibungslos funktioniert, haben wir das Feature released. Das hat zwei Wochen extra gekostet. Es war jede Minute wert.

Die ehrliche Bilanz

ladekosten.app hat dreimal so lange gedauert wie ursprünglich geplant. Nicht wegen der Kernfunktion - Ladekosten erfassen ist technisch trivial. Sondern wegen der Compliance.

War es das wert? Absolut. Die App hat aktuell über tausend aktive Nutzer, die sich darauf verlassen, dass ihre Daten einer Betriebsprüfung standhalten. Dieses Vertrauen kann man nicht nachträglich einbauen.

Und genau das ist die Lektion: Wenn Sie eine App bauen, die mit regulierten Daten arbeitet, planen Sie die Compliance nicht als Phase drei ein. Planen Sie sie als Phase null.

---

Sie planen eine App mit regulatorischen Anforderungen? Sprechen Sie mit uns - wir teilen unsere Erfahrungen aus ladekosten.app und beraten Sie ehrlich, welche Compliance-Anforderungen auf Sie zukommen.