S/4 

HANA Finance 
On Premises 1610 (S/4HANA Enterprise 
Management )

1
AGENDA
Introduction to SAP S/4 HANA 1610 version

Major Changes in Gener

al Ledger Accountin
g

Practicals on Gener
al Ledger Accountin
g and Ledger Reporting

Changes in AP/A
R and Banking Process

Practicals onBP master data and Banking Process

Changes in Asset Accountin

g

Practicals on Asset Accountin

g Configurationsand reporting
 S/4 HANA – SAP 4th Generation High‐Performance Analytic Appliance

1972
• 1972 – SAP R/1 – Real Time Data Processing

1980
• 1980 ‐ SAP R/2 – Included No of Countries and Currencies

1990
• 1990 – SAP R/3 – R/3 Stands for , 1 Application server 2 Data Base Server 3 Presentation server

1999
• 1999 – Mysap.com – Web based

2004
• 2004 – net weaver – ECC ( Enterprise central component)‐ ECC 5

2005
• ECC 6

2015
• 2015 – S/4 HANA(High‐Performance Analytic Appliance) Simple Finance

2016
• 2016 – S/4 HANA Enterprise Management(Simple Finance and Simple Logistics)
3
What is SAP S/4HANA?

4
5
6
7
•SAP S/4HANA Finance 1503 : March 2015
•SAP S/4HANA 1511: November 2015
•SAP S/4HANA Finance 1605: May 2016
•SAP S/4HANA 1610: October 2016

SAP ERP, SAP S/4 HANA Finance and SAP 
S/4 HANA are different Products

8
Release Strategy for 2017 and definition of Delivery

9
Challenges from having Multiple Sources of Truth include the following: 
•The combined content of several tables represents "the truth". Reconciliation efforts are needed by architecture. 
•Different level of detail stored in the respective components or tables. 
•Components are structured differently (for example, fields and entities differ). 
•Must move data to the appropriate table for reporting (for example, settlement). 
•Different capabilities in the components (customer fields, currencies, multi‐GAAP, and so on). 
•Multiple BI extractors required to cover the complete truth in BI. 
10
The New Architecture: Universal Journal Entry as the Single 
Source of Truth 

11
Simplified Data Model 

12
Non Disruptiveness 

13
14
15
 https://youtu.be/_morrLqAZTQ
SAP Fiori
Offering an beautiful, role based, integrated user experience with modern usability 
based on mobile first principle.

16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
One of the basic promises and focus of SAP S/4HANA development is to provide a product that does not disrupt the business
processes and the day‐to‐day life of a business. A great effort has been made to safeguard the customer investments that
were made in custom code. Existing programs and interfaces can still be used through generated compatibility views:
 Read access from custom ABAP programs or reports to prior tables work as before. 
 Read access is automatically redirected to the universal journal as the new single source of truth. 

All programs with write access to those deleted tables replaced by CDS views will cause problems and cannot be used 
anymore without adaptation. To do this, remove all write accesses for the tables that have been replaced by views. You can 
use the code inspector to find all affected sections of the code (see SAP note 1976487). 
35
36
 The Universal Journal can be
extended with customer fields.
Extensibility is available for all
components that use the Universal
Journal (G/L, CO, AA, ML).
P&L line extension using CO‐PA
capabilities is provided, both for field
definition (characteristics) and the
rich derivation tools from CO‐PA.

 The standard General Ledger coding block extensibility can be used and affects the Universal Journal. 
 The new SAP HANA‐based reporting of all components (G/L, AA, ML, CO) can access the customer fields. 
 The new journal entry consists of a header (table BKPF) and the respective items (table ACDOCA). 
 There are rare cases, where entries in ACDOCA are written without a respective document header (for example, carry 
forward, corrections in migration). These entries do not represent standard business processes. 
 The corresponding line items have artificial document numbers beginning with letters, for example, 'A'. 
 The ACDOCA table contains all fields needed for G/L, CO, AA, ML, PA. 
 All cost elements, including secondary cost elements are G/L accounts. 
 Multi‐GAAP capability is available through the Ledger (RLDNR) dimension. 
 There is 6 digit field for line item numbering and 23 digits for currency fields. 

37
 Data for COEP, FAGLFLEXA, ANEP, MLIT, and so on, is stored directly in ACDOCA. 
 BSEG is maintained, as it was earlier it is not affected by the new architecture. BSEG is still limited to 999 lines per 
document but you can summarize those lines and have up to 999.999 analytically at the highest granularity directly in 
ACDOCA. 
 Profit center accounting, special purpose ledgers, and consolidations remain technically untouched so they continue to 
work. 
 Components that have been built with special purpose ledger functionality such as joint venture accounting, and public 
sector management continue to work as before. Additionally, we have costing‐based CO‐PA that also works exactly as 
before with the enhancements that come with SAP HANA systems and CO‐PA. 
38
There are five pillars to the SAP Fiori User experiences paradigm: 
•Role‐based: Users have access to the applications where they perform their tasks, and the applications are specific to 
completing this task. 
•Responsive: The application interface is responsive; it adapts to the size and device used by the users to access it. 
•Simple: Simple application scope, one user, one use case, up to three screens for each application. 
•Coherent: The applications are developed with a coherent structure, apps all speak the same language, and can be 
implemented in multiple landscapes and environments. 
•Instant value: Instant value through a low adoption barrier, both on the IT‐system side and on the user‐adoption side. 
39
40
 There are three SAP Fiori app types:
1.Transactional apps.
2.Analytical apps.
3.Fact sheets.

• Transaction apps offer task‐based access to tasks like change, create, display (documents, master records), or entire 
processes with guided navigation. 

• Analytical apps provide insight to action, they give you a visual overview of complex topics for monitoring or 
tracking purposes. 

• Factsheets give you the opportunity to search and explore your data. They provide a 360 degree view on essential 
information about an object and contextual navigation between related objects. 

41
 The SAP Fiori launchpad is the 
single entry point for the user to 
interact with the system. It is role‐
based and persona centric. 

The users access those applications 
that are specific to their role within 
the company and allow them to 
perform the specific tasks as per 
their requirement. 

There is embedded search, 
collaboration, and feed 
functionality. 

The SAP Fiori launchpad offers themes and can be personalized to meet branding requirements. 

It offers a stable URL for bookmarking and sharing and as it is browser based, it works with multiple devices and browsers.

The launchpad also offers active tiles through which the user can receive updated information directly from the front page 
without opening the application. 

42
The following personalization options are available in SAP Fiori Launchpad: 
•Adding applications from the catalog assigned to them
•Removing applications that they do not want to use
•Modifying and adding applications for filtered report results
43
In SAP Fiori Launchpad designer, you can do the following: 
•Configure tiles for static app launchers, dynamic app launchers, and to configure the target mapping. 
•Create preconfigured groups and catalogs for the Launchpad home page, for assigning to users. 
•Transport configurations, correction request packages, or the customizing workbench. 

Note: SAP Fiori Launchpad Designer help document: https://go.sap.corp/fldhelp

44
In the SAP Fiori theme designer, you can design custom themes for the Launchpad. For example, you can do the following: 
•Change font colour
•Change background colour
•Add images
•Assign a new theme to users

45
46
General Ledger Accounting
In the classical data model, an
account consists of charts of
accounts data (SKA1), company
code specific data (SKB1), and
an account description (SKAT).

If an account is relevant for

controlling, a cost element
(primary cost element) has to be
generated. During the creation of
the cost element, the CSKA,
CSKB and CSKU tables are
updated. Secondary cost
elements exist for cost elements
only and so only the CSK* tables
are updated.

In the new data model, the account is the master record and it is all that is required.
In this model, you move between the following G/L account types (GLACCOUNT_TYPE): non-operating expense or
income; primary costs or revenue; secondary costs; balance sheet account. The tables SKA1, SKB1 and SKAT are always
filled. With the G/L types primary costs or revenue and secondary costs, the CSK* tables are also updated.

47
In SAP Accounting CO relevant postings do not check the CO Period Lock (OKP1) only as in the past. You must also 
check the G/L period opening/closing (OB52). Therefore, you have to allow postings to accounts from the Secondary 
Costs account type in the G/L period opening/closing. 
In the CO Period Lock, you need to specify which transactions you want to lock and for which periods. 
In SAP Accounting, it is also necessary to open accounts from the Secondary Costs account type for FI postings.

48
 In transaction OB52, for each
variant you can specify which
posting periods are open for
posting. You can choose period
intervals 1 between and 3.
You can use period intervals 1 and
2 for all normal posting processes
in regular and special periods.

For period interval 1, you can enter a group of authorized users. This means that for month-end or year-end closing, for
example, you can open posting periods for specific users only. You make the necessary authorization settings in the optional
authorization object Accounting Document: Authorizations for posting periods (F_BKPF_BUP).
We recommend using period interval 1 for special periods because authorizations can only be managed here.

49
Period interval 3 is used for postings from Controlling (CO) to Financial Accounting (FI). If you do not make an entry 
for period interval 3, the check on these postings is made against period intervals 1 and 2. If you make an entry for 
period interval 3, the check on these postings is only made against period interval 3. For each interval, you specify 
the lower and upper limits of the posting period as well as the fiscal year. 

You can also use the report RFOB5200. You want to use authorizations to control who is allowed to execute the 
program RFOB5200 for the opening and closing of posting periods in the background. See SAP Note 2251160. 

Which accounting period version is checked? The leading ledger works with the accounting period that is assigned to 
the accounting area. Non‐leading ledgers can be assigned different posting period variants. 

Should the version of the not leading ledger not only be checked at ledger group specific bookings but also for 
bookings with ledger group blank you have to determine this by marking the field "Manage Posting Period" in the 
global parameters of the company code. 

50
 In new General Ledger Accounting, different
accounting principles are mapped using the
accounts approach. In addition to accounts, the
new G/L also lets you use different ledgers to
save the different valuation approaches. This is
called the ledger approach.

In an account approach, there is only one ledger,

the leading ledger 0L. In a ledger approach, there
is next to the leading ledger other not leading
ledgers. These ledgers are all called standard
ledgers. A standard ledger contains a full set of
journal entries for all business transactions.

In addition, other extension ledgers can be added.

Extension ledgers are based on an underlying
ledger.

An extension ledger is assigned to a standard ledger and inherits all journal entries of the standard ledger for reporting. Postings made
explicitly to an extension ledger are visible in that extension ledger but not in the underlying standard ledger.
An extension ledger stores delta values and points to another ledger - thus providing a flexible mechanism for adjustments and reporting. An
important use case is for management views on top of legal data (IFRS or Locale GAAP). Besides creating a master record, Extension
Ledgers do not need additional configuration. Reporting on the extension ledger always includes the data of the underlying ledger (in the
figure). Multiple extension ledgers can point to the same underlying ledger. Benefit of reduced data footprint and zero reconciliation effort as
only delta values are kept.
Extension ledgers are stored in the universal journal - same as standard ledgers. Extension ledgers can be assigned own booking period
variants. This means the standard ledger can be closed and the assigned extension ledger can be open.
51
Each specific ledger is self contained, has a special purpose, and provides a specific view on financial data. A ledger usually 
stores a lot of redundant data in other ledgers. 

With extension ledgers you can "staple" ledgers on top of each other, providing the different views you need. This 
minimizes the data footprint and provides new flexibility for easily creating additional views. 

The underlying ledger has to be a standard ledger. 
52
 Only manual postings are allowed to the
appendix ledger. Use the transaction with
which you can explicitly add the ledger group
to the expending ledgers, for example, KB11N,
KB41N, FB50L, and FB01L.

ACDOCA stores the data for all extension

ledgers.

BSEG does not store any extension ledger data, because you can only book ledger specific onto the extension ledger the table
BSEG_ADD is filled.
Implementing the BADI BADI_FINS_APPL_RELEVANCE allows you to feed components like PCA, FI-SL, EC-CS with the
data posted to extension ledgers. This functionality should be handled with care. The BADI implementation must clearly
separate extension ledger data from the other data.
RWIN: Processes via table TRWPR post the CO interface process and Functional Module 
53
Extension Ledger/Appendix ledger
 The extension ledger inherits all transaction data of the underlying base ledger while
