Learn a way of using a standard business transaction event (BTE) to reduce the number of postings to the dummy profit center and the consequent need to reclass these (incorrect) postings. Organizations that have implemented the classic general ledger and have activated Profit Center Accounting (EC-PCA) are advised to implement this BTE to significantly curtail the dummy profit center postings and, more importantly, avoid any discrepancies between the classic general ledger and the EC-PCA ledger.
Key Concept
Profit center determination depends on accurate data entry and master data mapping, as well as completing several steps in the configuration. If one or more of these steps are incomplete, then the document posts to a dummy profit center configured in the system. It is a general practice to review all the dummy profit center postings at month end and reclassify them to the correct profit center so that you end up with complete, accurate Profit Center Accounting (EC-PCA) reporting that reflects the same picture as that of the SAP General Ledger. If your postings are entered to the correct profit center in the first place, you do not need to spend additional time and effort reclassifying incorrect entries.
The Profit Center Accounting (EC-PCA) module is a statistical component that allows summarization of profit and loss (P&L) and balance-sheet data according to profit centers. These profit centers usually reflect the internal structure of areas of responsibility within a particular organization, thereby allowing profit calculation of a company within a company. EC-PCA data in some form is frequently used for external or internal reporting. Therefore, the data in this ledger needs to be accurate and complete.
The Technical Mechanics of Profit Center Determination
The system has a standard algorithm that takes into account the hierarchical priority of profit center determination. The profit center is assigned either dynamically, based on certain characteristics in the document, or indirectly, based on assignments in a preceding document (e.g., a goods receipt takes into account the assignment on the purchase order). It is important to keep in mind that in the former scenario, the currently assigned profit center is always used, but in the latter scenario, any assignment changes after the date of the preceding document are not considered.
For every posting, you need to complete several checks before posting the document in the final profit center. I describe these checks in order of priority.
The first check is to verify whether the profit center has been entered manually by the user. The user enters a profit center in the line item of the transaction, such as through transaction code FB50 (journal entry), FB60 (non-purchase order [PO] vendor invoice), or MIRO (PO vendor invoice). The system then determines whether an input value has been entered in that field.
The second check is substitution maintenance. To complete this check, execute transaction code GGB1. The system then checks to determine if there are substitution rules set up in the system to default profit centers. Figure 1 shows a sample substitution rule used to default profit centers based on certain prerequisite criteria.

Figure 1
A sample substitution rule
The third check is to see if data is posted to a cost or revenue element. The profit center is derived from the real cost object in the posting (in cases in which there is more than one cost object on the line, the statistical object is ignored). To change the cost center, execute transaction code KS02 and follow menu path Accounting > Controlling > Cost Center Accounting > Master Data > Cost Center > Individual Processing > KS02 Change Cost Center). To display the cost center execute transaction code KS03 and follow menu path Accounting > Controlling > Cost Center Accounting > Master Data > Cost Center > Individual Processing > KS03 Display Cost Center. For example, using transaction code KS02 or KO02, you can maintain the Profit Center in the cost center master record or internal order master record. As shown in Figure 2, the profit center maintained (example COS-PROF) can then be populated (derived) on the line item of the financial posting.

Figure 2
The cost center master record
The fourth check is to see if data is posted to a balance sheet account and no profit center has been derived from any of the methods mentioned in the previous checks. The system checks to see if the account has been set to transfer to EC-PCA (transaction code 3KEH – Figure 3) and checks if there is a default profit center mapped to the account (transaction code 3KEI – Figure 4). To configure the default profit center, execute transaction code 3KEH and follow menu path Controlling > Profit Center Accounting > Actual Postings > Choose additional balance sheet and P&L accounts > Choose accounts. In the screen that appears (Figure 3), you can assign the default (dummy) profit center the system derives if it is unable to obtain a profit center from other master data as explained above. This can be done by specifying a default profit center for each general ledger account (or a range of accounts) as shown in Figure 3. Click the save icon (not shown) to save your entries.

