Aggregation of lines in bank statement
Here is another blog post describing a nice feature in electronic bank statement processing in SAP. This feature allows you aggregate i.e., compress bank statement line items. Let’s consider the business scenario. In most cases, banks charge you a small fee for each outgoing payment. Depending on the technical capabilities of the bank, you might get one aggregated amount in the bank statement totaling all fees incurred during the day or you might get many lines with bank fees: one for each outgoing payment. Normally, a bank fee is a standardized operation which can be posted automatically. But if there is a standard functionality that will allow us to process such operations in a more optimal way, why not consider it?
I’ve prepared three bank statements in MT940 format for test purposes. The screenshot below shows a typical bank statement. It has two lines representing bank charges. Each line has the amount of 5 UAH.
External BTC code 004 is assigned to a posting rule Z-01. The settings for the posting are described below. As you can see, I’ve activated compression in the bank statement for each side of the posting. Let’s see what impact this will have.
Screenshot below shows the summary of bank statement immediately after upload. As you can see below, the program posted one document and shows that there are compressed lines:
Screen of the bank statement items (i.e., print view) shows that we uploaded a statement with two lines:
When you open the bank statement in FEBAN (or FEB_BSPROC), you can see that there is only one document which is used across two lines:
Accounting posting itself has two lines for a total amount of bank charges:
One interesting, but not obvious limitation is that the program will not copy the note to payee from bank statement into accounting line items. I guess the program cannot decide which text i.e., text from which line of the bank statement to use for accounting posting.
Let’s experiment with the settings next. I adjusted the posting rule and deactivated the compression on debit side:
As you can see, accounting posting looks a bit different: debit posting to GL account representing bank charges is not aggregated, but credit posting is aggregated. Please also note that in this setup, the program filled the item text for the lines representing bank charges. The text was copied from the bank statement note to payee.
Both examples above were based on the posting rule with one posting area. Let’s see what happens when the posting rule has two posting areas. I defined a new posting rule Z-02 and assigned it to BTC code 004. As you can see, I activated aggregation on both (Dr./Cr.) sides for a new posting rule and in both posting areas.
As you can see, the program generated one document per posting area:
The accounting postings follow the settings in the posting rule with only difference that the values are aggregated:
Please also note, how the system is filling the field Assignment (ZUONR) for accounting line items. The logic is slightly different than the standard logic for this field as it is described by SAP. Please check the OSS-note 3077336 “Assignment number for the bank clearing account” for more details.
Values like 00000231, 00000232 or 00000233 represent the key for the bank statement (i.e., FEBKO-KUKEY), whereas values like 0000023200001 provide additional reference to the line item of the bank statement (i.e., FEBEP-ESNUM). Nonetheless, if you’re managing bank subaccounts with open items management, you’ll be able to clear the open items automatically via program SAPF124 (F.13). As you can see, line items on this bank account representing two different posting areas have the same amount & Assignment.
Please note, bank statement will aggregate the accounting documents for bank statement only if you upload it with the option “Post immediately”. Relevant controlling parameter on the selection screen of transaction FF_5 is highlighted below:
Another concluding remark, this might be a simple case and maybe you do not even need to bother about such fine-tuning in the bank statement. But I believe that as consultants we should understand the capabilities of the system, especially in those cases where SAP did not provide sufficient standard documentation.