Stellen Sie sich vor: Es ist der 28. des Monats. Ihre Buchhalterin exportiert Rechnungen aus dem CRM, importiert sie manuell ins Faktura-Tool, überträgt die Zahlungseingänge aus dem Banking-Export in die Tabellenkalkulation – und gleicht das alles gegen den Lagerbestand ab, den jemand anders gepflegt hat.
Irgendwo in dieser Kette passiert ein Fehler. Meistens fällt er erst beim Steuerberater auf.
Dieser Artikel zeigt, warum Insellösungen im Mittelstand strukturell fehleranfällig sind, was GoBD-Revisionssicherheit im Alltag wirklich bedeutet und wie eine gemeinsame Datenbasis diesen Aufwand beseitigt.
Eine Studie des Digitalverbands Bitkom schätzt, dass KMU im DACH-Raum durchschnittlich 4,5 Stunden pro Woche mit der manuellen Übertragung von Daten zwischen Softwaresystemen verbringen. Das sind 18 Stunden im Monat – oder etwa zwei bezahlte Arbeitstage.
Rechnen Sie das durch: Bei einem Stundensatz von 35 Euro für eine kaufmännische Fachkraft entstehen allein durch Doppeleingabe rund 630 Euro im Monat. Pro Jahr sind das über 7.500 Euro – für Arbeit, die keinen Mehrwert schafft.
Hinzu kommen die versteckten Kosten:
Die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form (GoBD) klingen abstrakt. Im Betriebsprüfungsalltag sind sie es nicht.
Die GoBD verlangen:
1. Unveränderlichkeit: Eine einmal gebuchte Rechnung darf nicht einfach überschrieben werden. Korrekturen müssen als Stornobeleg erkennbar bleiben.
2. Nachvollziehbarkeit: Jede Änderung an einem Buchungsvorgang muss protokolliert sein – wer hat wann was geändert?
3. Zeitgerechtigkeit: Buchungen müssen zeitnah erfasst werden. Ein Export, der einmal täglich läuft, erfüllt diese Anforderung je nach Auslegung möglicherweise nicht.
In der Praxis scheitern viele KMU bereits an Punkt drei. Wenn das CRM und die Faktura-Software nur einmal täglich synchronisiert werden, liegen zwischen Auftragsannahme und Buchung bis zu 24 Stunden. Bei einer Betriebsprüfung kann das unangenehme Fragen aufwerfen.
Ein kryptographisch verketteter Audit-Trail – bei dem jeder Datensatz einen Hash seines Vorgängers enthält – macht nachträgliche Manipulationen technisch nahezu unmöglich und ist gegenüber dem Prüfer sauber nachweisbar.
Ab dem 1. Januar 2025 müssen Unternehmen im B2B-Bereich in Deutschland E-Rechnungen empfangen können. Ab 2027 – für Unternehmen mit mehr als 800.000 Euro Jahresumsatz bereits ab 2026 – müssen sie auch selbst strukturierte E-Rechnungen ausstellen.
Was bedeutet das konkret?
Eine E-Rechnung im Sinne des Gesetzes ist keine PDF-Datei. Es ist ein maschinenlesbares XML-Dokument, das den europäischen Standard EN 16931 erfüllt. In Deutschland ist das in der Regel XRechnung oder ZUGFeRD.
Das Problem: Viele Rechnungsstellungstools erzeugen zwar XML-Dateien, prüfen sie aber nicht. Eine XRechnung, die formal falsch ist, wird von öffentlichen Auftraggebern und zukünftig auch von privaten Empfangssystemen abgewiesen. Der Auftrag gilt dann als nicht fakturiert – was Ihre Liquidität direkt betrifft.
Die Validierung gegen das KoSIT-Schematron ist der entscheidende Schritt. Das Schematron ist das offizielle Regelwerk der Koordinierungsstelle für IT-Standards und prüft nicht nur die XML-Struktur, sondern auch die fachliche Korrektheit: Stimmen Mehrwertsteuersätze mit den Positionsdaten überein? Sind alle Pflichtfelder korrekt befüllt?
Eine Software, die diese Prüfung nicht vor dem Versand durchführt, gibt Ihnen keine Sicherheit darüber, ob Ihre Rechnungen tatsächlich rechtskonform sind.
Der Begriff wird von vielen Anbietern verwendet. Der Unterschied liegt in der Architektur.
Bei einer echten gemeinsamen Datenbasis gilt: Wenn ein Kundenauftrag im System angelegt wird, wird gleichzeitig der Lagerbestand reserviert, eine Rechnungsvorlage vorbereitet und eine CRM-Aktivität angelegt. Diese Schritte passieren in einer Transaktion, nicht durch nächtliche Synchronisierung.
Bei einem System, das mehrere Einzellösungen über APIs verbindet, gilt: Jede Schnittstelle ist ein potenzieller Fehlerort. Wenn die API-Synchronisierung fehlschlägt, entsteht Datendivergenz. Und die bemerken Sie oft erst, wenn der Schaden entstanden ist.
Praktisches Beispiel: Ein Vertriebsmitarbeiter legt um 14:30 Uhr einen Auftrag über 200 Einheiten an. Das Lager hat noch 180 Einheiten. Bei echter Datenbasis wird das sofort angezeigt. Bei einer API-basierten Verbindung sieht der Mitarbeiter möglicherweise den Lagerstand vom Morgen – und bestätigt den Auftrag.
Prüfen Sie Ihre aktuelle Systemlandschaft mit drei konkreten Fragen:
1. Wie lange dauert es, bis ein neuer Kundenauftrag im Lager, im Faktura-System und im CRM sichtbar ist?
2. Können Sie für jede Buchung der letzten zwölf Monate lückenlos dokumentieren, wer sie wann angelegt und ob jemand sie verändert hat?
3. Validiert Ihr aktuelles System E-Rechnungen vor dem Versand gegen das KoSIT-Schematron?
Wenn eine dieser Fragen Ihnen Unbehagen bereitet, lohnt sich ein genauerer Blick auf Ihre Systemarchitektur – bevor es der Betriebsprüfer tut.
ledgura bietet eine kostenlose Testphase ohne Mindestumsatz und ohne Pflicht-Add-ons. Sie können das System in Ihrer eigenen Infrastruktur betreiben oder im deutschen Rechenzentrum hosten lassen.
---
Viele Buchhaltungsverantwortliche haben den Begriff E-Rechnung in den letzten Monaten oft gehört. Die meisten verbinden damit zunächst eine Rechnung im PDF-Format, die per E-Mail verschickt wird. Das ist falsch – und dieser Irrtum kann teuer werden.
Dieser Artikel erklärt, was E-Rechnung im gesetzlichen Sinne bedeutet, wo die häufigsten Validierungsfehler liegen und wie Sie sicherstellen, dass Ihre Rechnungen nicht abgewiesen werden.
Eine E-Rechnung im Sinne der EU-Richtlinie 2014/55/EU und des deutschen UStG ist ein strukturiertes elektronisches Dokument, das den europäischen Standard EN 16931 erfüllt. In Deutschland haben sich zwei Formate etabliert:
XRechnung: Ein reines XML-Format. Maschinenlesbar, kein menschenlesbares Layout. Wird vor allem von öffentlichen Auftraggebern verlangt. Pflicht für B2G-Rechnungen (Business to Government) seit 2020 beziehungsweise 2021.
ZUGFeRD: Ein hybrides Format. Enthält sowohl ein visuelles PDF/A-3b-Dokument als auch eine eingebettete XML-Datei nach EN 16931. Eignet sich für Unternehmen, die eine menschenlesbare Rechnung und gleichzeitig die maschinelle Verarbeitbarkeit benötigen.
Was ausdrücklich keine E-Rechnung im gesetzlichen Sinne ist: