Hallo,
der Import der MT940-Datei ist gelungen. Jedoch kommt im Datensatz in Hibiscus nur der Betrag an. Alles andere ist leer.
Die Importdatei kommt von Mollie und scheint valide.

Hier der Inhalt (etwas geändert):

:20:940A190305
:25:NL30ABNA0599990900
:28C:64/1
:60F:C190305EUR0,00
:61:1903040304C2,40NMSC
:86:/TRTP/SEPA OVERBOEKING/NAME/Tom Mayer/REMI/Bestellung 10160/
EREF/tr_mdKJfgzetrK
:62F:C190305EUR2,40

Danke,
Steffen

Das liegt wohl daran, dass es sich um ein ausländisches MT940 handelt.
Das Feld ":86:", welches den Verwendungszweck enthält, beginnt in Deutschland eigentlich mit einem 3-stelligen numerischen Geschäftsvorfallcode, wenn es sich um strkturierte Daten handelt. Handelt es sich um einen unstrukturierten Verwendungszweck, muss als GV-Code "999" angegeben sein. Siehe auch https://www.kontopruef.de/mt940s.shtml

Die Zeile mit dem Verwendungszweck beginnt aber mit: ":86:/TRTP/". Würde die Zeile mit ":86:999/TRIP/" beginnen, würde der Verwendungszweck berücksichtigt werden.

Wobei - unabhängig davon: Die Notation mit den "/" und den Sepa-Tags "TRIP", "NAME" und "REMI" im Feld 86 habe ich so auch noch nicht gesehen.

Somit: Die zu importierenden Dateien einfach mit dem Editor öffnen und ein Suchen/ersetzen :86: => :86:999 durchführen, schon klappts.

Und dass jede Bank eigene Erfindungen zur Verwendung von Subfeld-TAGs hat, ist ja nichts neues. Denken wir mit Grausen an die Erfindungen der SPARDA-DV

Vielen Dank. Ich probiere es dann einmal.
VG

Nur dass dieses Format eher nach einem niederländischen MT940 aussieht

Jo, Mollie ist ein niederländischer e-Commerce-Zahlungsanbieter.
Ich hatte aber eben gedacht, wenn schon standardisiert (mt940, CAMT), dann weltweit.

@hibbie: Du glaubst auch noch "an's Gute im Menschen" respektive bei den Banken? Es ist (leider) eine alte Tatsache, dass es an Standards geben kann, was es will, letztlich interpretiert das jede Bank / Rechenzentrum anders. Und bei den SEPA-Standards sind die sogar offiziell von Land zu Land verschieden. Du kannst z.B. auch eine SEPA-XML-Datei mit Zahlungsaufträgen, die für eine deutsche Bank generiert wurde, nicht bei einer österreichischen Bank einreichen und umgekehrt...

Weltweit standardisiert und standardisiert sind schon gravierende Unterschiede.
Die Spezifikation des Aufbaus eines MT940 ist durchaus übergeordnet. Aber es gibt auch innerhalb einer Spezifikation Möglichkeiten für (Länder/Bank) individuelle Belegungsrichtlinien, die nicht übergreifend funktionieren und dennoch von der Spezifikation gedeckt sind.

Das ist hier im MT940 z.B. der Fall.
Das Feld 86 ist dafür ein gutes Beispiel. Das Feld 86 ist von der Spezifikation her ein Mehrzweckfeld. Es kann eben für den Transport von diversen Informationen genutzt werden.
In Deutschland gibt es dafür eine Belegungsrichtlinie, wie dieses Feld bei einer strukturierten Verwendung aufzubauen ist und wie eine unstrukturierte Belegung zu kennzeichnen ist. In anderen Ländern nutzt man dieses Feld ggf. für den Transport von anderen Informationen, dafür hat man aber vielleicht andere optionale Felder aus der Spezifikation für sich als Pflichtfeld deklariert.

Und dann gibt es die Fälle, die msa immer gerne nennt.
Einige von denen halten sich sehr wohl an die Spezifikation, interpretieren aber Belegungsrichtlinien ..."kreativ".
Einige halten sich an die Spezifikation und an den Belegungsrichtlinien und liefern trotzdem fachlich "kreative" Informationen
und dann gibt es auch noch die, die nicht mal dier Spezifikation richtig umsetzen oder psitiv formuliert, deren Interpretation der Spezifikation auch bei viel gutem Willen nicht nachvollziehbar ist.....

Danke für die Erläuterungen.
Ich muss zugeben, dass ich von Banken und deren Zusammenarbeit keine Ahnung habe. Ich muss als Online-Händler die Bankdaten nur insofern vorhalten, wie ich und der Buchprüfer darin etwas findet. Das machen die meisten durch das "beliebte" PDF. Ich freue mich hingegen sehr, wenn ich Daten bekomme, die tatsächlich digital und auch durchsuchbar und auswertbar sind. Deshalb hatte ich mich auch voller Energie auf den MT940-Auszug gestürzt.
Mir ist es mit dem oben genannten Ersetzen aber wirklich gelungen, den Verwendungszweck zu füllen, auch wenn dort jetzt das Gegenkonto usw. mit drin steht.

Danke aber!
VG
Steffen

Wenn Du das Gegenkonto auch in getrennten Feldern haben möchtest, müßtest Du Dir ein kurzes Umsetzprogramm schreiben, welches den 86er Satz so umbaut, dass die div. Angaben in entsprechenden Subfeldern nach deutscher Lesart stehen. Das wäre letztendlich garnicht wirklich kompliziert. Allerdings solltest Du evtl. keine allzu großen Arbeiten für MT940 tun, denn das Format ist ja eher im Niedergang begriffen und wird durch CAMT ersetzt. Wobei auch das wieder relativ ist - es wird sicher genügend Banken geben, die bis zum St. Nimmerleins-Tag mit MT940 weitermachen, um nur nichts ändern zu müssen...

