Zum Inhalt

Senden und Empfangen per SFTP

Diese Anleitung beschreibt, wie Sie Rechnungen und Gutschriften per SFTP an xTool senden: Zugang einrichten, Dateien benennen und hochladen, Antwort-XML lesen.

Eingehende Dokumente erscheinen in der xTool-Web-App (siehe Empfang per Peppol). Sie werden nur dann in den SFTP-Ordner download kopiert, wenn Inbound-Rechnungen aktiv sind.

Für CSV-Import per SFTP siehe CSV-Import per SFTP und Dokumente importieren.


Was SFTP ist

xTool stellt für Ihre Organisation einen SFTP-Server bereit. Nach der Aktivierung in der Web-App zeigt xTool Host, Port und Benutzername — Sie wählen ein Passwort. Ihr ERP oder Integrationsclient verbindet sich mit diesem Server und legt Dateien im Ordner upload ab. xTool verarbeitet sie nach Zeitplan und schreibt Status-XML in Antwortordner.

Unterstützte Dateitypen entsprechen dem Web-Upload: XML- und PDF-Rechnungen und -Gutschriften in unterstützten Formaten sowie xTool-CSV für den Import.

Testumgebung

Für Entwicklung und Tests nutzen Sie das Testsystem: https://xtool-test.invoice-portal.de/.


Zugang einrichten

  1. Melden Sie sich in der xTool-Web-App an und wählen Sie Ihre Organisation.
  2. Öffnen Sie Schnittstellen → SFTP-Konfiguration (Berechtigung zum Verwalten von Integrationen erforderlich).
  3. Passwort eingeben und bestätigen, dann SFTP einrichten klicken.
  4. Nach erfolgreicher Einrichtung werden die Verbindungsdaten (Host, Port, Benutzername) angezeigt, der Status ist Aktiv.

Passwort selbst aufbewahren

xTool zeigt das Passwort nach dem Setzen nicht erneut an. Bewahren Sie es sicher auf. Bei Verlust setzen Sie ein neues Passwort unter Passwort ändern.

