Nordlet

← Dokumentation / Leitfäden

Bank- & Zahlungsimporte

camt.053-Auszüge, Stripe-CSV, PSP-Abwicklungsabstimmung und benutzerdefinierte JSON-Feeds.

Alle Importe landen als Banktransaktionen auf einem Bankkonto (bank/accounts/create). Transaktionen besitzen eine externalId; ein erneuter Import derselben Datei ist sicher, da Zeilen, deren (bankAccountId, externalId) bereits existieren, übersprungen und im Zähler skipped ausgewiesen werden. Importierte Transaktionen beginnen im Status new und werden nur dann im Hauptbuch verbucht, wenn sie zugeordnet wurden (bank/transactions/match, mit bank/transactions/suggest-matches für Kandidaten).

Die Web-App stellt dieselben Importe unter Bank → Datei importieren bereit (Dateiupload, Vorlagenauswahl).

Eine falsche Zuordnung wird mit bank/transactions/unmatch rückgängig gemacht (Zuordnung aufheben unter Bank → Transaktionen). Verbuchte Buchungen werden niemals bearbeitet oder gelöscht: Eine Zahlung, die einer Rechnung zugeordnet wurde, oder eine Zeile, die von einer Importvorlage auf ein Konto gebucht wurde, erhält eine Stornobuchung, bei der sich jede Buchungszeile auf der gegenseitigen Seite befindet, datiert auf date (Standard: heute, und niemals vor der ursprünglichen Buchung). Der bezahlte Betrag und der Zahlungsstatus der Rechnung verringern sich um den Betrag dieser Bankzeile. Eine Zeile, die mit einer Zahlungsdienstleister-Abwicklung (PSP settlement) verknüpft ist, wird lediglich getrennt, da die Abwicklungsbuchung zum Stapel gehört. Die Zeile kehrt zum Status new zurück und kann erneut zugeordnet werden. Das Stornodatum muss in eine offene Rechnungslegungsperiode fallen.

Importvorlagen

Eine Importvorlage benennt eine Datenquelle, listet die von der Quelle gelieferten Felder auf und ordnet die geldwerten Felder Hauptbuchkonten zu. Vorlagen werden unter Bank → Importvorlagen und über bank/import-templates/create|update|delete|get|list verwaltet.

