Löschkonzept über Systemgrenzen: Shop, ERP, Buchhaltung

Der Grund liegt in der Architektur, nicht in der Sorgfalt. Eine Kopplung zwischen Shop und ERP erzeugt Kopien, das ist ihr Zweck. Jede Kopie liegt danach in einem System mit eigener Datenhaltung, eigener Sicherung, eigenen Berechtigungen und, das ist der entscheidende Punkt, eigener Rechtsgrundlage für die Speicherung. Der Shop speichert das Kundenkonto, weil der Vertrag es erfordert. Das ERP speichert denselben Namen, weil er auf einem Handelsbrief steht. Die Buchhaltung speichert ihn ein drittes Mal, weil er Teil eines Buchungsbelegs ist. Drei Systeme, drei Gründe, drei Fristen.

Ein Löschkonzept, das diese drei Antworten nicht kennt, kann sie auch nicht abarbeiten. Es scheitert typischerweise nicht an der Technik, sondern daran, dass niemand je aufgeschrieben hat, welche Kopie aus welchem Grund liegt. Der erste Arbeitsschritt ist deshalb eine Bestandsaufnahme der Felder, nicht der Systeme. Wie sich Feldzuordnungen über Systemgrenzen hinweg überhaupt beschreiben lassen, zeigt der Beitrag zum Daten-Mapping zwischen ERP und Shop; dieselbe Aufstellung ist die Grundlage für jede Löschentscheidung.

Die Verkürzung der Belegfrist von zehn auf acht Jahre stammt aus dem Vierten Bürokratieentlastungsgesetz, verkündet am 29. Oktober 2024 (BGBl. 2024 I Nr. 323). Für Löschkonzepte ist weniger die Zahl interessant als die Übergangsregel. Nach Art. 97 § 19a Abs. 2 EGAO gilt die neue Fassung erstmals für alle Unterlagen, deren Aufbewahrungsfrist nach dem bis einschließlich 31. Dezember 2024 geltenden Recht noch nicht abgelaufen war. Die Verkürzung greift damit in den vorhandenen Bestand: Belege, die unter der alten Zehnjahresregel abgelegt wurden und deren Frist noch lief, dürfen zwei Jahre früher entfernt werden.

Ein Archiv, das weiterhin nach zehn Jahren räumt, speichert zwei Jahrgänge länger als erforderlich, und das ist unter dem Grundsatz der Speicherbegrenzung kein neutraler Zustand. Für einen Teil der Wirtschaft gilt die Verkürzung allerdings nicht: Art. 97 § 19a Abs. 3 EGAO nimmt drei Gruppen von Steuerpflichtigen aus, und das Handelsrecht führt für dieselben drei Gruppen zehn Jahre (§ 257 Abs. 4 HGB) für Buchungsbelege ausdrücklich fort. Wer als Shopbetreiber an ein solches Haus liefert, ist davon nicht betroffen; wer selbst dazugehört, belegt die Löschklasse für Buchungsbelege abweichend. Die drei Gruppen sind im Gesetz benannt:

Ein Löschkonzept, das jede Datenart einzeln bewertet, ist nach der dritten Schnittstelle kaum noch pflegbar. Praktikabel wird es über Löschklassen: eine überschaubare Zahl von Regeln, die jeweils eine Frist, einen Fristbeginn, eine Rechtsgrundlage und ein führendes System bündeln. Jede Tabelle, jedes Feld und jede Datei im Verbund wird genau einer Klasse zugeordnet. Der Vorteil zeigt sich beim nächsten Systemwechsel: Eine neue Anbindung erbt Klassen, statt eine neue Bewertungsrunde auszulösen. In einem Verbund aus Shop, ERP und Buchhaltung deckt erfahrungsgemäß bereits ein kleiner Satz von Klassen den größten Teil des Bestands ab.

Die Klasse gehört in eine maschinenlesbare Datei und nicht in eine Präsentation, denn sie soll später von einem Prüflauf gelesen werden. Ein tragfähiger Satz enthält je Klasse eine stabile Kennung, die Frist in Jahren, den Anknüpfungspunkt für den Fristbeginn, die Rechtsgrundlage im Klartext und das System, das den Ablauf berechnet. Wo die Frist aus der Zweckbindung folgt und nicht aus einem Gesetz, tritt an die Stelle der Jahreszahl ein Ereignis: Vertragsende, Widerruf, letzter Kontakt. Die Middleware ist der natürliche Ort für diese Datei, weil sie ohnehin alle beteiligten Systeme kennt.

