New General Ledger versus Classic General Ledger

The General Ledger is a repository of all the business transactions relevant for the external
accounting. The General Ledger purpose is to record all the postings (primary and secondary)
and it is integrated with all the other areas of the company.
In the SAP FI Conventional General Ledger its possible to choose the posting level
(company code or corporate group), make automatic posting from other sub-ledgers using the
reconciliation accounts or update the cost accounting areas using the related cost elements.
The SAP system is an integrated system, therefore the posts to G/L can occur in three ways:
from operational transactions, posting transactions in the subsidiary ledgers and transactions
that are originally assigned to the G/L.
The New G/L brings a few advantages comparing to the conventional G/L: an extended data
structure, document splitting, real-time integration between Controlling and Financial
Accounting and new procedures for parallel accounting.1
Document splitting
In the conventional G/L during financial posting expenses and revenues are assigned to profit
centers because the P&L item are assigned to a cost element. The others G/L account (ex.
Payables, Receivables) cannot generate any values for the profit center or any organizational
unit in CO. In a document, a Vendor line item could belong to more then one profit center
depending on which profit center bought goods/ services from it, and it is a fact that should
be reported. For accounting purpose, the Vendor line item belongs to the legal entity that is
responsible for the accrual of expenses dues. All financial postings catered to accounting
requirement of the posting they posted to the legal entity responsible for incurring the
liability. At the month-end, users could execute a series of steps to transfer Vendor, Customer,
Asset and Inventory balances to Profit Centers. During this transfer, the outstanding balance
at the time of transfer would split by profit centre and post to respective profit centers. 2
This process has one disadvantage: the users have to manually split the lines during data
entry in order to have real time information about Profit Centers.
The New G/L has the document splitting functionality. The line items of a financial document
are split in real time according to the assign scenario like profit center or segment.
Below is an example of a vendor invoice in the general ledger view in the classic G/L in
company code 1000 and in the New G/L in company code 0005.

1 AC210 The New General Ledger, pg. 6

2http://veritysolutions.com.au/2011/09/12/document-splitting-new-gl-sap-overview-of-newgl-document-splitting-process/

Figure 1Document in General Ledger view in company code 1000. Document splitting is not activated

Figure 2 Document splitting is activated in company code 0005.

The amount on the Vendor line is split to the Profit Centers using the ratio of the amounts of
the base line items. This is called active split and it occurs when the amounts on the line
items that do not have Profit Centre are split by the system based on preconfigured splitting
rules. When the amounts on the line items that do not have Profit Centre they are split by the
system based on preceding processes. An example is when Vendor Invoice is paid, the Vendor
line items on the payment document are split in the ratio of the original split in the preceding
Vendor Invoice document (passive split).3
The document splitting functionality is delivered with another useful functionality
zero/self-balancing. This functionality enables users to generate a Balance Sheet and Profit &
Loss by Profit Centre. With t-code S_PL0_86000028 we can generate a financial statement

3 http://veritysolutions.com.au/2011/09/12/document-splitting-new-gl-sap-overview-of-newgl-document-splitting-process/

per Profit Center. In the classic G/L is generated only a P&L, in the New G/L is both P&L
and Balance Sheet.

Figure 3 P&L for Profit Center 1402 in Company Code 1000

Figure 4 P&L and Balance Sheet for Profit Center T-3000 in Company Code 0005

In Classic G/L, Balance Sheet line items cannot derive a Profit Center in real time because
they were not posted against cost objects. There is no mechanism to derive the Profit Center
from the offsetting line items either. These line items post to G/L without Profit Center.
At period end, the user has to process two transactions to move these line items to Profit
Centers:
Balance Sheet Readjustment (transaction code F.5D): This transaction assigns Profit Center
number to records which have a blank in the Profit Center field (typically a Receivables/
Payables record). The system does this by looking at the Profit Center on the offsetting
record. The program identified the source document of these items; then it derived the Profit
Center from the Profit Center on the offsetting line item. If the offsetting line item were
assigned to multiple Profit Centers, then the program splits the Sub ledger open item into
multiple line items based on offsetting Profit Centers.