POST /v1/bank/import-templates/create
{
  "name": "Stripe payments export",
  "type": "stripe",
  "fields": [
    { "name": "id" },
    { "name": "Created date (UTC)" },
    { "name": "Amount" },
    { "name": "Fee", "accountCode": "6800" },
    { "name": "Amount Refunded" }
  ],
  "metaFields": ["order_id"]
}
  • type ist entweder stripe, iso20022 oder bank_connection.
  • Jedes Feld verfügt über einen name und einen optionalen accountCode. Nur geldwerte Felder akzeptieren ein Konto: Stripe Amount, Fee und Amount Refunded; camt.053 Ntry/Amt; Bank-Feed transaction_amount.amount. Das Konto muss im Kontenplan vorhanden sein (legen Sie es mit ledger/accounts/create an).
  • fields kann weggelassen werden; in diesem Fall wird standardmäßig die Standardspielfeldliste des Typs verwendet: die Spaltennamen der Stripe-Datei Payments → Export (ohne die 19 Card …-Spalten, die das Formular standardmäßig ebenfalls unmarkiert lässt), die camt.053-Elemente, die jeder Auszug enthält (Stmt/Id, Stmt/Acct/Id/IBAN, Stmt/Bal/…, Ntry/Amt, Ntry/CdtDbtInd, Ntry/Sts, Ntry/BookgDt), oder die Attribute, die ein PSD2-Bank-Feed pro Transaktion zurückgibt. Fügen Sie Einträge hinzu oder entfernen Sie sie, damit sie zu Ihrer Datei passen: Der Importer liest außerdem die optionalen camt.053-Elemente Ntry/ValDt, Ntry/NtryRef, Ntry/AcctSvcrRef, Ntry/AddtlNtryInf, TxDtls/Refs/EndToEndId, TxDtls/Refs/TxId, TxDtls/RltdPties/Dbtr/Nm, TxDtls/RltdPties/DbtrAcct/Id/IBAN, TxDtls/RltdPties/Cdtr/Nm, TxDtls/RltdPties/CdtrAcct/Id/IBAN, TxDtls/RmtInf/Ustrd und TxDtls/AddtlTxInf.
  • Ein Stripe-Feld Customer Email kann den Wert "createPartner": true enthalten. Der Import erstellt daraufhin für jede E-Mail-Adresse in der Datei, für die kein bestehender Partner existiert, einen Kunden (Partner vom Typ natürliche Person, als Kunde markiert), wobei Customer Description als Name (oder die E-Mail-Adresse, falls dieses leer ist) und die Spalten Card Address … als Adresse verwendet werden, sofern die Datei diese enthält. Bestehende Partner werden anhand der E-Mail-Adresse (ohne Berücksichtigung der Groß- und Kleinschreibung) abgeglichen. Die Antwort gibt die Anzahl in customersCreated aus.
  • metaFields (nur Stripe) listet die Metadatenschlüssel auf, die Ihre Belastungen (charges) enthalten. Stripe exportiert jeden Schlüssel als Spalte <key> (metadata); die Liste ist frei formulierbar und kann lang sein.
  • invoiceItemId (nur Stripe, optional) ist ein Katalogartikel. Wenn dieser gesetzt ist, verweist jede Rechnungs- und Gutschriftsposition, die der Import erstellt, auf diesen Artikel (dessen Buchung und, sofern invoiceVatRatePercent leer ist, dessen Steuersatz); der Text der Position stammt weiterhin aus der Belastung.
  • companyMetaField (nur Stripe) benennt einen dieser Schlüssel als Firmenkennzeichen. Wenn eine Belastung den Wert true, 1, yes, company, business oder b2b in dieser Spalte aufweist, ist der für sie erstellte Kunde ein Partner vom Typ Unternehmen anstelle einer natürlichen Person.
  • invoiceMetaField (nur Stripe) benennt einen dieser Schlüssel, zum Beispiel eine Bestellnummer, und invoiceVatRatePercent den Steuersatz für die daraus erstellten Rechnungen. Beim Import wird jede Belastungs- und Erstattungszeile nach dem Wert dieses Schlüssels gruppiert:
    • Ein Wert, der mit einer bestehenden Ausgangsrechnung übereinstimmt – ein Kundenauftrag, dessen externalRef diesem Wert entspricht (ecommerce/orders/create, beliebiger Kanal), oder eine Rechnung, deren fullNumber diesem Wert entspricht – verknüpft die Gruppe mit dieser Rechnung;
    • Ein Wert ohne Rechnung erstellt eine neue: Partner aus Customer Email (wird bei Fehlen erstellt, wie bei createPartner), eine Position pro Belastung (Checkout Line Item Summary oder Description als Text, der Belastungsbetrag als Bruttopreis zu invoiceVatRatePercent), Ausstellungsdatum = das Datum der ersten Belastung, Umsatzsteuerbehandlung aus Unternehmen und Kartenland. Die Rechnung wird sofort ausgestellt und verbucht, und ein Kundenauftrag mit dem Kanal stripe und diesem Wert als externalRef wird erfasst, damit spätere Importe eine Verknüpfung vornehmen, anstatt neue Rechnungen zu erstellen;
    • Jede Belastung in der Gruppe wird anschließend als Zahlung mit der Rechnung abgeglichen (Verbuchung des Zahlungseingangs);
    • jede Erstattung erstellt eine ausgestellte Gutschrift für den erstatteten Betrag gegen die Rechnung und gleicht die Erstattung mit dieser ab. Die Anzahl wird in invoicesCreated, invoicesLinked, creditNotesCreated und paymentsMatched zurückgegeben; Gruppen, die nicht verarbeitet werden konnten (keine Kunden-E-Mail, gemischte Währungen, eine verknüpfte Rechnung, die sich noch im Entwurf befindet oder bereits vollständig bezahlt ist), werden unter warnings aufgeführt und verbleiben als new Banktransaktionen. Ordnen Sie in derselben Vorlage nicht zusätzlich Amount einem Hauptbuchkonto zu: Eine mit einer Rechnung abgeglichene Belastung wird nicht ein zweites Mal verbucht, eine nicht zugeordnete Belastung jedoch schon.
  • Vorlagennamen sind pro Unternehmen eindeutig.
  • camt.053- und Bankverbindungsvorlagen beinhalten dieselben Optionen, die aus dem Auszug anstelle von Stripe-Spalten gelesen werden:
    • Fehlende Partner erstellen: createPartner in der Zeile des Zahlungspflichtigen (TxDtls/RltdPties/Dbtr/Nm, Feed debtor.name) erstellt einen Kunden für jeden unbekannten Zahler eingehenden Geldes; in der Zeile des Zahlungsempfängers (TxDtls/RltdPties/Cdtr/Nm, Feed creditor.name) einen Lieferanten für jeden unbekannten Empfänger ausgehenden Geldes. Partner werden anhand der IBAN (gespeichert in partner_bank_accounts) und anschließend anhand des exakten Namens erkannt; ein neuer Partner ist ein Unternehmen, wenn der Name eine Rechtsform enthält (UAB, MB, SIA, GmbH, Ltd, …), ansonsten eine natürliche Person. Die Anzahl wird als customersCreated (Dateisimport) oder partnersCreated (Feed-Synchronisierung) zurückgegeben.
    • Rechnungen nach Referenz verknüpfen: invoiceMetaField, das auf eine Verwendungszweck- oder Referenzzeile gesetzt ist (TxDtls/RmtInf/Ustrd, TxDtls/RmtInf/Strd/CdtrRefInf/Ref, TxDtls/Refs/EndToEndId; Feed remittance_information, reference_number), gleicht jede neue Bankzeile, deren Referenz, Verwendungszweck oder Beschreibung die Nummer einer offenen ausgestellten Ausgangsrechnung (Gelangend) oder registrierten Eingangsrechnung (Gehend) enthält, ab und verbucht die Zahlung. Wenn die IBAN des Zahlers bei einem Partner gespeichert ist oder der Name des Zahlers dem Namen oder Code eines Partners entspricht, muss die Rechnung zu diesem Partner gehören. Eine Zahlung von einem unbekannten Zahler wird nur dann verknüpft, wenn sie dem verbleibenden Saldo der Rechnung entspricht und die Rechnungsnummer ihr Serienpräfix enthält, sodass eine bloße Nummer wie ein Betrag niemals als Referenz herangezogen wird. Eine Zahlung, die den verbleibenden Saldo übersteigt, wird niemals verknüpft. Zeilen, die diese Prüfungen nicht bestehen, bleiben für den manuellen Abgleich im Status „neu“ und werden in den Warnungen aufgeführt. Mit advanceInvoices: true erstellt eine nicht zugeordnete eingehende Zahlung von einem bekannten Partner eine ausgestellte Anzahlungsrechnung (Typ advance) für den Betrag zum Steuersatz invoiceVatRatePercent oder dem Satz der invoiceItemId und gleicht die Zahlung damit ab; der Partner muss bekannt sein, markieren Sie daher auch die Zeile des Zahlungspflichtigen.
    • Buchungsregeln nach Transaktionscode: Neben Ntry/Amt / transaction_amount.amount verfügt die Feldliste über Regelzeilen Ntry/BkTxCd=CHRG, =INTR, =TAXE, Ntry/CdtDbtInd=DBIT, =CRDT (Feed: bank_transaction_code=…, credit_debit_indicator=…). Eine Zeile wird auf dem Konto der ersten Regel verbucht, die übereinstimmt: zuerst nach Banktransaktionscode-Familie, dann nach Richtung und schließlich die einfache Betragszeile. Regelzeilen werden nicht gegen die Datei geprüft.
    • Bankgebühren-Partner: createPartner in der Regelzeile …=CHRG erstellt einen Lieferanten, der nach der Bank benannt ist (Auszug Stmt/Acct/Svcr/FinInstnId/Nm oder die Bank der Verbindung beziehungsweise der Name des Hauptbuch-Bankkontos), und verbucht jede Gebühr auf diesen Partner.
    • Bankverbindungsvorlagen werden pro Feed-Konto mit bank/feeds/accounts/configure ausgewählt (Bank → Verbindungen in der App), wodermit auch syncSchedule (manual, daily, weekly, monthly) festgelegt wird: Die API synchronisiert konten mit einem Zeitplan eigenständig, sobald deren Periode abgelaufen ist. Vorlagen werden bei jedem bank/feeds/sync angewendet; die Synchronisierungsantwort meldet daraufhin auch posted, partnersCreated, invoicesLinked, invoicesCreated, paymentsMatched und warnings.

