Vielen Dank, Leute. Wie von @thomash vorgeschlagen, hat das Ersetzen aller Backslash-Vorkommen das Problem gelöst. Es sieht so aus, als ob, obwohl DATEV den Backslash als gültiges Zeichen ansieht, die Kombination des Backslashs mit der oktalen Darstellung eines Zeichens zu dessen Interpretation führen kann (das sieht für mich wie ein Fehler aus). Zum Beispiel:   APRR NFC\36 RUE DOCTEUR SCHMITT\ST APOLLINAIR\21850 FRAF Schlägt fehl, weil \36 als RS (Record Separator) Zeichen interpretiert wird THE OUTSIDERS STORE \47 Brunel Avenue Schlägt nicht fehl, weil \47 als ' (Apostroph) Zeichen interpretiert wird   Siehe Tabelle der Oktal-ASCII-Zeichen auf Wikipedia: https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange#ASCII-Tabelle   @vogtsburger, unsere Integration exportiert Zahlungskartentransaktionen nach DATEV, das Feld Buchungstext enthält den Händlernamen und wird von Mastercard mit den Backslash-Zeichen gesendet Übersetzt mit www.DeepL.com/Translator (kostenlose Version) ... Mehr anzeigen

Hallo @thomash, danke für deine Antwort.   Wir validieren die XML-Daten anhand der von DATEV bereitgestellten Regex (siehe: https://developer.datev.de/portal/de/dxso/zeichensatz) und alle Dateien werden erfolgreich validiert.   ^[a-zA-Z0-9§@€\\t\\r\\n\\#\\|\\`\\´\\'\\^\\°\\%\\&\\\\*\\~\\:\\;\\.\\-\\/+=_ \\?\\$\\!\\{\\}\\[\\]\\,\\(\\)\\<\\>\\p{InLatin1Supplement}\\p{InCJKUnifiedIdeographs}\\p{InHangulSyllables}\\\\]*$ Seltsam ist nur, dass von den beiden folgenden Dateien die erste von DATEV abgelehnt wird, während die andere erfolgreich importiert wird:   <?xml version="1.0" encoding="utf-8"?> <LedgerImport version="5.0" generator_info="XXX" generating_system="DIS v21.46.0" xml_data="Kopie nur zur Verbuchung berechtigt nicht zum Vorsteuerabzug" xmlns="http://xml.datev.de/bedi/tps/ledger/v050" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xml.datev.de/bedi/tps/ledger/v050 Belegverwaltung_online_ledger_import_v050.xsd"> <consolidate consolidatedAmount="-26.70" consolidatedDate="2021-11-11" consolidatedCurrencyCode="EUR"> <cashLedger> <date>2021-11-11</date> <amount>-26.70</amount> <information>Payment Top-up Wallet</information> <currencyCode>EUR</currencyCode> <bookingText>APRR NFC\36 RUE DOCTEUR SCHMITT\ST APOLLINAIR\21850 FRAF</bookingText> </cashLedger> </consolidate> </LedgerImport>   <?xml version="1.0" encoding="utf-8"?> <LedgerImport version="5.0" generator_info="XXX" generating_system="DIS v21.46.0" xml_data="Kopie nur zur Verbuchung berechtigt nicht zum Vorsteuerabzug" xmlns="http://xml.datev.de/bedi/tps/ledger/v050" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xml.datev.de/bedi/tps/ledger/v050 Belegverwaltung_online_ledger_import_v050.xsd"> <consolidate consolidatedAmount="-111.87" consolidatedDate="2021-11-11" consolidatedCurrencyCode="EUR"> <cashLedger> <date>2021-11-11</date> <amount>-111.87</amount> <information>Payment Top-up Wallet</information> <currencyCode>EUR</currencyCode> <bookingText>THE OUTSIDERS STORE \47 Brunel Avenue</bookingText> </cashLedger> </consolidate> </LedgerImport> Der Schrägstrich ("/") ist ein gültiges ASCII-Zeichen und sollte in XML nicht weiter kodiert werden müssen.   Auf jeden Fall bin ich für Ihren Vorschlag dankbar, ich werde ihn testen und diese Konversation aktualisieren. Kennen Sie ein anderes Sonderzeichen, das den "Intruder Alert" verursachen könnte?     ... Mehr anzeigen