Discrepancies between FI and Profit Center Accounting (PCA) figures often confuse even the most experienced controllers. The author shows how the transfer of balance sheet A/P and A/R accounts from FI to PCA can produce unexpected and bewildering results. He also explains the logic used to obtain PCA data.
In numerous projects, I have been asked to sort out differences between Profit Center Accounting (PCA) and FI figures and apparent mistakes in PCA reporting. SAP logic at times can be confusing, even to experienced controllers. The issue centers on balance sheet A/P and A/R accounts that are transferred periodically from FI to PCA via transaction 1KEK. They are treated differently than normal P&L accounts or balance sheet accounts that are directly linked to PCA via customizing transaction 3KEH.
Most companies transfer A/R and A/P open items at month-end using transaction 1KEK. Checking during the first posting period does not raise many questions: The G/L is in line with PCA line items and totals. However, once the second month-end is completed, differences appear out of nowhere and this continues during the whole year. PCA line items are not in line with totals anymore and the link with G/L seems dubious. The same type of confusion crops up during month-end allocations: "All reports look OK. But when we run 4KE5 (PCA distribution) in test mode, either cumulative or iterative, I get strange numbers. Therefore we did not run the distribution, but rather made a manual journal entry to reclassify."
Note!
For more information related to the A/R and A/P balances that are transferred with 1KEK, refer to SAP notes 180906 and 181063.
Let's take a look at an example in Table 1. These figures surfaced during my analysis of the dummy profit centers in a company I worked with.
Period 0 | 0 | 0 | 0 | Period 1 | -€ 160,058.22 | -€ 160,058.22 | -€ 160,058.22 | Period 2 | -€ 139,392.64 | -€ 139,392.64 | € 20,665.58 | Period | 0 | 0 | 0 | Period 1 | -€ 160,058.22 | -€ 160,058.22 | -€ 160,058.22 | Period 2 | -€ 139,392.64 | -€ 299,450.86 | -€ 139,392.64 | | | | | Table 1 | A/R postings in G/l and PCA on dummy | |
At first glance, you see an obvious problem in period 2. The total profit center balance in this period does not match the balance on A/R for the period, but the line item report does match. On the other hand, the year-to- date balance for the line item report shows no relation with the G/L figure, but the totals view now provides a match with A/R. When the finance department wanted to distribute the A/R position on this profit center, the test run proposed a total amount of € 20,665.58. However, that would clearly leave a balance on the line item view, instead of providing a zero balance, which was a mystery. In period 1, none of these problems arose.
Once users are confronted with this discrepancy, they often lose trust in the system. In my example, a manual journal was used to reclassify the amount of -€ 139,392.64 that appeared in the line item view. This attempt at making a correction is a mistake. In fact, the figures in Table 1 are absolutely correct. It is the reading of them that is at fault.
Users are accustomed to the way data is presented in FI with the line item report (FBL3N) and the account balance report (FS10N). These reports match and present a full picture of all financial postings to a given account. When they look at the PCA line item (KE5Z) or totals (2KEE) report, they expect to see the same. However, the logic of this report is different. This article shows step by step how the PCA data is obtained.
Period 1
In period 1, A/R shows a balance of -€ 160,058.22 that cannot be allocated to a profit center. During the month-end close, this balance is transferred to the dummy profit center via transaction 1KEK. In PCA, this results in two actions:
- The transfer of -€ 160,058.22 is registered in the line item report. If during 1KEK, you select the option of line items, a line per customer account is created. Therefore, a finance balance is translated into one or more line items. This sometimes confuses users who seek to match actual transactions in A/R with the PCA line item report.
- The PCA 2KEE report does not register the balance for the period, but instead calculates the delta between its last total and the total in the current period. In period one, it posts the total balance of A/R minus the balance on the profit center for the same account in period 0. In my example, this results in a total of -€ 160,058.22 minus 0 = -€ 160,058.22.
The result in PCA for period 1 is thus a line in the line item report of -€ 160,058.22. The total for the period in 2KEE for -€ 160,058.22 matches a balance in A/R of -€ 160,058.22. This strengthens the expectation that these figures should match. In fact, this is an exception.
Period 2
In period 2, and of course in subsequent periods also, the baffling figures arise. A/R now shows a balance of -€ 139,392.64 that will be transferred to the dummy profit center. In PCA, you find the same logic as before:
- The line item report KE5Z registers the balance of -€ 139,392.64 as a line item. The report for periods 1 and 2 shows two lines (balances for period 1 and 2) that total -€ 299,450.86. It is now obvious that you cannot relate this figure in any direct way to the G/L. The often leads to misunderstandings and discussions: "The balance in A/R does not match the total in PCA."
- The 2KEE report shows the update of the total balance. In this case, for period 2, the figure of € 20,665.58 is the difference between the total PCA A/R balance over period 0-1 and the current A/R balance, or -€ 139,392.64 - (0 -€ 160,058.22) = € 20,665.58. Again, this figure has no apparent relationship with either the G/L or the line item report.
From this exercise you can conclude that if you use the PCA totals report for balance sheet accounts, you should always select period 0 – current period to find a match between the balance in G/L and the balance in PCA. This logic should also be used in creating reports based on PCA. The line item report shows the movement of balance sheet account balances within the period for record type 0 (actual postings). This figure should match the A/R balance in the period.
Distributions and Assessments
One final ingredient for possible confusion exists. In assessments and distributions, R/3 uses table GLPCT, the table used by report 2KEE. In my example, distributing 100 percent of A/R on dummy for period 2 results in a figure of € 20,665.58. This is correct given the logic I have just described. However, once the distribution is executed, it creates a line item (record type 2) for € 20,665.58. If a user uses the line item report to check if everything is OK, the result is not a zero balance. Instead, period 2 shows a figure of -€ 139,392.64 (actual posting) and a figure of € 20,665.58 (distribution).
This is why in analyzing A/R and A/P balance sheet positions in PCA, you should always use report 2KEE and table GLPCT. You should also use year-to-date figures because GLPCT updates with a monthly delta posting.
Dr. Stef G.M. Cornelissen
Dr. Stef G.M. Cornelissen, MBA, is an experienced international SAP business consultant from the Netherlands with certifications in FI, CO, and SD. He took part in important international projects involving the large Dutch multinationals. Before specializing in SAP, he worked as a management consultant and was a senior advisor to the Board of Directors of the University of Nijmegen. Stef's academic background is in business administration, economics, and organizational science. He is the owner of Bowstring BV and principal partner at Sperry Associates.
You may contact the author at info@bowstring.nl.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.