Figure 3
Configure the default profit center
To map the default profit center to an account, execute transaction code 3KEI and follow menu path Controlling > Profit Center Accounting > Actual Postings > Choose additional balance sheet and P&L accounts > Derivation rules for finding the profit center. In the screen that appears (Figure 4), you assign the default profit center to be derived based on the general ledger account and company code. This step allows you to derive a different profit center for the same account, based on company code.

Figure 4
Assign the default profit center by account
The fifth check is for other balance sheet items, including:
- Payables and receivables that get their profit centers from the offsetting lines of the invoices (transaction codes F.5D and 1KEK)
- For work in process, the profit center is derived from the work breakdown structure (WBS) element or production order
- Material stocks derive their profit centers from the material–plant combination
- Asset entries get their profit center from the asset master record
- Sales order stock and project stock get their profit centers from the sales order and WBS element, respectively
The sixth check is for a dummy profit center. If no profit center is derived through any of the preceding methods mentioned, then the preconfigured default (dummy) profit center (transaction code 3KEH) is populated in the document.
What Can Go Wrong?
In an ideal scenario using the classic general ledger, EC-PCA data is expected to be in sync with the classic general ledger and the controlling ledger, with which it interfaces in real time. However, because of errors in configuration, incorrect or incomplete data entry, incomplete or incorrect master data mapping, and faulty business processes (e.g., off-timing execution of transactions), it is not uncommon to find discrepancies between these ledgers and also postings made to the incorrect or dummy profit centers. Such incorrect postings need to be reclassified manually per accounting period, which is a tedious, time-consuming, error-prone process.
Making any changes to default profit centers involves making configuration changes, which, owing to the organization’s IT procedures, can be time-consuming and come with several administrative hurdles. Therefore, having a way to make these changes in production directly (without compromising the integrity of the system) can offer significant value and time savings to the finance and accounting departments. Implementing business transaction event (BTE) 00001020 can help you prevent some of the errors in configuration, data entry, or master data mapping mentioned above. I describe this BTE in the next section.
BTE 00001020 to Post Document: Prior to Final Check
A BTE has a predefined interface that allows you to add additional functionality using a custom function module. The BTE that I describe in this article is triggered prior to completing the document and falls between the methods mentioned in the fifth and sixth checks listed above. This BTE is accessed once per posting (similar to validations) and is triggered before the system assigns a document number.
You use transaction code FIBF to search for the BTE mentioned above (00001020), to activate it, and to develop the custom function module. You can search for this BTE by selecting the Info System (P/S) option under Environment in the top menu. This action directs you to the Business Transaction Events: Publish & Subscribe Interfaces screen that displays the list shown in Figure 5. From this list, you can highlight event 00001020 and then view the sample function module or the documentation for this BTE. To do this, click the Sample function module or Documentation button.

Figure 5
List of BTEs retrieved from a search
You can view the list of processes shown in Figure 6 by executing transaction code FIBF and selecting the Infosystem (Processes) option under Environment in the top menu of the initial screen (not shown). The system then takes you to the Business Transaction Events: Process Interfaces screen (Figure 6) that displays a list of process interfaces. From this list, highlight the process 00001120 and then view the sample function module or the documentation for this process by clicking the Sample function module or the Documentation button.

Figure 6
Results of a search for the process interfaces for BTE 00001020
For my example, click the Sample function module button for process 1120 and create a Z-function module. Execute transaction code FIBF, and follow menu path Settings > Products > …Of a customer. In the screen that appears, create a new product and activate it by selecting the check box in the Activate column as shown in Figure 7. Click the save icon to save your data.

Figure 7
Create a new product
At this point, you are ready to map the custom function module and the product created in earlier steps to the relevant process (Figure 8). To complete this step execute transaction code FIBF and follow menu path Settings > Process modules > …Of a customer. Populate the fields as shown in Figure 8 and save your entries by clicking the save icon.