Übergeben Sie templateId anstelle von format an bank/statements/import: Der Typ der Vorlage wählt den Parser aus, und die Datei muss jedes in der Vorlage aufgelistete Feld enthalten. Eine Datei, in der eines dieser Felder fehlt, wird mit HTTP 422 und den Namen der fehlenden Spalten oder Elemente abgelehnt. Metadatenfelder müssen nicht zwingend vorhanden sein. Bankverbindungsvorlagen beschreiben einen Live-PSD2-Feed und können nicht für den Dateimport verwendet werden.

Eine ISO-20022-Vorlage liest auch MT940-Dateien: Eine Datei, die mit {1: oder :20: beginnt (oder mit "format": "mt940" gesendet wird), wird als MT940 geparst, und die Referenzabgleichs- und Buchungsregeln der Vorlage werden auf ihre Zeilen angewendet. Die Elementprüfung wird für MT940 übersprungen, und Ntry/BkTxCd=…-Regeln finden auf MT940-Zeilen keine Anwendung, da MT940 keinen ISO-20022-Banktransaktionscode enthält; verwenden Sie stattdessen die Ntry/CdtDbtInd=…-Regeln.

Ein Bankkonto führt eine Währung. Ein Auszug in einer anderen Währung wird mit HTTP 422 abgelehnt (bei einer camt.053-Datei mit Auszügen in mehreren Währungen für dieselbe IBAN wird nur der Auszug in der Währung des Kontos importiert), ebenso wie eine an bank/transactions/import gesendete Zeile mit einer anderen currency als der des Kontos.

Jede Bewegung, die aus einem Feld mit einem accountCode hervorgeht, wird zum Importzeitpunkt als ein einzelner Buchungssatz verbucht: Gelangend belastet das Hauptbuchkonto des Bankkontos und gutschreibt das zugeordnete Konto; Gehend belastet das zugeordnete Konto und gutschreibt das Hauptbuchkonto des Bankkontos. Beträge werden zum Datum der Bewegung in die Basiswährung umgerechnet. Die Banktransaktion wird daraufhin mit diesem Buchungssatz abgeglichen (matchedDocumentType = journal_transaction) und nicht mehr für den Rechnungsabgleich angeboten. Die Antwort gibt die Anzahl in posted aus. Bewegungen aus nicht zugeordneten Feldern bleiben new und werden wie zuvor Rechnungen zugeordnet – ordnen Sie beispielsweise Fee dem PSP-Gebührenaufwandskonto zu und belassen Sie Amount ohne Zuordnung, damit Belastungen weiterhin mit Ausgangsrechnungen abgeglichen werden.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "templateId": "…",
  "content": "id,Created date (UTC),Amount,…"
}