Figure 5 Calculate Balance Sheet Adjustment (F.5D)

After that, the user has to execute a program to bring over these open items from Sub-Ledger
accounts into Profit Center whit t-code 1KEK Transfer Payables/ Receivables.4

Figure 6 Transfer payables and receivables per Profit Center (1KEK)

In conclusion, assigning Profit Centers for all the line items in the documents is possible with
the classic G/L but it requires more processes and cannot offer real-time information.

Real-time integration between Controlling and Financial Accounting

In classic G/L postings made in CO that are relevant to FI are made automatically in FI using
reconciliation postings. These reconciliation postings can be made at any time: you can make
a reconciliation posting at the end of a period or any other time between CO and FI. The SAP
system posts all internal CO postings that apply to all company codes, business areas, or
functional areas. It does this in summarized form and posts them to FI. This involves the
following processes: Periodic allocations (assessment, distribution, transfer
posting); Manual transfer postings to CO (T-Code KB11(N) ); Activity allocations
(T-Code KB21(N) ); Settlement from orders or projects (T-Code KO88 and CJ88).5

4 http://veritysolutions.com.au/2012/07/12/classic-vs-newgl-profit-center-accounting-3/
5 AC210 The New General Ledger, pg. 81

Figure 7 CO-FI manually reconciliation in classic G/L.

During allocations in Controlling, most of the postings created do not affect Financial
Accounting. These postings do not update any G/L account transaction figures; they are
postings within Controlling. If, however, an allocation in Controlling leads to a change in the
functional area or any other characteristic (such as Profit Center or Segment) that is relevant
for evaluations in Financial Accounting, a shift occurs between the affected items in the profit
and loss statement. For this reason, this information has to be transferred to Financial
Accounting. In the New G/L this reconciliation between CO and FI takes place by means of
real-time integration. This mean that Financial Accounting is always reconciled with
Controlling. A document is created in Financial Accounting for each posting in Controlling.
This means that the detailed information contained in the CO documents is always available
in reports in New General Ledger Accounting. This information can be sorted by the
following, for example: Functional area, Cost center or Internal order. 6

6
http://help.sap.com/saphelp_erp60/helpdata/en/66/bc7fd143c211d182b30000e829fbfe/frames
et.htm

Figure 8 CO-FI automatic reconciliation in New G/L.7

Figure 9 CO documents for cross-company code transaction

7
http://veritysolutions.com.au/wp-content/uploads/2012/03/2_COFI-reconciliationpostings.jpg

In the cross-company code transaction example are generated two CO documents: one for
each company code.
Another example of CO-FI real-time integration is reposting a line item in CO. Assuming that
an account assignment was incorrect (the correct Cost Center should be 4279 instead of T114000) in document number 190000003 in company code 005.

Figure 10 Document 19000000003 in company code 0005

We have to repost the line item to the correct Cost Center with t-code KB61. This will
generate the CO document 200193046.

Figure 11 Reposting of line items (KB61)

Figure 12 CO document 200193046. Transfer of cost element from Cost Center T-114000 to 4279

Figure 13 Transfer of Cost element 2112OO from Cost center T-114000 to Cost center 4279.

The transactions within CO generated in real-time an FI document. The amount is no longer

in the balance sheet of Company code 0005 instead it is in the balance sheet of Company
code 1000.

Figure 14 The FI document generated from the reposting in CO.

Figure 15 The balance of the Profit Center 1600, assigned to Company code 1000.

In the New G/L reconciliations postings and the Reconciliation Ledger are not used anymore.
Transaction KALC is no longer available (by default) after the new general ledger is
activated an information message points out the new real-time integration between CO and
FI.

Figure 16 Transaction KALC.

