Die Welt der Online-Zahlungen verändert sich schnell. Die Kunden haben steigende Ansprüche, wollen sofort Geld erhalten und immer mehr automatisieren. Mollie ist Vorreiter dieser Veränderungen und muss Schritt halten, um sicherzustellen, dass wir Sie als Partner für alle Händler handlungsfähig halten können. Dabei verändern und verbessern wir den Kern von Mollie, damit wir für die kommenden Jahre zukunftssicher sind.
In dieser Hinsicht hat sich das Verhältnis zwischen Abrechnungen und Rechnungen geändert.
Eine Abrechnung gehört nicht mehr wie früher zu einer Rechnung / fällt nicht mehr unter eine Rechnung. Nach unserer alten Arbeitsweise würde unser Rechnungsvorgang nur noch Gebühren in Rechnung stellen, die mit einer oder mehreren Abrechnungen verbunden sind. Dies würde zu Verwirrung führen, wenn Zahlungen bearbeitet wurden, Kosten anfallen, aber keine Abrechnung erhalten wurde (eine Auszahlung kann aus zahlreichen Gründen pausiert oder gesperrt werden). In diesem Fall gäbe es für diesen Zeitraum keine Rechnung, obwohl Kosten anfallen würden.
Dieser Rechnungsvorgang wurde dahingehend geändert, dass nur noch Gebühren berechnet werden, die innerhalb eines Monatszeitraums erhoben wurden (z.B. 01. Januar 00:00:00 (einschließlich) -> 01. Februar 00:00:00 (ausschließlich) auf der Grundlage der Europa-/Amsterdam-Zeit). Sie wird also von den Abrechnungen abgekoppelt sein. Aufgrund dieser grundlegenden Änderung hat sich auch das Verhältnis geändert und wurde die Settlements API angepasst.
Die folgende Grafik bietet einen Überblick über diese sich ändernde Beziehung. Wie Sie sehen können, gehört eine alte Abrechnung immer zu einer Rechnung. Bei neuen Abrechnungen kann eine Abrechnung zu zwei Rechnungen gehören.
Übersicht über die Änderungen
In diesem Abschnitt werden die relevanten Änderungen beschrieben, die eingetreten sind und berücksichtigt werden sollten.
Neues „invoiceId“-Feld pro Zeitraum.
Um die einbehaltenen Transaktionsgebühren mit den jeweiligen Rechnungen zu korrelieren, können Partner jetzt das „invoiceId“-Feld in der Get Settlement API verwenden.
Für alte Abrechnungen gibt es eine „invoiceId“-Funktion auf der obersten Ebene. Alle von dieser Abrechnung gemeldeten Kosten, unabhängig von den Zeiträumen, gehören zu der Rechnung, die mit dieser individuellen Funktion verknüpft wird. Im vorstehenden Beispiel würde die dritte Abrechnung Erlöse und Kosten für zwei Zeiträume enthalten, die jedoch mit einer Rechnung korrelieren.
Für neue Abrechnungen bleibt die „invoiceId“-Funktion auf der obersten Ebene erhalten, aber sie ist nicht die einzige Rechnung, die für die in dieser Abrechnung ausgewiesenen Kosten relevant ist. Stattdessen gehören die in der Abrechnung ausgewiesenen Kosten zu einer anderen Rechnung, je nach Zeitraum, in dem sie sich befinden. Im vorstehenden Beispiel (rechte Seite) hätte die dritte Abrechnung zwei Zeiträume (mit Erlösen und Kosten) und die Kosten würden sich auf zwei verschiedene Rechnungen beziehen.
Aus diesem Grund wurde die Settlements API aktualisiert, um eine „invoiceId“-Funktion in jeden separaten Zeitraum aufzunehmen, der von der Abrechnung gemeldet wird. Die „invoiceId“-Funktion auf der obersten Ebene (sowie die Rechnung in den „Links“) wird mit der ältesten Rechnung gefüllt, die mit dieser Abrechnung verknüpft ist (ältester Zeitraum).
Die textlichen Beschreibungen in der Settlements API können sich unterscheiden.
Bei den neuen Abrechnungen können die Felder „description“ und „method“ andere Werte zurückgeben als bisher. Dies hat mit einer erhöhten Granularität der Berichterstattung zu tun oder mit textlichen Beschreibungen, denen es an Klarheit fehlte oder deren Übersetzung verbessert wurde.
Fixe und variable Kosten werden nicht mehr aufgeteilt.
In der Settlements API hat jedes Element unter „costs“ eine mit ihm verbundene Preisgestaltungseigenschaft, die die fixe und variable Gebühr angibt. Früher hat Mollie bei der Einbehaltung von Geldern für die Vorauszahlung des fixen und variablen Bestandteils einer Gebühr diese unter Verwendung von zwei separaten Kostenelementen ausgewiesen. Ein Element enthält lediglich die fixe Gebühr (mit der variablen Preisgestaltung gleich 0) und ein Element die variable Gebühr (mit der fixen Preisgestaltung gleich 0).
Bei den neuen Abrechnungen werden solche Gebühren mit einem fixen und variablen Bestandteil einfach als eine einzige Zeile mit der erwähnten fixen und variablen Preisgestaltung angezeigt.
Hinzugefügt: der Rechnungsausgleich
Mit unserem neuen Saldosystem werden Zahlungen in Echtzeit auf den Saldo abgerechnet und die Gebühren sofort von der Abrechnung abgezogen (dies entspricht einer Vorauszahlung der Gebühr). Aus diesem Grund muss der von uns abgezogene Betrag ein gerundeter realer Betrag sein.
Wird dem Händler am Monatsende eine Rechnung gestellt, stimmen diese einzelnen Rundungen möglicherweise nicht mit dem Gesamtbetrag der Rechnung überein, der am Ende aufgrund der Summierung oder der Berechnung der Mehrwertsteuer möglicherweise anders gerundet wurde.
In diesem Fall hat der Händler mehr als den Rechnungsbetrag im Voraus bezahlt. Aber keine Sorge, wir überweisen diesen Betrag direkt zurück in den Saldo des Händlers. Dies erfolgt im Rahmen des Rechnungsausgleichs. Der fällige Betrag auf der Rechnung wird daher Null ergeben.
Dieser Rechnungsausgleich ist notwendig, um den Rechnungsbetrag in der Buchhaltung richtig zuzuordnen. Dies ist unter Interface, Settlements API oder Exports (MT940 / CODA) zu finden.
Anmerkung:
- Exports: Der Rechnungsausgleich für eine Rechnung über den Zeitraum vom Januar wird im darauffolgenden Zeitraum angezeigt, da die Rechnung dann erstellt und das Geld auf dem Saldo des Händlers eingezahlt wird.
- Settlements API: Der Rechnungsausgleich für eine Rechnung über den Zeitraum vom Januar wird im selben Zeitraum angezeigt, da sie mit der „invoiceId“ verknüpft sein sollte, die für diesen Zeitraum zurückgemeldet wird.