In this article, we explain the new logic for processing bank transactions via a clearing account and outline the differences between the previous and the new logic.
Overview:
- Introduction
- Problems with the previous logic
- Correctness of temporal booking data
- New logic for booking via clearing accounts
- Bookings via clearing accounts
- Transfer to the general ledger
- Marking irrelevant bank bookings
- Activation of the new feature
Introduction
The new feature for processing bank transactions via a clearing account was designed and developed based on customer feedback, specifically from some enterprise customers. The feature aims to facilitate the processing of bank bookings by first booking all recorded bank transactions to a clearing account before they are assigned to members (= debtors) from the clearing account.
Problems with the previous logic
The complete recording and booking of all transactions in a company's bank accounts is crucial for accounting. Until now, however, Magicline only booked transactions that could be assigned to a debtor, i.e., a member. This mainly concerned incoming transfers from members as well as return debits that could be assigned to a previous direct debit. Other transactions, such as transfers between the company's bank accounts, account maintenance fees, or transfers not from members, were not recorded in Magicline. Although these transactions were recognized, they were discarded and not booked due to the lack of assignment options.
This procedure led to two major problems:
Double booking: Since the bank accounts are recorded in both Magicline and the general ledger ( e.g., DATEV), double bookings may occur when transferring bookings from Magicline to the general ledger. While the general ledger books all bank transactions directly and daily, bookings from Magicline are usually transferred monthly. This results in the same transactions appearing twice on the bank account – once from the daily general ledger and once from the monthly Magicline booking.
Incomplete reconciliation: Transactions not recorded in Magicline, such as internal money transfers or fees, must be handled directly in the general ledger and assigned to the appropriate accounts. Since these transactions are not booked in Magicline, there is no complete reconciliation between the general ledger and the sub-ledger at the end of the booking period. While the balance of the bank account in the general ledger is correct, there is no detailed overview of all processed transactions. This makes the reconciliation process between the two systems more difficult, and unbooked transactions must be manually reviewed and corrected.
This business transaction is not represented in Magicline and must, therefore, be booked in the general ledger or a designated sub-ledger. Magicline receives the information about this transaction through the imported bank statement and records its existence, but discards the transaction as irrelevant. As a result, the booking described above is not triggered, and the bank account cannot be fully replicated in Magicline.
In summary, the current handling of bank transactions in Magicline resulted in both double bookings and gaps in reconciliation between the general ledger and sub-ledger.
Correctness of temporal booking data
In the current process, incoming transfers, which are assigned to a member after the bank statement has been processed, are booked retroactively to the original bank booking day. This can be problematic if there is a significant time gap between the transfer receipt and assignment, as retroactive bookings are made into a period that may already have been transferred to the general ledger.
The new approach, which decouples the bank booking from the member assignment via a clearing account, simplifies this process. The bank booking and subsequent allocation are booked separately, preventing such retroactive bookings in closed periods. Further details on this can be found in the section Bookings via clearing accounts.
New logic for booking via clearing accounts
To address the challenges of booking bank transactions, we have extended the booking logic and created a central point for managing bank transactions in the finance area with the new banking system.
The core of the feature is the processing of transactions via clearing accounts for each bank account. All bank transactions are booked to this account as soon as they are imported by Magicline. The booking is made on the bank booking day according to the bank statement, ensuring that the bank statement is fully represented and replicated in Magicline. The new system, unlike the old logic, accepts all bookings on the bank statement and creates booking entries for all transactions. This means that all bank bookings are fully recorded and visible as transactions in the banking area, even if the booking is not relevant for Magicline. We will discuss the advantages of this system for reconciliation later.
Bookings remain on the clearing account until they are rebooked to the member (= debtor). The clearing account can be assigned a corresponding account number in the studio bank configuration.
Bookings via clearing accounts
So now the bookings are no longer made directly from the bank to the debtor but via the respective clearing account. The bookings are temporarily "parked" there until they can be rebooked to the correct debtor or sorted out by the user as irrelevant for Magicline.
Compared to the previous booking logic, the only change is that each booking is now routed through the clearing account. However, this separation ensures that the chronological sequence of bookings is correctly represented.
In an example, a bank statement with transactions dated September 1, 2024, is imported. All bank bookings are recorded on the clearing account on their booking day as per the bank statement. This applies to all transactions listed on the September 1, 2024, bank statement. In this example, three business transactions are listed to illustrate the booking logic. They share the common feature that the clearing account is only temporarily debited and is always cleared with the allocation to the debtor.
For return debits and outgoing transfers (e.g., payout of credits to the member), the booking days at the bank and in Magicline usually fall on the same day. This is because these transactions can be automatically assigned to a debtor. The clearing account is immediately cleared with the second transaction, as the reallocation occurs immediately.
To illustrate the advantages of the intermediary clearing account, consider the example of an incoming transfer. The money is received on September 1, 2024, but the reallocation does not occur until October 15, 2024. Why is that? Incoming funds cannot always be immediately assigned to the correct debtor. The reasons can vary: incorrect membership numbers in the reference, a completely blank reference, the account holder not matching the member, or a combination of these reasons. Let's assume the correct member is identified on October 15, 2024, and the allocation of the incoming funds is manually carried out. The funds were received on September 1, 2024, and are booked as such in the general ledger. This is important to ensure the bank statement is booked in a timely and accurate manner. The assignment and thus the booking to the debtor now take place in the October period. Since the September period has already been closed, a retroactive booking to the debtor as of September 1, 2024, would affect a previously closed period and distort it. Probably, this booking will no longer be transferred to the general ledger because you simply did not notice it.
To enable a period-appropriate booking, the reallocation from the clearing account to the debtor is therefore booked on the actual date, October 15, 2024, and thus enters the October period. The bank booking correctly remains in September, and the booking to the debtor and thus the settlement of the member's outstanding receivables falls in October. As a result, the open item is visible until October 14, 2024, and is only closed on October 15, 2024. By booking through the clearing account, these two processes are transparently separated and can be tracked individually through the booking entries.
Transfer to the general ledger
As shown in the section Bookings via clearing accounts, bank bookings are now processed via clearing accounts. Since all bank accounts are already booked in the general ledger, they must also be booked to a clearing account at the customer level. This is necessary in any case because the general ledger does not know the individual members (= debtors) and cannot make its own assignment. Therefore, the splitting of bookings occurs separately in the general and sub-ledger.
When importing bookings into the general ledger, the respective clearing account on the bank account must always be booked as a counter-account to park the transactions. The clearing of the counter-side is then done through the import of bookings from Magicline (= sub-ledger). By assigning transactions from the bank statement to individual debtors, a booking entry is triggered in the studio of the affected member, which includes the clearing account of the affected bank account and the member's account.
The general ledger transactions are processed daily when the bank statement is imported into the general ledger. Although the sub-ledger transactions are also processed daily, they are only transferred to the general ledger at the end of the respective booking period. In our example, two bookings on the clearing account in the general ledger are balanced after the end of the September period with the import of sub-ledger data from Magicline. The incoming transfer is not balanced until the end of the October period and the import of booking data at the beginning of November.
In this example, the clearing account in the general ledger shows a balance of 50 EUR on September 1, 2024. On October 15, the transaction is assigned to a member and can be debited from the clearing account. At this point, the general ledger still shows a balance on the clearing account because the sub-ledger has not yet communicated the booking to the general ledger. On November 1, 2024, the monthly bookings for October are transferred to the general ledger with a batch date of October 31, 2024. Now the booking from October 15, 2024, clears the balance on the clearing account, resulting in a balance of 0 EUR. The booking cycle is now closed, and the clearing account is settled.
As described above, there may also be transactions that cannot be assigned to a debtor in Magicline. These transactions remain on the clearing account and must be manually reconciled and rebooked directly in the general ledger. We have also extended an existing function for this purpose, which makes it easier to find these bookings in Magicline and use them for reconciliation in the general ledger.
Marking irrelevant bank bookings
Magicline already has a function for discarding irrelevant bank transactions. Based on this process, we have made an extension to create more transparency when working with discarded transactions.
In the banking area, the user can access all bank accounts across locations. Below the overview page, there is a detail page for each bank account, showing all transactions on the bank account. In addition to the individual transactions, the user can also view the respective total amounts in debit and credit as well as the balance for the period.
Here, all transactions on the bank account are displayed without exception. In addition to the booking date, the value date, the identification number of the bank statement for the transaction, a category, and the purpose of the transaction are also listed. The amounts for the transaction are shown in the debit and credit columns, along with the status.
Using quick filters and a search function, specific transactions can be easily filtered, e.g., to focus on all unassigned transactions such as booked bank fees at the end of the month. In addition to the filters, the function for discarding transactions has been extended. The search function allows transactions to be found via full-text search in the reference. This allows individual transactions, which a user may want to process in Magicline from the banking program of their house bank, to be quickly found. This function is also helpful when a member contacts and asks why there are still outstanding receivables in their member account, even though the outstanding amount has already been transferred. This is probably because the assignment has not yet taken place, as the member could not be found.
You can define your own reasons for discarding a transaction via a configuration under Settings > Finance > Rejection Reasons. This configuration can be used to systematically specify why a transaction was marked as discarded. These could be reasons like "account maintenance fees," "account transfer," or "payment to service provider." These reasons are saved with the transaction and written to the export. You can use this export to filter discarded transactions quickly and easily at the end of the month and rebook them from the clearing account to the intended account in the general ledger.
The rejection reasons can be configured and assigned across all studios to ensure consistent classification of discarded transactions across all studios.
Using the export function, which also contains various filter options, lists can be exported as Excel files to be used for reconciliation of accounts in the general ledger. By booking via the clearing account, bookings from both the sub-ledger and the general ledger are merged. Ideally, the clearing account will be fully balanced at the end of a period, as all transactions to be booked in Magicline are fully assigned to members, and the remaining transactions in the general ledger have been rebooked to the appropriate accounts or parked in another intermediate account.
Activation of the new feature
With the release of the new feature, nothing will change for you at first. The new configuration for the clearing account will be delivered empty upon release. As long as no clearing account is set, bookings will continue to be made directly to the bank account stored in the studio bank or, if this account is not set, to the fallback bank account in the studio's accounting configuration.
Once you set the clearing account, all bank transactions will run through the new clearing account, and the described booking path will become the standard for all bank transactions of the affected bank account. This allows you to decide for itself whether and when to activate the new path via the clearing account. Only then will the transactions also be displayed in the banking area.
If you choose to test the clearing account on just one of several bank accounts at first, that is possible. The procedure described above applies: all accounts with a clearing account run through this intermediate step, while all others without a clearing account will continue to be booked as before.
Once the clearing account is set, Magicline immediately begins booking transactions via the clearing account. This only affects transactions from the point at which a clearing account is set, not past transactions. It is advisable to make this adjustment at the turn of a period, e.g., on the 1st of a month.