ISO 20022 camt.053 (Open-Banking-XML)

Litauische Banken (Swedbank, SEB, Luminor, Šiaulių bankas, …) ermöglichen den Download von Kontoauszügen als ISO-20022- camt.053-XML über ihr Online-Banking – in der Regel unter Auszugsexport/-download, Format „ISO XML“ oder „camt.053“. Dasselbe Format wird von PSD2-Kontoinformations-APIs zurückgegeben.

POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "camt053",
  "content": "<?xml version=\"1.0\"…>…"
}
  • Eine Datei kann mehrere Auszüge enthalten; die IBAN jedes Auszugs muss zur IBAN des Bankkontos passen (Auszüge ohne IBAN oder
  • Konten ohne IBAN werden im Ist-Zustand akzeptiert).
  • Eintragsreferenzen (AcctSvcrRef/NtryRef, mit Rückfall auf einen Inhalts-Hash) werden zu externalId.
  • Die Antwort gibt auszugsbezogene Metadaten aus: Auszugs-ID, Zeitraum, Eröffnungs-/Schlusssalden, Transaktionsanzahl.
  • Gegenparteiname, IBAN und Verwendungszweck werden pro Eintrag für den Abgleich extrahiert.

Zahlungen in die Gegenrichtung werden über bank/payments/export als pain.001 exportiert.