Passwortanforderungen: mindestens 12 Zeichen; mindestens ein Großbuchstabe, ein Kleinbuchstabe, eine Ziffer und ein Sonderzeichen (!@#$%^&*()_+-=[]{}|;:,.<>?).

Die Anmeldung erfolgt mit diesem Passwort. Eine Schlüssel-Anmeldung für das Organisationskonto ist nicht vorgesehen.

Aktionen auf der SFTP-Seite:

Aktion Zweck
Verbindung testen SFTP-Anmeldung prüfen und Dateien im Upload-Ordner auflisten.
Passwort ändern Neues Passwort setzen.

xTool prüft den Ordner upload etwa einmal pro Stunde. Neu hochgeladene Dateien werden übersprungen, bis sie mindestens etwa 10 Sekunden alt sind (damit der Transfer abgeschlossen ist). Quelldateien mit Anhängen warten bis zu 5 Minuten auf die Anhangsdateien.

Siehe Organisation und Benutzer zu Berechtigungen.


Dateinamen-Regeln

Dateinamen dürfen keine Leerzeichen, Umlaute oder andere Sonderzeichen enthalten.

Erlaubte Zeichen im Basisnamen: a-z, A-Z, 0-9, ., _, -

Erlaubte Erweiterungen für Rechnungsdateien: .xml, .pdf, .csv

Beispiele — korrekt:

  • INV2020_158.xml
  • INV2020_212.pdf
  • invoice.csv

Beispiele — falsch:

Dateiname Grund
invoice 20200401-002.xml Leerzeichen
Rechnung_zubehör.xml Umlaut
Rechnung.txt Falsche Erweiterung

Verwenden Sie + als Trennzeichen, wenn Konvertierungs- oder E-Mail-Routing im Dateinamen stehen soll (siehe unten).

Limits: eine Datei bis 50 MB. Doppelter Inhalt (gleicher SHA-256-Hash wie eine bereits verarbeitete Datei dieser Organisation) wird abgelehnt. Versteckte Dateien (Namen beginnend mit .) werden ignoriert.


Vollständige Rechnungsdateien

Versand per Peppol — IDs in der XML

Setzen Sie Peppol-Teilnehmer-IDs von Absender und Empfänger in die Rechnungs-XML (oder ins PDF mit eingebetteter XML). Verwenden Sie einen eindeutigen Dateinamen:

<eindeutiger-dateiname>.xml
<eindeutiger-dateiname>.pdf

xTool validiert die Datei, legt das Dokument an und sendet per Peppol, wenn das erkannte Format Peppol unterstützt. Die Adressierung kommt aus dem Dokumentinhalt, nicht aus dem Dateinamen.

Versand per E-Mail

Für Versand per E-Mail statt Peppol die Empfängeradresse in den Dateinamen setzen:

<eindeutiger-dateiname>+<E-Mail-Empfänger>.xml
<eindeutiger-dateiname>+<E-Mail-Empfänger>.pdf

Beispiele:

invoice-20200821-1+receiver@webware24.de.xml
68451+buyer@example.com+xrech_ubl.pdf

Steht im Dateinamen eine E-Mail-Adresse, sendet xTool per E-Mail statt Peppol, KSeF oder France (wenn das Format E-Mail unterstützt). Diese Adresse ist bei allen unterstützten Dateitypen der E-Mail-Empfänger beim Versand. Bei fertigen strukturierten Rechnungen (Peppol BIS, XRechnung, ZUGFeRD usw.) wird die Datei für die Adressierung nicht verändert: Die Endpoint ID des Käufers stammt aus dem Dokumentinhalt, nicht aus dem Dateinamen.

Bei Raw PDF mit Formatcode schreibt xTool nach der Erkennung die E-Mail (oder Peppol-ID) aus dem Dateinamen in die Endpoint ID der erkannten Rechnung. Bei SAP IDoc gilt Entsprechendes, wenn der Name E-Mail oder Peppol-ID enthält und in ein Zielformat konvertiert wird. Enthält der Dateiname keine Empfängeradresse, wird die Endpoint ID des Käufers aus dem IDoc-Inhalt (Partner- und Routingdaten) ermittelt, nicht aus dem Dateinamen.

Validierung des Dateinamens: höchstens eine Empfängeradresse (E-Mail oder Peppol-ID) in den +-Segmenten. Zwei E-Mails, zwei Peppol-IDs oder E-Mail zusammen mit Peppol-ID werden als mehrdeutig abgelehnt. Doppelte hold-, source- oder Formatcode-Segmente werden ebenfalls abgelehnt.

Konvertierung vor dem Versand

Fügen Sie einen Formatcode hinzu, um Konvertierung oder PDF-Erkennung in ein Zielformat vor der Validierung dieses Formats und dem Versand anzufordern:

<eindeutiger-dateiname>+<format-code>.xml
<eindeutiger-dateiname>+<format-code>.pdf

Der Code darf in einem beliebigen +-Segment nach dem Basisnamen stehen (z. B. 68451+fa3.xml, 68451+xrech_ubl.pdf oder 68451+buyer@example.com+xrech_ubl.xml).

Formatcode Zielformat
fa3 KSeF FA Invoice 3.0 (XML)
xrech_ubl XRechnung Invoice 3.0 (UBL)
xrech_cii XRechnung Invoice 3.0 (CII)
peppol_ubl PEPPOL BIS Billing 3.0 (UBL)
peppol_cii PEPPOL BIS Billing 3.0 (CII)
zugferd_en Zugferd EN 16931
zugferd_de Zugferd XRechnung
fr_peppol_ubl Peppol BIS Billing France Invoice 3.0 (UBL)
fr_peppol_ubl_cn Peppol BIS Billing France Credit Note 3.0 (UBL)
fr_cius_ubl France CIUS Invoice UBL EN16931
fr_cius_ubl_cn France CIUS Credit Note UBL EN16931
fr_cius_ubl_ext France CIUS Invoice UBL Extended
fr_cius_ubl_ext_cn France CIUS Credit Note UBL Extended
fr_cius_cii France CIUS Invoice CII EN16931
fr_cius_cii_ext France CIUS Invoice CII Extended
fr_facturx Factur-X France EN16931
fr_facturx_ext Factur-X France Extended
fr_facturx_wl Factur-X France BASIC WL

Unbekannte Formatcodes werden abgelehnt.

Strukturierte Dateien (XML, PDF mit eingebetteter Rechnung, …)

Erkennt xTool ein strukturiertes Format (z. B. Peppol-XML oder ZUGFeRD-/Factur-X-PDF), löst der Formatcode eine Binärkonvertierung aus: Quelle validieren, konvertieren, konvertierte Datei validieren, Ergebnis hochladen, dann senden. Bei Erfolg wird die konvertierte XML zusätzlich unter upload_response/<Rechnungsnummer>/ als <Original-Stamm>_<Unix-Zeitstempel>_converted.xml gespeichert.

Raw PDF mit Formatcode

Erkennt xTool ein Raw PDF (Scan oder gewöhnliches PDF ohne eingebettete E-Rechnungsdaten), löst der Formatcode PDF-Erkennung statt Binärkonvertierung aus — dieselbe Art Erkennung wie Formatkonvertierung in der Weboberfläche. Ohne Formatcode startet SFTP keine automatische Erkennung; die Datei wird als Raw PDF gespeichert. Versand per E-Mail ist über den Dateinamen möglich; Peppol nur, wenn das PDF eingebettete Rechnungsdaten enthält (siehe oben).

Bei Raw PDF mit Formatcode:

  1. xTool validiert das PDF und speichert es in xTool (Validation Accepted, Upload Accepted für das Raw PDF).
  2. xTool führt die Erkennung ins Zielformat durch und legt ein zweites Dokument an (das ursprüngliche Raw PDF bleibt erhalten).
  3. Antwortschritte enthalten Recognition Accepted oder Recognition Rejected (mit <Errors> bei Ablehnung). Es wird keine *_converted.xml in upload_response geschrieben.
  4. Bei Recognition Accepted sendet xTool das erkannte Dokument (nicht das Raw PDF). Steht eine E-Mail-Adresse im Dateinamen, erfolgt Versand per E-Mail statt Peppol, Frankreich oder KSeF.
  5. Bei Recognition Rejected (Erkennung fehlgeschlagen, erkanntes Dokument ungültig oder France-Empfänger nicht anwendbar) überspringt xTool den Versand, entfernt die Datei aus upload und verschiebt sie nicht nach rejected — wie bei Conversion Rejected nach fehlgeschlagener Validierung der konvertierten Datei. Raw PDF und ggf. erkanntes Dokument bleiben in xTool zur Prüfung.

Beispiele:

1
2
3
68451+xrech_ubl.pdf
603275+fa3.pdf
68451+buyer@example.com+peppol_ubl.pdf

Bei Raw PDF mit Formatcode können Sie den +source-Workflow mit Anhängen nutzen (siehe Dateien mit Anhängen): xTool erkennt das Scan-PDF zuerst ins Zielformat, bettet Anhänge in die erkannte Rechnung ein und sendet dieses Dokument (nicht das ursprüngliche Raw PDF).

Nach Konvertierung oder erfolgreicher Erkennung folgt der Sendekanal dem Zielformat (und einer E-Mail im Dateinamen, falls vorhanden): KSeF-Formate gehen an KSeF; Peppol-fähige Formate an Peppol; französische Formate an den Kanal Frankreich, sofern kein E-Mail-Empfänger gesetzt ist. Der Versand nach Frankreich setzt eine aktive France-Konfiguration der Organisation voraus, die Rechnungen ausstellen darf (nicht nur Empfang).

Empfänger Frankreich im Dateinamen

Bei französischen Zielformaten kann der Käufer im Dateinamen stehen (ein +-Segment):

Empfängersegment Beispiel
SIREN (9 Ziffern) invoice+fr_cius_ubl+346628948.xml
SIRET (14 Ziffern) invoice+fr_cius_ubl+34662894800012.xml
SIREN + Suffix invoice+fr_cius_ubl+346628948_SERVICE.xml
SIREN + SIRET + Routing-Code invoice+fr_cius_ubl+346628948_34662894800012_ROUTE.xml
Raw PDF + FR-Code (nach Erkennung) invoice+fr_cius_ubl+346628948.pdf

Bei strukturierten Dateien wird das Empfängersegment vor dem Upload angewendet. Bei Raw PDF mit französischem Formatcode wird es auf das erkannte Dokument nach der Erkennung angewendet; schlägt dieser Schritt fehl, lautet der Antwortstatus Recognition Rejected.

Eine E-Mail-Adresse im Dateinamen bewirkt weiterhin Versand per E-Mail statt Frankreich.

Nur hochladen (hold)

Das reservierte Segment hold in einer beliebigen +-Position nach dem Basisnamen validiert (und konvertiert bei Bedarf), speichert das Dokument in xTool und überspringt Peppol-, E-Mail-, KSeF- und Frankreich-Versand:

1
2
3
invoice+hold.xml
68451+xrech_ubl+hold.xml
invoice+source+hold+buyer@example.com.xml

hold lässt sich mit Formatcodes, source, Sender/Empfänger-Segmenten und IDoc-Dateien kombinieren (siehe unten).


Dateien mit Anhängen

Für XRechnung- oder Peppol-BIS-Rechnungen mit eingebetteten Anhängen gilt diese Namenskonvention:

Rechnungsdatei:

<eindeutiger-dateiname>+source.xml
<eindeutiger-dateiname>+source.pdf

Anhangsdateien:

<eindeutiger-dateiname>+attachment_<id>.<Erweiterung>

<id> ist 1–3 Ziffern. Erlaubte Anhangs-Erweiterungen: jpg, jpeg, png, pdf, xlsx, ods

xTool wartet bis zu 5 Minuten nach Erscheinen der Quelldatei, damit Anhänge hochgeladen werden können. Eine Quelldatei ohne passende Anhänge wird abgelehnt.

Formatcode und/oder E-Mail-Empfänger können nach +source stehen:

1
2
3
invoice-20200821-1+source+xrech_ubl.xml
invoice-20200821-1+attachment_1.pdf
invoice-20200821-1+attachment_2.png
invoice-20200821-1+source+max@webware24.de.xml
invoice-20200821-1+attachment_1.pdf

Anhänge werden in die Rechnungs-XML eingebettet, danach werden die Original-Anhangsdateien aus upload entfernt.

Bei strukturiertem XML (oder XML nach Konvertierung) erfolgt das Einbetten vor dem Upload. Bei Raw PDF mit Formatcode erfolgt es nach der PDF-Erkennung in das erkannte Dokument.

Beispiel (Raw PDF + Erkennung + Anhänge):

invoice-20200821-1+source+zugferd_en+hold.pdf
invoice-20200821-1+attachment_1.pdf

SAP IDoc

XML-SAP-IDoc-Rechnungen werden am Dateiinhalt erkannt. Standardmäßig kommt das Routing (E-Mail vs. Peppol, XRechnung vs. ZUGFeRD) aus IDoc-Enhancement-Segmenten (X-E, X-P, Z-E, Z-P).

Die gleichen +-Segmente wie bei anderen Dateien sind möglich (hold, Formatcodes, source, Sender/Empfänger). Anweisungen im Dateinamen haben Vorrang vor IDoc-Routing — z. B. sendet INVOIC+other@mail.com.xml an diese E-Mail statt an ZZ_EMAIL_RE, und INVOIC+hold.xml speichert in xTool ohne Versand.

Ohne +-Segmente im Namen bleibt das Verhalten unverändert (z. B. invoice.xml).


Ordnerstruktur

Mit aktiviertem SFTP-Zugang werden diese Ordner angelegt. Lassen Sie die Systemordner bestehen.

Ordner Zweck
/upload Ausgehende Dateien hier ablegen
/upload_response/<Rechnungsnummer>/ XML-Antworten pro Verarbeitungsschritt (und konvertierte Dateien)
/rejected Dateien mit fehlgeschlagenen Prüfungen, plus *_error.txt und eine kurze Antwort-XML
/download Empfangene Dateien, wenn Inbound-Rechnungen aktiv sind
/download_status Status-XML zu jeder eingehenden Zustellung
/archive/send Ausgehende Rechnungen nach Versand abgeschlossen, wenn Archivspeicher aktiv ist
/archive/receive Eingehende Rechnungen nach Empfang abgeschlossen, wenn Archivspeicher aktiv ist

Beim Einrichten entstehen außerdem /download_response und /tech. Sie werden für den hier beschriebenen Rechnungsfluss nicht genutzt.

Sie können mehrere Dateien gleichzeitig hochladen, einschließlich ZIP-Archive oder Ordner. ZIP-Archive werden entpackt; Dateien aus Unterordnern werden nach upload verschoben (Pfade innerhalb des ZIP werden auf den Dateinamen reduziert). Das Archiv wird anschließend entfernt; leere Unterordner werden nach Möglichkeit gelöscht.

ZIP-Limits: insgesamt 200 MB entpackt, höchstens 1000 Dateien.


Ausgehende Rechnungen

Upload-Ordner

So senden Sie eine Rechnung per SFTP:

  1. Gültige Rechnungsdatei mit korrektem Namen in upload hochladen.
  2. Nach den oben genannten Wartezeiten holt xTool die Datei beim stündlichen Lauf ab (validieren, optional konvertieren, per Peppol, E-Mail oder KSeF senden).
  3. Bei Erfolg wird die Datei aus upload entfernt. Das Dokument ist im Portal sichtbar.

Beispiel-Dateinamen:

  • INV2020_158.xml
  • INV2020_212.pdf
  • invoice+receiver@webware24.de.xml
  • 68451+fa3.xml
  • 68451+xrech_ubl.pdf
  • 603275+fa3.pdf

Upload-Response-Ordner

Pro verarbeiteter Rechnung werden eine oder mehrere Antwort-XML-Dateien in upload_response/<Rechnungsnummer>/ geschrieben — in der Regel eine pro Verarbeitungsschritt (Validierung, Konvertierung, Upload nach xTool, Versand). Der Unterordner heißt nach der Dokumentnummer aus der Rechnung, sofern sie gelesen werden kann; sonst nach dem Dateinamen ohne Erweiterung.

Als Schrittstatus gibt es Upload Accepted / Upload Rejected, wenn das Dokument in xTool gespeichert wird. Schlägt die Validierung nach der Konvertierung fehl, schreibt xTool trotzdem Conversion Rejected (mit Fehlern), speichert das konvertierte Dokument in xTool als ungültig, schreibt Upload Accepted und versendet nicht sowie verschiebt die Datei nicht nach rejected.

Bei Raw PDF + Formatcode sind typische Schritte Validation Accepted, Upload Accepted (Raw PDF), dann Recognition Accepted oder Recognition Rejected. Bei Recognition Rejected überspringt xTool den Versand und entfernt die Datei aus upload, ohne sie nach rejected zu verschieben — wie beim Konvertierungsfall oben.

Schritt-Antwortdateien heißen:

<Format>_<Unix-Zeitstempel>_<eindeutig>.xml

<eindeutig> ist eine kurze Zufalls-ID, damit mehrere Berichte in derselben Sekunde sich nicht überschreiben.

<Format> ist der interne Formatcode, z. B. peppol_bis_billing.invoice.3_0.xml_ubl oder ksef_fa.invoice.3_0.xml — kein Kurzname wie FA3.

Nach erfolgreicher Konvertierung wird die konvertierte XML im selben Unterordner gespeichert als:

<Original-Stamm>_<Unix-Zeitstempel>_converted.xml

Schlägt Validierung oder Konvertierung fehl, wird eine Antwort mit Status Validation Rejected oder Conversion Rejected und einem <Errors>-Block im selben Unterordner geschrieben; die Originaldatei wandert danach nach rejected.

xTool kann zusätzlich eine Zusammenfassungsdatei <Original-Stamm>_<Unix-Zeitstempel>_<eindeutig>_response.xml mit Status VALIDATION_ACCEPTED oder VALIDATION_REJECTED schreiben.

Rejected-Ordner

Dateien, die vor oder während der Verarbeitung scheitern (nicht unterstützte Erweiterung, leere Datei, ungültige Zeichen im Namen, unbekannter Formatcode, doppelter Inhalt, Datei größer als 50 MB, Fehler bei Validierung/Konvertierung/Versand), werden nach rejected verschoben. Der Originalname bleibt nicht erhalten: Die Datei heißt danach:

<Original-Stamm>_<Unix-Zeitstempel><Erweiterung>

Pro Ablehnung schreibt xTool außerdem:

<Original-Stamm>_<Unix-Zeitstempel>_error.txt
<Original-Stamm>_<Unix-Zeitstempel>_response.xml

Die Textdatei enthält File, Status (z. B. Validation Error oder Duplicate), Time und Details. Die Organisation erhält zusätzlich eine E-Mail zur Ablehnung.

Beispiel: Original INV2020_144.xml wird zu INV2020_144_1592399949.xml plus INV2020_144_1592399949_error.txt.


Eingehende Rechnungen

Empfangene Rechnungen stehen in der Web-App bereit. Siehe Empfang per Peppol.

Unter Schnittstellen → SFTP-Konfiguration steuert Inbound-Rechnungen, ob eine erfolgreich empfangene Rechnung zusätzlich auf SFTP liegt. Der Standardmodus ist Deaktiviert: es wird nichts geschrieben, bis ein Modus und mindestens ein Inhalt gewählt und gespeichert sind.

Nach erfolgreichem Empfang (Peppol, E-Mail, KSeF, Frankreich oder Slowakei) schreibt xTool die gewählten Dateien nach /download/<Dokumentnummer>/:

Modus Was geschrieben wird
Originaldatei Die gewählten Dateien einzeln
ZIP-Archiv Ein ZIP mit den gewählten Dateien
Separater Ordner Die gewählten Dateien einzeln in diesem Ordner

Als Inhalt sind Original-XML, Anhänge und eine PDF-Darstellung möglich. Eine Statusdatei /download_status/<Dokumentnummer>_<Zeitstempel>.xml enthält den Status SUCCESS oder FAILED und die Liste der zugestellten Dateien. Ein gesperrtes SFTP-Konto wird übersprungen.


Archivspeicher

Unter Schnittstellen → SFTP-Konfiguration steuert Archivspeicher, ob erfolgreich verarbeitete Dokumente nach /archive/send bzw. /archive/receive kopiert werden. Es wird nichts geschrieben, bis Archivspeicher aktiviert und gespeichert ist.

Die Ablage erfolgt nur bei Dokumentstatus Versand abgeschlossen oder Empfang abgeschlossen. Fehlgeschlagene Vorgänge landen nicht im Archiv. Das ist unabhängig von Inbound-Rechnungen in /download.

Einstellbar sind:

  • PDF-Visualisierung einschließen — {Rechnungsnummer}_visual.pdf (separate lesbare PDF, keine Kopie der PDF/A-3-Rechnung).
  • Ablage — nur Rechnungsdatei im Stamm von send/receive (Zeitstempel im Dateinamen), Ordner {Rechnungsnummer}_{Zeitstempel}/ oder ZIP {Rechnungsnummer}_{Zeitstempel}.zip.
  • Gruppierung — keine, nach Jahr (/archive/send/2026/...) oder nach Jahr und Monat (/archive/receive/2026/09/...).

Die Rechnungsdatei ist immer enthalten. Stammordner ist nur möglich, wenn die PDF-Visualisierung deaktiviert ist.


Antwortdateien

Jede Schritt-Antwort-XML enthält ein <Status>-Element für diesen Verarbeitungsschritt.

Statuswerte für ausgehende Dateien:

  • Validation Accepted / Validation Rejected
  • Conversion Accepted / Conversion Rejected
  • Recognition Accepted / Recognition Rejected
  • Attachment Embedding Failed
  • Upload Rejected
  • Peppol Accepted
  • Email Accepted
  • KSeF Accepted / KSeF Rejected
  • Rejected (in /rejected bei frühen Fehlern)

Peppol Accepted und Email Accepted bedeuten, dass xTool den Versand angestoßen hat. Das ist keine Bestätigung vom Peppol-Netz oder Mailserver. Es gibt keine Statusdatei Peppol Rejected auf dem Erfolgspfad; ein Sendefehler verschiebt die Datei nach /rejected.

Bei Fehlern enthält die Antwort einen <Errors>-Block. Jeder Fehler ist ein Element <e> (nicht <Error>).

<Format> ist die interne Formatkennung (z. B. peppol_bis_billing.invoice.3_0.xml_ubl), kein Anzeigename. <Sender> und <Receiver> kommen aus dem Dokument, wenn sie gelesen werden können; sonst können sie leer sein oder 0088:0000000000000.

Ausgehend — Validierung erfolgreich

1
2
3
4
5
6
7
8
9
<?xml version="1.0" encoding="utf-8"?>
<Response>
  <File>INV2020_158.xml</File>
  <Time>2020-06-01 09:37:16</Time>
  <Format>peppol_bis_billing.invoice.3_0.xml_ubl</Format>
  <Sender>9930:987654321</Sender>
  <Receiver>9930:123456789</Receiver>
  <Status>Validation Accepted</Status>
</Response>

Ausgehend — Validierung abgelehnt

<?xml version="1.0" encoding="utf-8"?>
<Response>
  <File>INV2020_144.xml</File>
  <Time>2020-06-01 09:37:16</Time>
  <Format>peppol_bis_billing.invoice.3_0.xml_ubl</Format>
  <Sender>9930:987654321</Sender>
  <Receiver>9930:123456789</Receiver>
  <Status>Validation Rejected</Status>
  <Errors>
    <e>Validation error: example message</e>
  </Errors>
</Response>

Frühe Fehler (bevor das Dokument geparst wird) nutzen <Format>Unknown</Format>, leere <Sender> / <Receiver> und <Status>Rejected</Status>. Diese Dateien landen in /rejected.

Ausgehend — Peppol angestoßen

1
2
3
4
5
6
7
8
9
<?xml version="1.0" encoding="utf-8"?>
<Response>
  <File>INV2020_158.xml</File>
  <Time>2020-06-01 09:37:16</Time>
  <Format>peppol_bis_billing.invoice.3_0.xml_ubl</Format>
  <Sender>9930:987654321</Sender>
  <Receiver>9930:123456789</Receiver>
  <Status>Peppol Accepted</Status>
</Response>

KSeF-Konvertierungskette (Beispiel)

Laden Sie eine Peppol-BIS-3-XML-Rechnung mit +fa3 im Dateinamen hoch (z. B. 603275+fa3.xml), validiert xTool die Quelle, konvertiert nach KSeF FA (3), validiert das Ergebnis und übermittelt an KSeF. Die Organisation muss bereits mit KSeF verbunden sein. Feldmapping: Peppol BIS nach KSeF FA(3). Antwortdateien für jeden Schritt landen in upload_response/<Rechnungsnummer>/. Bei Erfolg enthält die Antwort die KSeF-Referenznummer:

<?xml version="1.0" encoding="utf-8"?>
<Response>
  <File>603275+fa3.xml</File>
  <Time>2026-03-31 15:14:00</Time>
  <Format>ksef_fa.invoice.3_0.xml</Format>
  <Sender>9945:PL5252567476</Sender>
  <Receiver>9945:PL9581498695</Receiver>
  <Status>KSeF Accepted</Status>
  <KSeF>5252567476-20260331-6B31C2000000-54</KSeF>
</Response>

Das konvertierte FA-(3)-Dokument wird im selben Unterordner als <Original-Stamm>_<Unix-Zeitstempel>_converted.xml gespeichert.

Bei einem Raw PDF mit +fa3 (z. B. 603275+fa3.pdf) nutzt xTool PDF-Erkennung nach FA (3) statt XML-Konvertierung. Antwortschritte enthalten Recognition Accepted oder Recognition Rejected; es wird keine *_converted.xml in upload_response geschrieben. Gelingt die Erkennung, erfolgt die KSeF-Übermittlung wie nach einer Konvertierung.

Siehe Status-Lebenszyklus.


CSV-Import per SFTP

Legen Sie .csv-Dateien im Ordner upload ab. Jede Datei muss eine Rechnung oder Gutschrift im Format xTool CSV v1.0 enthalten. xTool nutzt denselben Importer wie Web und API, wandelt das Ergebnis ins interne Modell und fährt mit Validierung und Versand wie bei jeder anderen Datei fort.

Einen Formatcode (+fa3, +xrech_ubl, …) anhängen, wenn vor dem Versand konvertiert werden muss. Eine E-Mail-Adresse im Dateinamen bewirkt Versand per E-Mail nach dem Import.

Peppol-Absender und -Empfänger müssen in den CSV-/Dokumentdaten stehen, nicht im Dateinamen. Segmente, die wie Peppol-IDs aussehen, werden nicht für die Adressierung verwendet.

Siehe Dokumente importieren — SFTP und CSV-Importformat.


Nächste Schritte

← Dokumente importieren · Per Peppol versenden