Voor partners: afstemming van betalingen/facturen ondernemers

Vanaf 1 januari 2020 wordt het Dashboard van Mollie vernieuwd. De accounts van onze klanten worden geleidelijk gemigreerd. Voordat we je account migreren naar het vernieuwde dashboard informeren we je daarover per e-mail. Pas nadat je account naar het vernieuwde dashboard is gemigreerd, is onderstaande informatie op jou van toepassing.

Waarom deze veranderingen?

De wereld van online betalingen verandert razendsnel. Klanten hebben steeds meer wensen, willen hun geld meteen ontvangen, en zijn steeds verder geautomatiseerd. Mollie loopt voorop in deze veranderingen en wil koploper blijven om te verzekeren dat jij, als partner, met iedereen zaken kunt blijven doen. Daarom zijn wij de coreprocessen van Mollie aan het veranderen en upgraden, zodat we helemaal klaar zijn voor de toekomst. 

Daarbij is de verhouding tussen betalingen en facturen veranderd.

Een betaling is niet meer op dezelfde manier als voorheen aan een factuur gekoppeld. Bij onze factureringsmethode werden kosten gefactureerd die verband hielden met een of meer betalingen. Dit veroorzaakte verwarring wanneer er betalingen werden verwerkt, kosten werden gemaakt, maar geen betaling werd ontvangen (een betaling kan om verschillende redenen worden gepauzeerd of geblokkeerd). In dat geval zou er geen factuur zijn voor die periode, hoewel er wel kosten waren gemaakt.

Dit factureringsproces is veranderd: er worden voortaan alleen kosten opgevoerd die in een maandelijkse periode in rekening zijn gebracht (bv. van 1 januari 00:00:00 uur (inclusief) tot 1 februari 00:00:00 uur (exclusief) Nederlandse tijd). Het factureringsproces wordt dus losgekoppeld van de betalingen. Vanwege deze fundamentele verandering is de relatie tussen facturen en betalingen veranderd en is de Settlements API aangepast.

In onderstaande grafiek staat een overzicht van deze veranderingen. Zoals je ziet, is bij de oude methode een betaling altijd gekoppeld aan één factuur. Bij de nieuwe methode kunnen voor een betaling twee facturen worden gebruikt.

              Screenshot_2020-03-19_at_20.27.53.png

Overzicht van de wijzigingen

Deze passage bevat een beschrijving van de doorgevoerde wijzigingen waarmee rekening moet worden gehouden.

Nieuw “invoiceId” veld per periode.

Om de ingehouden transactiekosten af te stemmen op de respectieve facturen kunnen partners nu gebruikmaken van het “invoiceId” veld in de Get Settlement respons van de API. 

Voor betalingen oude stijl is er een top-level “invoiceId” veld. Alle kosten die bij zo'n betaling worden opgevoerd, hebben ongeacht de periode betrekking op de factuur die uiteindelijk aan dit specifieke veld wordt gelinkt. In het bovengenoemde voorbeeld omvat de derde betaling inkomsten en kosten die op twee periodes betrekking hebben, maar op één factuur worden opgevoerd.

Voor betalingen nieuwe stijl bestaat dit top-level “invoiceId” veld nog steeds, maar is dit is niet de enige factuur die relevant is voor de kosten die bij deze betaling worden opgevoerd. In plaats daarvan behoren bij de betaling opgevoerde kosten bij een andere factuur naargelang de periode waarin zij zijn gemaakt. In het bovenstaande voorbeeld (rechterkant) heeft de derde betaling betrekking op twee periodes (met inkomsten en kosten) en worden de kosten opgevoerd op twee verschillende facturen.

Daarom is de Settlement API uitgebreid met een “invoiceId” veld voor iedere afzonderlijke periode waarop de betaling betrekking heeft. In het top-level “invoiceId” veld wordt (net als de factuur in het “links”) de oudste factuur die betrekking heeft op deze betaling vermeld (oudste periode).

Beschrijvingen in de Settlements API kunnen verschillen

Wat betreft de betalingen nieuwe stijl kunnen de “description” en “method” velden andere waarden te zien geven dan eerder het geval was. Dit heeft te maken met de grotere fijnmazigheid van de administratie of kan het gevolg zijn van een verbetering van de beschrijvingen of de vertalingen daarvan.

Vaste en variabele kosten zijn niet langer opgesplitst.

In de Settlements API heeft ieder onderdeel onder “costs” een bijbehorend “pricing” veld met een specificatie van de vaste en variabele kosten. Voorheen werden deze twee afzonderlijke kostenelementen getoond wanneer Mollie een bedrag inhield voor vooruitbetaling van kosten met een vaste en variabele component. Het ene element bevatte alleen de vaste kosten (met de variabele prijs ingesteld op 0) en het andere element bevatte alleen de variabele kosten (met de vaste prijs ingesteld op 0).

Bij de betalingen nieuwe stijl worden kosten met zowel een vaste als variabele component gewoon op één regel getoond met vermelding van de vaste en variabele prijs.

Toevoeging: de Invoice Compensation

In ons nieuwe salderingssysteem worden betalingen in real time verrekend met het saldo en brengen wij de kosten meteen in mindering op de afschrijving af (d.w.z. vooruitbetaling van de kosten). Daarom moet het bedrag dat door ons in mindering wordt gebracht een afgerond bedrag zijn.

Aan het eind van de maand, wanneer de ondernemer wordt gefactureerd, komen deze individuele afrondingen mogelijk niet overeen met het totaalbedrag van de factuur, dat immers anders kan zijn afgerond als gevolg van sommatie of btw-berekening.

In een dergelijk geval heeft de ondernemer meer vooruitbetaald dan het factuurbedrag. Maar dat is geen reden voor bezorgdheid: we boeken het te veel betaalde bedrag meteen terug naar het saldo van de ondernemer. Dit gebeurt onder de naam “Invoice Compensation” (factuurverrekening). Het verschuldigde bedrag op de factuur zal daarom nul luiden. 

Deze factuurverrekening is noodzakelijk om tot een evenwichtig factuurtotaal te komen in de boekhouding. De factuurverrekening is te vinden in onze interface, Settlement API, of Exports (MT940 / CODA).

NB:

  • Exports: De factuurverrekening van een factuur over de periode januari is te zien in de volgende periode, omdat dat de periode is waarin de factuur wordt aangemaakt en het geld wordt bijgeschreven bij het saldo van de ondernemer.
  • Settlements API: De factuurverrekening van een factuur over januari is te zien in de periode januari, omdat deze gelinkt moet zijn aan de invoiceId die wordt gerestitueerd voor die periode.