Woran eine Kontoauszugsdatei gemessen wird

Diese Zeilen haben nicht so viele Spalten wie die Kopfzeile. Meist steckt ein nicht in Anführungszeichen gesetztes Komma in einer Beschreibung („Überweisung an Anna, Sparen“). Importer verschieben dann alle folgenden Spalten oder weisen die Datei zurück. Das muss von Hand korrigiert werden — eine automatische Reparatur müsste raten, welches Komma echt ist.

Mehrere Importer hören bei der ersten Leerzeile auf zu lesen und verwerfen still alles danach — das klassische „nur die Hälfte meiner Umsätze wurde importiert“. Leerzeilen können automatisch entfernt werden.

Excel setzt diese Markierung beim Speichern als „CSV UTF-8“. Manche Finanzprogramme lesen sie als Teil des ersten Spaltennamens („ Datum“ statt „Datum“) und finden die erwartete Überschrift dann nicht mehr. Beschwert sich Ihr Importer über eine unbekannte erste Spalte, entfernen Sie sie.

Genau das meldet YNAB als „Datei ist leer“ und andere Programme als „0 Buchungen importiert“. Der Export Ihrer Bank enthielt keine Zeilen: meist ein Zeitraum ohne Umsätze oder eine Exportschaltfläche, die nur die Spaltenüberschriften erzeugt hat.

Deutsche und andere europäische Excel-Exporte trennen Spalten mit „;“. Importer, die Kommas erwarten (YNAB, viele Upload-Formulare), lesen die ganze Zeile als eine Spalte. Die Datei kann automatisch auf Kommas umgeschrieben werden; Felder in Anführungszeichen bleiben dabei korrekt erhalten.

Empfängernamen wie „AT&T“ oder „H&M“ müssen in OFX/QFX-Dateien als „AT&T“ geschrieben werden. Ein rohes „&“ bricht die SGML/XML-Verarbeitung genau an dieser Stelle ab — einer der häufigsten Gründe, warum eine Datei nicht importiert, obwohl sie im Texteditor einwandfrei aussieht.

Die Datei beginnt mit einer unsichtbaren UTF-8-Markierung. Viele OFX-Parser verlangen, dass die allerersten Zeichen „OFXHEADER“ lauten, und weisen die Datei sonst als ungültig zurück. Das ist eine der häufigsten Ursachen für „ungültige Datei“ bei Dateien, die im Editor völlig normal aussehen.

Das <OFX>-Aggregat wird nie geschlossen. Meist wurde der Download von der Bank oder vom Browser abgebrochen. Die meisten Importer melden dann nur „Datei kann nicht gelesen werden“. Das schließende Tag kann ergänzt werden — prüfen Sie aber, ob die Umsatzliste vollständig ist.

OFX-Daten müssen als JJJJMMTT geschrieben sein (optional mit Uhrzeit und Zeitzone). Werte wie „2026-08-01“ oder „01.08.2026“ führen dazu, dass der Importer die Buchung oder die ganze Datei zurückweist.

Jedes <STMTTRN> braucht eine eindeutige FITID — daran erkennen Quicken, QuickBooks und YNAB, ob eine Buchung schon importiert wurde. Buchungen ohne FITID werden still verworfen oder lassen den ganzen Import scheitern. Eindeutige Kennungen können aus Datum, Betrag und Empfänger erzeugt werden.

OFX-1.x-Dateien müssen vor dem <OFX>-Rumpf mit einem Headerblock beginnen (OFXHEADER:100, DATA:OFXSGML, VERSION, ENCODING …). Ohne diesen Header weisen Quicken, QuickBooks und GnuCash die Datei zurück. Ein Standardheader kann automatisch vorangestellt werden.

TRNAMT-Werte müssen reine Zahlen mit Punkt als Dezimaltrennzeichen sein (z. B. -1234.56). Tausendertrennzeichen, Währungszeichen oder Leerzeichen führen dazu, dass die Buchung übersprungen wird.

Umlaute und Akzente (ä, ü, é …) stehen in einer Datei, deren Header reines ASCII angibt. Manche Importer ersetzen sie durch Zeichensalat, andere brechen ab. Fragen Sie die Bank nach einem UTF-8-Export. Eine automatische Umschrift wird bewusst nicht angewandt, um Namen nicht zu verfälschen.

Zwei verschiedene Buchungen tragen dieselbe FITID. Importer behandeln gleiche FITIDs als dieselbe Buchung und überspringen alle bis auf die erste — das klassische „nach dem Import fehlen Umsätze“. Die Duplikate können mit einem Zahlensuffix eindeutig gemacht werden.

Die Datei ist lesbar, enthält aber kein einziges <STMTTRN>. Programme melden das als „Datei ist leer“ oder „0 Buchungen importiert“. Banken erzeugen leere Dateien, wenn im gewählten Zeitraum keine Umsätze liegen — laden Sie einen größeren Zeitraum herunter.

QFX- und QBO-Dateien enthalten normalerweise ein <INTU.BID>-Tag, das eine für Web Connect lizenzierte Bank benennt. Fehlt es, lehnt Quicken die Datei mit „keine gültige Web-Connect-Datei“ ab. Dieses Werkzeug setzt keine Bankkennung ein — diesen Wert vergibt Intuit an die Bank. Importieren Sie ersatzweise per CSV.

Dies ist ein Depot- bzw. Wertpapierauszug (INVSTMTRS), dessen Buchungen Käufe, Verkäufe und Überträge sind statt der bankentypischen Einträge. Die Datei ist nicht leer. Die dokumentweiten Prüfungen — Header, Maskierung, Datumsformat, Abschneiden — wurden durchgeführt; Prüfungen einzelner Wertpapierbuchungen werden noch nicht unterstützt.

Jede QIF-Buchung muss mit einer Zeile enden, die nur „^“ enthält. Sätze ohne diesen Abschluss verschmelzen mit der nächsten Buchung oder verschwinden ganz — das klassische „nur ein Teil meiner Umsätze wurde importiert“.

Eine QIF-Datei muss mit einer Typangabe wie „!Type:Bank“ oder „!Type:CCard“ beginnen. Ohne sie verweigern GnuCash und Quicken die Datei oder importieren null Buchungen. Ein allgemeines „!Type:Bank“ kann vorangestellt werden — für Kreditkarten ändern Sie es auf !Type:CCard.

Beträge wie „1,234.56“ bringen mehrere Importer aus dem Tritt, weil sie das Komma als Feld- oder Dezimaltrennzeichen lesen. Die Kommas können automatisch entfernt werden („1234.56“).

Vor der ersten „!“-Zeile steht eine unsichtbare UTF-8-Markierung. Ältere QIF-Importer lesen sie als Datenmüll und weisen den Header zurück. Sie kann gefahrlos entfernt werden.

QIF-Daten werden je nach Land als M/T/JJ, M/T/JJJJ oder T/M/JJ geschrieben. Andere Schreibweisen (ISO 2026-08-01, Monatsnamen …) lassen Importer Sätze still überspringen. Da QIF seine Datumsreihenfolge nicht deklariert, wäre ein automatisches Umschreiben geraten — stellen Sie das Format im Importdialog ein.

In keinem !Type:Bank/CCard/Cash-Abschnitt wurden Buchungssätze gefunden; die Datei enthält also nichts zu importieren. Wenn Sie Daten erwartet haben, war der Exportzeitraum vermutlich leer.