Speeding up the period-end closing process has been a longstanding objective for almost every company. After the US Securities and Exchange Commission (SEC) demanded quicker preparation of financial statements, fast closing became even more important to US public companies.

Faster close enables fast identification, investigation, and elimination of accounting issues. It allows companies to react faster as conditions change, perform better, and make significant improvements in total cost of ownership (TCO).

mySAP ERP introduced a unified data structure with the new G/L and new functions to accelerate closing tasks. Many time-consuming and error-prone closing tasks become obsolete with mySAP ERP’s new G/L. Also new functions were introduced to speed up the closing process. In this article, I will explain these fast closing methods. As many of the closing tasks are organization-specific, depending on your SAP implementation and your requirements you can use some or all of these methods to achieve fast closing in your organization:

• Elimination of reconciliation ledger postings by enabling real-time CO to FI integration
• Elimination of profit and loss (P&L) and balance sheet adjustments with on-line splitting functionality
• Elimination of transfer payables/receivables to Profit Center Accounting (PCA) by using segment reporting in the new G/L
• Elimination of PCA allocation by using new G/L allocations
• Use of a Closing Cockpit to obtain a simplified overview of the entire closing process
• Use of cross-system intercompany reconciliation to speed up intra-group reconciliation processes

Now I will explain how to use these methods.

CO to FI Integration

You can eliminate reconciliation ledger postings by enabling real-time CO to FI integration. Real-time integration from FI to CO has been available since SAP Release R/2. However, when a posting involved crossing company codes or business areas, this information was stored initially in CO and transferred to FI at period close.

The reconciliation ledger, which is maintained in the CO module, was used for CO reconciliation with FI. Transaction code KALC (reconciliation ledger posting) was executed each period end, creating

FI documents to reconcile CO with FI. However, reconciliation postings were not created on the cost-object level and it was not easy to match the FI reconciliation posting with the corresponding CO transaction postings. You can now eliminate the reconciliation ledger entirely by enabling the real-time integration from CO to FI in the new G/L, which you need to set up.

Variants control the real-time integration (Figure 1). To define variants, follow menu path Financial Accounting (New)>Financial Accounting Basic Settings (New)>Ledgers>Real-Time Integration of Controlling Cross-company code with Financial Accounting>Define Variants for Real-Time Integration.

Figure 1

Define variants for real-time integration

Variants define the cases in which CO transactions create financial documents. For example, you can set up a variant so that any cross-company, cross-profit center, cross-segment, and functional area CO postings create FI follow-up documents.

If you try to use the reconciliation ledger after the new G/L is activated, the system gives you the following message: “New General Ledger Accounting is activated. In this way, the real-time integration of Controlling with Financial Accounting is implemented for reconciliation.”

You can suppress this message if you do not want to use real-time integration and prefer to continue using KALC. However, using the reconciliation ledger is not recommended. It is not possible to have segment or profit center details in the reconciliation posting. This causes problems for reconciliation and segment reporting.

You can either use check boxes or Business Add-Ins (BAdIs) or define your own rules to determine the base characteristics for creating FI documents (Figure 1). After defining the variant, you need to assign it to your company code. Follow menu path Financial Accounting (New)>Financial Accounting Basic Settings (New)>Ledgers>Real-Time Integration of Controlling Cross-company code with Financial Accounting>Assign Variants for Real-time integration to company codes.

You use account determination to specify which accounts are used for reconciliation postings. Usually, you transfer primary cost element CO postings to FI with the original cost elements. You must transfer secondary cost element postings via account determination, as secondary cost elements are not defined as G/L accounts. Secondary postings never used to be visible in FI. To define an account assignment, follow menu path Financial Accounting (New)>Financial Accounting Basic Settings (New)>Ledgers>Real-Time Integration of Controlling with Financial Accounting>Account Determination for Real-Time Integration.

To determine the accounts for secondary cost element postings, click on the Change Account Determin. button shown in Figure 2. You see CO transactions and corresponding G/L accounts, shown in Figure 3.

Figure 2

Determine accounts for secondary cost element postings

Figure 3

View CO transactions and corresponding G/L accounts

To determine how many different accounts you need for CO-FI real-time integration, you have to consider the level of detail needed in the financial accounting documents created as a result of the CO postings. You can assign all the CO transactions to the same account or you can assign an account for each transaction or several transactions. In Figure 3, CO transactions using secondary cost elements such as RKIU (assessment) are assigned to Account 499998 whereas CO transactions using primary cost elements such as RKIV (distribution) are assigned to Account 499999.

You can also use account determination for primary cost elements by selecting the Account Determination for Primary CElems option (Figure 2).