Stripe-CSV

Export aus dem Stripe-Dashboard – beide Berichte funktionieren:

  • Reports → Balance → Itemized balance change from activity (empfohlen): Spalten balance_transaction_id, created_utc, currency, gross, fee, net, reporting_category, description.
  • Payments → Export: Spalten id, Created (UTC), Amount, Fee, Currency, Description, Customer Description.
POST /v1/bank/statements/import
{
  "bankAccountId": "…",
  "format": "stripe-csv",
  "content": "balance_transaction_id,created_utc,currency,gross,fee,net,…"
}

Erstellen Sie ein dediziertes Bankkonto für Stripe (z. B. Name „Stripe“, SKR03/SKR04-Konto 1200 / 1800 oder ein eigenes Unterkonto) – das Stripe-Guthaben verhält sich wie ein Bankkonto: Belastungen fließen ein, Gebühren werden abgezogen, Auszahlungen übertragen das Guthaben auf Ihr reales Bankkonto.

Importverhalten:

  • Jede Bilanztransaktion wird zu einer Banktransaktion für den Bruttobetrag (externalId = Bilanztransaktions-ID).
  • Eine nicht-これで (nicht-null) Gebühr wird zu einer zweiten Transaktion mit umgekehrtem Vorzeichen (externalId = <id>:fee, Gegenpartei „Stripe“), sodass Gebühren getrennt vom Umsatz als Aufwand abgeglichen/verbucht werden können. Auf Rückerstattungen erstattete Gebühren kommen als positive Beträge herein.
  • Auszahlungszeilen werden als einzelne negative Transaktionen importiert; gleichen Sie diese mit der entsprechenden eingehenden Transaktion auf Ihrem realen Bankkontoauszug ab.
  • Zeilen mit Nullbetrag werden übersprungen; das Datum wird aus created_utc (UTC) übernommen.
  • Zahlungs-Export-Zeilen, bei denen kein Geld geflossen ist, werden übersprungen: Captured = false (Autorisierungen/verzögerte Erfassungen) und Status Failed/Canceled (Fehlgeschlagen/Storniert).
  • Ein nicht-null Amount Refunded (erstatteter Betrag) wird zu einer dritten, negativen Transaktion (externalId = <id>:refund) datiert auf Refunded date (UTC), sodass in Zahlungszeilen eingebettete Teil- und Gesamterstattungen nicht verloren gehen.

PSP-Abwicklungsabstimmung (Stripe-Auszugsberichte)

Um eine Pauschalauszahlung in ihre zugrundeliegenden Aufträge, Erstattungen, Gebühren und Rücklastschriften aufzuteilen, verwenden Sie anstelle des einfachen Auszugsimports die Abwicklungsendpunkte. Es werden zwei Stripe-Exporte akzeptiert (automatisch erkannt):

  • Reports → Payouts → Payout reconciliation, itemized (Berichtstypen payout_reconciliation.itemized.* oder payout_reconciliation.by_id.itemized.*) – exakt, eine Zeile pro Bilanztransaktion; auf Live-Konten bevorzugt.
  • Payments → Export (unified payments) – der Export auf Belastungsebene; funktioniert im Test-/Sandbox-Modus, in dem die Auszugsabstimmung nicht verfügbar ist. Erfasste Belastungen werden nach der Auszahlungs-ID in der Spalte Transfer gruppiert; nicht erfasste/fehlgeschlagene Zeilen werden übersprungen (skippedNotSettled); ein nicht-null Amount Refunded wird zu einer synthetischen Erstattungszeile im Auszahlungsstapel der Belastung – eine Annäherung, da die Erstattung möglicherweise erst in einer späteren Auszahlung abgewickelt wurde. Abgleichsreferenzen stammen aus der Belastungs-ID, PaymentIntent ID, Invoice Number, Client Reference ID und jeder … (metadata)-Spalte (z. B. einer Bestellnummer in den Metadaten).

