Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
Bohdan
Active Contributor
Dear SAPers,

Here is a small post that explains how standard SAP logic groups line items for the purposes of interest calculation and how it builds accounting posting for interest calculated on overdue items.

Overview of the scenario


Consider the following scenario: your company is charging the customers the interest on overdue items. The interest is calculated only on those open items that are overdue. From the system perspective, you’re using interest indicator of type “P” (Item Interest Calculation). You can check these settings in transaction code OB46 or via the following menu path:

SPRO → Financial Accounting → Accounts Receivable and Accounts Payable → Business Transactions → Interest Calculation → Interest Calculation Global Settings → Define Interest Calculation Types.


Additionally, your company is calculating interest not only on debit items (i.e., sales invoices), but also on credit items (i.e., credit memos). Relevant functionality can activated under the settings of the interest calculation indicator (transaction code OB82). Alternatively, you can use the following menu path to access the settings:

SPRO → Financial Accounting → Accounts Receivable and Accounts Payable → Business Transactions → Interest Calculation → Interest Calculation Global Settings → Prepare Interest on Arrears Calculation.


As a result, when you execute the interest calculation program (i.e. transaction FINT), the program assigns different transaction types (CREIR vs. DEBIR) to open items. Additional explanations behind the use of these transaction types are provided below (i.e., under “Additional notes”). The screenshot below provides an example of the calculation in test mode.


If you’re using standard GL accounts determination logic, items with transaction type DEBIR will generate the posting of interest income, whereas the items with transaction type CREIR will generate interest expense posting. The screenshot below shows how the posting will look like.


The question is: is it possible to aggregate the posting, so that the program generates only one open items for the net amount of interest receivable? Answer is “Yes”. I’ve reversed the interest run for the month, adjusted the settings, and re-posted the interest run. The posting below shows the aggregated posting. As you can see, the program generated one open item for the net amount of interest receivable, which is offset by one aggregated P&L line for interest income.



Overview of the system configuration


The screenshot below shows the standard system configurations for GL accounts determination. You can check these settings in transaction code OBV1 or via the following menu path:

SPRO → Financial Accounting → Accounts Receivable and Accounts Payable → Business Transactions → Interest Calculation → Interest Posting → A/R: Calculation of Interest on Arrears.


As you can see, there are two transaction keys:
- 1000 which corresponds to interest income (i.e., transaction type DEBIR in FINT).
- 2000 which corresponds to interest expense (i.e., transaction type CREIR in FINT).
Activate the compression of accounting postings as shown on the screenshot below. There is no need to adjust the assignment of GL accounts to account symbols.


In accordance with these settings, the program will aggregate both customer open items & interest income / expense items before the posting. The program will first calculate the net amount for the P&L item and then will fetch the GL account for the relevant account symbol (0001 or 0002).
There might be alternative combination. For instance, you might activate aggregation of customer open items only, while interest income / expense will not be compressed and will be posted to separate GL accounts.

Additional notes


The screenshot of the simulation mode for transaction FINT showed two invoices & three credit memos. If you check the resulting entries carefully, you might wonder why two credit memos were assigned the category DEBIR, whereas only one of them (i.e., 1600000007) was assigned the transaction type CREIR? The explanation is rather simple: standalone credit memos will have the transaction type CREIR, whereas credit memos with the reference to original invoices will have the category DEBIR. Screenshot below shows how the references are displayed in the open item of the credit memo:


From technical point of view, these references are stored in the table BSEG (fields REBZG / REBZJ / REBZZ / REBZT). See the screenshot from SE16N below:


Hope this post was useful and you found something of value. Please comment and let me know if you have any questions or suggestions. Please also check out my profile for other posts on this and related topics.

 

Regards,

Bohdan

P.S. Disclaimer: customer names used in this example were invented and do not represent actual companies.

 
1 Comment
Labels in this area