Hi Joachim,
The basic business process for the components you mentioned is as follows:
- Every day payments are processed via the given payment provider
- At the end of the day the sum of all payment minus the cost the provider takes into account is transferred to the bank account of the my organization.
- An overview of the individual payments + costs is made available by the payment provider via a file (e.g. Ingenico) or an API (e.g. PayPal)
Without the functionality of the components an user should perform the following tasks:
- When matching a bank statement the total payment amount should be transffered to a designated balance account (credit).
- After receiving the payout specification a general entry should be made so the designated balance account is in balance (debit), the costs are booked (debit) and each invoice that is payed is booked (credit)
The journal entry scheme is as follows for the two steps mentioned above
Step 1 - Journal = Bank
| Ledger account | Debit | Credit | |
|---|---|---|---|
| Bank | 10.000,- | ||
| Balance account payment provider | 10.000,- |
Step 2 - Journal = General
| Ledger account | Debit | Credit | |
|---|---|---|---|
| Balance account payment provider | 10.000,- | ||
| For each payed invoice - Debtor account | 11.000,- | ||
| Cost payment provider | 1.000,- |
The first step is often automated by creating a bank template. The second step is where the application can really make the difference. The process in the reconciliation components tries to reduce the manual labour for an user by:
- Importing a payout + the transactions of a payout
- Finding the bank transaction based on the pay out reference
- Matching all the imported transacties to an invoice
- Reconciliating the designated balance accounf for the payment provider