Eine CSV-Datei kann sich über viele Auszahlungen erstrecken. Stripe lädt den Einzelnachweisbericht als eine Datei pro Abschnitt herunter (…_charge_…, …_refund_…, …_fee_…); importieren Sie alle – Zeilen für eine bereits importierte Auszahlung verschmelzen mit dem bestehenden Stapel (gemeldet im Zähler updated), solange dieser noch nicht verbucht wurde, und die Stapelsummen werden neu berechnet.

POST /v1/bank/settlements/import
{
  "bankAccountId": "…",
  "provider": "stripe",
  "content": "balance_transaction_id,created_utc,…,reporting_category,…,automatic_payout_id,…"
}

Importverhalten:

  • Zeilen werden anhand von automatic_payout_id in Abwicklungsstapel gruppiert – ein Stapel pro Auszahlung, mit Brutto-/Gebühren-/
  • Nettosummen (Summe der Zeile net = der Betrag, der auf Ihrem Bankkonto eingeht). Das erneute Importieren einer Auszahlung wird übersprungen (skipped-Zähler). Noch keiner Auszahlung zugewiesene Zeilen und die payout-Zeilen selbst werden übersprungen und separat gezählt.
  • Jede Belastungs-, Erstattungs- und Anfechtungszeile wird automatisch mit einer Ausgangsrechnung abgeglichen, und zwar in folgender Reihenfolge: die externalRef eines E-Commerce-Auftrags (ein beliebiger Wert aus order_id, payment_intent_id, source_id, charge_id oder einer beliebigen *_metadata[...]-Spalte), eine in diesen Spalten auftretende Rechnungs-fullNumber und – für Erstattungen und Rücklastschriften – die charge_id einer zuvor abgeglichenen Belastung (selbe Datei oder frühere Importe).
  • Überprüfung mit bank/settlements/list / bank/settlements/get; Korrektur von Resteinträgen mit bank/settlements/match { lineId, invoiceId } (oder invoiceId: null zum Aufheben der Zuordnung).

POST /v1/bank/settlements/post { id, date?, commissionPercent? } verbucht den gesamten Stapel als einen ausgeglichenen Buchungssatz und gleicht die zugeordneten Rechnungen aus (paidAmount/paymentStatus, sale_invoice.paid-Webhooks):

  • Belastung des Hauptbuchkontos des Bankkontos für die Nettoauszahlung; Belastung der PSP-Gebühren (settlements.fees, Standard 6800 / SKR03 4970) für einbehaltene Gebühren und Gebührenzeilen.
  • Gutschrift der Forderungen aus Lieferungen und Leistungen pro abgeglichener Belastung; Erstattungen und Rücklastschriften kehren dies um. Die Anwendung ist auf den verbleibenden Betrag jeder Rechnung gedeckelt – ein etwaiger Überschuss landet mit einer Warnung auf dem Verrechnungskonto.
  • Nicht zugeordnete Belastungen: Bei gesetztem commissionPercent werden sie in Provisionserträge (settlements.commissionRevenue, Standard 5001) und eine Verbindlichkeit gegenüber dem Verkäufer (settlements.sellerPayable, Standard 4499) aufgeteilt – das Marktplatzmodell, bei dem eingezogenes Geld größtenteils den Verkäufern gehört. Ohne diesen Parameter werden sie auf settlements.suspense geparkt (Standard 4440, erhaltene Anzahlungen).
  • platform_earning-Zeilen (Stripe-Connect-Anwendungsgebühren) werden auf Provisionserträge gebucht; transfer-Zeilen (Auszahlungen an angebundene Verkäufer) reduzieren die Verkäuferverbindlichkeit.
  • Alle vier Konten können pro Unternehmen über Buchungsregeln (ledger/posting-rules) überschrieben werden.
  • Eine Zeile, deren Belastung, Gebühr oder Erstattung bereits über den Stripe-Zahlungsexport (bank/statements/import) auf ein anderes Bankkonto importiert wurde, wird nicht auf Gebühren, Forderungen oder Verrechnungskonten gebucht. Stattdessen wird ihr net-Betrag dem Hauptbuchkonto dieses Bankkontos gutgeschrieben, sodass das Stripe-Bankkonto Auszahlung für Auszahlung ausgeglichen wird. summary.clearedAmount ist der auf diese Weise bewegte Gesamtbetrag; eine Zeile, deren Betrag von dem abweicht, was jenes Konto hält, wird in warnings benannt. Wenn nichts zu buchen übrig bleibt, wird der Stapel mit der journalTransactionId null verbucht.

