The payout straight to the bank
The payout is booked as one receipt. Fees and refunds disappear into the net amount, invoices are closed in bulk or not at all, and what the provider still holds is invisible.
Most online shops on Business Central post payouts straight to the bank, park provider money on a G/L account, or keep it on a customer. Each loses something: the fees, the currency, or the trail. This is the setup Wakakuu runs six payment sources on, and why it holds up.
At any moment: how much does each payment provider owe us, in its own currency? Adyen, Klarna, Avarda and the rest hold your money for days between the sale and the payout. If that balance is not a thing in the ledger, nobody can say whether a payout is missing, short, or simply not due yet.
The payout is booked as one receipt. Fees and refunds disappear into the net amount, invoices are closed in bulk or not at all, and what the provider still holds is invisible.
Works while everything is in one currency. A G/L account keeps its balance in your local currency only, so euros at Adyen become kronor at whatever rate each line was posted at.
Money held by the provider sits among your customer receivables. Payouts and fee lines fill the customer ledger, and applying the right entry gets harder every month.
Business Central already has the right object for money someone else holds for you: a bank account. Treat each provider as one.
ADYEN_EUR, ADYEN_SEK, AVARDA_SEK, VIPPS_NOK. Set the currency code on every account that is not in your local currency, and give them a posting group that points to one G/L account for money held by payment providers.
The order is an invoice, the return a credit memo. Both stay open until the provider's settlement says they are paid.
Payments are applied to their invoices, refunds to their credit memos, and fees go to your fee account. Every line balances against the provider's bank account, which now shows exactly what the provider owes you.
When the money lands, it moves from the provider's bank account to your company bank account. Anything the provider keeps back, a reserve or a negative balance, simply stays on the provider's bank account.
The provider's bank account should agree with what the provider says it holds. Business Central's bank reconciliation works on it the same way it works on your real bank.
The same payout as on our home page: 412 payments, 9 refunds and the day's fees, paid out as one sum.
| Line | Debit | Credit | EUR | On ADYEN_EUR |
|---|---|---|---|---|
| 412 payments, applied to their invoices | ADYEN_EUR | Customers | 191 256,40 | 191 256,40 |
| 9 refunds, applied to their credit memos | Customers | ADYEN_EUR | 1 027,40 | 190 229,00 |
| The day's fees | Payment fees | ADYEN_EUR | 6 024,00 | 184 205,00 |
| The payout lands | Bank EUR | ADYEN_EUR | 184 205,00 | 0,00 |
Before the payout, 184 205,00 sits on ADYEN_EUR: what Adyen owes you, in euros, with every order behind it closed. After it, the bank account is back to zero. If it is not, something is missing, and you can see exactly how much.
A bank account with a currency code keeps its balance in that currency. 184 205,00 euros stays 184 205,00 euros, whatever the rate does in between.
Payment lines applied to invoices, refunds to credit memos, fees on their own lines, the day balanced against the provider's bank account in its currency, and the payout as its own pair to your bank.
Yes, one for each currency a provider settles in. A provider that pays out in euros and kronor gets two bank accounts in Business Central, each with its own currency code.
The same. A marketplace that collects from shoppers and pays you later is a payment provider for this purpose, so it gets its own bank account per currency.
No. Creating bank accounts and a posting group is standard setup a finance user can do.
Yes. At the start of a period, move what is left on the clearing G/L account to the new provider bank accounts with one journal, then post new settlements against them.