Ein Systemwechsel scheitert selten an der neuen Software. Er scheitert an dem, was aus der alten mitkommen soll: die Auftragshistorie von zwölf Jahren, Kundenstammdaten in drei Schreibweisen, Artikelnummern mit führenden Nullen und ein Bemerkungsfeld, in das über Jahre alles geschrieben wurde, wofür es kein eigenes Feld gab. Wer die Datenübernahme als letzten Punkt der Projektliste behandelt, merkt am Umstellungswochenende, dass sie das größte Einzelrisiko war. Dieser Beitrag beschreibt den Weg, der sich im Mittelstand bewährt hat: Bestandsaufnahme vor Technik, bewusste Auswahl statt Übernahme aller Datensätze, dokumentierte Feldzuordnung, mindestens zwei Probeläufe, ein nachprüfbarer Abgleich der Summen und ein Stichtag mit geregeltem Nachlauf. Am Ende steht die Frage, die im Zweifel eine Prüferin stellt: Womit belegen Sie, dass die Übernahme vollständig war? Wie ein Altsystem geordnet abgelöst wird, hängt an dieser Antwort.
Das Wichtigste in Kürze
- Die Datenübernahme ist der Teil eines Systemwechsels mit dem höchsten Risiko und dem geringsten Vorlauf: Sie wird meist zuletzt geplant, obwohl sie darüber entscheidet, ob der Stichtag hält.
- Vor jeder technischen Umsetzung steht die Bestandsaufnahme: welche Datenbestände es überhaupt gibt, wer sie fachlich verantwortet, wie viele Datensätze sie umfassen und welche davon im Tagesgeschäft noch bewegt werden.
- Es ist keine Schwäche, Daten zurückzulassen — Karteileichen, Dubletten und Testdatensätze verteuern die Übernahme und belasten das neue System; historische Bestände gehören häufig in ein Lesearchiv statt in den produktiven Datenbestand.
- Die Feldzuordnung gehört schriftlich festgehalten, Feld für Feld, samt Umrechnungsregel und Umgang mit Feldern ohne Entsprechung; sie ist zugleich die Grundlage für die spätere Verfahrensdokumentation.
- Belegt wird die Vollständigkeit über drei Ebenen: Anzahl der Datensätze, fachliche Summen wie offene Posten oder Lagerbestände und Stichproben einzelner Vorgänge — jede unerklärte Abweichung verschiebt den Stichtag.
Warum die Datenübernahme das eigentliche Risiko ist
In den meisten Ablöseprojekten ist die Auswahl des neuen Systems der Teil, über den am längsten gesprochen wird. Funktionslisten werden verglichen, Vorführungen angesehen, Angebote geprüft. Die Datenübernahme taucht in der Angebotsphase oft als eine einzige Zeile auf: Datenmigration nach Aufwand. Genau diese Zeile entscheidet später darüber, ob der geplante Termin hält. Der Grund ist einfach: Das neue System lässt sich vorführen, den eigenen Datenbestand kann niemand vorführen — den kennt nur, wer ihn öffnet und Zeile für Zeile ansieht.
Gewachsene Datenbestände sind selten so geordnet, wie die Beteiligten annehmen. Über Jahre entstehen Behelfslösungen: Ein Kunde wird zweimal angelegt, weil die Suche ihn nicht gefunden hat. Eine Sonderkondition steht im Bemerkungsfeld, weil das System dafür kein Feld hat. Eine Artikelgruppe wird zweckentfremdet, um eine Auswertung zu ermöglichen. Nichts davon ist falsch gemacht worden — es war der Weg, den das alte System offen gelassen hat. Bei der Übernahme trifft dieser gewachsene Bestand jedoch auf ein System mit strengeren Regeln, und dort fällt jede Behelfslösung einzeln auf.
Dass solche Wechsel häufiger werden, hat einen einfachen Hintergrund: Für einzelne Aufgaben werden zunehmend spezialisierte Anwendungen genutzt, und ältere Gesamtlösungen erreichen das Ende ihrer Wartung. Die Europäische Kommission hat für 2030 das Ziel gesetzt, dass 75 Prozent (Europäische Kommission) der Unternehmen in der EU Cloud-Dienste, Datenanalyse oder Künstliche Intelligenz nutzen. In Deutschland sind mehr als 99 Prozent (Statistisches Bundesamt) der Unternehmen kleine und mittlere Unternehmen — sie führen solche Wechsel ohne eigene Projektabteilung durch, meist neben dem Tagesgeschäft. Umso wichtiger ist ein Vorgehen, das ohne Stabsstelle funktioniert.
Drei Begriffe, die oft vermischt werden
Bestandsaufnahme: Was liegt überhaupt im Altsystem?
Der erste Schritt ist unspektakulär und wird trotzdem regelmäßig übersprungen: eine Liste aller Datenbestände, die für den Betrieb relevant sind. Relevant heißt nicht „liegt in der Hauptdatenbank". Zu einem Auftragssystem gehören in der Praxis Nebenablagen, die niemand als System bezeichnet: eine Tabellenkalkulation mit Sonderpreisen, ein Ordner mit unterschriebenen Verträgen, ein Postfach mit Lieferantenbestätigungen, eine handgepflegte Liste mit Ansprechpartnern. Wird das übersehen, entsteht nach dem Stichtag genau dort die Lücke, weil das neue System diese Daten voraussetzt.
Für jeden gefundenen Bestand werden wenige Angaben festgehalten. Sie klingen banal, ersparen aber später Rückfragen und machen den Aufwand überhaupt erst schätzbar. Erfahrungsgemäß dauert diese Aufnahme in einem Betrieb mit einem Hauptsystem und einigen Nebenablagen ein bis drei Arbeitstage — deutlich weniger, als die Klärung derselben Fragen unter Zeitdruck kurz vor der Umstellung kostet (Projekterfahrung).
- Bezeichnung und Speicherort: In welchem System oder in welcher Ablage liegt der Bestand tatsächlich?
- Fachliche Verantwortung: Wer entscheidet inhaltlich, was richtig ist, wenn zwei Werte widersprechen?
- Umfang: Wie viele Datensätze sind es, und wie viele davon wurden in den letzten zwei Jahren bewegt?
- Abhängigkeiten: Welche anderen Bestände verweisen darauf, etwa Aufträge auf Kunden oder Positionen auf Artikel?
- Exportweg: Lässt sich der Bestand geordnet ausgeben, und in welchem Format und Zeichensatz?
- Pflichten: Unterliegt der Bestand Aufbewahrungspflichten oder enthält er personenbezogene Daten?
Die letzte Frage der Liste wird gern verschoben und gehört an den Anfang. Personenbezogene Daten von Beschäftigten, Bewerberinnen oder Kunden dürfen nicht ohne Weiteres in ein neues System kopiert werden, nur weil sie technisch verfügbar sind; hier gelten Zweckbindung und Löschfristen weiter. Ebenso gehören Bestände mit steuerlicher oder handelsrechtlicher Aufbewahrungspflicht gesondert betrachtet. Beides sollte im Einzelfall fachlich geprüft werden — dieser Beitrag ersetzt keine Rechtsberatung. Wer die Bestandsaufnahme ohnehin im Rahmen einer Prozessanalyse durchführt, erhält die Antworten meist als Nebenprodukt.
Nicht alles mitnehmen — und warum das kein Verlust ist
Der verbreitete Reflex lautet: Wir nehmen sicherheitshalber alles mit. Er ist verständlich und teuer. Jeder zusätzliche Datensatz muss zugeordnet, umgerechnet, geprüft und im Fehlerfall einzeln geklärt werden. Ein Bestand mit vielen Karteileichen erzeugt in der Prüfung mehr Arbeit als der aktive Teil, weil gerade die alten Datensätze die unvollständigsten sind: fehlende Umsatzsteuer-Identifikationsnummern, Adressen ohne Land, Artikel ohne Maßeinheit. Diese Datensätze fallen im Probelauf als Fehler auf und binden Zeit, die für die aktiven Bestände fehlt.
Dazu kommt der Dauereffekt: Was übernommen wird, erscheint danach in jeder Suche, jeder Auswahlliste und jeder Auswertung des neuen Systems. Ein Vertrieb, der bei der Kundensuche durch dreitausend inaktive Einträge blättert, verliert an jedem Arbeitstag Zeit — und die Akzeptanz für das neue System sinkt in den ersten Wochen, in denen sie am wichtigsten ist. Die Auswahl ist deshalb keine Sparmaßnahme, sondern eine Qualitätsentscheidung. Sie sollte fachlich getroffen und schriftlich begründet werden, damit später nachvollziehbar bleibt, warum ein Bestand nicht im neuen System steht.
| Datenart | Übliche Entscheidung | Begründung |
|---|---|---|
| Offene Aufträge und Bestellungen | Übernehmen | Werden nach dem Stichtag im neuen System weiterbearbeitet |
| Lagerbestände zum Stichtag | Übernehmen | Grundlage für Disposition und Inventurwert ab dem ersten Tag |
| Stammdaten mit Bewegung in 24 Monaten | Übernehmen | Aktiver Bestand, wird im Tagesgeschäft gebraucht |
| Laufende Verträge, Preise, Konditionen | Übernehmen | Ohne sie entstehen ab dem Stichtag falsche Belege |
| Belegdaten unter Aufbewahrungspflicht | Übernehmen oder revisionssicher archivieren | Der Zugriff muss über die gesamte Frist möglich bleiben |
| Stammdaten ohne Bewegung seit Jahren | Zurücklassen, bei Bedarf einzeln nacherfassen | Erzeugt Prüfaufwand und stört später jede Suche |
| Dubletten und Testdatensätze | Vor der Übernahme bereinigen | Werden sonst mitgenommen und im neuen System verfestigt |
| Auftragshistorie älterer Jahre | In ein Lesearchiv statt in den Produktivbestand | Auskunftsfähigkeit bleibt, ohne das neue System zu belasten |
Feldzuordnung: von Spalte zu Spalte
Die Feldzuordnung ist das Herzstück der Übernahme und zugleich der Teil, der am häufigsten mündlich bleibt. Sie beantwortet für jedes Feld des alten Systems drei Fragen: In welches Feld des neuen Systems geht der Inhalt? Muss er dabei umgerechnet oder umgeformt werden? Und was passiert, wenn das Feld leer oder ungültig ist? Solange diese Antworten nur im Kopf einer Person stehen, ist die Übernahme weder prüfbar noch wiederholbar — und wiederholt wird sie mit Sicherheit, denn kein Probelauf läuft auf Anhieb durch.
Praktisch führt man die Zuordnung als Tabelle mit einer Zeile je Feld. Wichtig sind die Umformungsregeln, denn dort steckt die eigentliche Arbeit: führende Nullen entfernen oder erhalten, Vor- und Nachname trennen oder zusammenführen, Datumsformate vereinheitlichen, Beträge mit Punkt oder Komma, Mengeneinheiten umrechnen, Textlängen kürzen. Jede dieser Regeln ist für sich klein. In Summe entscheiden sie darüber, ob die Daten im neuen System auswertbar sind oder ob dort in zwei Jahren dieselben Behelfslösungen wieder entstehen.
Altsystem Neues System Regel
-------------------------------------------------------------------------------
KUNDENNR (Text, 8) kunde.nummer führende Nullen entfernen
NAME1 + NAME2 kunde.name zusammenführen, Trennzeichen Leerzeichen
STRASSE adresse.strasse Hausnummer in eigenes Feld abtrennen
PLZORT (Text, 40) adresse.plz / .ort am ersten Leerzeichen trennen
USTID kunde.ust_id Leerzeichen entfernen, Großbuchstaben
ZAHLZIEL (Zahl, Tage) kunde.zahlungsziel unverändert
SPERRKZ (X oder leer) kunde.gesperrt X wird wahr, leer wird falsch
BEMERKUNG (Freitext) kunde.notiz übernehmen, nicht maschinell auswerten
RABATTGRUPPE — keine Entsprechung, siehe KlärlisteZur Zuordnung gehört eine zweite Liste: die Klärliste. Dort stehen alle Felder, für die noch keine Entscheidung getroffen wurde, jeweils mit verantwortlicher Person und Frist. Eine Übernahme, deren Klärliste am Tag des Probelaufs noch Einträge enthält, ist nicht bereit für den Stichtag. Welche Systeme später welche Felder führen, ist übrigens eine eigene Frage: Sie gehört in die Datenintegration und sollte entschieden sein, bevor der erste Datensatz kopiert wird.
Felder ohne Entsprechung: vier mögliche Wege
In jedem Projekt gibt es Felder, für die das neue System keinen Platz vorsieht. Das ist der Moment, in dem Übernahmen entgleisen — nicht weil die Entscheidung schwierig wäre, sondern weil sie vertagt wird. Vier Wege stehen zur Verfügung, und jeder ist in bestimmten Fällen richtig. Wichtig ist nur, dass für jedes betroffene Feld einer davon bewusst gewählt und notiert wird.
In ein vorhandenes Feld überführen
Häufig existiert im neuen System ein Feld mit ähnlicher Bedeutung, etwa eine Kategorie statt einer Kennziffer. Dann wird eine Übersetzungstabelle angelegt: alter Wert links, neuer Wert rechts. Das ist der sauberste Weg, weil die Information auswertbar bleibt.
Als zusätzliches Feld anlegen
Wenn die Information fachlich gebraucht wird und keine Entsprechung hat, wird im neuen System ein eigenes Feld eingerichtet. Das kostet Aufwand und sollte begründet sein, sonst entsteht dort mit der Zeit derselbe Wildwuchs wie im alten System.
In ein Notizfeld sichern
Für Inhalte, die nur gelegentlich gelesen und nie ausgewertet werden, genügt eine Notiz am Datensatz. Der Inhalt geht nicht verloren, ist aber bewusst nicht auswertbar — das sollte allen Beteiligten vorher klar sein.
Bewusst weglassen
Manche Felder wurden vor Jahren angelegt und seither nicht mehr gepflegt. Sie werden nicht übernommen, und diese Entscheidung wird mit Datum und verantwortlicher Person festgehalten. Der alte Bestand bleibt bis zum Ende der Aufbewahrung lesbar verfügbar.
Besondere Aufmerksamkeit verdienen Freitextfelder. In gewachsenen Systemen enthalten sie oft Informationen, die eigentlich strukturiert gehören: Zahlungsvereinbarungen, Lieferhinweise, Zugangsdaten zu Kundenportalen, Namen von Ansprechpartnern. Sie einfach als Notiz mitzunehmen, ist der schnellste Weg, aber er verschiebt das Problem. Ein Zwischenschritt hilft: Die Freitexte werden gelesen, häufige Muster erkannt und daraus zwei oder drei strukturierte Felder abgeleitet. Der Rest wandert als Notiz mit. Damit ist der wertvolle Teil der Freitexte gerettet, ohne dass jeder Satz einzeln bewertet werden muss.
Historische Daten: übernehmen, archivieren oder stehen lassen
Bei der Historie treffen zwei berechtigte Interessen aufeinander. Fachlich möchte man Auskunft geben können: Was hat dieser Kunde vor vier Jahren gekauft, zu welchem Preis, mit welcher Seriennummer? Technisch möchte man das neue System nicht mit Datensätzen füllen, die nur noch gelesen werden. Die Lösung liegt selten bei „alles" oder „nichts", sondern in einer Aufteilung: ein begrenzter Zeitraum wandert in den produktiven Bestand, der ältere Teil in ein Lesearchiv.
Ein Lesearchiv kann sehr schlicht sein. Es genügt häufig ein exportierter, durchsuchbarer Bestand mit Belegen als Dateien und einer Übersichtstabelle, die Belegnummer, Datum, Kunde, Betrag und Dateiname enthält. Entscheidend ist nicht die Technik, sondern dass der Zugriff geregelt ist: Wer darf suchen, wo liegt der Bestand, wie ist er gesichert, und bis wann muss er verfügbar bleiben? Wenn Belege ohnehin auf Papier oder verstreut vorliegen, lohnt es sich, diesen Schritt mit dem Digitalisieren der Dokumente zusammenzulegen statt zweimal anzufassen.
Die Frist gilt für die Daten, nicht für das alte Programm
Der Probelauf: mindestens zweimal, mit echten Daten
Ein Probelauf mit ausgedachten Testdaten beweist, dass das Verfahren technisch funktioniert. Er beweist nicht, dass es mit dem eigenen Bestand funktioniert — und genau darum geht es. Der Probelauf muss deshalb mit einer echten Kopie des Altbestands laufen, in einer Umgebung, die vom produktiven Betrieb getrennt ist. Erst dort zeigen sich die Fälle, die niemand vorhergesehen hat: der Kunde mit einer Adresse aus acht Zeilen, der Artikel mit negativer Menge, das Datum aus dem Jahr 1899, das ein Programm vor Jahrzehnten als Platzhalter gesetzt hat.
Ein einziger Probelauf reicht nicht. Der erste deckt die groben Fehler auf; nach der Korrektur zeigt der zweite, ob die Korrekturen wirken und keine neuen Fehler erzeugt haben. Erst wenn ein Lauf ohne unerklärte Abweichung durchläuft und die fachlichen Prüfungen bestanden sind, wird der Stichtag verbindlich gesetzt. Wer den Termin vor dem zweiten sauberen Lauf zusagt, verhandelt später über Fehler statt über den Zeitpunkt (Projekterfahrung).
Kopie ziehen und einfrieren
Eine vollständige Kopie des Altbestands mit festgehaltenem Zeitpunkt. Alle folgenden Zahlen beziehen sich auf genau diese Kopie, sonst ist kein Abgleich möglich, weil sich der Produktivbestand weiterbewegt.
Bereinigung vor der Übernahme
Dubletten zusammenführen, offensichtlich ungültige Werte korrigieren, Testdatensätze markieren. Bereinigt wird nach Möglichkeit im Altsystem, damit der Betrieb bis zum Stichtag mit dem korrigierten Bestand arbeitet.
Erster Lauf mit Fehlerprotokoll
Der Lauf bricht nicht bei jedem Fehler ab, sondern schreibt jeden abgewiesenen Datensatz mit Grund in ein Protokoll. Dieses Protokoll ist die Arbeitsliste für die Fachabteilung, nicht für die Technik allein.
Fachliche Prüfung am echten Vorgang
Die Menschen, die täglich mit den Daten arbeiten, prüfen ihre eigenen Fälle im neuen System: der schwierigste Kunde, der Artikel mit Staffelpreisen, der Auftrag mit Teillieferung. Diese Prüfung findet keine Technikfehler, sondern Bedeutungsfehler.
Zweiter Lauf und Abnahme
Nach den Korrekturen läuft die Übernahme erneut vollständig durch. Zeilenzahlen und Summen werden verglichen, Stichproben gezogen, das Ergebnis wird schriftlich abgenommen. Erst danach wird der Stichtag terminiert.
Eine vollständige Kopie des Altbestands mit festgehaltenem Zeitpunkt. Alle folgenden Zahlen beziehen sich auf genau diese Kopie, sonst ist kein Abgleich möglich, weil sich der Produktivbestand weiterbewegt.
Dubletten zusammenführen, offensichtlich ungültige Werte korrigieren, Testdatensätze markieren. Bereinigt wird nach Möglichkeit im Altsystem, damit der Betrieb bis zum Stichtag mit dem korrigierten Bestand arbeitet.
Der Lauf bricht nicht bei jedem Fehler ab, sondern schreibt jeden abgewiesenen Datensatz mit Grund in ein Protokoll. Dieses Protokoll ist die Arbeitsliste für die Fachabteilung, nicht für die Technik allein.
Die Menschen, die täglich mit den Daten arbeiten, prüfen ihre eigenen Fälle im neuen System: der schwierigste Kunde, der Artikel mit Staffelpreisen, der Auftrag mit Teillieferung. Diese Prüfung findet keine Technikfehler, sondern Bedeutungsfehler.
Nach den Korrekturen läuft die Übernahme erneut vollständig durch. Zeilenzahlen und Summen werden verglichen, Stichproben gezogen, das Ergebnis wird schriftlich abgenommen. Erst danach wird der Stichtag terminiert.
Ein häufiger Fehler ist die Trennung von technischer und fachlicher Prüfung. Die Technik prüft, ob alle Zeilen angekommen sind. Ob der Wert im Feld auch das bedeutet, was er vorher bedeutet hat, kann nur die Fachabteilung beurteilen. Ein Beispiel: Wenn im Altsystem das Feld für den Rabatt in Prozent geführt wurde und im neuen System als Faktor, kommen alle Zeilen an, alle Summen der Zeilenzahlen stimmen — und trotzdem sind sämtliche Preise falsch. Solche Fälle findet nur, wer echte Vorgänge nachrechnet.
Der Abgleich der Summen: wie Vollständigkeit belegt wird
Vollständigkeit lässt sich nicht behaupten, sie muss gezeigt werden. Bewährt hat sich ein Nachweis auf drei Ebenen, der jeweils vor und nach der Übernahme erhoben wird. Erstens die Anzahl: Wie viele Datensätze enthält der Bestand in der Quelle, wie viele im Ziel? Zweitens die fachliche Summe: Welchen Wert haben die offenen Posten, welchen Wert die Lagerbestände, wie hoch ist die Summe der offenen Aufträge? Drittens die Stichprobe: Zwanzig zufällig gezogene Vorgänge werden Feld für Feld verglichen.
Differenzen sind dabei nicht verboten — unerklärte Differenzen sind es. Wenn dreißig Datensätze fehlen, weil sie als Dubletten zusammengeführt wurden, ist das in Ordnung, sofern die Zahl dreißig aus der Bereinigungsliste hervorgeht und die Summe der Werte gleich bleibt. Fehlen dreißig Datensätze und niemand kann sagen, welche, ist die Übernahme nicht abgenommen. Diese Unterscheidung ist der ganze Trick: Nicht die Null in der Differenz zählt, sondern die Erklärbarkeit jeder Abweichung.
- Zeilenzahl je Bestand in Quelle und Ziel, jeweils mit Zeitpunkt der Messung.
- Summe der offenen Posten aus Forderungen und Verbindlichkeiten zum Stichtag.
- Summe und Anzahl der Lagerbestände, getrennt nach Lagerort, falls mehrere geführt werden.
- Anzahl offener Aufträge und Bestellungen sowie deren Gesamtwert.
- Stichprobe über mindestens zwanzig Vorgänge quer durch alle Bestandsarten, Feld für Feld verglichen.
- Liste aller bewusst nicht übernommenen Bestände mit Begründung, Datum und verantwortlicher Person.
Stichtag, Parallelbetrieb und Nachlauf
Der Stichtag ist der Zeitpunkt, ab dem im neuen System gearbeitet wird. Er sollte in eine ruhige Phase fallen und möglichst mit einem Periodenabschluss zusammenfallen, damit die Summen ohne Zwischenrechnung vergleichbar sind. Ein Monatswechsel genügt in vielen Betrieben; im Handel oder in der Logistik ist die saisonale Lage wichtiger als der Kalender. Vor dem Stichtag wird der Altbestand eingefroren: keine neuen Buchungen mehr im alten System, Änderungen laufen ab diesem Moment nur noch im neuen.
Ein häufiger Wunsch ist der Parallelbetrieb: Beide Systeme laufen einige Wochen nebeneinander, damit man notfalls zurückkann. Das klingt nach Sicherheit und ist in der Praxis anspruchsvoll, weil jede Buchung doppelt erfasst werden muss. Wird das nicht diszipliniert durchgehalten, entstehen zwei Wahrheiten, und niemand weiß mehr, welche gilt. Tragfähiger ist eine Zwischenform: Das Altsystem bleibt lesend verfügbar, führend ist ausschließlich das neue. Wer eine echte Rückfalloption braucht, sollte sie zeitlich befristen und die Bedingung vorher festlegen, unter der zurückgeschaltet wird.
Ein Parallelbetrieb ohne festes Ende ist kein Sicherheitsnetz, sondern eine doppelte Arbeitslast mit zwei Datenbeständen, die auseinanderlaufen. Sicherheit entsteht durch den geprüften Probelauf davor, nicht durch das offene Hintertürchen danach.
- Nachzügler einplanen: Belege, die nach dem Stichtag noch mit altem Datum eintreffen, brauchen einen festgelegten Weg.
- Korrekturen an alten Vorgängen: Wer darf im Lesearchiv nachschlagen, und wie wird eine nachträgliche Gutschrift im neuen System abgebildet?
- Nummernkreise: Fortlaufende Beleg- und Kundennummern dürfen sich nicht überschneiden; der Startwert im neuen System wird vor dem Stichtag festgelegt.
- Schnittstellen: Alle Verbindungen zu anderen Systemen müssen zum Stichtag auf das neue System zeigen, auch selten genutzte.
- Erreichbarkeit: In den ersten Tagen braucht es feste Ansprechpersonen für Rückfragen, sonst entstehen Behelfslösungen, die bleiben.
Der Nachlauf endet nicht mit dem ersten störungsfreien Arbeitstag. Sinnvoll ist eine Nachschau nach vier bis sechs Wochen: Stimmen die Auswertungen? Tauchen Vorgänge auf, die niemand zuordnen kann? Gibt es Felder, die seit dem Stichtag leer bleiben, weil sie im Ablauf nicht mehr vorkommen? Diese Nachschau kostet wenige Stunden und verhindert, dass ein Fehler erst beim Jahresabschluss auffällt, wenn niemand mehr weiß, woher er kommt.
Der Nachweis: was am Ende dokumentiert sein muss
Am Ende einer Übernahme steht ein Übernahmeprotokoll. Es ist kein Formalismus, sondern die Antwort auf eine Frage, die in zwei oder fünf Jahren gestellt werden kann — von einer Prüferin, von einem Wirtschaftsprüfer, von einer neuen Kollegin, die wissen will, warum ein Bestand endet. Das Protokoll fasst zusammen, welche Bestände wann aus welcher Quelle in welches Ziel übernommen wurden, welche Zahlen dabei verglichen wurden, welche Abweichungen es gab und wie sie erklärt sind.
Dazu gehören die Feldzuordnung im Stand der tatsächlichen Übernahme, die Liste der bewusst nicht übernommenen Bestände samt Begründung sowie der Ort und die Zugriffsregelung des Lesearchivs. Diese Unterlagen sind zugleich Bausteine der Verfahrensdokumentation, die für steuerrelevante Abläufe ohnehin verlangt wird. Wer sie während des Projekts mitschreibt, hat sie danach; wer sie nachträglich erstellen will, rekonstruiert Entscheidungen aus dem Gedächtnis. Eine geordnete Prozessdokumentation macht aus dem Projektergebnis einen belastbaren Nachweis.
Der Satz, an dem sich alles messen lässt
Praxishinweis für den Start
Verwandte Artikel
Tabellenkalkulation ablösen: wann es sich lohnt, wie es geht
Wenn eine Tabelle zum heimlichen Kernsystem wird: fünf Bruchstellen, drei Entscheidungsfragen und ein Umstellungsweg mit Parallelbetrieb statt Stillstand.
Verfahrensdokumentation erstellen: Aufbau, Umfang, Pflege
Verfahrensdokumentation nach GoBD: welche vier Teile hineingehören, wie ausführlich sie sein muss, wie sie aktuell bleibt und was ihr Fehlen bedeuten kann.
Aufbewahrungsfristen digital: Fristen und Löschläufe
Aufbewahrungspflicht und Löschpflicht widersprechen sich nur scheinbar. So entsteht ein Ablagekonzept mit Fristen je Dokumentart, Löschsperren und Protokoll.