bank/settlements/list und /get geben pro Stapel clearedNet, clearingDifference (Auszahlungszeilen abzüglich der Beträge, die das andere Bankkonto für sie hält; Null, wenn sie übereinstimmen) und clearingOpenCount (Zeilen mit einer Differenz oder einer unverbuchten Bewegung) zurück; /get gibt dasselbe pro Zeile als clearingBankAccountId, clearingBooked, clearingDifference und clearingUnposted zurück. Erstattungszeilen einer Belastung werden zusammen verglichen, da der Zahlungsexport nur den erstatteten Gesamtbetrag enthält. Ein Stripe-Zahlungsexport, der nach der Verbuchung seiner Auszahlung importiert wird, überspringt die Bewegungen dieser Auszahlung und benennt sie in warnings.

Die Umsatzsteuer auf die Provision selbst wird separat in Rechnung gestellt (Ausstellung einer Provisionsrechnung an den Verkäufer); die Aufteilung weist lediglich den eingezogenen Cashflow zu.

Auszahlungen in einer anderen Währung

Der Buchungssatz wird stets in der Unternehmensbasiswährung erstellt, aber eine Auszahlung in einer anderen Währung wird automatisch verbucht – es ist keine manuelle Erfassung erforderlich:

  • Der Stapel rechnet zum Kurs für das Buchungsdatum um (date, mit Rückfall auf das Auszahlungsdatum und danach das heutige Datum). Der Kurs ist der unternehmenseigene Kurs für diese Währung (reference/exchange-rates/set), sofern dieser mindestens so aktuell wie der offizielle Kurs ist, ansonsten der letzte offizielle Kurs an oder vor diesem Datum. Ist kein Kurs an oder vor dem Datum vorhanden, schlägt der Aufruf mit 422 fehl und benennt reference/exchange-rates/sync.
  • Jedes Konto wird zu diesem Stapelkurs umgerechnet, mit Ausnahme von Forderungen aus Lieferungen und Leistungen, die zu dem fxRate-Kurs ausgebucht werden, zu dem die jeweilige Rechnung ausgestellt wurde. Die Differenz zwischen den beiden Kursen wird als realisierte Kursdifferenz auf bank.fxGain (Standard 5803) oder bank.fxLoss (Standard 6803) gebucht, sodass der Buchungssatz dennoch ausgeglichen ist.
  • Die Antwort summary gibt den verwendeten fxRate und die resultierende exchangeDifference zurück, und der Stapel behält den Kurs bei, zu dem er verbucht wurde. Eine abgeglichene Rechnung, deren eigene Währung von der Stapelwährung abweicht, wird nicht ausgeglichen: ihr Betrag geht unter einer Warnung auf das Verrechnungskonto.
  • Eine Importbegrenzung bleibt bestehen: Eine einzelne Auszahlung, deren Zeilen mehrere Währungen mischen, wird mit 422 abgelehnt, ebenso wie ein erneuter Import, dessen Währung von dem bereits für diese Auszahlung gespeicherten Stapel abweicht.

Manuelle / benutzerdefinierte Feeds

Alles andere kann als reines JSON übergeben werden:

POST /v1/bank/transactions/import
{
  "bankAccountId": "…",
  "transactions": [
    { "date": "2026-07-01", "amount": "-25.00", "currency": "EUR",
      "counterpartyName": "…", "description": "…", "externalId": "unique-ref-1" }
  ]
}

Geben Sie pro Transaktion eine stabile externalId an, um erneute Importe idempotent zu halten.