reporting.

 This ledger contains only line items posted to the extension ledger only.

 This ledger inherits currency settings and the fiscal year variant of the base ledger.

 This ledger allows for a separate company code assignment (a subset of the base ledger)

 This ledger allows for a separate open period variant.

 The extension ledger can be used to create management views without duplicating the
data from the base ledger.
 The extension ledger can’t be part of ledger groups, except a generated group containing
the ledger itself.
 The extension ledger only accepts manual postings (Transactions FB01L, FBB1, KB11,
and KB41).
 Many extension ledgers can be assigned to the same base ledgers, but an extension
ledger can’t be stacked on top of another extension ledger.
54
S/4HANA impact on SAP General Ledger Accounting

Traditionally, SAP stored SAP General Ledger (G/L), customer, and vendor balances and open item statuses in various
database tables to support reporting. With the introduction of SAP S/4HANA Finance, the same reporting can be
achieved directly from table ACDOCA without storing balances or open item statuses separately. All the fields from sub
modules such as Controlling (CO), Asset Accounting (FI‐AA), SAP Material Ledger (ML), and Profitability Analysis (CO‐PA)
are available in table ACDOCA.

In an earlier version of SAP ERP Financials (FI), the secondary cost elements couldn’t be displayed in the financial
statement. In SAP S/4HANA Finance, the secondary cost elements are created as G/L accounts, which allows secondary
cost elements to be included and viewed in the financial statement version as well. With the release of SAP S/4HANA
1511, Feature Package Stack 02, the new SAP General Ledger (new G/L) is mandatory.
55
Currencies in Universal Journal

Situation in ECC:
 In the Business Suite (ECC) there used to be up to 3 parallel currencies in FI (table T001A / tx OB22) and 2 parallel 
currencies in CO (TKA01 / tx OKKP): CO area currency and object currency.
 The currencies of non leading ledgers in New GL (T882G) were a subset of the currencies in the leading ledger (T001A).
 One of the CO currencies needed to be the local currency (CT 10), but it was not necessary that the other currency in CO 
was also configured in FI.

Situation in S/4H:
With the universal journal and the common line item table ACDOCA for FI and CO, there is also a central currency 
configuration for the universal journal. As the currency configuration depends on the universal journal ledgers, there is a 
combined view cluster for ledgers and currencies, tx FINSC_LEDGER.

IMG menu path: Financial Accounting( New ) ‐ Financial Accounting Global Settings (New) ‐ Ledgers ‐ Ledger ‐ Define 

Settings for Ledgers and Currency Types.

Overview on amounts fields of the Universal Journal (as of S/4H 1610 and S/4H Finance 1605)

56
ACDOCA  Description
Fieldname
WSL Amount in Transaction Currency (Document Original currency of the transaction, not contained in balances, as it might
Currency) happen that different currencies cannot be aggregated; corresponds to
BSEG-WRBTR.
TSL Amount in Balance Transaction Currency Amount converted to the currency of the G/L account, in order to allow
aggregation on G/L account level; corresponds to BSEG-WRBTR.
HSL Amount in Company Code Currency (Local Currency) Currency of the company code; corresponds to BSEG-DMBETR in FI and
object currency in CO (except co area currency type is local currency)
KSL Amount in Global Currency Currency type configured in the controlling area (TKA01-CTYP)

OSL Amount in Freely Defined Currency 1 Currency configured per ledger and company code in tx: FINSC_LEDGER

VSL Amount in Freely Defined Currency 2 Currency configured per ledger and company code in tx: FINSC_LEDGER

BSL Amount in Freely Defined Currency 3 Currency configured per ledger and company code in tx: FINSC_LEDGER

CSL Amount in Freely Defined Currency 4 Currency configured per ledger and company code in tx: FINSC_LEDGER

DSL Amount in Freely Defined Currency 5 Currency configured per ledger and company code in tx: FINSC_LEDGER

ESL Amount in Freely Defined Currency 6 Currency configured per ledger and company code in tx: FINSC_LEDGER

FSL Amount in Freely Defined Currency 7 Currency configured per ledger and company code in tx: FINSC_LEDGER

GSL Amount in Freely Defined Currency 8 Currency configured per ledger and company code in tx: FINSC_LEDGER

CO_OSL Amount in Object currency of CO Object currency of CO, only if it is really the object currency (70)

57
58
 SAP S/4 HANA for advanced Available‐to‐promise (ATP)
 Integrated Quality Management
 Extended Warehouse Management embedded in SAP S/4 HANA
 Embedded software in Product Development
 SAP Portfolio and Project Management for SAP S/4 HANA
 SAP S/4 HANA International Trade Compliance
 SAP S/4 HANA Finance
 Industry to Core: Oil & Gas – Oil and Gas Downstream with SAP S/4 HANA
 Billing and Revenue Innovation Management (aka BRIM)
 Master Data Governance (MDG)
 Manufacturing Planning: Production Planning and detailed scheduling (PPDS)

Dose Note require any additional Licensing for the above innovation

59
New Implementation Methodology _ Agile/ Activate Methodology 

60
New Implementation Methodology _ Agile/ Activate Methodology 
 3 ledgers going to be created

0L – Leading Ledger for Local GAAP (K4 - Jan to Dec) – PV 2505

B1 – IFRS Ledger (V3 -April to March) – PV 2506 Posting Period Variant
B2– (Extension Ledger) Underlying Ledger attaching with 0L 2505 – K4 Jan to Dec
B3– Other Ledger For Asset (K4 - Jan to Dec) – PV 2505 2506 – V3 Apl to March

Ledger Groups:
0L – 0L Ledger Ledger to Accounting Principle
B1 - IFRS Ledger Ledger Accounting Prin
B2 - Extension Ledger 0L AB01
B3 – AA Ledger for Match B1 AB02 Currencies:
B0 – B1 and B3 B3 AB02 Company Code currency 10 – USD _Global
Group Currency 30 – EUR_ Company Code
Ledger Group to Acc. Principle Hard currency 40 – GBP _ Company Code
Ledger Group Accounting Prin
Accounting Principles:
0L AB01 Additional Currency Z1 – AED _Company Code
B0 AB02 Additional Currency Z2 – INR _Company Code
AB01 – Local GAAP
AB02 – IFRS

