Mollie BankEntry

[i6media]

In Exact Online it's possible to connect PSP Mollie. All Payments are automatically imported as BankEntries. Exact automatically assigns Journal 1 to Mollie.

When trying to get Entries, Exact Online outputs nothing:

$bankentry = new BankEntry($connect); dd($bankentry->filter("JournalCode eq '1'", 'BankEntryLines', '', ['$top'=> 1]));

How can we get those Entries?

[remkobrenters]

I looked into this myself recently and I noticed they marked the Mollie account as a different type (16 betalingsdienst). My theory for now is that the BankEntry endpoints only give back data for type 12 bank and not for this relatively new type. As I did not needed the data that hard (was just easier to validate something) I did not dive deeper into it.

Maybe you or someone else who needs this can open a case with Exact Online support to figure out if this is expected behavior and / or how we can get the transactions for the Mollie (and other future payment providers).

[i6media]

I opened a case with Exact Online Support over a month ago, so it's gonna take a while before this issue is gonna reach developers and it will be merged into production.

[remkobrenters]

Clear. Let's keep this one open. Am curious how we can get these entries.

[remkobrenters]

@i6media Any updates yet?

[i6media]

@remkobrenters I got the following answer from Exact Support after months:

Mollie's ledger is not really a bank ledger, but a Payment Provider ledger. This is the reason why you cannot read the data from it using endpoint BankEntries or BankEntryLines either.

You can, however, retrieve the data via endpoint TransactionLines. A single endpoint, a bulk endpoint and a sync of these are available. You can filter by, for example, JournalCode (in the single and bulk endpoints) to retrieve only Mollie's transactions.

Haven't had the time to try it out yet though.

[remkobrenters]

Yeah we went there but we ran into issues to figure out which lines belonged to which settlement because the dates in one settlement can span more days. It also mean you have no access to the opening balance, closing balance etc. In our case the whole Mollie integration (especially the matching) was not working well and we decided to write our own integration from scratch so we had far more control over the matching of data (especially the charge backs, failed payments etc).

[sandervanhooft]

Hi @remkobrenters ,

Can you perhaps share some more insights about your own implementation?

Also note Mollie has a balance reporting API in beta that could be of use here.

[remkobrenters]

What we learned is that the standard Mollie integration works great in normal situations but not if you have lots of transactions and no bank information in Exact for the accounts as it cannot make good matches anymore between transactions, invoices and accounts. Also by default transactions that failed can overlap between settlements and are by default just corrected on the bankEntry without a good relation to the original invoice (or account). Again a scale issue as if you have a couple of them a month it works fine but if you have several a day it results in a lot of manual labor to figure out to which account/invoice it belongs.

In general what we did is we fetch the settlements from Mollie, match them in our platform to the orders/invoices/accounts. Create a bankEntry per settlement with all the lines and than through the XML API we save the matches between the entryLines and other records (also allowing us to nicely match partial gift card payments).

[sandervanhooft]

That's really insightful, thank you for sharing.

Would I be correct in thinking that with the new Mollie Balances API, the Mollie balance movements could perhaps be treated as bank account transactions?

And if that's the case, that would simplify syncing against Exact?

https://docs.mollie.com/reference/v2/balances-api/overview

[remkobrenters]

It sounds promising. I must say that, beside some issues with transactions/failed transactions that overlap dates over two settlements, the settlements API was sufficient for our approach but maybe this new endpoint resolves a part of these issues. Our issue was mainly that the default integration just was not complete enough resulting in hundreds of unmatched or wrongly matched records per day.