Stichtag und Parallelbetrieb beim Wechsel auf Odoo
Kurz gesagt
Umschalten heißt: ein fester Stichtag, ein führendes System (Empfehlung der Redaktion) und je Bereich eine abgeschlossene Übergabe. Testen Sie vorher auf einer Kopie, zählen Sie am Stichtag den Bestand und buchen Sie Eröffnungssalden, offene Posten und Aufträge. Läuft das Altsystem weiter, darf derselbe Vorgang nur in einem System bilanzielle oder gewinnwirksame Wirkung entfalten (GoBD Rz. 41); in Deutschland gilt die lückenlose Aufzeichnung (§ 146 Abs. 1 AO).
Das Wichtigste
- Stichtag ist das Datum, ab dem Odoo führt: Bestände, Salden und offene Posten gelten zu diesem Tag.
- Probebetrieb testet auf einer Kopie; im Parallelbetrieb vergleicht das zweite System nur und hat keine Buchungswirkung.
- In Deutschland sind Buchungen vollständig und lückenlos aufzuzeichnen (§ 146 Abs. 1 AO; GoBD Rz. 36, 40).
- GoBD Rz. 41: derselbe Geschäftsvorfall darf nicht mehrfach aufgezeichnet werden; die Aufzeichnung in verschiedenen Systemen ist zulässig, solange keine mehrfache bilanzielle oder gewinnwirksame Auswirkung entsteht (Deutschland).
- Odoo.sh legt für einen Staging-Zweig eine neutralisierte Kopie an; Odoo Online dupliziert mit der Option For testing purposes.
- Am Stichtag: Bestand zählen (Physical Inventory), Register schließen (Close Register) und ein Sperrdatum setzen (App Buchhaltung laut Editionsseite Enterprise).
Ein Systemwechsel hat einen Tag, an dem die Verantwortung übergeht. Vorher läuft alles im alten System, danach im neuen; dazwischen liegt das Fenster, in dem Lücken entstehen. Diesen Übergang planen Sie Bereich für Bereich, nicht als einen einzigen Termin.
Worauf es beim Umschalten ankommt
Der Stichtag ist das Datum, ab dem Odoo führt: Bestände, Salden und offene Posten gelten zu diesem Tag, und jeder Vorgang danach gehört in Odoo. Legen Sie ihn fest, bevor die Umstellung beginnt, und halten Sie ihn schriftlich fest.
Drei Entscheidungen tragen den Wechsel. Die erste ist das führende System — eine Empfehlung der Redaktion: Buchführung und Fortschreibung liegen nur dort, auch wenn ein zweites System zum Vergleich mitläuft. Rechtlich entscheidend ist, dass derselbe Vorgang nicht in beiden Systemen bilanzielle oder gewinnwirksame Wirkung entfaltet (GoBD Rz. 41). Die zweite ist die Reihenfolge: Lager, Verkauf, Einkauf, Kasse und Buchhaltung werden zu unterschiedlichen Zeitpunkten übergeben, nicht am selben Vormittag. Die dritte ist der Nachweis: Jede Übergabe braucht eine Kontrolle, an der sich eine Lücke erkennen lässt.
In Deutschland verlangt § 146 Abs. 1 AO, dass Buchungen einzeln, vollständig, richtig, zeitgerecht und geordnet vorgenommen werden. Die GoBD führen das aus: Geschäftsvorfälle sind vollzählig und lückenlos aufzuzeichnen (Rz. 36), im DV-System sichern technische und organisatorische Kontrollen die lückenlose Erfassung (Rz. 40), und ein unbarer Vorgang, der innerhalb von zehn Tagen in der Grundaufzeichnung erfasst wird, gilt als zeitnah (Rz. 47). Für Österreich gilt die vollständige und zeitgerechte Eintragung nach § 131 Abs. 1 Z 2 lit. a BAO, für die Schweiz die vollständige Erfassung nach Art. 957a Abs. 2 Ziff. 1 OR.
Probebetrieb, Parallelbetrieb oder harter Wechsel
Zwei Fragen sind zu trennen: wie Sie vorher testen und wie Sie umschalten. Getestet wird im Probebetrieb auf einer Kopie; umgeschaltet wird entweder hart am Stichtag oder in einem befristeten Parallelbetrieb.
| Weg | Was passiert | Bedingung | Grenze |
|---|---|---|---|
| Probebetrieb | Der ganze Ablauf läuft auf einer Kopie der Datenbank mit den Stichtagsdaten. | Kopie der Produktivdatenbank; bei Odoo.sh ein Staging-Zweig, bei Odoo Online oder im eigenen Server der Datenbankmanager. | Ohne Wirkung auf die echten Bücher; Ergebnisse tragen Sie von Hand in die Produktivdatenbank. |
| Parallelbetrieb | Beide Systeme nehmen laufende Vorgänge an, die Zahlen werden verglichen. | Das zweite System erzeugt keine eigene bilanzielle oder gewinnwirksame Wirkung; ein führendes System festzulegen, ist eine Empfehlung der Redaktion. | Derselbe Vorgang darf nicht mehrfach bilanziell oder gewinnwirksam wirken (GoBD Rz. 41, Deutschland). |
| Harter Wechsel | Das Altsystem wird am Stichtag abgeschaltet, Odoo führt allein. | Ein abgenommener Probebetrieb. | Fehler wirken sofort; eine Rückfalllinie gibt es nur über die Sicherung. |
Die Kopie entsteht je Hosting anders (Dokumentation 20.0). Odoo.sh legt für einen Staging-Zweig eine neutralisierte Kopie der Produktionsdatenbank an; geplante Aktionen sind aus, ausgehende E-Mails werden abgefangen, Zahlungs- und Versanddienste laufen im Testmodus. In Odoo Online heißt der Schritt im Datenbankmanager Duplicate; die Vorgabe For testing purposes schaltet externe Aktionen ab, und ein Duplikat verfällt nach 15 Tagen. Im eigenen Server duplizieren Sie über den Datenbankmanager und setzen dabei die Neutralisierung.
Der Stichtagsplan je Bereich
Der folgende Ablauf ist eine Empfehlung der Redaktion, kein Verfahren der Odoo-Dokumentation; die Odoo-Schritte stehen in der Dokumentation 20.0. Der Plan rechnet in Tagen vor und nach dem Stichtag T0.
| Zeitpunkt | Bereich | Tätigkeit | Kontrolle |
|---|---|---|---|
| T-10 | Plan | Stichtag und führendes System festlegen, Parallelbetrieb bejahen oder verneinen | im Projektplan unterschrieben |
| T-5 | Stammdaten | Stammdaten einfrieren, letzten Export erstellen und bereinigen | Datensatzzahl gegen das Altsystem |
| T-3 | Test | den ganzen Stichtagslauf in der Kopie wiederholen | kein offener Fehler im Testprotokoll |
| T-1 | Kasse | Register im Altsystem schließen, Kassenbestand zählen | Tagesabschluss des Altsystems |
| T-1 | Bank | Kontoauszüge bis T-1 abstimmen | Liste offener Posten und Salden |
| T0 | Lager | Bestand zählen und als Physical Inventory erfassen (Inventory app ‣ Operations ‣ Physical Inventory) | Zählprotokoll, Summe je Lagerort |
| T0 | Buchhaltung | Eröffnungssalden und offene Posten buchen | Salden stimmen mit dem Altsystem |
| T0 | Verkauf und Einkauf | offene Aufträge und Bestellungen übernehmen | Liste offener Vorgänge abgehakt |
| T0 | Zugänge | Benutzer und Rechte anlegen; Sperrdatum auf den Buchungstag der Eröffnungssalden (T0) setzen (Accounting ‣ Accounting ‣ Lock Dates; App Buchhaltung laut Editionsseite Enterprise) | Anmeldung je Rolle getestet, Sperrdatum deckt T0 |
| T+1 | Betrieb | erster Geschäftstag in Odoo, Kasse am Abend schließen, Bank abstimmen | Tagesabschluss in Odoo |
| T+5 | Abgleich | Tageszahlen gegen das Altsystem vergleichen | Abweichungsliste je Bereich |
| T+10 | Buchhaltung | Nummernkreise und Belege stichprobenweise auf Lücken prüfen | Befund schriftlich |
| T+30 | Archiv | Probebetrieb beenden, Altsystem nur lesbar halten | Kopie ohne alten Server lesbar |
Die Hauptlast liegt am Stichtag auf Lager und Buchhaltung; Verkauf und Einkauf folgen mit den offenen Vorgängen. Die Kasse schließen Sie im Altsystem ab und öffnen sie in Odoo neu: Am Ende jeder Sitzung schließt Close Register das Register und erzeugt die Buchungen (Dokumentation 20.0). Das Sperrdatum schützt gebuchte Journalbuchungen mit Buchungsdatum bis einschließlich seines Datums und verschiebt neue Buchungen mit früherem Datum auf den Folgetag; es deckt nur Buchungen bis zu diesem Tag ab (App Buchhaltung laut Editionsseite Enterprise, Dokumentation 20.0). Damit die am Stichtag T0 gebuchten Eröffnungssalden geschützt sind, muss es T0 einschließen; mit T-1 blieben sie änderbar. Ausnahmen können Administratoren setzen; Ausnahme und Begründung stehen danach im Verlauf des Firmendatensatzes (Dokumentation 20.0).
Typische Fehler
- Mehrfache Wirkung in zwei Systemen. Werden laufende Vorgänge in beiden Systemen mit bilanzieller oder gewinnwirksamer Wirkung gebucht, verstößt das in Deutschland gegen GoBD Rz. 41; die bloße Zweitaufzeichnung in einem Vergleichssystem ohne eigene Wirkung ist zulässig. Ein führendes System festzulegen ist eine Empfehlung der Redaktion.
- Stichtag ohne Kontrollsummen. Ohne Abgleich von Salden, Beständen und offenen Posten bleibt eine Lücke unbemerkt.
- Bestand ohne Zählprotokoll. Ein Bestand ohne dokumentierte Zählung lässt sich später nicht gegen das Altsystem belegen.
- Kasse ohne Abschluss. Bleibt das Register offen, fehlt die Zuordnung der Buchungen zu Sitzung und Tag.
- Altsystem am Stichtag abgeschaltet. Ohne lesbare Kopie fehlt der Nachweis, wenn ein Prüfer auf alte Vorgänge zugreift.
- Zugänge zu spät. Ohne angelegte Benutzer und Rechte kann am ersten Tag niemand buchen (Benutzer und Zugriffsgruppen).
So gehen Sie vor
- Setzen Sie den Stichtag und bestimmen Sie das führende System; halten Sie beides schriftlich fest.
- Üben Sie den kompletten Ablauf auf einer Kopie mit den Stichtagsdaten; die Datenübernahme bereiten Sie nach Datenübernahme aus dem Altsystem vor.
- Frieren Sie die Stammdaten einige Tage vor T0 ein, damit der Import stabil bleibt (Stammdaten vorbereiten, CSV und Excel importieren).
- Zählen Sie am Stichtag den Bestand und buchen Sie Eröffnungssalden und offene Posten; das Vorgehen steht unter Eröffnungssalden und offene Posten.
- Setzen Sie nach dem Stichtag ein Sperrdatum, das den Buchungstag der Eröffnungssalden (T0) einschließt, damit die übernommenen Buchungen unverändert bleiben (App Buchhaltung laut Editionsseite Enterprise; GoBD-Grundlagen).
- Vergleichen Sie in der ersten Woche täglich die Zahlen mit dem Altsystem und führen Sie eine Abweichungsliste; die Abnahme vor dem Start regelt die Go-live-Checkliste, den Betrieb danach Die ersten 90 Tage.