3 typische BMD-Import-Probleme — und warum sie jede Kanzlei kennt
Die drei häufigsten Fehlerbilder beim BMD-NTCS-Import: woher sie kommen, warum jede Kanzlei sie kennt, und was ein KI-Konverter daran löst.
Wenn Sie eine österreichische Kanzlei führen oder in einer arbeiten, kennen Sie vermutlich diesen Ablauf: Mandant schickt CSV, Buchhalter versucht Import, BMD beschwert sich, zwei Stunden Excel-Arbeit beginnen. Dasselbe Drama jeden Monat.
Dieser Text beschreibt die drei häufigsten Fehlerbilder beim BMD-NTCS-Import konkret: wo sie herkommen, warum sie passieren, und was ein automatisierter Konverter daran löst. Die Beispiele sind keine Theorie. Sie stammen aus Forumsdiskussionen, Hilfe-Dokumentationen von Buchhaltungssystemen und aus Dateien, die uns Kanzleien in den letzten Monaten geschickt haben.
Problem 1 — Das Format stimmt an drei Stellen gleichzeitig nicht
BMD NTCS erwartet eine strikte Struktur:
- Datumsformat DD.MM.YYYY (Punkt, kein Bindestrich, kein Slash).
- Semikolon als Trennzeichen (kein Komma, kein Tab).
- CP1252 / ANSI kodiert (nicht UTF-8); Umlaute und Sonderzeichen werden sonst falsch interpretiert.
Was stattdessen von Mandanten kommt, in typischer Häufung:
- Shopify und Amazon liefern standardmäßig MM/DD/YYYY oder ISO-8601 (YYYY-MM-DD).
- Moderne Export-Tools speichern UTF-8-kodiert. Das führt beim BMD-Import zu Zeichensatzfehlern, weil BMD CP1252/ANSI erwartet.
- Wenn Sie die CSV in Excel öffnen und wieder speichern, kann Excel die Datei mit einem Byte-Order-Mark (BOM) oder in einem falschen Encoding (UTF-8 statt CP1252) ablegen, was BMD beim Parsen der ersten Spalte stolpern lässt.
Das Resultat: BMD bricht den Import ab mit Fehlermeldungen wie „Trennzeichen ungültig” oder „Datumsformat nicht erkannt”. Oder schlimmer: Der Import läuft scheinbar durch, aber Beträge landen in falschen Spalten, Rundungsfehler entstehen bei der Komma/Punkt-Verwechslung, und das merkt niemand, bis im Monatsabschluss eine Differenz auffliegt.
Typischer Arbeitsaufwand, den wir in Kanzleien beobachten: 15 bis 40 Minuten pro Datei für Encoding-Korrektur, Datumsumformung und Trennzeichen-Tausch, wenn man weiß, wie’s geht. Wenn man’s nicht weiß: erheblich länger, mit dem Risiko stiller Fehler.
Was ein KI-Konverter hier löst: Die Software erkennt das Ausgangsformat automatisch (Datum, Trenner, Encoding), wandelt es in die BMD-Anforderung um und verhindert stille Fehler, weil jede Spalten-Zuordnung vor dem Export sichtbar ist. Einmal eingerichtet, fällt dieser Korrekturschritt bei diesem Mandanten weg.
Problem 2 — Die Konten existieren in BMD nicht
Aus der BMD-Dokumentation, praktisch wörtlich: Die Sachkonten müssen bereits in Ihrem BMD-Kontenplan existieren, damit der spätere Import gelingt.
Was das in der Praxis heißt: Ein Mandant liefert eine Buchungsliste mit einem Konto „4001 Umsatzerlöse Dienstleistung Inland 20 %”, aber Ihre Kanzlei hat dieses Konto für diesen Mandanten nie im BMD-Kontenplan hinterlegt. Oder das Mandanten-System nennt Konten anders, als Ihre Kanzlei sie führt.
Dazu kommen typische Mapping-Probleme beim Wechsel zwischen Kontenrahmen:
- Ein Mandant, der mit DATEV-SKR03 oder SKR04 arbeitet, liefert Daten im deutschen Kontenrahmen. Diese sind in Österreich nicht FinanzOnline-kompatibel. Der offizielle DATEV-Kompromiss dafür ist der SKR07, der sich am österreichischen Einheitskontenrahmen (EKR) orientiert. Jede Konto-Nummer muss trotzdem abgebildet werden.
- Ein E-Commerce-Shop liefert Umsatz-Erlöse als Sammelposten, aber Ihre Kanzlei möchte OSS-Lieferungen, inländische 20%-Umsätze und ermäßigte 10%-Umsätze getrennt sehen. Das Mapping muss jemand machen.
Was passiert, wenn man’s ignoriert: BMD bricht beim Import ab mit „Konto nicht im Kontenplan”. Ein Buchhalter legt das Konto manuell an, beim nächsten Mandanten nochmal. Beim übernächsten auch.
Was ein KI-Konverter hier löst: Der Konverter wird einmal mit den Konto-Mappings des Mandanten konfiguriert („Umsatz 20 % geht auf 4000” / „Vorsteuer auf 2500” / und so weiter). Danach laufen alle Importe dieses Mandanten automatisch auf die korrekten BMD-Konten, auch wenn der Mandant sein Export-Schema unverändert lässt.
Problem 3 — Die Buchsymbole sind nicht definiert, oder der Steuercode passt nicht
BMD arbeitet mit Buchsymbolen, die explizit in den Stammdaten hinterlegt sein müssen. Die wichtigsten:
- KA für Kassa
- BK für Bank
- AR für Ausgangsrechnung
- ER für Eingangsrechnung
- KK für Kreditkarte
Wenn ein Mandant seinem CSV eine Spalte „Zahlungsart” mitgibt, aber die Werte dort „Cash” und „Card” heißen, kennt BMD diese Begriffe nicht.
Parallel dazu ein verwandtes Problem: Die Steuercodes. Ein Shopify-Export liefert „VAT 20 %”, BMD erwartet aber den internen Steuercode „AT20” oder eine mandantenspezifische Variante. Shopware und andere Systeme liefern Codes, die nirgendwo einheitlich dokumentiert sind.
Besonders tückisch: Split-Buchungen. Wenn eine einzelne Zahlung aus dem E-Commerce-Shop in Umsatz, Versand, Rabatt und Steuer zerfallen muss, und in BMD NTCS das Sachkonto eine Steuerkonto-Eigenschaft hat, muss in manchen Fällen über ein Umweg-Konto ohne Steuerkonto-Eigenschaft gebucht werden. Das ist ein Workaround, den nur erfahrene BMD-Anwender kennen, und der bei jedem Import-Vorgang erneut nachgearbeitet werden muss.
Was ein KI-Konverter hier löst: Der Konverter speichert die Zuordnung „Cash → KA, Card → KK” oder „VAT 20 % → AT20” einmalig. Bei Split-Buchungen erkennt die KI das Muster und erzeugt die BMD-konformen Buchungssätze inklusive Umweg-Konten-Logik, wenn nötig. Einmal eingerichtet, erkennt der Konverter das Muster bei jedem folgenden Import automatisch.
Warum das in Summe so teuer ist
Keine dieser drei Fehler-Kategorien ist einzeln dramatisch. Ein Buchhalter kann sie, wenn er’s weiß, mit etwas Excel-Routine beheben. Das Problem liegt in der Häufigkeit: Wenn Sie 20 Problem-Mandanten haben, und bei jedem 30 bis 60 Minuten Nachbereitung pro Monat anfallen, sprechen wir über 10 bis 20 Stunden manuelle Arbeit. Pro Monat. Bei einem kalkulatorischen Buchhalter-Stundensatz von etwa 115 Euro (nach dem österreichischen Benchmark von meetadam.io) sind das 1.150 bis 2.300 Euro monatlich, für eine Tätigkeit, deren einziger Output ein funktionierender Import ist.
Dazu kommt die schwer bezifferbare, aber reale Größe: Frustration, Fachkräfte-Bindung, Fehlerquote bei Übermüdung. Die Fachkräfteverordnung 2025 führt Buchhalter:innen auf Platz 56 der bundesweiten Mangelberufe. Arbeitszeit, die Sie bei CSV-Korrekturen verlieren, ist Arbeitszeit, die nirgendwo sonst zur Verfügung steht.
Was wir damit machen
Für jeden Ihrer Mandanten bauen wir einen Konverter, der genau die oben beschriebenen Probleme löst. Einmal eingerichtet, läuft er monatlich automatisch: Datei rein, BMD-konforme Datei raus. Das Erste machen wir kostenlos als Proof-of-Concept für Ihren schwierigsten Mandanten. Sie bekommen die fertige Importdatei zurück und können direkt in BMD einspielen. Ohne Risiko, ohne Verpflichtung.
Schicken Sie uns die Datei, die in Ihrer Kanzlei den größten Ärger macht: hallo@kanzlei-import.at. Anonymisiert, wenn Sie möchten. Nur die Struktur zählt.
Quellen (Stand April 2026): Fachkräfteverordnung 2025, BMD-NTCS-Hilfedokumentation, öffentliche Benchmark-Plattform für Steuerberatungshonorare (meetadam.io).
Dominik Pototschnig, Gründer kanzlei-import.at Kontakt: hallo@kanzlei-import.at Weiterführend: Wie der Konverter in 60 Sekunden entsteht · BMD vs. RZL vs. DATEV — was wir abdecken · Was manuelle Imports kosten