The benefit is a faster Period Close with New GL because: Reconciliation Ledger is not
required; Balance sheet Adjustments are not required; Profit and Loss Adjustments are not
required; Activities related to Special Purpose Ledger are not required; Depreciation posting
is online instead of a batch session.8
Migration to New General Ledger Accounting
Many different migration scenarios are imaginable for the transition from classic General
Ledger Accounting to new General Ledger Accounting, ranging from the straightforward
merge of existing ledgers to a totally new conception of accounting, such as the introduction
of segment reporting for compliance with new accounting principles. In particular in the case
of a new conception of accounting, there are two aspects to the transition to new General
Ledger Accounting: firstly, a conceptual business part, and secondly, a technical part dealing
with the migration of the existing accounting data to the new structures for General Ledger
Accounting.
The new features relate to very extensive changes, the transition to new General Ledger
Accounting is very complex. A comprehensive analysis of the client situation at the outset
8 http://www.infosysblogs.com/sap/2009/08/comparative_analysis_between_n.html

and the detailed planning of the migration are crucial to the success of the migration. SAP
therefore recommend setting up an individual project for the migration, entailing project
phases, milestones, and so forth, and taking the appropriate steps to ensure sufficient testing
and training.
Preparing and performing the steps relating to the technical part of the migration of the data is
of central importance for such a project and must be conducted with extreme caution and
thoroughness to ensure that the principles of orderly accounting are still upheld after the
migration.
To achieve a high degree of safety in this respect, SAP accompanies each migration project
with the SAP General Ledger Migration Service. This mandatory technical service relates to
the standard migration scenarios and contains a scenario-specific General Ledger Migration
Cockpit and service sessions to ensure the quality of the data and of the migration project.
The SAP General Ledger Migration Service supports the following scenarios:

Scenario / Pack 1: Merging of the FI Ledgers

Scenario / Pack 2: Merging of FI Ledgers, Profit Center Ledgers, and/or Special Purpose
Ledgers
Scenario / Pack 3: Merging of FI Ledgers, Profit Center Ledgers, and/or Special Purpose
Ledgers with Document Splitting (such as for reporting at profit center, segment, or business
area level)
Scenario / Pack 4: Merging of FI Ledgers, Profit Center Ledgers, and/or Special Purpose
Ledgers with Switch from Account Approach to Ledger Approach
Scenario / Pack 5: Merging of FI Ledgers, Profit Center Ledgers, and/or Special Purpose
Ledgers with Document Splitting and Switch from Account Approach to Ledger Approach
Scenario / Pack 6: Subsequent Implementation of Document Splitting9
The principles of Migration are: the migration date is always the first day of a fiscal year
(current or future fiscal year) and the year-end closing of the old fiscal year must be complete
before New General Ledger Accounting is activated.

Technical Procedure for Performing the Migration

Determination of the migration objects ("old" OIs and documents from phase 1)

Transfer of balance carry forward (accounts not managed on an open item basis)
If applicable, reposting of balance carry forward values (accounts not managed on an open
item basis)
Preparation of documents from phase 0 (enhancing open items with document splitting
information)
Transfer of "old" open items (customer/vendor accounts, G/L accounts) and simultaneous
build of balance carry forward for relevant reconciliation accounts
Preparation for documents from phase 1 (supplementary account assignment, such as
Segment or Profit Center)
9 Migration to New General Ledger Accounting pg. 13-21

Transfer of documents from phase 1 into tables of New General Ledger Accounting

Reconciliation of the data

Activation of New General Ledger Accounting
Completion of the migration
The phase model consists of three phases:

Conception of new General

Ledger Accounting

Closing the old fiscal year

Use of new General Ledger

Accounting in the production
Closing of Customizing of system
Customizing of new General new
General
Ledger
Ledger Accounting
Deactivation of the update of
Accounting
classic
General
Ledger
Function and integration Closing of Customizing of Accounting (GLT0) after a
tests on new General Ledger the migration
transition period
Accounting in a test system
Closing of the function and Deactivation or deselection
Planning and conception of integration tests on new of other functions (such as
the migration
General Ledger Accounting classic
Profit
Center
Accounting) that are replaced
in a test system
Analysis of the production
by new functions in new
system, in particular when
Analysis of the validation General Ledger Accounting10
document splitting is used
results for the check run on
document splitting
Where
applicable,
Customizing of document Test runs for the migration
splitting
in a test system
Actual migration at the end
Customizing
of
the of phase 1
migration, in particular when
document splitting is used
Activation of new General
Ledger Accounting after
successful migration
10 AC212 Introduction to Migration to New General Ledger, pg. 6-8