Figure 8
Map the function module to the product
The custom function module created can be used to read data from two custom (maintainable) tables:
- Table ZDEFAULTPC: This table is used to maintain a default profit center by company code (a high-level balance-sheet profit center that is one of the higher nodes in the profit center hierarchy – a catch-all profit center node).
- Table ZPCDERIVE: This table (see Figure 9 for technical details) is used to maintain a default profit center by GL account or an account range (see Figure 10 for sample table entries). This table is very similar to the derivation table used in transaction code 3KEI; however, unlike transactional code 3KEI, this table is maintainable in production.

Figure 9
Technical details of the custom table to maintain the PCA parameters

Figure 10
Sample entries in the custom table ZPCDERIVE
A small group of accounting managers or controllers can be provided access to these tables so that any changes to profit center mapping are tightly controlled. The security team may need to create custom authorization objects to help with the previous step; this authorization object is mapped to the user profile of those individuals who can maintain these tables in production.
Based on the entries in these two tables, the BTE derives the relevant profit center for a particular account used in the line item for a particular company code.
Sample Logic for the Custom Function Module or Process
As explained above, the custom function module is needed to incorporate the code to derive the profit center from one or more custom maintainable tables. The skeleton code and logic for a sample function module are shown in Figure 11.
If a record is found in table ZPCDERIVE for the specified company code (BUKRS) and the GL account (HKONT) then
Loop through each line of the document in BSEG
If BSEG-KOART = 'S' and BSEG-XBILK = 'X'
If BSEG-PRCTR = '' or BSEG-PRCTR = 'DUMMY'
Read ZPCDERIVE table for the company code (BUKRS) and the GL account (within the range)
If record found, then BSEG-PRCTR = zpcDERIVE -PRCTR
Figure 11
Sample logic for the custom function module
Once the above steps are complete, the BTE is ready to be tested and used. The BTE will be triggered before a financial document is posted and the correct profit center based on entries in the custom tables is populated in the line item.
Advantages of This Approach
The biggest change (and the biggest value addition) in implementing this innovative approach is that any changes in profit center assignments (either on an account level or at a company code level) are no longer a configuration change; the business is no longer dependent on the organization’s IT department and can make its own changes using the maintainable tables suggested above using custom transaction codes. This saves a lot of time and administrative work, but at the same time, it makes the accounting department responsible for amalgamating this process into the organization’s existing business processes.
Other than the two maintainable tables described above, no additional changes to any transactional processes are required for business users. The table maintenance in itself is also quite straightforward requiring minimal training.
This strategy requires very minimal, if any, tweaks to existing security and roles.
While you are implementing this BTE, it is also important to note the following:
- This approach works as well as the maintenance on the two custom tables. It is important to keep the custom tables updated as new profit centers, GL accounts, and company codes are created.
- The BTE described herein is triggered only in the FI module of the SAP system; transactions posted within EC-PCA, such as to create a profit center document (transaction code 9KE0), transfer program for plan data (transaction code 1KE0), or transfer payable or receivables (transaction code 1KEK) do not trigger this BTE. The only option for these cases would be to do a manual reclassification of these entries within the EC-PCA ledger.
- While following the approach that I describe helps curtail incorrect EC-PCA postings significantly, a few postings are always made to the dummy profit center in certain unique scenarios (for example, in asset accounting or CO-FI reconciliation). Therefore, the need to review the EC-PCA postings at period end is not negated, but the effort is reduced significantly.
The innovative approach that I describe is relatively easy to implement and affords significant value over the longer term as it requires very little training, if any. Considering the manpower and time that EC-PCA document review and correction involves, an effort toward implementing this initiative is well justified.
R. Venkat Balaji
R. Venkat Balaji is a seasoned SAP finance consultant who has been a part of several implementations, upgrades, and support roles at various organizations in the public and private sector.
You may contact the author at rvb@apropos-consulting.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.