Buchhaltungsübergabe in Österreich: Odoo und BMD/RZL

Wer die Buchungen erst am Quartalsende exportiert, kann die Monatsfrist des § 131 Abs. 1 Z 2 lit. a BAO reißen, sofern sein Voranmeldungszeitraum monatlich ist; ist er vierteljährlich, gilt das Kalendervierteljahr. Und wer die Belege nicht mitliefert, muss mit Rückfragen rechnen. Drei Dinge müssen zusammenpassen: der Aufbau der Datei, den die Kanzleisoftware liest, die Fristen des § 131 BAO und der Bezug zwischen Buchung und Beleg.

Worauf es bei der Übergabe ankommt

Den Aufbau der Datei gibt die Kanzleisoftware vor, nicht Odoo. RZL FIBU Next übernimmt Konten, Salden, Buchungen, offene Posten und Journalzeilen über Datenimport ‣ RZL-Format; die Datei muss laut RZL-Angabe der RZL Schnittstellenbeschreibung entsprechen, die im RZL-Anwenderbereich liegt und bei RZL angefordert werden kann. BMD beschreibt auf der Seite zur Buchhaltungssoftware den Austausch von Buchungen über externe Tools und den Import aus Warenwirtschaftsprogrammen in die BMD FIBU.

Eine Vorlage für diesen Aufbau nennt die am 14. Oktober 2026 geprüfte Odoo-Dokumentation nicht. Die Seite Austria beschreibt für die Buchhaltung den SAF-T-Export als XML und die lokalisierten Berichte; einen BMD- oder RZL-Export nennt sie nicht. Die Fassungen 19.0 und 20.0 der Seite sind bis auf die Versionsangabe wortgleich und nennen dieselben vier Module.

Bücher, Aufzeichnungen und die zugehörigen Belege sind mindestens sieben Jahre aufzubewahren und darüber hinaus so lange, als sie für ein Abgabenerhebung betreffendes anhängiges Verfahren von Bedeutung sind, in dem die Buchführungspflichtigen oder die freiwillig Bücherführenden Parteistellung haben (§ 132 Abs. 1 BAO); die Frist läuft für Bücher vom Schluss des Kalenderjahres, für das die Eintragungen vorgenommen wurden, und für Belege vom Schluss des Kalenderjahres, auf das sie sich beziehen. Für Belege lässt § 132 Abs. 2 BAO die Aufbewahrung auf Datenträgern zu, wenn die Wiedergabe bis zum Fristende vollständig, geordnet, inhaltsgleich und urschriftgetreu gewährleistet ist; für Bücher verlangt § 131 Abs. 3 BAO die inhaltsgleiche, vollständige und geordnete Wiedergabe.

Für maschinell festgehaltene Geschäftsvorfälle kommt § 131 Abs. 2 BAO dazu: Verweisungen oder Buchungszeichen sollen den Zusammenhang zwischen den einzelnen Buchungen und zwischen Buchungen und Belegen klar nachweisen, Summenbildungen sollen nachvollziehbar sein. Eine Zeilenliste ohne Belegnummer und ohne Zuordnung zu einer Buchung trägt diesen Nachweis nicht.

Zur Verfügbarkeit: Die Seiten Austria und Germany nennen die Module, ordnen sie aber weder einer Edition noch einer Hostingart zu. Im öffentlichen Community-Zweig 19.0 und 20.0 liegt von den Austria-Modulen nur l10n_at; l10n_at_saft, das den SAF-T-Export liefert, l10n_at_reports und l10n_at_pos stehen dort nicht, ebenso wenig l10n_de_reports mit den DATEV-Exporten. Für die beschriebenen SAF-T-, Berichts- und DATEV-Funktionen belegt damit keine der geöffneten Seiten eine Edition oder Hostingart. Klären Sie Modulumfang, Edition und Hostingart im Angebot. Auf Odoo Online sind eigene Module und Module aus dem Apps-Store laut Dokumentation nicht möglich; die FAQ des Apps-Store nimmt davon Datenmodule ohne Python-Dateien aus und verweist für die Kompatibilität auf die Verfügbarkeitsangabe des jeweiligen Moduls. Die Abdeckung der Lokalisierung steht in Odoo für Österreich.