Zwischen Löschen und Behalten liegt ein dritter Zustand, den viele Systeme technisch beherrschen und organisatorisch übersehen: die Einschränkung der Verarbeitung. Sie ist zunächst ein Recht der betroffenen Person (Art. 18 Abs. 1 DSGVO). Das Bundesdatenschutzgesetz macht sie zusätzlich zum Ersatz für die Löschung, wenn diese bei nicht automatisierter Verarbeitung nur mit unverhältnismäßig hohem Aufwand möglich wäre und das Interesse der betroffenen Person an der Löschung als gering anzusehen ist (§ 35 Abs. 1 BDSG), und nach § 35 Abs. 3 BDSG auch dann, wenn einer Löschung satzungsgemäße oder vertragliche Aufbewahrungsfristen entgegenstehen. Für den Systemverbund heißt das: Der Datensatz bleibt liegen, ist aber für jede Verwendung außerhalb der Aufbewahrung gesperrt.

Technisch ist das ein Kennzeichen am Datensatz, kein eigener Ordner. Ein separater Archivmandant oder ein Export in eine zweite Datenbank verlagert das Problem nur, denn dort gelten dieselben Fristen und dieselben Zugriffsregeln. Sinnvoll ist ein Sperrkennzeichen, das die angeschlossenen Prozesse tatsächlich auswerten: Werbeselektion, Empfehlungslogik, Auswertungen, Exportlisten, Suchindex des Shops. Wird das Kennzeichen nur in der Oberfläche des ERP angezeigt, ist es Dekoration.

Die Belastungsprobe eines Löschkonzepts ist die Anfrage einer betroffenen Person, denn sie hat eine Frist. Der Verantwortliche stellt die Informationen über die ergriffenen Maßnahmen unverzüglich zur Verfügung, in jedem Fall aber innerhalb eines Monats (Art. 12 Abs. 3 DSGVO) nach Eingang des Antrags. Diese Frist kann um weitere zwei Monate (Art. 12 Abs. 3 DSGVO) verlängert werden, wenn Komplexität und Anzahl der Anträge es erfordern, und über die Verlängerung ist innerhalb des ersten Monats zu unterrichten. Ein Monat klingt großzügig, solange die Antwort aus einem System kommt. Über drei Systeme hinweg vergeht die Hälfte davon regelmäßig damit, überhaupt zu klären, wer wo nachsieht.

Der Ausweg ist derselbe wie beim Löschen: ein Vorgang, ein Weg, Quittungen aus jedem System. Praktisch bewährt sich ein Auskunftslauf, der dieselbe Nachrichtenstrecke nutzt und je System eine strukturierte Antwort zurückgibt, also gefundene Datensätze, zugeordnete Löschklasse, berechnetes Fristende und Sperrstatus. Aus dieser Antwort entsteht sowohl die Auskunft an die Person als auch der interne Nachweis. Liegen Kundendaten zusätzlich in einem CRM, gehört es in dieselbe Strecke; welche Felder dabei entstehen, zeigt der Beitrag zur CRM-Anbindung an den Shop.

Der Aufbau lässt sich in eine Reihenfolge bringen, die ohne Projektstillstand auskommt. Sie beginnt bei der Bestandsaufnahme und endet bei einem wiederholbaren Lauf, und sie berührt an keiner Stelle den laufenden Verkauf. Erfahrungsgemäß ist der zweite Schritt der aufwendigste, weil dort die fachliche Zuordnung stattfindet; die technischen Schritte drei und vier sind vergleichsweise geradlinig, sobald die Klassen stehen. Welche Leistungen dabei ineinandergreifen, fasst die Übersicht der Leistungen zusammen.

Der Zeitpunkt für den vierten Schritt ist selten willkürlich. Da fast alle Fristen mit dem Schluss des Kalenderjahrs beginnen, fällt der erste scharfe Lauf sinnvollerweise in die Wochen nach dem Jahreswechsel, also in dieselbe Phase, in der ohnehin Bestände abgeglichen werden; wie sich diese Phase über die Schnittstellen planen lässt, beschreibt der Beitrag zu Inventur und Jahreswechsel. Für die Buchhaltung gilt dabei dasselbe Prinzip wie beim Belegtransfer selbst: Die DATEV-Anbindung bestimmt mit, welche Belege überhaupt beim Steuerberater ankommen, und die dafür nötigen Formate beschreibt der Beitrag zur DATEV-Automatisierung im E-Commerce. Wer zusätzlich auf die E-Rechnung umstellt, sollte die Löschklassen gleich mitziehen; der Beitrag zur Rechnungspflicht ab 2027 ordnet die Termine ein.