62
 Operating Concern 2505

Controlling Area 2505

Company Code 2505

Segment for Plant 1 Segment for Plant 2

Profit Centers for Plant  Profit Centers for Plant 2
1

Cost centers for Plant 1 Cost centers for Plant 2

63
Business Partner – Accounts Payable (AP) and Accounts Receivable(AR)

Business partners (BPs) is mandatory in SAP S/4HANA 1511 & 1610 (Enterprise Management. 

Business partners (BPs) is optional  in SAP S/4HANA 1503 & 1605 (S/4 HANA Finance). 

64
Business Partner – Accounts Payable (AP) and Accounts Receivable(AR)

Business partners (BPs) is mandatory in SAP S/4HANA 1511 & 1610 (Enterprise Management. 

Business partners (BPs) is optional  in SAP S/4HANA 1503 & 1605 (S/4 HANA Finance). 

65
66
House Bank Configuration

1. FBZP configuration up to Payment method in company code
2. FIN_FSCM_CLM should be deactivated
3. Define Number Ranges for Change Requests FCLM_BAM_REQNR
4. Define Number Ranges for Bank Account Technical IDs FCLM_BAM_ACCNR
5. Bank Key configuration through FI01
6. House Bank Configuration through FI12_HBANK
7. House Bank with Bank ID and account assignment through Fiori APP “ Manage 
Bank Accounts”
8. Account determination with House Bank through FBZP
9. Create Cheque Lot through FCHI
10. Table : T012K and FCLM_BAM_ACLINK2         
2261568 ‐ Release Information Note: Bank Account Management Lite (SAP S/4HANA Finance 1605)
2261568

2214054_Release Information Note SAP Cash Management SAP S/4HANA 1511 2214054

2243324 ‐ Release Information Note: Bank Account Management Lite (SAP S/4HANA1511)  2243324

67
Impact on Asset Accounting ‐Architectural Impact 
 New Asset Accounting is the only Asset Accounting solution in S/4 HANA.
 Classic Asset Accounting is not available any more in S/4 HANA.
 Configuration and activation is on the client level.
 Both multiple valuation approaches are possible: Ledger Approach and Account Approach.
 Usage of the new Depreciation Calculation Engine is mandatory.
 Business Function FIN_AA_PARALLEL_VAL to be activated

All actual FI‐AA line item postings are stored in table ACDOCA
Header information is stored in table BKPF.
All statistical line item information stored in table FAAT_DOC_IT.
Plan data that used to be stored in table ANLP and table ANLC is now stored in table FAAT_PLAN_VALUES
Year‐dependent depreciation attributes are stored in table FAAT_YDDA
FI‐AA tables ANEK, ANEP, ANEA, ANLP, and ANLC won’t be updated going forward.

Upon the creation of the asset, planned depreciation values are calculated on a real‐time basis and are stored in table
FAAT_PLAN_VALUES. If there are any errors (e.g., inconsistent depreciation key) while calculating planned depreciation,
that particular asset’s planned depreciation value will be empty and won’t be updated.
During the month‐end depreciation run, actual postings will use the planned depreciation values from table
FAAT_PLAN_VALUES. Assets with errors won’t stop the full depreciation run. An asset with issues/errors won’t have an
actual depreciation posting and will be reflected in the depreciation run log.
68
Impact on Asset Accounting ‐Architectural Impact 

69
New Asset Accounting

New asset accounting features

• Fixed asset accounting based on universal journal
• After new asset accounting migration, previous year reporting is possible due to compatibility views.
• We have an option of assigning the depreciation is to accounting principle.
• Here we can segregate the accumulated depreciation and depreciation asset wise, but it is not
happening now in classic asset accounting.
• Simplified chart of depreciation, only one depreciation area per valuation is necessary, no delta
depreciation areas required for parallel valuation, but which is happening now in classic asset
accounting.
• Flexible account determination and no more FI-AA reconciliation is required.

Benefits of new asset accounting:

• No more hard coupling of depreciation area 01
• Posting to different periods possible, but beginning /end of the FY need to be equal.
• New transactions for accounting principle, depreciation area specific documents.
• The beauty of new asset accounting is always systems will posts the separate documents per each
accounting principle, like ledger specific document in new GL.
• As I said above details depreciation postings will happen each asset wise.

70
New Asset Accounting in S/4 HANA Finance

• The traditional asset tables like ANEK, ANEP, ANEA, ANLP & ANLC now replaced with ACDOCA and ANEK table data will be 
replaced with BKPF; we will call ACDOCA as a universal journal table.
• Due to compatibility views we will get the old year reports in new asset accounting.
• In new asset accounting technical clearing account acts as a zero balance clearing account in new GL and it is a offsetting
account.
• In new asset accounting after posting the document, the display document in FB03 contains the special tab of Asset 
accounting display, once you click on this document it will give you the accounting principle wise posted accounting 
document, here the technical clearing account will acts as a offsetting account in both the accounting principles.
• In AW01N transaction you have hierarchical views for both accounting principles and we can differentiate the same.
• The AFAB depreciation screen modified completely and you can give the company code range in AFAB screen, accounting 
principle specific we can run the depreciation.
• Now the reason for posting run options are obsolete in AFAB.
• In the classic asset account, system won’t allow you to post any depreciation if you have errors in depreciation run, but now 
in new asset accounting, you can exclude the errors and can execute the depreciation for other assets, like cost estimate for 
materials in CK40N.
• Periodic Depreciation run ASKBN is no longer required 

71
The posting logic in new FI‐AA has changed as follows:  

 The operational entry document posts a debit to the technical clearing account and a credit to the vendor account. This
document doesn’t update the asset values, and the asset data are only used to perform checks.

 The accounting principle‐specific documents are posted with a debit to the asset reconciliation account and a credit to
the technical clearing account. This document updates the asset line items. This is applicable for both the ledger approach
and the account approach, when multiple postings occur for each of the ledger groups assigned to the accounting
principles for each depreciation area.

72
Currencies in Universal Journal

Situation in ECC:
 In the Business Suite (ECC) there used to be up to 3 parallel currencies in FI (table T001A / tx OB22) and 2 parallel currencies 
in CO (TKA01 / tx OKKP): CO area currency and object currency.
 The currencies of non leading ledgers in New GL (T882G) were a subset of the currencies in the leading ledger (T001A).
 One of the CO currencies needed to be the local currency (CT 10), but it was not necessary that the other currency in CO was 
also configured in FI. 

Situation in S/4H:
With the universal journal and the common line item table ACDOCA for FI and CO, there is also a central currency 
configuration for the universal journal. As the currency configuration depends on the universal journal ledgers, there is a 
combined view cluster for ledgers and currencies, tx FINSC_LEDGER.

IMG menu path: Financial Accounting( New ) ‐ Financial Accounting Global Settings (New) ‐ Ledgers ‐

Ledger ‐ Define Settings for Ledgers and Currency Types.

The second and third parallel currencies of FI (BSEG‐DMB2 or BSEG‐DMBE3) correspond to 2 amount fields of KSL ‐ GSL 
according to configuration in tx FINSC_LEDGER.
Table BSEG is not extended and still contains only 3 parallel currencies. Our goal is to implement full process integration of all 
currencies fields in all processes in accounting.

73
Asset Accounting ‐ Functionality Impact 
Legacy Asset Migration:
Transaction AS91 used to be a single transaction to load asset master data and values for previous years and the current year. In 
SAP S/4HANA Finance, it’s a three‐step process: 
1. Master data are loaded through Transaction AS91. 
2. Asset historical values, accumulated depreciation, and depreciation for the year are loaded through Transaction ABLDT. 
3. The current year acquisitions are managed through Transaction AB01. 

Asset migration through Transaction AS91 doesn’t upload values in SAP S/4HANA Finance.

Depreciation Run selection screen has been simplified with a new screen that has the following attributes:

 You can now run depreciation posting for a particular Accounting Principle that can be entered on the selection screen.
 Server group needs to be entered in SAP S/4HANA Finance.
 The Reason for posting run section, which includes Planned posting run, Repeat, Restart, and Unplanned posting run, has now
been eliminated in SAP S/4HANA Finance
 The Depreciation Posting Run detailed log option reports depreciation at the individual asset level with corresponding cost
center information

74
 Old Transaction New Transaction
Transaction ABST2 (Reconciliation Analysis FI‐AA) (no longer  Transaction FAGLGVTR used for the G/L close process
required)
Transaction AB01 (Create Asset Postings) Transaction AB01L
Transaction ASKB <RAPERB200 > (Periodic APC Run) Obsolete, posting now performed directly to G/L
Transaction ABST(L) < RABST01 > (Réconciliation Program G/L‐ Obsolete, no AA tables anymore to reconcile with G/L, just 
AA) table ACDOCA
Transaction ABST2 < RABST02> (Réconciliation Program G/L‐AA) Obsolete, no AA tables anymore to reconcile with G/L, just 
table ACDOCA
Transaction AB02 (Change Asset Document) Changes in asset documents made via Transaction FB02

Transaction AW01_AFAR (Asset Explorer) (old depreciation) Not available anymore (replaced by Transaction AW01N)

Transaction ABF1/ABF1L (Post Differences in Asset Accounting) Not required because the ledger can be entered directly in 
the transaction
Transaction OASV (Transfer Balances) Not required; now a real‐time functionality
Transaction FAA_GL_RECON (Consistency Check for FI‐AA [New] Not required; now a real‐time functionality
and FI‐G/L [New])
Transaction RAGITT01 (Asset History Sheet) New Program S_ALR_87011990

75
Asset Accounting ‐ Configuration Impact
Activate New Asset Accounting 
Activate the new functions for new FI‐AA by selecting the Actv. (active) option in the New Asset Accounting area 

Technical Clearing Account for Integrated Asset Acquisition 
The business transaction pertaining to FI‐AA is allocated into an operational part and a valuating part during the integrated asset 
acquisition posting: 
 For the operational part (vendor invoice), a ledger‐group‐independent document valid for all accounting principles is posted 
against the technical clearing account for integrated asset acquisitions. 
For each valuating part (asset posting with capitalization of the asset), a separate ledger‐group‐specific document valid for each of 
the accounting principles is posted against the technical clearing account for integrated asset acquisition.
the technical clearing account for integrated asset acquisitions is posted automatically and always has a zero balance for each of 
the accounting principles in the chart of depreciation 

7676
The new architecture does not support the following features (and vice versa):
• Joint Venture Accounting (JVA) (officially released for ledger‐solution via Business Function as of EhP6) This feature may be supported in a future 
support package. See SAP Notes 2199682 and 2137314.
• Lease Accounting Engine (LAE)
• Real Estate Classic (RE Classic)
• Public Sector Management ‐ Funds Management (PSM‐FM) using requests
It is necessary to check if new Asset Accounting can be used with installed industry components.
• Application Link Enabling (ALE): transfer of assets
• Transaction Post transfer between depreciation areas (ABUB)

77
78
 Company Code

Purchase Organisation

Plant 1 Plant 2

Profit Centers Profit Centers

Cost Centers Cost Centers

79
Account Category Reference

Material Type

Valuation Class with Account Category 
Reference

Valuation Class assigned with GL accounts 
based on Transactions, example BSX, 
GBB,WRX,PRD

Valuation Class will be assigned to Material 
Master

80
 Client
Sales Area

Company Code Sales Org

Distribution
Division
Channel
Plant 1 Plant 2

81
S/4 HANA Controlling and Profitability Analysis

 Account based CO-PA is an extension of your general ledger and feeds off financial postings made there.

 Costing‐based CO‐PA, has its own data model to capture costs and revenues, due to the many advantages costing‐based CO‐
PA has over account‐based CO‐PA, a majority of companies use costing‐based CO‐PA. Even though it’s widely used, costing‐
based CO‐PA has its own limitations, such as a different data model, duplication of data, timing differences, reconciliation 
issues, and so on.

Due to these limitations, costing‐based CO‐PA may not fit into the future SAP product road map. As the foundation and digital 
core of all current and future SAP products, SAP S/4HANA is all about removing redundancies, providing a single version of 
truth, and directionally building a “thick journal” (the Universal Journal) that will be the one‐stop shop for all statutory, tax, 
regulatory, or management information. 

The majority of greenfield implementations on SAP S/4HANA Finance are likely to be account‐based. Account‐based CO‐PA 
under SAP S/4HANA Finance does have a few limitations, but those limitations will be addressed by future releases of SAP 
S/4HANA Finance.

Costing based CO‐PA with its separate data model and tables might not fit into the SAP product road map. In SAP S/4HANA, the 
single version of truth will emanate from the Universal Journal. The Universal Journal will be the foundation for statutory, tax, 
regulatory, and management reporting of which profitability is a key reporting view. 

82
S/4 HANA Controlling and Profitability Analysis

Future of Costing‐Based Profitability Analysis:
If you continue the Costing‐based CO‐PA the same old reconciliation issues experienced with SAP ERP. If you’re using 
costing‐based CO‐PA and are migrating to SAP S/4HANA, you can continue to use it but you should activate account‐
based CO‐PA as well. It’s not possible to migrate the history from costing‐based CO‐PA to account based CO‐PA, so you 
may want to retain costing‐based CO‐PA for a certain period. After your business is comfortable with account‐based 
COPA, and you have enough history built up, you may decide to deactivate costing‐based CO‐PA.

83
S/4 HANA Controlling and Profitability Analysis
Key Differences between Costing-Based and Account-Based CO-PA before SAP S/4HANA Finance
Functionality Account‐based CO‐PA Costing‐based CO‐PA Impacts
Data models Uses COEP, BSEG,and CE4XXXX. Uses CE1XXXX,CE2XXXX,CE3XXXX, and CE4XXXX  Data is an issue with costing‐based CO‐PA, as data is 
tables. stored in non‐finance tables. This leads to 
reconciliation issues between the general ledger data 
and CO‐PA data.
Statistical  Statistical values The costing‐based method can account and report  Data flow is limited to financial postings with 
values cannot be updated statistical values that are not posted to the general  account‐based CO‐PA. Businesses might want to 
to CO‐PA. ledger. report certain statistical values that do not hit their 
books of accounts. This is only possible in costing‐
based CO‐PA.
Insights on COGS is posted and reported under a COGS can be split into different cost components,  Costing‐based CO‐PA provides insights about the 
cost of goods single general ledger account. like material, labour, and so on. breakup of the COGS for better planning and analysis.
sold (COGS)
Insights on Production variances are reported at  Production variances can be broken down into  Costing‐based CO‐PA provides insights about the 
production summary level under one general  different types, like material price, variance, and  breakup of different types of variances and helps to 
variance ledger account. material quality variance. take remedial action to improve profitability.
Timing of data   The timing of dataflow to CO‐PA is  The timing of dataflow is not linked to financial  Costing‐based CO‐PA leads to reconciliation issues 
flow linked to events that trigger financial  postings all the time. For example, COGS financial  between financial statements and CO‐PA reports.
postings. postings happen at the time of goods dispatch, but 
the data flows to CO‐PA at the time of billing.
Data   Data enrichment is not possible  You can enrich data for business events like losses  Costing‐based method allows businesses the
enrichment because CO‐PA is virtually a more  due to bad debts, discounts, and so flexibility to record future business transactions that 
detailed copy of general ledger. on. You can record them in CO‐PA using some  haven’t hit the general ledger yet.
business rules, even though they haven’t hit the 
book of accounts yet.
Flexibility with  There isn’t any flexibility in using  You have the flexibility to define alternative Business is limited to use only one valuation
cost estimates different cost estimates in CO‐PA. standard cost estimates and valuations. for COGS under account‐based CO‐PA. 84
S/4 HANA Controlling and Profitability Analysis
Key Profitability Analysis Functionalities in SAP S/4HANA Finance
Extension of Characteristics:

The Universal Journal has extensibility features that come with SAP S/4HANA. You can easily extend the CO‐PA characteristics
to enhance your information needs. After you extend the CO‐PA characteristics, they become part of the Universal Journal.
Extensibility was available even before SAP S/4HANA through extension of coding block in the general ledger. The setup for
extensibility in the general ledger and CO‐PA are separate activities. With extensibility as standard functionality in SAP
S/4HANA, why anyone would want to implement costing‐based CO‐PA because all the dimensions required to report
profitability are and can be part of table ACDOCA, which the account‐based method uses.
Real-Time Insights:
With SAP S/4HANA as the single platform for both online analytical processing (OLAP) and online transaction processing
(OLTP), profitability reporting is now done in real‐time. If a large sale is made for multiple cranes in Asia, the CEO, CFO, and
other executives across the globe can see how that event impacted the profitability for that region, brand, and branch by
running the SAP Fiori reports such as margin analysis. This is a big leap from the current capabilities of CO‐PA reporting
where you have to wait for month‐end activities to complete, perform reconciliations, and extract data to SAP BW before
seeing the profitability information.

Always an issue with CO‐PA before SAP S/4HANA as the margin and contribution weren’t readily available for sales and
marketing people. The primary reason is that CO‐PA was never real‐time, and no one could trust the CO‐PA numbers due to
the reconciliation issues with the general ledger. In a way, CO‐PA has become more of an after‐the‐fact analysis of
profitability. Sales representatives who were on the road trying to make deals and win business couldn’t open their iPads or
mobile devices and get answers to questions below.
S/4 HANA Controlling and Profitability Analysis

Key Profitability Analysis Functionalities in SAP S/4HANA Finance

Real-Time Insights:

»How much of a discount can I give to my customer, and how does that impact the gross margin?
»If I change the product mix, how does that impact profitability?
»Which of the two competing offers should I accept?
»Which products should I push to maximize profitability?
»Does it make sense to pursue a lead?
Operating Concern
The fiscal year of the operating concern should match that of the controlling area and the company code.
There is no change in the way the operating concern is defined under SAP S/4HANA. However, all new implementations are 
likely going to be account based CO‐PA. If you don’t activate the account‐based CO‐PA during upgrade, you’ll get error 
message FCO_CO‐PA 006. If you’re implementing SAP S/4HANA as a greenfield implementation, make sure account‐based 
CO‐PA is active. Costing‐based CO‐PA is optional.
Characteristics and Value Fields
Both characteristics and value fields are critical because transacting, planning, and reporting in CO-PA are done on
these elements. A combination of characteristics is known as a profitability segment. There are three types of
characteristics in CO-PA:
 Fixed characteristics
Fixed characteristics are predefined for all
operating concerns in a SAP client and include
items such as product number, company code,
plant, customer, and so on. You don’t need any
extra configuration to use them as they are
available for all operating concerns in a SAP

Predefined characteristics
These additional characteristics, such as customer
group, customer district, country, and so on, can be
activated for your operating concern if you want to
measure profitability for those dimensions. You need
to configure these characteristics to use them in your
operating concern.

Custom characteristics
If fixed and predefined characteristics aren’t meeting the requirements, you can define custom characteristics that are specific to your organization
and measure profitability on them. SAP allows you to add 50 non fixed characteristics. It’s recommended to name the custom characteristics
starting with “WW”. While defining the characteristics, you also identify which characteristic is segment level and which is not.
Change Impacts
With SAP S/4HANA, there is no concept of segment‐level and non segment level characteristics because all characteristics 
are segment‐level characteristics. Transaction KEQ3, where you define the segment and non‐segment characteristics, is no 
longer available for use.
87
Value Fields and Cost Elements

Value fields are measurements through which you can record and assess your organization’s profitability. Cost elements are
general ledger accounts that are used in Controlling (CO) for the same purpose. Value fields are used only in costing-based CO-
PA. Examples of value fields are sales revenue, rebates, quantity, discounts, and so on. If you’re defining a custom value field,
you need to prefix the field with “VV”. For account‐based CO‐PA, instead of value fields, cost elements are used to capture transactional
figures, which are stored in table COEP with a different value type.
Change Impacts
Change Impacts
Value fields are still needed if you use costing‐based CO‐PA, and nothing changes there. There is a limit of 120 value fields,
but rarely do you see a customer needing so many value fields to report on profitability. In SAP S/4HANA, general ledger
accounts and cost elements are merged into one to reduce dual maintenance issues. P&L accounts now do what cost
elements once did. There are three ways P&L accounts are defined in SAP S/4HANA:
 P&L accounts with no reference to CO
 P&L accounts for postings to cost centers, orders, projects, CO‐PA dimensions, and so on (formerly primary cost elements)
 P&L accounts to document cost flows from senders to receivers (formerly secondary cost elements)
Account‐based CO‐PA uses all of these types of P&L accounts in SAP S/4HANA.
In addition, for standardized reporting, customers preferred not to report the quantities in Logistics but instead to convert 
the quantities into their own reporting units. SAP provides enhancement COPA0005 for converting quantities. However, with 
SAP S/4HANA, you get a new feature to add three new quantity fields in CO line items and a Business Add‐In (BAdI) for 
conversion of Logistics quantities to common quantities.
S/4 HANA Controlling and Profitability Analysis
Universal Journal Entry
In SAP ERP, CO-PA has multiple tables for updating CO and FI postings depending on the method used. For
costing-based CO-PA, there are multiple tables (tables CE1XXX–CE4XXXX), and for account-based CO-PA, there
are tables COEP and CE4XXXX. Several tables were updated for the same source document, which caused
reconciliation issues, redundant commits, and proliferation of reports for end users to run.

Change Impacts
Table ACDOCA now stores all values in SAP S/4HANA under account-based CO-PA and that were updated in the
past in table COEP. Table COEP is no longer a table in SAP S/4HANA but is now a SAP HANA view

Characteristic Derivation
There are five types of derivation types you can configure in CO-PA:
»Derivation rule
This derivation type works on the logic of “if” certain characteristics have certain values, “then” the target characteristic should have a specific value.
»Table lookup
This type is used to derive values of certain characteristics based on the value of a system-delivered characteristic.
»Move
This derivation type allows you to update values from a source field or a constant.
»Clear
This derivation type allows you to clear the value of a characteristic or put back the original value.
»Enhancement
When none of the preceding derivation types meet your requirements, you can go for enhancement COPA0001.

89
S/4 HANA Controlling and Profitability Analysis

Change Impact
With SAP S/4HANA, derivations can be done early at the time of posting so that you can report on profitability with
all derived dimensions in real time instead of waiting till month-end. Before SAP S/4HANA, you had to wait till
month-end to post costs and revenues to correct profitability segments by running settlements. Derivation of
market segments early in the process helps eliminate the need for period-end activities and moves the organization
toward a real-time close.

90
S/4 HANA Controlling and Profitability Analysis
The way you define the derivation types to derive certain characteristic values continues to be the same.
Derivation rules can be used whether it’s account-based or costing-based. With SAP S/4HANA, table ACDOCA
stores all the characteristic values for profitability reporting. Table ACDOCA allows extensibility, so it’s likely to
have many fields that businesses may want to report on, and not all of them can be input by the user or be
derived using SAP’s standard logic. Therefore, you may have to configure derivation rules to populate values in
those fields.
Realignments
Change Impact
If you’re using account-based CO-PA, the realignment functionality isn’t supported. However, if only costing-
based CO-PA is active, then realignment is possible. Realignments are a widely used functionality in CO-PA,
and you get the error message, when you go to Transaction KEND. Per SAP Note 2176823, realignment will be
available from SAP S/4HANA, on-premise edition 1610. The realignment functionality isn’t supported for
account-based CO-PA in SAP S/4HANA Finance for the lower releases.
Valuation Strategies
Valuation strategies control the timing and basis of value flow to CO-PA from product cost estimates. Through
valuation strategies, the system calculates sales, sales discounts, and other direct costs such as transportation,
which are important for CO-PA. This is mostly relevant for costing based CO-PA because account-based CO-PA
uses the same basis as the general ledger for valuation and timing. Different valuation strategies can be used,
such as condition types, material cost estimates and transfer prices, to control the valuation.
S/4 HANA Controlling and Profitability Analysis

Change Impact
If you use costing-based CO-PA, there is no change to the design and configuration in this area. This functionality
wasn’t available in the account-based method, and this continues to be the same under SAP S/4HANA. This might
limit the flexibility to view profitability that is being measured in a manner different from what is booked in the general
ledger. In the current version of SAP S/4HANA for account-based CO-PA, this missing functionality might be
a limitation.
Planning

CO-PA has planning functionality through which you can plan revenue and costs and report on how different
business dimensions performed in terms of meeting contribution margin. You can plan quantities and values on
any characteristics. CO-PA planning is also integrated with planning in other modules such as SAP Sales and
Operations Planning (S&OP).

Change Impact
If you’re using costing-based CO-PA in SAP S/4HANA, all of the preceding steps remain the same, and you can do
planning in the CO-PA module. If you’re using account-based CO-PA under SAP S/4HANA, you can leverage SAP
Business Planning and Consolidation powered by SAP HANA. Because it runs on the same database and shares
the master data of the Universal Journal in terms of general ledger accounts and characteristics, there is no need
to replicate the master and transaction data to a separate SAP Business Planning and Consolidation system
because it’s done concurrently. This is a huge advantage with SAP S/4HANA because plan and actuals for CO-PA
run on the same system.
92
S/4 HANA Controlling and Profitability Analysis
CO-PA Planning in SAP S/4HANA
In SAP ERP, the planning functionality is available at the general ledger, cost center, and profitability segment
levels. Because these levels aren’t integrated, users were doing them separately. You could run plan versus actuals in SAP 
ERP, but they were separate processes.

Change Impacts
In SAP S/4HANA, the native finance planning functionality of general ledger planning, cost center planning, and internal 
order planning is disabled by default. If you still want to use these functionalities, you can activate them. In the future, 
however, most customers are likely to use a single planning process of planning at the Universal Journal to eliminate 
redundant and siloed planning activities.
Adobe Acrobat
Transfer of Sales Order Data Document

Businesses may need to see an early view of profitability at the time of sales order creation. This isn’t a widely
used scenario but can be configured if business has a requirement to see the impact of sales orders on
profitability before products are shipped or billed. In costing‐based CO‐PA, it’s possible to show the impact of sales 
orders on profitability even though sale or delivery isn’t complete.
Change Impact
In costing-based CO-PA, the transfer of sales order data functionality stays the same, along with the associated
configuration. In account-based CO-PA, this functionality wasn’t there in SAP ERP and will be missed for
customers who choose to implement only account-based method under SAP S/4HANA. It might be included in one
of the future releases of SAP S/4HANA.
93
S/4 HANA Controlling and Profitability Analysis
Transfer of Billing Documents
When billing documents are generated, accounting documents get posted in the general ledger, and those values
are transferred to CO-PA. This is an important scenario because it affects a majority of the data flow to CO-PA.
Record type F is used to identify the values that get passed to CO-PA from the billing scenario.

In costing-based CO-PA, condition types are mapped to value fields to enable the value flow to CO-PA. At the time
of billing, both billing and cost of sales flow to CO-PA, along with any discounts. Both gross and net quantities can
also be mapped to value fields in CO-PA.
There is a difference in timing because COGS in account-based CO-PA is updated to CO-PA at the time of
delivery and not at the time of billing.
Change Impact

If you’re using account-based CO-PA, there is a new functionality that allows you to split COGS into different cost
categories. As noted previously, one of the benefits of costing-based CO-PA is the ability to see the various cost
components in profitability reports.

If you’re using account-based CO-PA under SAP S/4HANA, you can map different cost components of the material
cost estimate to multiple general ledger accounts, thereby increasing the insights on COGS. Without this
functionality, businesses could only see one line item for COGS.

The new capability to view and analyse the breakdown of costs such as material, labour, utilities, and overhead
gives great insights into how business units are performing. 94
Sai Krishna Vallurupalli,  sais4hana1605@gmail.com, +91 9440475440
S/4 HANA Controlling and Profitability Analysis

Production Variances

Production variances are the variances between standard costs and actual costs of goods manufactured/sold. Any 
profitability analysis without accounting for variances is meaningless. At the time of billing, standard cost is taken into 
account to book COGS, and the same values flow to CO‐PA.
Change Impact
In the past, all these variances were bundled and posted to one price difference (PRD) account. This greatly limited the 
capability of the business to perform analysis of variances and take remedial actions to control variances. Such insights 
were only possible if you were using costing‐based CO‐PA. However, with SAP S/4HANA, you now can post variances to 
different general ledger accounts and provide insights to management that weren’t available before. 
Period-End Activities
Following are CO-PA period-end tasks with their corresponding transactions:
»Running assessments from cost centers to profitability segments (Transaction KEU5)

»Variance calculations (Transaction KKS1)

»Settlement of variances to profitability segments (Transaction CO88)

»Reconciliation among CO, FI, and SD (Transaction KEAT)

»Direct postings to CO-PA (Transaction KE21N)

95
S/4 HANA Controlling and Profitability Analysis
Change Impact
In SAP S/4HANA, the period‐end processes mostly remain the same, but you gain performance improvements in high‐
volume tasks such as variance calculations, settlements, and assessments. If you’re using account‐based CO‐PA,
characteristic derivation happens early in the process and reduces the tasks at month‐end. If you’re using account‐based 
CO‐PA, you save time by eliminating reconciliations because CO‐PA data ties in with the general ledger. For customers who 
decide to use both methods, it’s recommended to run the CO‐PA/FI reconciliation reports to make sure that the numbers 
agree, and any reconciling items are explained.
SAP Fiori Apps in SAP S/4HANA

Change Impacts
SAP S/4HANA has brought significant changes to the data extraction and reporting process. With SAP HANA, there is no 
need to pull the CO‐PA data in to SAP BW because the data are readily available in the transactional system itself with 
granular detail. You have a number of delivered SAP Fiori analytical apps for analysing the profitability that can be run 
anytime, anywhere. These apps have drilldown capability to the source document if you need to research what is being 
reported on.
SAP Fiori apps are role based, and the profitability apps are under the Manager– Finance Information role. The apps 
currently available for profitability reporting are listed here:
Gross Margin
Net Margin
Net Margin Results
Profit Analysis
96