Die Übergabewege und ihre Grenzen

Die Tabelle nennt je Weg, was in Odoo entsteht, wer die Datei liest und wo die Grenze liegt. Angaben zur Kanzleisoftware stammen aus deren eigenen Hilfen, Stand 14. Oktober 2026; Menünamen sind die der englischen Odoo-Dokumentation, in der deutschen Oberfläche können sie abweichen.

Weg	Was in Odoo entsteht	Wer es liest	Grenzen (belegt)
SAF-T-Prüfungsdatei	XML aus Accounting ‣ Reports ‣ General Ledger, dort rechts neben dem PDF-Knopf der Eintrag SAF-T; Modul l10n_at_saft	Finanzverwaltung, wenn sie die Datei verlangt	Verlangt vollständige Firmen- und Partnerdaten, ÖNACE-Code, Gewinnermittlungsart und je Konto ein Kennzeichen des SAF-T-Kontenrahmens; offene Punkte zeigt View Problematic Accounts. Als Buchungsimport für die Kanzlei nennt die Seite Austria die Datei nicht.
RZL-Format: Konten, Salden, Buchungen, offene Posten	Datei im RZL-Aufbau, außerhalb von Odoo erzeugt	RZL FIBU Next, Datenimport ‣ RZL-Format	Aufbau laut RZL Schnittstellenbeschreibung, die im RZL-Anwenderbereich liegt; importierte Buchungen liegen in einem nicht finalisierten Stapel (Kürzel BI); Eröffnungsbuchungen brauchen einen eigenen EB-Stapel, der keinen offenen EB-Stapel duldet; beim Saldenimport sind Sammelkonto und Stichtag Pflicht, offene Posten nur für OP-führende Konten.
RZL-Belegdaten	Belegdatei plus XML nach der RZL-XSD-Beschreibung, gleicher Dateiname mit der Endung .xml	RZL Belegverarbeitung über das lizenzpflichtige Zusatzmodul RZL XML Belegdatenimport Schnittstelle	Als Format des Odoo-Listenexports nennt die Dokumentation Excel und CSV; XML müssen Sie auf einem anderen Weg erzeugen. Der Import legt ungebuchte Belege an, gebucht wird in RZL, und die Werte lassen sich dort noch ändern.
BMD	Buchungen aus Fremdsystemen; Belege aus der Mandanten-App	BMD FIBU beziehungsweise BMD Com-Mandantenplattform	BMD beschreibt den Austausch von Buchungen über externe Tools und den Import aus Warenwirtschaftsprogrammen; den Aufbau der Importdatei verlangen Sie bei BMD oder Ihrem Partner an.
Odoo-Listenexport	Excel oder CSV aus jeder Listenansicht, etwa Buchungen und Buchungszeilen, Felder frei gewählt und als Vorlage speicherbar	jede Empfängersoftware, wenn Sie die Zuordnung selbst machen	Ohne Zielaufbau für BMD oder RZL: Spalten, Konten, Steuerkennzeichen und Belegbezug liefern Sie; Buchungen und Buchungszeilen sind zwei getrennte Listen; große Exporte können laut Dokumentation in eine Zeitüberschreitung laufen, deshalb in kleineren Blöcken exportieren.
Odoo-Berichte	Excel oder PDF aus der Berichtsansicht, etwa General Ledger, Bilanz und Gewinn- und Verlustrechnung	zum Lesen und Ablegen	Darstellung zum Prüfen und Archivieren, nicht zum Einlesen in eine Buchhaltung.

Die Gegenrichtung: Im RZL-Klientenportal lassen sich Buchungen im Klientenbereich vorerfassen, mit oder ohne Vorkontierung – ob eine Vorkontierung möglich ist, steht in den Klientenstammdaten – und von der Kanzlei in die Finanzbuchhaltung übernehmen. Journalzeilen, Saldenliste und Kontenebene kann sie dort bereitstellen, optional samt Belegen.

Ein Rechenbeispiel