As you saw in Figure 1, there is an activation date for defining CO variants (in my example, 01/09/2005). This means the CO postings are not updated in FI before this date. However, you can subsequently transfer CO documents created before the activation date (Figure 4). To do so, follow menu path Financial Accounting (New)>Financial Accounting Basic Settings (New)>Ledgers>Real-Time Integration of Controlling with Financial Accounting>Account Determination for Real-Time Integration>transfer CO Documents Retrospectively.

Figure 4

Transfer CO documents into external accounting

Next, I’ll show you how the real-time integration from CO to FI works. Suppose that you have two cost centers assigned to different profit centers and segments: CCA1 belongs to segment 1 and CCA2 belongs to segment 2. Reposting a line item from CCA1 to CCA2 (Figure 5) prompts the immediate and automatic creation of an FI document to reconcile the associated profit centers and segments (Figure 6).

Figure 5

Repost from CCA1 to CCA2

Figure 6

FI document created by reposting in CO

P&L and Balance Sheet Adjustments

You can eliminate P&L and balance sheet adjustments with the online splitting functionality. Before the new G/L, at period end programs SAP F180 (balance sheet adjustment) and SAP F181 (P&L adjustment) populated the cost objects details in the offsetting lines based on the original cost objects in PCA. Verifying, reconciling, and explaining the adjustment postings were difficult, time-consuming closing tasks. PCA is now integrated into the new G/L accounting with mySAP ERP. The new online splitting and zero balancing functions enable you to create balance sheets not only for company codes but also for entities such as the profit center and segment. (For more information about these new functions, see my article, “Simplify Segment Reporting with the New General Ledger,” in the November/December 2005 issue of SAP Financials Expert). As a result, it is no longer necessary to execute a periodic adjustment posting for balance sheet and P&L statements, as all information is already available on the document level in the new G/L. The elimination of these programs significantly speeds up the closing process.

Transferring Values

You can eliminate the transfer of payables/receivables to PCA using segment reporting in the new G/L. With the new G/L segment reporting functionality, profit center/segment details are updated in the G/L in real time, so you do not need to update PCA to get segment reporting. These reports are now available in the new G/L. It is no longer necessary to transfer balance sheet items to PCA periodically for segment reporting. In other words, you can eliminate transferring balance sheet items to profit center accounting (transaction code 1KEK) from the period closing process.

Although PCA is integrated into the new G/L, it does not mean that you have to turn off PCA. You can still use PCA parallel to the new G/L and continue to use the adjustment programs. See SAP note 826357 for SAP’s recommendation for using the classic PCA when you use the new G/L accounting.

G/L Allocations

You can eliminate PCA allocation by using new G/L allocations. The distribution and assessment functionality that you know from PCA and FI-SL are available within the new G/L. This enables criteria- based amount distributions on the cost-object (segment, profit center) level in the G/L. It uses cycle and segment methods to define distribution and assessment rules (Figure 7). Define the cost allocations in the functional menu Financial Accounting>General Ledger>Periodic Processing>Closing>Allocation. Other functions from FI-SL, such as rollup and planning, are also part of the new G/L. You can execute these tasks directly in the new G/L. You have a unified data structure instead of multiple related databases, which gives you the advantage of eliminating reconciliation tasks.

Figure 7

Define distribution cycle

Cost Allocations

The cost allocations in the profit center and the new G/L both depend on the same logic. However, there are four main differences:

• The statistical key figure is not yet used as a tracing factor in mySAP ERP 2004 although it is available in mySAP ERP 2005.
• Both distribution and assessment create FI postings.
• Assessment accounts should be created in the new G/L and should be different from the secondary cost elements.
• Actual cycles should always be assigned to version 1 because the system updates actual postings in the new G/L in version 1. To manage various planning scenarios you can create planning versions in customizing. To maintain planning versions in the new G/L use transaction GCVP.

The cost center allocations are still in CO and should be performed in cost center accounting.

New mySAP ERP Features

Now I’ll discuss the new functions of mySAP ERP that you can use to accelerate your closing process. Note that these functions are available in mySAP ERP even if you use the classic G/L.

Closing Cockpit

Closing Cockpit is a new concept in mySAP ERP. Delivered as an extension of the Schedule Manager functionality, you use it for scheduling the tasks you execute on a regular basis. It provides a simplified overview of the entire closing process. You can define all your closing tasks on a single screen. You can easily schedule, execute, and monitor your tasks for a selected organizational level. By doing so, the closing process becomes more transparent and you can find errors easily. Closing Cockpit uses the Schedule Manager logic. Follow these four steps to define the Closing Cockpit:

Step 1. Define organizational hierarchies and template. You first need to define your organizational hierarchy so that the system executes the closing process for the organizational structures. For example, if you create the company code as the organizational hierarchy, you can execute the special features at the company code level for the specified company codes during the closing process.

