BMD vs. RZL vs. DATEV — welche Import-Pfade wir abdecken

Dieser Text ist technisch. Er richtet sich an Buchhaltungskräfte und IT-Verantwortliche in Kanzleien, die genau wissen möchten, welche Import-Formate unser System bedient und welche Besonderheiten pro System gelten. Wenn Sie Entscheider sind und einen Überblick brauchen, springen Sie direkt zur Vergleichstabelle weiter unten.

Der österreichische Markt auf einen Blick

In Österreich dominieren drei Buchhaltungssysteme die Kanzlei-Landschaft:

• BMD Business Software aus Steyr: nach Marktberichten etwa 80 % Marktanteil bei Steuerberatern und Wirtschaftsprüfern. Etwa 30.000 Kunden im DACH-Raum plus Ungarn, Tschechien, Slowakei. 97 Mio. Euro Umsatz im Geschäftsjahr 2024/25. Das NTCS-System ist der de-facto-Standard.
• RZL Software: österreichische Alternative, starke Präsenz bei mittelständischen Kanzleien, schlankere Importlogik als BMD.
• DATEV: dominant in Deutschland, in Österreich Nischenlösung, aber relevant für Kanzleien mit deutschen Mandanten oder DACH-Gruppenstrukturen.

Wir decken alle drei ab. Hier die technischen Details.

BMD NTCS — das CSV-Format im Detail

Das BMD-NTCS-Importformat ist als CSV mit Semikolon-Trennung definiert. Eine Kennziffer identifiziert die Datei gegenüber BMD als Import im BMD-Format. Wichtig sind die strikten Format-Regeln:

Dateistruktur

• Eine einzige, spaltenbasierte CSV mit Feldern wie satzart, konto, belegnr, belegdatum, soll, haben, steuercode, buchungstext usw.
• Die Struktur ist flach: keine getrennten Dateien für Sachkonten, Personenkonten und Buchungen, sondern ein einheitlicher Satzaufbau, in dem die Satzart pro Zeile angibt, um welchen Datensatz es sich handelt.

Pflicht-Format

• Trennzeichen: Semikolon. Komma scheitert bei Firmennamen mit Komma („Meier, Hans GmbH”); Tab ist nicht vorgesehen.
• Datum: DD.MM.YYYY (Punkt, nicht Slash).
• Encoding: CP1252 / ANSI (nicht UTF-8); Umlaute und Sonderzeichen werden sonst falsch interpretiert.
• Dezimaltrenner: Komma.
• Nach dem letzten Feld kein Trennzeichen.

Import-Module in BMD NTCS

• „Vorerfassung Buchungen” für den Standardfall.
• Klassisch pr08 (ohne Sammelbuchen) und pr08i für Kontenstämme.

Voraussetzungen im BMD-Mandanten

• Kontenplan muss existieren. Sachkonten, die im Import verwendet werden, müssen vorher in BMD angelegt sein. Das ist einer der häufigsten Importfehler-Gründe.
• Buchsymbole müssen in den Stammdaten hinterlegt sein. Die Defaults (KA = Kassa, BK = Bank, AR = Ausgangsrechnung, ER = Eingangsrechnung, KK = Kreditkarte) sind nicht automatisch aktiv.
• Steuercodes mandantenspezifisch (üblich: AT20, AT10, AT13). Fremdsoftware-Codes wie „VAT 20 %” werden nicht automatisch übersetzt.

Unser System generiert direkt die BMD-konforme CSV im korrekten Satzaufbau, unter Berücksichtigung der mandantenspezifischen Kontenplan- und Buchsymbol-Konfiguration.

DATEV EXTF/DTVF — der europäisch dominante Standard

DATEV ist in Österreich weniger verbreitet, aber technisch der am besten dokumentierte Standard. Seit einiger Zeit ist die Format-Dokumentation über das DATEV Developer Portal (developer.datev.de) kostenfrei zugänglich, einschließlich eines Prüf-Tools. Früher kostete die Dokumentation etwa 280 Euro.

Der Header ist streng normiert. Beispielzeile:

"EXTF";700;21;"Buchungsstapel";13;20240130140440439;;"RE";"";"";
29098;55003;20240101;4;20240101;20240831;"Buchungsstapel";"WD";
1;0;0;"EUR";;"";;;"03";;;"";""

Schlüsselfelder:

• Kennzeichen EXTF (Export aus Fremdsoftware) oder DTVF.
• Versionsnummer 700 (aktuell).
• Datenkategorie: 21 (Buchungsstapel), 16 (Debitoren/Kreditoren), 20 (Kontenbeschriftungen), 67 (Buchungstextkonstanten).

Besonderheit für Österreich: SKR07. Deutsche SKR03 (Prozessgliederung) und SKR04 (Abschlussgliederung) sind nicht FinanzOnline-kompatibel und in Österreich nicht zulässig. Der DATEV-Kompromiss ist der SKR07, der sich am österreichischen Einheitskontenrahmen (EKR) orientiert. Wenn Sie DATEV-Daten in RZL oder BMD einspielen, muss der SKR07 verwendet werden.

Unser System erzeugt DATEV EXTF/DTVF mit korrekter Header-Struktur und Mapping auf SKR07 bei österreichischen Mandanten.

RZL FIBU — schlankes ANSI-Format mit zwei Varianten

RZL nutzt einfache ANSI-Dateien mit Semikolon als Trennzeichen. Die Pflicht-Regeln:

• Trennzeichen: Semikolon.
• Encoding: CP1252 / ANSI.
• Datum: TTMMJJJJ ohne Trennzeichen (z. B. 18042026 für den 18. April 2026) in der Euro-Variante. Das ist ein häufiger Stolperstein; Punkte oder Slashes sind hier nicht erlaubt.
• Dezimaltrenner: Komma.
• Zeilenende CR/LF, keine Trennzeichen in Textfeldern, nach letztem Feld kein Trenner.

Zwei Varianten:

• 41-Felder-Format (Euro): der klassische Aufbau für RZL FIBU.
• 14-Felder-Format (FIBU Next): der schlankere Aufbau für die neuere FIBU-Next-Generation.

Import-Kategorien: Buchungen, Salden, Personenkonten, offene Posten, Journalzeilen.

DATEV-Unterstützung in RZL: Nach DATEV-Leitfaden Version 1.4 (Mai 2011) mit Oktober-2015-Erweiterungen. Neuere Leitfaden-Updates sind nicht garantiert. In der Praxis heißt das: DATEV-Daten können in RZL importiert werden, solange die älteren Standards eingehalten werden und SKR07 verwendet wird.

Unser System erzeugt wahlweise die 41-Felder- oder die 14-Felder-Variante, je nachdem, mit welcher RZL-Version Ihre Kanzlei arbeitet. Die passende Variante legen wir beim Kickoff-Call fest.

Einheitskontenrahmen (EKR) versus SKR03/04/07: warum das wichtig ist

Österreichische Kapitalgesellschaften müssen nach § 189 UGB den Einheitskontenrahmen (EKR) verwenden, veröffentlicht als Fachgutachten KFS/BW 6 der KSW. Die deutschen Kontenrahmen SKR03 und SKR04 sind in Österreich nicht zulässig für den offiziellen Abschluss und nicht FinanzOnline-kompatibel.

Die 10 EKR-Kontenklassen:

• 0–2: Aktiva
• 3: Passiva
• 4–8: Erfolgskonten
• 9: Abschluss

Typische Konten: 2000 (Forderungen), 2500 (Vorsteuer), 2800 (Bank), 3500 (USt).

Wenn ein Mandant Daten aus einem System liefert, das mit SKR03 oder SKR04 arbeitet (typisch: deutsche Tochter, deutsches Buchhaltungsprogramm), muss das Mapping auf EKR erfolgen, etwa SKR03-Konto 4400 „Erlöse 19 %” auf EKR 4000 „Umsatzerlöse 20 %”. Unser System unterstützt diese Mapping-Regeln pro Mandant.

Vergleichstabelle: die wichtigsten Unterschiede

Aspekt	BMD NTCS	DATEV EXTF/DTVF	RZL FIBU
Marktanteil AT (StB/WP)	~80 %	Nische (DE-Mandanten)	Mittelstand AT
Dateiformat	CSV, Semikolon	CSV, Semikolon, normierter Header	CSV, Semikolon, 41- oder 14-Felder
Kontenrahmen AT	EKR	SKR07 (AT-Variante)	EKR, DATEV nur SKR07
Datumsformat	DD.MM.YYYY	YYYYMMDD oder DD.MM.YYYY	TTMMJJJJ (ohne Trenner)
Encoding	CP1252 / ANSI	ANSI/UTF-8	CP1252 / ANSI
Dokumentation	BMD-intern	developer.datev.de (offen)	RZL-intern
Import-Module	Vorerfassung, pr08	Standardimport	FIBU / FIBU Next

Welches System in welcher Kanzlei?

BMD dominiert den österreichischen Steuerberatungs-Mittelstand. Wenn Sie eine klassische österreichische Kanzlei mit 5 bis 50 Mitarbeitern führen und mehrheitlich AT-Mandanten bedienen, arbeiten Sie mit hoher Wahrscheinlichkeit mit BMD NTCS.

RZL hat starke Verbreitung in bestimmten Regionen und bei Kanzleien, die eine schlankere Software bevorzugen. In der Praxis sehen wir RZL-Kanzleien, die DATEV-Importe brauchen, weil ein größerer Mandant aus Deutschland kommt. Hier kommt der SKR07-Umweg ins Spiel.

DATEV sehen wir in Österreich vor allem bei Kanzleien, die deutsche Gruppengesellschaften oder Tochter-Mandanten betreuen und aus Konsistenz-Gründen mit dem deutschen Standard arbeiten.

Wir decken alle drei ab, ohne dass Sie dafür zusätzlich zahlen oder Module dazubuchen müssen. Beim Kickoff-Call im Onboarding legen wir fest, welche Zielsysteme für Ihre Kanzlei relevant sind.

Was im Demo passiert

Sagen Sie mir im Call, welches System Ihre Kanzlei nutzt und welche Mandanten-Situation Sie konkret haben. Ich zeige Ihnen dann, wie eine typische Datei (zum Beispiel ein Shopify-Export, ein Bankauszug oder eine Kassenabrechnung) in das Zielformat Ihres Systems verwandelt wird. Sie sehen die Ausgabedatei vor dem Import und können beurteilen, ob sie den Anforderungen Ihrer Kanzlei entspricht.

Wenn Sie mir vorab schreiben, welches System Sie einsetzen, bereite ich den Konverter direkt darauf vor.

---

Quellen (Stand April 2026): § 189 UGB, KFS/BW 6 (Fachgutachten KSW), DATEV Developer Portal (developer.datev.de), BMD-NTCS- und RZL-FIBU-Produktdokumentation.

Dominik Pototschnig, Gründer kanzlei-import.at Kontakt: hallo@kanzlei-import.at Weiterführend: 3 typische BMD-Import-Probleme · Wie der Konverter in 60 Sekunden entsteht