Die Zahlen sind erfunden. Ein Betrieb mit 320 Buchungen im Monat und drei Zeilen je Buchung erzeugt 960 Buchungszeilen; Soll- und Habensumme liegen bei je 132.480,00 Euro, an 210 Rechnungen hängt ein Beleg. Der Listenexport der Buchungszeilen hat damit drei Prüfgrößen: 960 Zeilen, zweimal 132.480,00 Euro und 210 Belegnummern.

Weicht eine Größe ab, suchen Sie die Buchung im Hauptbuch und korrigieren sie vor dem Export: Ein zweiter Export mit demselben Zeitraum kann zu doppelten Zeilen führen, wenn beide Dateien in der Kanzlei ankommen. Als Richtwert der Redaktion: rund 30 Minuten je Monat, für den ersten Probelauf mit der Kanzlei ein halber Tag.

Typische Fehler

• Nur die Buchungszeilen exportieren, ohne Kopffelder: Ohne Belegnummer, Buchungsdatum und Journal trägt die Zeile keinen Bezug zu ihrer Buchung.
• Konten und Steuerzeilen nicht abgestimmt: Im Listenexport wählen Sie die Felder selbst; den Zielaufbau für BMD oder RZL nennt keine der geöffneten Hilfeseiten. Klären Sie vor dem ersten Export, wer Konten und Steuerzeilen zuordnet; sonst kann diese Arbeit bei der Kanzlei hängen bleiben.
• Belege nicht mitliefern: Nach § 131 Abs. 2 BAO soll bei maschinell festgehaltenen Geschäftsvorfällen der Zusammenhang zwischen den Buchungen und den Belegen durch Verweisungen oder Buchungszeichen klar nachgewiesen werden; eine Liste ohne Belegbezug trägt diesen Nachweis nicht.
• Denselben Zeitraum zweimal importieren: In RZL liegen importierte Buchungen in einem nicht finalisierten Stapel und sind am Kürzel BI erkennbar; ob ein doppelter Import auffällt, hängt von der Prüfung ab, die Sie mit der Kanzlei vereinbaren. Prüfen Sie Zeilenzahl und Summen, bevor der Stapel finalisiert wird.
• Kontenrahmen weicht ab: Das Paket der Lokalisierung lässt sich laut Dokumentation nur wechseln, solange kein Eintrag gebucht ist. Gleichen Sie den Kontenrahmen der Kanzlei vor der ersten Buchung ab.

So gehen Sie vor

1. Fragen Sie die Steuerberatung nach Software, Importweg und Dateiaufbau (RZL Schnittstellenbeschreibung oder BMD-Aufbau) und lassen Sie schriftlich festhalten, wer Konten und Steuerkennzeichen zuordnet.
2. Gleichen Sie den Kontenrahmen ab, bevor Sie in Odoo die erste Buchung erfassen.
3. Legen Sie Feldliste, Zeitraum und Dateinamen fest; speichern Sie die Feldliste im Exportdialog als Vorlage, damit jeder Monat gleich aussieht.
4. Exportieren Sie, und prüfen Sie Zeilenzahl und Summen gegen das Hauptbuch (im Beispiel oben 960 Zeilen und zweimal 132.480,00 Euro).
5. Testen Sie mit einem kurzen Zeitraum und lassen Sie den Stapel in der Kanzlei prüfen, bevor er finalisiert wird.
6. Halten Sie Rhythmus, Aufbewahrung und Zuständigkeiten schriftlich fest, damit der Weg auch bei Personalwechsel gleich bleibt.

Den Rhythmus gibt der gesetzliche Rahmen vor: Eintragungen in Bücher und Aufzeichnungen für die Erhebung der Abgaben vom Umsatz, Einkommen und Ertrag, ausgenommen Abzugssteuern, sind spätestens einen Monat und 15 Tage nach Ablauf des Kalendermonats vorzunehmen (§ 131 Abs. 1 Z 2 lit. a BAO); bei vierteljährlichem Voranmeldungszeitraum gilt das Kalendervierteljahr. Die Bücher und die Belege bleiben im Betrieb, siehe Aufbewahrung in Odoo und Verfahrensdokumentation. Wer den Weg im Detail braucht, findet ihn in DATEV-Export aus Odoo, dort für die deutsche Lokalisierung und DATEV.