To define or select the organizational hierarchy, follow menu path Financial Accounting>General Ledger>Periodic Processing>Closing>Closing Cockpit (Manage Templates and Task Lists) or use transaction CLOCOC.

Choose option Template/Task List on the menu bar and then choose Organizational Hierarchies to define or select the organizational hierarchy for the template (Figure 8). Later in step 2, the system generates a proposal for a task list template according to the selected hierarchies and organizational objects available in the system. In my example, I have selected controlling area and company code as the organizational hierarchy criteria.

Figure 8

Closing task list template with proposed organizational hierarchies

Step 2. Define folders and create tasks for the closing process. The system generates sample folders to categorize the closing tasks (such as Accounts Payable, Accounts Receivable, G/L Accounting, and Asset Accounting). You can delete or change the existing folders or create new folders. After that, you need to create closing tasks in the folder (Figure 8). To do so, right-click on the relevant folder and select the desired option. You can also copy and change an existing template.

mySAP ERP delivers templates in the standard business context for month-end closing (template 1-FC- MONTH) and year-end closing (template 1-FC- YEAR) that you can map to your own organization.

To add a new task, select the task folder, click on the right mouse button, and choose Add Task (Figure 8). A task dialog box appears in the system and you can choose from four task types. You can define all the steps in the overall process in the task list template as a note, transaction, program (with or without a variant), or a flow definition.

For example, you can add the G/L Actual Distributions task to be performed by the system under Financial Accounting folder as a transaction. This way, users can navigate to the required transaction FAGLGA35 from the Closing Cockpit directly (Figure 9).

Figure 9

Add a task in the dialog box for Closing Cockpit template

You can use the Assignment to Closing Types indicator to derive task lists from any template to filter out those tasks that are relevant for the respective closing types (such as month-end or year-end). In the example below, the G/L Actual Distributions task is defined as relevant to use in month-end closing, quarter-end closing, and year-end closing. In Figure 9, the G/L Actual Distributions task belongs to the Financial Accounting subfolder of the Closing Tasks at Period- End folder.

Step 3. Define dependencies. Programs and transactions included in the task list template are frequently dependent on each other due to business-related or system-related factors. You can define a finish-to-start dependency so that the dependent tasks do not start until the prerequisite task completes successfully. You can do this by dragging and dropping the successor task into the dependencies area. Then you insert the predecessor task by right-clicking on the successor task and choosing Insert Dependency. In Figure 10 you can see that the Period Lock for G/L Accounts task is dependent on tasks Period Lock for Customer Accounts and General Adjustment Postings. The system inserts the periodic lock for customer accounts and adjustment posting tasks as a dependent task for period lock for G/L accounts. These tasks are under period lock for the G/L account task. The system can only start the successor task (Period Lock for G/L Accounts task in my example) automatically if all predecessor tasks have the processing status terminated without errors.

Figure 10

Define task dependencies in the template

Step 4. Create and release the task list. To perform tasks included in a task list, you must create variant parameters. With the separation of the task list template from the task list, you can define the structured process flow as a generic template (task list template) and then make a task list available for processing with specific parameter values.

The task list generated from the task list template automatically updates the time-related program parameters of the selection variants when you enter corresponding header information in the task list. For example, all relevant time parameters of the tasks variants in my task list are updated with a Key Date of 30.05.2006 and a Fiscal Year of 2006 (Figure 11). After releasing the task list, you can start using it for running the closing process.

Figure 11

Creating and releasing the task list

Cross-System Intercompany Reconciliation

You formerly used program RFICRC00 to check customer and vendor documents based on business transactions within a group and to clear any differences necessary for reconciling associated companies. It is no longer available beginning with mySAP ERP 2004. mySAP ERP Financials includes new intercompany reconciliation programs that can load and store documents or totals from SAP and non-SAP systems in a central data repository. These programs provide more functions and flexibility, and enable you to reconcile data across different systems. You can match, reconcile, and recall intercompany transactions related to Accounts Payable and Accounts Receivable, G/L open items, and G/L accounts automatically and reduce manual reconciliation steps.

You execute the intercompany reconciliation task in three main steps. You can reach these steps in the functional menu Financials>General Ledger>Periodic Processing>Closing>Check/Count>Intercompany Reconciliation.

Step 1. Select documents. In this step, the system selects the intercompany items automatically from both SAP and non-SAP systems. Non-SAP system open items are selected via Remote Function Calls (RFCs). The system transfers the selected open items to the reconciliation database.

Step 2. Assign documents. After the system transfers selected documents to the reconciliation database, the second step is to match the intercompany open items automatically. The rules for automatic document assignments are in the configuration. The system should transfer intercompany documents automatically to the reconciliation database before matching the documents.

Step 3. Reconcile documents manually and trigger adjustment postings. You can reconcile documents that are not reconciled automatically in this step. You can match the items manually and create an email-based notification for the unbalanced items.