am 13.01.2026 08:35
Guten Morgen,
seit gestern Abend gibt es ein Problem bei der Abholung der Umsätze mittels HBCI 🤔
Hier der Auszug aus dem Protokoll:
> Abholen Kontoumsätze für Konto Girokonto
> Amount value has too many significant digits, the maximal display length is 15.
> Abmeldung von der Bank erfolgt.
Das Abholen erfolgt mit dem Lexware Finanzmanager 2026 (Version 33.14, DDBAC 5.10.86.0).
Gestern war davon auch das Girokonto betroffen, dieses funktioniert aber seit heute wieder.
Beim Tagesgeldkonto tritt der Fehler nach wie vor auf!?
Wo liegt da das Problem?
Gruß Micha
am 16.02.2026 12:15
@Dennis_B schrieb:
@TH80 schrieb:"not able to convert 2026-02-11+01:00 to a date"
Die CAMT Spezifikation listet nur "UTC Zeitformat", was an sich nicht näher spezifiziert ist.
Wenn laut CAMT Spezifikation ein UTC Zeitformat gefordert wird, was ich selbst nicht geprüft habe, dann ist die Angabe der Zeitzone im Datensatz definitiv falsch. (Denn +01:00 ist nicht UTC)
Für Datenfelder wo nur ein Datum gefordert ist, dann sicher ohne Angabe einer Zeitzone, wenn eine Zeitangabe codiert wird die in UTC angegeben werden soll wäre die Angabe einer Zeitzone die nicht UTC entspricht ebenfalls falsch.
Folgenden Datensatz sehe ich im Protokoll der App der Sparkasse (https://play.google.com/store/apps/details?id=com.starfinanz.smob.android.sfinanzstatus) in der aktuellen Version 8.1.0:
(Ich bin kein Sparkassen-Kunde, nutze deren kostenlose App aber zum HBCI-Abruf meiner Comdirect-Konten.)
Ich habe Daten die ich geheim halten möchte durch "########################" ersetzt, das was ich nicht geschwärzt habe dürfen von mir aus alle lesen. (Also die Tatsache, dass ich am 2025-12-30 per PayPal 150 Euro von meinem Comdirect-Konto habe abbuchen lassen.)
<Ntry>
<NtryRef>########################</NtryRef>
<Amt Ccy="EUR">150.00</Amt>
<CdtDbtInd>DBIT</CdtDbtInd>
<Sts>BOOK</Sts>
<BookgDt>
<Dt>2025-12-30+01:00</Dt>
</BookgDt>
<ValDt>
<DtTm>2025-12-30T00:00:00.000+01:00</DtTm>
</ValDt>
<AcctSvcrRef>########################</AcctSvcrRef>
<BkTxCd>
<Prtry>
<Cd>005</Cd>
<Issr></Issr>
</Prtry>
</BkTxCd>
<NtryDtls>
<TxDtls>
<RltdPties>
<Cdtr>
<Nm>PAYPAL EUROPE S.A.R.L. ET C IE S.C.A</Nm>
</Cdtr>
<CdtrAcct>
<Id/>
</CdtrAcct>
</RltdPties>
<RmtInf>
<Ustrd>######################## , Ihr Ei</Ustrd>
<Ustrd>nkauf bei</Ustrd>
<Ustrd>End-to-End-Ref.:</Ustrd>
<Ustrd>########################</Ustrd>
<Ustrd>######################## / Mandatsref.:</Ustrd>
<Ustrd>####################</Ustrd>
<Ustrd>Gläubiger-ID:</Ustrd>
<Ustrd>LU96ZZZ0000000000000000058</Ustrd>
</RmtInf>
</TxDtls>
</NtryDtls>
</Ntry>Bei Bedarf kann ich comdirect-Mitarbeitern auf sicherem Weg auch ein ausführliches und ungeschwärtzes Übertragungsprotokoll aus der Sparkassen-App zukommen lassen.
Da sieht aktuell (bei einem Abruf vor wenigen Minuten) im Datenfeld BookgDt -> Dt das Datum in der Form "2025-12-30+01:00" was also nach obiger Erläuterung verdächtig nach einem Kodierungs-Fehler/Mangel aussieht.
Ich hoffe das kann helfen das Problem einzugrenzen.
LG
am 16.02.2026 13:02
Danke!
Hier sieht man sehr gut, dass das Valutadatum (ValDt) als Datetime (DtTm) korrekt übermittelt wird, aber als Buchungsdatum (BookgDt) nur ein Datum ohne Zeit (Dt) erwartet wird. Statt dessen steht dort zusätzlich eine fehlerhafte "+01:00" Angabe. Und genau das sorgt bei einigen Banking Programmen anscheinend für Probleme, da sie das Datum (das der Parser erwartet wegen des <Dt>) nicht dekodieren können.
am 16.02.2026 13:16
Hallo @p-schneider,
ich hab's gecheckt und kann das Problem bestätigen. Allerdings funktioniert die Schnittstelle bei anderen Apps. Getestet habe ich Finanzguru und Star Money. Der Kontoabruf ist bei diesen Apps kein Problem. Das bedeutet für uns, dass die Schnittstelle grundsätzlich funktioniert. In diesem Fall müsstest du entweder die App wechseln oder dich mit dem Herausgeber der Sparkassen App in Verbindung setzen.
Tut mir leid.
VG
Christoph
am 16.02.2026 13:30
Das heißt also, dass die comdirect den Fehler nicht beheben wird, sondern das Problem an die Softwareentwickler weiterreicht?
Das ist schade.
am 16.02.2026 13:36
Die Funktionsfähigkeit einzelner Apps ist aus meiner Sicht kein hinreichender Nachweis für Spezifikationskonformität.
Entscheidend ist, ob die gelieferten CAMT-Daten dem Schema entsprechen.
Wenn hier Abweichungen vorliegen, sollte die Behebung aus meiner Sicht auf Serverseite erfolgen – unabhängig davon, ob einzelne Clients tolerant reagieren.
Gruß Crazyalex
am 16.02.2026 13:36
Ich kann's gerne nochmal an die Kollegen weiterleiten mit der Bitte dies zu prüfen. Da es jedoch generell zu funktionieren scheint, greift das, was ich bereits erwähnte, dass wir grundsätzlich keinen Support für andere Apps übernehmen und man sich bitte an die Hersteller wenden soll. So steht es auch auf unserer Website.
VG
Christoph
am 16.02.2026 13:40
Ein Weiterleiten mit der Bitte um Prüfung wäre sehr gut - vielen Dank!
Zumal sich das Problem sicherlich bankseitig sehr leicht lösen lässt.
am 16.02.2026 13:44
16.02.2026 15:57 - bearbeitet 16.02.2026 16:00
16.02.2026 15:57 - bearbeitet 16.02.2026 16:00
@SMT_Chris schrieb:... Allerdings funktioniert die Schnittstelle bei anderen Apps. ... Das bedeutet für uns, dass die Schnittstelle grundsätzlich funktioniert. In diesem Fall müsstest du entweder die App wechseln oder dich mit dem Herausgeber der Sparkassen App in Verbindung setzen.
@SMT_Chris schrieb:
... Da es jedoch generell zu funktionieren scheint, greift das, was ich bereits erwähnte, dass wir grundsätzlich keinen Support für andere Apps übernehmen und man sich bitte an die Hersteller wenden soll.
Das ist hoffentlich nur ein schlechter Witz und sorgt für irgendwas zwischen Verwirrung und Unverständnis (und nicht nur bei mir, wie etliche Wortmeldungen in diesem Thread zeigen).
Ich hoffe, die Kollegen in der Fachstelle haben ein anderes Mindset.
PS: Bevor wieder Missverständnisse entstehen: Nein, ihr sollt keinen Support für fremde Software leisten.
am 16.02.2026 16:00
Die Apps funktionieren, die sich auf die falschen Daten der Bank angepasst haben. Das macht es aber nicht besser.