du meinst damit hoffentlich den Steuerberater, denn der Buchprüfer wird davon nicht begeistert sein.
(insbesondere da du dies ja als Gewerbetreibender schreibst)

aber nur privat

Warum nur privat?

weil im gewerblichen Bereich bisher die PDF-Kontoauszüge fiskalisch nicht zugelassen sind - bzw. bei einer Prüfung, dies ein sehr großes Risiko für die GF darstellt. Wir hatten die Thematik in den "papierfreien Threads" schon. (ebenso wie GoBD - richtige Archivierung)

im privaten hat bspw. bis Steuerjahr 2016 ebenfalls keine digitale Steuerbescheinigung ausgereicht.

Lag ich mit meiner Vermutung richtig.
Die Aussage ist so schon länger nicht mehr richtig. Fiskalisch sind elektronische Kontoauszüge vom BMF zugelassen. Früher nur dann, wenn diese qualifiziert signiert waren, oder die zusändige Oberfinanzdirektion ihren Finanzämtern die Akzeptanz gestattet hatte . Nachdem im Rahmen des Steuervereinfachungsgesetz die Erfordernis der qualifizierten Signatur für Rechnungen entfallen ist, hat es nach diversen Gesprächen mit dem BMF und BMWi dort auch die Entscheidung gegeben, dass für einfache Auszüge keine höheren Ansprüche als für eine umsatzsteuerrelevanten Rechnung gelten kann.
Sprich fiskalisch gilt der elektronische Kontoauszug.

Das ist die eigentliche Hürde. Die Anforderung der GoBD zu erfüllen, ist nicht so ganz trivial. Und da dreht man sich weider im Kreis mit einem signierten Kontoauszug wäre die Hürde deutlich kleiner....

und wieder sind wir bei dem Thema
ich bin nicht der Theoretiker in solchen Dinge, sondern der Praktiker und möchte (einigermaßen) ruhig schlafen.

und meine Aussage im o.g. Content (und nur so zu verstehen) ist meines Erachtens schon zutreffend.


denn genau dies ist doch bspw. das "aber"
und daher formulieren auch Verlage diese: wie folgt exemplarisch:
https://www.azonline.de/Welt/R…dazu-meint

Gehe ich aber bspw. ebenfalls exemplarisch auf die Signatur ein: https://www.sparkasse.de/unser…uszug.html die ja lt. der "Mainpage" der Sparkassen noch vorhanden ist.
Dies steht auch so in den Baukästen der Banken bspw.: https://www.sparkasse-freiburg…tfach.html
inkl. dem Hinweis auf eine kostenlose Software (light Version bzw. begrenzt auf 10 pro Tage) zur Prüfung der Signatur.
Anleitung: (inkl. Adobe Reader Nutzungshinweise) https://www.sparkasse-freiburg…uefung.pdf

seltsam ist aber, dass keine Signatur in den Kontoauszüge gefunden wird.

... und hier soll ich dann dem Prüfer sagen: "meine Bank hat gesagt/geschrieben, dass es sicher ist" (den evtl. Schaden wird die Bank mit Sicherheit nicht übernehmen)

Hast du denn einen Auszug mit einer QeS beauftragt? Aufgrund von Kosten erstellen viele (alle?) Sparkassen den elektronischen Auszug nur auf Wunsch mit Signatur.

nein hab ich nicht, da auf den Pages hierzu nichts steht, dass es sich um eine optionale Funktion handelt.
auch nach einem Log-in ist dem Postfach-Bereich hiervon nichts zu lesen.

Dazu lesenswert:
https://www.akademie.de/wissen…rechnungen
Gruß
Raimund

das wird nicht bezweifelt - jedoch siehe oben GoBD ist zwischenzeitlich das Problem.
Es muss also zwischen privat und gewerblich unterschieden werden, als nächstes Signaturpflicht erst zwingend dann nicht mehr und zu guter letzt die GoBD, die doch bei der "tollen Verfahrensdokumentation" anfängt: https://www.datev.de/web/de/to…mentation/
(irgendwie ist das ganze eine Zwickmühle - bis der Prüfer kommt)

... und nochmals so bekl... es sich anhört ein Ausdruck eines PDF-Kontoauszugs, ist nicht das Original, sondern eine Kopie.

Zu ganzem o.g. kommt hinzu, dass teilweise Informationen falsch bzw. unvollständig (und somit falsch siehe Sparkasse) bzw. veraltet sind.

//edit: nachstehend mal wieder was aus der Praxis ...
ein User auf fb bei caya schreibt bspw.

Das ist der Knackpunkt. Nicht jeder Auszug erhält automatisch eine Signatur, da das zB für rein private Kunden unnötig ist. Letztlich sollte das Beratungsthema zusammen mit dem eb-Team der Bank/Sparkasse sein.

Hier wird das so gehandhabt, dass wir abhängig vom Konto und dem Kunden die Signatur anbieten und besprechen. Wie schon im Verlauf dieses Freds genannt, ist ja nicht nur die Signatur nötig, auch auf Kundenseite muss noch einiges zusätzlich passieren.

Zum Thema Akzeptanz: Unsere regionalen Finanzämter haben uns schriftlich bestätigt, dass entsprechende Auszüge anerkannt werden, sofern die restlichen Rahmenbedingungen eingehalten werden.