SAP FINANCIALS AND CONTROLLING

FINANCIAL ACCOUNTING OVERVIEW

PETER MOXON

PUBLISHED BY:

SAPPROUK Limited

Copyright © 2014 by Peter Moxon. All rights reserved.

http://www.saptraininghq.com

Copyright, Legal Notice and Disclaimer:

All rights reserved.

No part of this publication may be copied, reproduced in any format, by any means,

electronic or otherwise, without prior consent from the copyright owner and publisher of

this book.

This publication is protected under the US Copyright Act of 1976 and all other applicable

international, federal, state and local laws, and all rights are reserved, including resale

rights: You are not allowed to give or sell this Guide to anyone else. If you received this

publication from anyone other than saptraininghq.com, you've received a pirated copy.

Please contact us via e-mail at support at saptraininghq.com and notify us of the situation.

Although the author and publisher have made every reasonable attempt to achieve

complete accuracy of the content in this Guide, they assume no responsibility for errors or

omissions. Also, you should use this information as you see fit, and at your own risk. Your

particular situation may not be exactly suited to the examples illustrated here; in fact, it's

likely that they won't be the same, and you should adjust your use of the information and

recommendations accordingly.

This publication is not affiliated with, sponsored by, or approved by SAP AG. Any

trademarks, service marks, product names or named features are assumed to be the

property of their respective owners, and are used only for reference. There is no implied

endorsement if we use one of these terms.

Contents About The Author ......................................................................................................................................................... 7

Contact the Author ....................................................................................................................................................... 8

OVERVIEW ....................................................................................................................................................................... 9

Prerequisites ..................................................................................................................................... 9

Structure ............................................................................................................................................. 9

Objectives ........................................................................................................................................ 10

General Financial Accounting Terms Part I .................................................................................................. 11

Organizational Elements of R/3 ............................................................................................... 12

Client ....................................................................................................................................................................... 12

Company Code ................................................................................................................................................... 12

Business Areas ................................................................................................................................................... 13

Country Templates .......................................................................................................................................... 15

Editing a Company Code .............................................................................................................. 16

General Financial Accounting Terms Part II ................................................................................................. 17

Variant Principle .......................................................................................................................... 17

Fiscal Year ........................................................................................................................................ 17

Year-Independent and Year-Dependent Variant ................................................................ 18

Year-Independent Variant ........................................................................................................................... 19

Year-Dependent Variant ............................................................................................................. 19

SAP Financial Accounting Basics Part I ........................................................................................................... 21

Document Principle ...................................................................................................................... 21

Documents ........................................................................................................................................ 21

Field Status ...................................................................................................................................... 22

Field Status Groups .......................................................................................................................................... 23

Control Keys .................................................................................................................................... 24

Document Number Ranges......................................................................................................... 25

SAP Financial Accounting Basics Part II ......................................................................................................... 26

Posting Key ...................................................................................................................................... 26

Standard Posting Keys ................................................................................................................. 27

Posting Periods .............................................................................................................................. 28

Posting Periods and Document Header ...................................................................................... 28

Posting Periods and Line Items ................................................................................................ 29

Authorization Groups .................................................................................................................. 29

Tolerance Groups .......................................................................................................................... 29

Assigning Posting Authorizations ............................................................................................ 30

General Ledger Features ........................................................................................................................................ 31

Chart of Accounts .......................................................................................................................... 31

Company Code-Specific Settings ............................................................................................... 31

Account Groups .............................................................................................................................. 32

Reconciliation Accounts .............................................................................................................. 32

Transaction Figures......................................................................................................................................... 32

Sub-Ledgers .................................................................................................................................................................. 33

Accounts Payable .......................................................................................................................... 33

Account Groups for Vendors ....................................................................................................................... 33

Accounts Receivable ..................................................................................................................... 34

Account Groups for Customers .................................................................................................................. 34

Credit Management Master Record ......................................................................................... 34

Asset Master Data .......................................................................................................................... 35

Asset Class ............................................................................................................................................................ 35

Depreciation Areas .......................................................................................................................................... 36

Account Determination ............................................................................................................... 36

Group Assets and Sub-Numbers ............................................................................................... 37

Overview of Integration with Other SAP Modules Part I ........................................................................ 38

Controlling Area ............................................................................................................................ 38

Country-Specific Chart of Accounts (COA) ............................................................................ 38

Group Chart of Accounts ............................................................................................................................... 39

Controlling Objects ....................................................................................................................... 39

Integration with Materials Management (MM) ................................................................... 39

Plants ...................................................................................................................................................................... 39

Purchasing Organizations ............................................................................................................................ 40

Materials Management View of the Vendor Master Record ............................................ 40

Posting Procurement Transactions in FI ............................................................................... 40

Integration with Sales and Distribution (SD) ...................................................................... 42

Sales Organizations ......................................................................................................................................... 42

Distribution Channels..................................................................................................................................... 42

Divisions ............................................................................................................................................................... 43

Sales Area Data in the Customer Master Record ................................................................. 43

Sales Process and FI...................................................................................................................... 43

SUMMARY ...................................................................................................................................................................... 45

About The Author

Peter Moxon was born in the UK in 1971 to proud Yorkshire parents and grew up in Leeds.

He has worked for a multitude of corporations implementing and support business

intelligence system and mobile app technology.

He has published video training courses at his website as well as publishing books through

Amazon.

From Peter:

I love almost anything to do with modern day technology.

I have run my own software and publishing company based in the UK since 2004 and

have been working in the software industry for over 15 years.

My work sees me mixing enterprise (SAP) work with digital publishing and more

recently investing in and managing new business ventures involving mobile app

development.

There are two key parts of my job that really give me a 'buzz'.

Building and introducing new solutions for my clients and showing them how they can

go from zero to hero within their business in super fast time.

I have a passion for teaching and mentoring. I find teaching the skills I have built up

over the years and passing on my knowledge and "lessons learnt" to both new and

experienced professionals really satisfying.

For SAP enterprise work check out - http://www.saptraininghq.com for lots of free training

material.

For digital publishing and mobile development, visit: http://www.nichespin.com

Contact the Author

As the reader of this book you are my most important critic and commentator. I would love

to hear from you to let me know what you did and did not like about this book, as well as to

what you think I could do in future books to make them stronger.

Please note that although I cannot personally help you learn SAP Financials on a one to one

basis, I am available for corporate hire for project management, technical lead and

mentoring programs.

Refer to my website http://www.saptraininghq.com to see all the training material I have

available and to get a good overview of my expertise.

As you have bought this book there is a special discount coupon code included “disc20”.

You can use this coupon code at https://academy.saptraininghq.com to save money on any of

the courses.

OVERVIEW

Hello and welcome to this SAP Financials and Controlling (FICO) book.

This book has been created for anyone who wants to understand Financials and Controlling.

Specifically, this book targets the following audience:

Graduates who have basic understanding of finance and financial terminology and want

to learn FICO.

SAP Consultants with technical knowledge of how SAP works.

Consultants who need to learn the fundamentals in order to work with the SAP finance

modules.

Prerequisites

You should ideally already understand some of the basics of finance and know some financial

terminology. You should also be able to use the SAP graphic user interface (GUI).

Structure

This book divided into five major sections:

Section 1: Consists of two parts and gives an overview of the general financial

accounting terms.

Section 2: Consists of two parts in which you will understand the basics of SAP financial

accounting.

Section 3: You will learn about the important features of a general ledger.

Section 4: You will be introduced to sub-ledgers, accounts receivable, accounts payable,

and asset accounting.

Section 5: Consists of two parts in which you will learn how financial accounting

integrates with other SAP modules.

Objectives

After reading this book, you will be able to:

1. Recognize the organizational elements of R/3.

2. Describe the basic settings.

3. Classify and reconcile R/3 documents with the original documents.

4. Open and close posting periods.

5. Assign posting authorizations to users.

Apart from the before-mentioned objectives, you will also be able to identify important

general ledger features and identify the characteristics of sub-ledgers like accounts

receivable, accounts payable, and asset accounting. You will also be able to identify the

organizational structures of cost accounting, such as controlling areas, country-specific charts of

accounts, and controlling objects, and recognize how financial accounting is integrated with

other SAP modules such as Materials Management and Sales and Distribution.

General Financial Accounting Terms Part I

The first part of the General Financial Accounting Terms section is focused on organization

units of R/3:

A. Client.

B. Company code.

C. Country templates.

In SAP applications, organizational units form the basis of an enterprise structure. An

organizational unit handles a specific business function. The “Client” is regarded as the highest

level element for all organizational units. A client may represent an enterprise with several

subsidiaries.

The next level down shows the smallest organizational element for which a complete self-

contained set of accounts can be drawn up in R/3 - the “company code.” The third level of the

hierarchy shows the business segments or branches in which a group operates can be set up in

the R/3 System as “Business Areas.” Setting up of a business area in the application is, however,

optional.

Organizational Elements of R/3

Client

Specifications or data that is valid for all organizational units in SAP ERP applications are

entered at the client level. This data need not be entered at any other level again. Each client

acts as an independent unit with separate master records and a complete set of tables and data.

The system has a table that holds the client-specific data. When the client data is first created,

you have to specify a client key that identifies a specific client. Each client is identified by a

three-character code. Example: client 000, client 001, client 066 and so on. From a commercial

point of view, the client is a corporate group. You must specify a client key and have a user

master record in the client in order to log on to the system.

Company Code

The “company code” is a financial accounting unit. It represents an independent balancing or

legal accounting entity. An example would be a company with independent accounts within a

corporate group.

Financial statements required by law can be created at the company code level. Every

organization for which a financial statement and profit and loss statement is to be created must

be stored as a company code in the SAP system. Thus the company code is the organizational

unit that helps to structure an enterprise from a financial accounting perspective.

Financial statements required by law can be created at company code level. As discussed before,

a company code is the minimum structure necessary in mySAP ERP Financials. “mySAP ERP”

is part of the SAP Business Suite software, the name for the modules comprising the former SAP

R/3. These include:

Accounts Payable

Accounts Receivable

Accounting

Financial Reporting.

For international businesses, where operations are scattered across countries, a separate company

code is created per country. A company code has a unique four-character key.

Business Areas

Business areas are set up for separate areas of operation within an organization. They can

be used across company codes. They are balancing entities that can create their own set of

financial statements for internal purposes. It is possible to save and evaluate transaction figures

for each business area.

So, how is a company code created?

The easiest way to create a company code is to copy an existing company code using the

organization copy function. This copies the definition, global parameters, customizing tables

(approximately 315 tables), general ledger accounts, and account determination.

In this way, one can copy the existing company code-specific parameters and then edit the

required data in the new company code.

Select a four-character alpha-numeric key as the company code key. This key identifies the

company code and must be entered later when posting business transactions or creating company

code-specific data.

Note: You can also define the company code and fill the customizing tables from scratch. This

can be done by only copying the clients from client 000 after all the required languages have

been imported into client 000.

Country Templates

In the R/3 standard system, company code 0001 is a template for a general company code with

chart of accounts INT and no special country-specifications.

If company code is needed in a country for which a country template exists, the country version

program can be used. It copies the country-specific customizing tables from the specific country

template into company code 0001. Once the copying is completed, company code 0001 will be

customized for the selected country. This company code can then be copied into the new desired

company code. The country version program will have to be started again to create a template for

another country and so on.

Note: The country version program not only creates a country-specific company code template

but also a country-specific template for controlling areas, plants, purchasing organizations, sales

organizations, credit control areas, financial management areas, etc.

The Implementation Guide or the IMG suggests the following order for creating a company

code:

Copy, delete, check company code; and then

Edit company code data.

Attention: Do not forget to copy the template before you proceed further. Do not use company

code 0001 as your productive company code because the country version program always uses

this company code as the target company code. Furthermore, you should run the country version

program only in a new installation of R/3 and not in an upgrade installation because the structure

of the country-specific customizing may have changed from one R/3 release to another.

Editing a Company Code

Once a company code is created it can be edited in order to customize it for the selected country.

The following information is required while editing a Company Code:

1. The four digit company code key.

2. The address data for correspondence which is also recorded on evaluation reports.

3. The currency for the specific company code. Accounts are managed in the company code

currency and all other currencies are indicated as foreign. The system converts the amounts

posted in a foreign currency into this currency. The currency defined in the company code is

known as the local currency within R/3.

4. The country key, specifying the home country. The system interprets all other countries as

foreign. This is important for business or payment transactions, since different forms are

needed for foreign payment transactions, and the system supports different formats for

addresses for foreign correspondence.

5. The city key specifying the city and the language key specifying the language of the home

country also needs to be specified. This ensures that the system can create texts automatically

in the correct language, for example, during issuing of checks.

Apart from these, the global parameters that need to be taken into account while editing a

company code are:

1. Chart of accounts.

2. Fiscal year.

3. Company code defaults.

General Financial Accounting Terms Part II

In this part of the General Financial Accounting Terms section, you will learn about:

A. The variant principle.

B. Fiscal year.

C. The year-independent and the year dependent variant.

Variant Principle

You can use the 3-step method variant principle to assign special properties to one or more R/3

objects. Variants are used mainly because it is easier to maintain properties which are common

among several business objects. Once a variant is defined in SAP, the same variant can be

assigned to various or several business objects.

In SAP, the variant principle is used for field status, posting periods, and fiscal years.

While creating a fiscal year variant, the following steps should be performed:

Step 1: Define the variant: K4 is the fiscal year variant.

Step 2: Populate the variant with values: define the properties of fiscal year K4.

Step 3: Assign the variant to R/3 objects: Assign K4 to various company codes that use

this fiscal year.

Fiscal Year

The fiscal year is defined as a variant which is assigned to the company code. The

company’s fiscal year corresponds to the calendar year. Accounting management requires

at least four special periods for posting year-end closings.

The fiscal year variant contains the definition of posting periods and special periods.

Special periods are used for postings which are not assigned to time periods, but to the

process of year-end closing. In total 16 periods can be used. The system derives the posting

period from the posting date.

When the posting date falls within the last normal posting period, the transaction may be

posted into one of the special periods. In order to ensure that you can compare the closing

months with the other periods of the fiscal year, you should make closing postings in

special periods.

SAP allows a maximum of 16 posting periods each fiscal year - normally 12 regular posting

periods and four special posting periods. The four special periods could be comprised as

follows:

Period 13 as accrual/deferral postings.

Period 14 as audit postings.

Period 15 as general meeting of shareholders.

Period 16 as adjustment postings.

In the example shown above, the fiscal year has 12 posting periods and 4 special periods. If

the posting date falls in the12th period, the transaction can instead be posted in one of the

four special periods.

Note: Information regarding whether a period is open or closed is not included in the fiscal year

variant; this is maintained in another table. The fiscal year variant only defines the amount of

periods and their start and finish dates.

Year-Independent and Year-Dependent Variant

If each fiscal year of a fiscal year variant uses the same number of periods, and the posting

periods always start and end at the same day of the year, the variant is called year-

independent.

A fiscal year variant has to be defined as year-dependent if the start and the end date of the

posting periods of some fiscal years will be different from the dates of other fiscal years, and/or

if some fiscal years shall use a different number of posting periods.

Year-Independent Variant

A year independent fiscal year variant can be defined as the calendar year and a non-

calendar year.

If the fiscal year is defined as the calendar year, the posting periods are equal to the months of

the year. Therefore, a calendar year variant must have 12 posting periods.

If the fiscal year is defined as a non-calendar year, the posting periods need to be defined by

assigning ending dates to each period. A non-calendar year can have between 1 and 16 posting

periods. If the non-calendar year does not start at January 1st the periods of the year which

belong to the former or the coming fiscal year must get an annual displacement indicator, -1 or

+1.

In a non-calendar year with 6 posting periods, which go from April to March; the months

January to March, still belong to the old fiscal year and need to have the annual displacement

indicator “-1.”

If the fiscal year differs from the calendar year, but the posting periods correspond to calendar

months, the day limit for February should be 29 to be prepared for leap years.

Fiscal years are normally year-independent.

Year-Dependent Variant

A year-dependent indicator has to be set if the fiscal year is changing from year to year.

If all of the years of a year-dependent fiscal year variant have the same number of periods,

only the different period dates for the different years have to be defined.

If one year of a fiscal year variant has less posting periods than the others, it is called a

“shortened fiscal year”. This could be required if closing has to be made before the end of the

normal fiscal year; for example, if the beginning of the fiscal year should be changed or if the

company was sold.

The shortened fiscal year and its number of posting periods have to be specified before

providing definition of the period dates. For this year only, a lesser number of posting

periods can be assigned.

SAP Financial Accounting Basics Part I

In this first part of the SAP Financial Accounting Basics section, you will learn about:

a. The Document Principle.

b. R/3 Documents.

c. Field Status.

d. Control Keys.

e. Document Types.

f. Document Number Range.

Here, you will understand document control and the principles that are needed to be followed

while posting a document. This is known as document principle in SAP.

Document Principle

Any posting in SAP R/3 is always stored in a document form. This is called the document

principle in R/3. In the system, a document remains as a complete unit in the system until it

is archived.

A document is identified by the combination of the document number, the company code, and

the fiscal year.

The FI document consists of a document header. The information in the document header applies

to the entire document.

The FI document also consists of 2 to 999 line items. Here the information is specific to that line

item. The header and the line items can also be shown in detail.

Note: The system limitation does not allow you to have more than 999 line items per financial

accounting document.

Documents

Every business transaction is recorded in the R/3 system as a document. More than one

document can be created for a single business event. For example, when goods are received

from a vendor, a material document is created to keep track of details important to inventory

tracking. An accounting document is created to track financially relevant information, such as

general ledger accounts and amounts.

In some cases, a document may be created in R/3 for a business event, but no corresponding

accounting document is produced because there is no financial impact. One such example would

be purchase orders.

Each of these documents receives a unique document number.

Document numbers can be assigned either by the R/3 system or by the user at document

entry time. When the R/3 system assigns the number, it is an internal assignment. When

the user assigns the number, it is an external assignment.

R/3 links the related documents together to provide a comprehensive picture of any business

transaction within the system.

Field Status

Different fields are displayed when making a document entry. This depends on the

transaction and the accounts used. These different fields display during document

processing and are controlled by field status. For example, when posting expenses, cost center

and tax information are usually required. When posting cash, however, the information is not

necessary.

As a general rule, one needs to customize the account-dependent field status on general ledger

accounts. For customer and vendor processing, field status on the posting key has to be

customized as necessary.

Just as in the field status definition general ledger accounts, the field status with the higher

priority applies.

However, there are some exceptions to this rule. If business areas are used, the field “business

area” has to be ready for input. It is switched on by enabling business area balance sheets for the

company code. With the field status, it has to be decided whether it should be a required or is an

optional entry field.

Tax fields are only ready for entry if the general ledger account is set up as tax-relevant.

The field status definitions “suppress” and “required entry” cannot be combined. This

combination causes an error.

Field Status Groups

Field Status Groups Variants Comp. Code

Cash Accounts

Text: Required

Cost Center: Sup.

Allocation: Opt.

G001 0001 C001

C002

C003

Expense Accounts

Text: Optional

Cost Center: Required

Allocation: Opt.

G002

General Accts

Revenue Accts

Material Accts

Text Optional

G003

GR04

GR05

It is essential to determine the status of every document entry field under each general

ledger account category like, cash accounts, and expense accounts. For example, will the text be

required, suppressed, or is it optional for document entry when using the general ledger

accounts? Will cost center be required, suppressed, or is it?

These “rules” are grouped into field status groups for each category of general ledger accounts.

Field status groups are assigned to the respective general ledger master records.

The field status groups are collected under one field status variant. The field status variant is

assigned to the company code(s). No posting can be made until this is complete. Typically, the

same field status variant is assigned to all the company codes so that the same “rules” apply

across all company codes.

The R/3 structure has a standard set of field status groups. It is recommended to copy the

standard delivered field status groups and modify as necessary. If a document is posted to a sub

ledger account, the field status group of the reconciliation account will apply.

Control Keys

The two most important control keys are (1) Document Type for the header and (2) the

posting key for the line items.

Document Type

Document type controls the document header. It is used to differentiate the business

transactions to be posted, for example, customer invoice, vendor payments, etc.

Document types are defined at the client level and are valid for all company codes.

A standard system is delivered with document types which can be used, modified, or copied.

Major controls of document types are the number range of document numbers, and the account

types allowed for posting.

Document type further controls the field status of the header fields “Text” and “Reference

Number”, and if invoices are posted with the net method.

In the SAP recommended procedure for filing original documents, the document type controls

document filing.

Remember to always store original documents under the number of the data processing

document. If the original document has an external number, enter the external number of the

original document into the reference number field in the header of the data processing document,

and then record the data processing document number in the original document.

Standard Document Types

Some of the important standard document types are AB for general documents, DR for

customer invoices, DZ for customer payments, and so on.

Note that only the document type AB (which includes general documents) allows postings to all

account types. All other document types limit the types of accounts that can be posted to. For

example, document type DG (that deals with Customer Credit Memos) allows posting to D

(customer) and S (general ledger accounts) only.

To transfer billing documents from the R/3 billing system, the standard system uses two

document types; RV and RE. RV indicates billing document transfer, and is the default

document type for SD billing documents (i.e. customer invoices). RE indicates invoice receipt,

and is the default document type for MM billing documents (i.e. vendor invoices).

When internal number assignment is used, the system assigns a new number to each document in

the Financial Accounting component. In external number assignment, the system transfers the

billing document number to the FI document as long as this number has not already been

assigned. The payment program uses the document type ZP, which stands for payment postings,

for its automatic postings.

Document Number Ranges

The document number range defines the allowable range in which a document number

must be positioned and cannot overlap.

In internal numbering, the system stores the last used document number from the number range

in the field “current number” and takes the subsequent number for the next document (examples

00 and 01).

In external numbering the user enters the original document number, or the number is transferred

automatically from a pre-invoicing system. The numbers usually are not used in sequence and

therefore the system cannot store a “current number”. The numbers may be alphanumeric.

The document number range has to be defined for the year in which it is used. Document number

ranges can be either defined until a fiscal year in the future or for each fiscal year.

In the first case, at the beginning of each fiscal year the system continues to take the next number

after the “current number”. It does not restart at the lower limit.

In the second case, when the document number ranges are defined per fiscal year the document

numbering starts again at the lower limit. This helps to avoid reaching the upper limit of a range.

Note that a single number range can be assigned to several document types.

SAP Financial Accounting Basics Part II

In this second part of the SAP Financial Accounting Basics section, you will learn about the

second important control key:

A. Posting Key.

B. Standard Posting Keys.

C. Posting Periods; and its relationships.

D. Document Header and Line Items.

E. Authorization Groups.

F. Tolerance Groups.

Posting Key

A posting key in SAP is a two-digit key that controls the entry of line items. Just like document

types, posting keys are also defined at the client level. The posting key indicates whether the

line item deals with a payment transaction or not. This information is required while analyzing

payment history and creating payment notices.

Debit Credit

GL Transaction 40 50

Customer Invoices 01 50

Vendor Invoices 31 40

Posting key also indicates whether the sales figures of the account should be updated by the

transaction, for example, when posting a customer invoice.

In the standard transactions, posting keys are labeled “debit” and “credit.” In customizing, R/3

delivers the following default values:

For GL Transactions: “debit” is posting key 40, “credit” is posting key 50.

For Customer Invoices: “debit” is posting key 01, “credit” is posting key 50.

For Vendor Invoices: “credit” is posting key 31, “debit” is posting key 40.

Standard Posting Keys

Take a look at the image. It shows the standard posting keys in SAP.

It is advisable to use these standard delivered posting keys. If required to change them or define

new posting keys, all tables containing a reference to these keys must also be maintained. If

posting keys are to be deleted, it should be ensured that these are not already used in the system.

Posting keys for assets and materials may only be used if the corresponding SAP components are

implemented. By influencing the field status definitions of posting keys and the field status

group, the field status can be made transaction-dependent and account-dependent.

Sub ledger accounts do not have a field status groups. Differentiation in the sub ledger postings

is mainly made by different posting keys. Therefore, there are a lot of posting keys for sub ledger

postings.

In general ledger postings, differentiation is mainly made by different field status groups.

Therefore, only two posting keys (40 and 50) are needed for general ledger postings.

Posting Periods

Posting periods are defined in the fiscal year variant. The posting date in the document header

determines the posting period in which postings are to take place.

Posting periods which are not in use can be closed. This prevents documents from being posted

to a wrong posting period.

Usually the current posting period is open and all other periods are closed.

At the end of a period, it is usually closed and the next period is opened. A period is opened by

entering a range into the posting period variant which encompasses this period. It is possible to

have as many periods open as desired.

During financial closing, some special periods may also be open for closing postings.

During the closing procedure, two period ranges should be open at the same time. Therefore, two

period ranges can be entered in the posting period table.

For technical reasons, for each posting period variant an entry “+” is required that is valid for

all account types such as customer, vendor, asset etc.

Posting Periods and Document Header

You can use the same posting period variant for several company codes. The closing and

opening of periods is then done at the same time for all assigned company codes, thus making

period maintenance easier.

At the document header level, R/3 checks the periods that are allocated to the account type “+”.

Since this is the first check, the account type “+” must be open for all periods which are

supposed to be open for any other account type. The account type “+” is the minimum entry in

the posting period variant.

Posting periods can be managed differently for different account types, that is, for a certain

period postings on customer accounts may be possible while postings on vendor accounts may

not.

Posting Periods and Line Items

At the line item level, R/3 checks the account type of the posting key to verify that the

period is open for the assigned account type.

The account range always contains general ledger accounts. By entering certain reconciliation

accounts behind sub-ledger account types, these sub-ledger accounts can be treated differently

than accounts which have a different reconciliation account.

Authorization Groups

During the time of the closing procedure, two period ranges have to be opened at the same

time. Therefore, two period ranges can be entered in the posting period table.

An authorization group may be assigned to the first range. Then, only users belonging to this

authorization group have the permission to post into the first period range. It makes sense to use

the first range for the special periods and authorize only the accountants involved in closing to

post into the special periods.

Using the standard authorization object F_BKPF_BUK, the user can determine which

company codes documents can be processed. The user must have the authorization for the

standard authorization object F_BKPF_BUP with the same value in the field “authorization

group” as in the posting period table.

Tolerance Groups

Processing of payment differences are controlled through tolerance groups. Tolerance

groups ensure that employees do not exceed their defined authority in financial

transactions.

The maximum amounts are defined per company code in tolerance groups. It defines the

upper limits for posting procedures, such as, total amount per document, amount per open

account item, the cash discount percentage a user with this tolerance group is able to grant.

Assigning Posting Authorizations

You can create as many tolerance groups as required. A user can be assigned explicitly to a

tolerance group.

In case a user is not assigned to any specific tolerance group, then entries in the default tolerance

group are valid for them. A blank space within quotes in the Tolerance Groups table

symbolizes the default tolerance group.

Usually the default tolerance group contains values which are to be valid for the largest number

of employees.

For any employees who have especially high or low limits, a special tolerance group should be

created and assigned to their user logon IDs.

General Ledger Features

In this chapter, you will learn some important general ledger features such as:

a. Chart of Accounts.

b. Company Code-Specific Settings.

c. Account Groups.

d. Reconciliation Accounts.

e. Transaction Figures.

Chart of Accounts

The chart of accounts is the list of all the general ledger accounts that can be used by one or

more company codes. It is one of the first organizational elements that should be finalized in a

company implementing SAP. The chart of accounts is the foundation for its reporting and

posting activities.

If you have access to a standard SAP IDES (SAP-internal demonstration systems) Demo

system you will see the following chart of accounts in use in. The IDES company codes use the

following charts of accounts: INT is used by company codes 1000, 2000, 2100, 2300, and

6000. CAUS is used by company codes 3000 and 4000. CAFR is used by company code

2200. CAJP is used by company code 5000.

Company Code-Specific Settings

First, the account definition at the chart of accounts level has to be maintained before one

can use an account in a company code. Then the company code-specific settings have to be

created. These settings are only valid in the company code. For example, the account currency

defined for a company code.

Most of the accounts in company code 1000 use the UNI currency, whereas company code 3000

uses USD for most of its accounts.

Account Groups

General ledger accounts are organized into account groups. The account group is a summary of

accounts based on criteria that affects how master records are created. The account group

determines the number interval from which the account number is selected when a general ledger

account is created. It also establishes the screen layout for creating general ledger accounts in the

company code-specific area.

These account groups help in managing a large number of general ledger accounts. The

accounts of an account group normally have similar business functions. For example, there

can be an account group for cash accounts, one for expense accounts, one for revenue

accounts, and one for other balance sheet accounts.

Reconciliation Accounts

Reconciliation accounts are general ledger accounts that receive postings from subsidiary

ledger accounts in real-time. This means that a posting to a subsidiary ledger also posts to

the corresponding reconciliation account in the general ledger at the same time. The

subsidiary ledgers which are connected to the general ledger via reconciliation accounts

are the accounts payable (A/P), accounts receivables (A/R), and asset ledgers.

Transaction Figures

Another important feature of general ledger accounts is the transaction figure. A

transaction figure is the total of all debit or credit postings. In general, the R/3 System

keeps one transaction figure for debits and one transaction figure for credits per account.

The financial statements for the company code are calculated using these transaction

figures.

While using business areas, transaction figures are also kept per business. If financial statement

for the business area is created, the transaction figures for that specific business area are used to

supply the information for the financial statements.

Sub-Ledgers

In this section, you will learn about the sub-ledgers:

a. Accounts Payable.

b. Accounts Receivable.

c. Credit Management Master Record.

d. Asset Master Data.

e. Account Determination.

f. Group Assets and Sub-Numbers.

Accounts Payable

Accounting data for all vendors are recorded and managed in the “Accounts Payable”

application component. Postings made in accounts payable are simultaneously recorded in

the general ledger. Accounts payable is a vital part of the purchasing system. Deliveries and

invoices are managed according to vendors.

The vendor master record stores all the data required to carry out business with the vendors. As

with general ledger accounts, vendor accounts are made up of two areas: a vendor account and

account groups for vendors.

A vendor account is defined for all company codes at the client level. General data, such as the

vendor's address, tax numbers, and bank details are stored in it. Note that postings cannot be

made to the account in a company code until company code-specific settings have been made,

such as the agreed terms of payment.

Account Groups for Vendors

Similar to general ledger accounts, vendor accounts can also be combined in various

account groups. The account group is a summary of accounts based on criteria that affects how

master records are created. The account group determines the number interval from which the

account number is selected when a vendor account is created. It also establishes the screen

layout for creating vendor accounts in the company code-specific area. This way, they can be

organized and managed more easily.

The accounts in an account group usually have similar characteristics. For example, one can have

one account group for domestic vendors, one for vendors abroad, one for affiliated vendors, and

one for one-time accounts.

Accounts Receivable

Accounting data for all customers are recorded and managed in the “Accounts Receivable”

application component. All postings made in accounts receivable are also simultaneously

recorded in the general ledger.

As with general ledger accounts and vendor accounts, customer accounts are also made up

of two areas: a customer account and account groups for customers.

A customer account is defined for all company codes at the client level. General data, such as the

customer's address, is also stored here. Postings cannot be made to the account in a company

code until company code-specific settings have been made, such as the agreed terms of payment.

Account Groups for Customers

Customer accounts can be combined in various account groups. The account group is a

summary of accounts based on criteria that affects how master records are created. The

account group determines the number interval from which the account number is selected

when a customer account is created. It also establishes the screen layout for creating

customer accounts in the company code-specific area. This way, the accounts can be organized

and managed more easily.

The accounts in an account group usually have similar characteristics. For example, one can have

one account group for domestic customers, one for customers abroad, one for affiliated

customers, and one for one-time accounts.

Credit Management Master Record

The credit department sets up a separate credit management master record. This is an

extension of the customer master record. Data applicable to credit management is maintained

and monitored through this master record.

The credit management master record is made up of three sections: general data, credit control,

and overview.

General data is relevant for all credit control areas. This could be the customer's address

and communication data, or the maximum total limit that can be permitted for the sum of

all granted credit limits.

Credit control is a data which is only relevant for a specific credit control area. This could

be the credit limit at credit control area level, or a customer's risk category.

The credit management master record also provides an overview, which contains the

most important data from all sections.

Asset Master Data

All accounting data related to assets are maintained in the asset sub-ledger account. Asset

sub-ledger accounts are created when an asset master record is created and are associated with a

reconciliation account in the general ledger.

Each asset belongs to a company code and business area. All postings made for the asset, for

example, acquisitions, retirements, depreciation, etc., are applied in the assigned company code

and business area. Additionally, they can be assigned to various CO objects; for example, cost

center, internal order, activity type, and logistic organizational units.

Two important aspects of asset master data are asset class and depreciation area. You will now

learn more about each of these. Let’s first take a look at asset class.

Asset Class

Asset class is the main criterion for classifying assets in financial accounting. It is used to

assign the assets to the correct general ledger accounts.

In the asset class, it is possible to define certain control parameters and default values for

depreciation and other master data.

Assets such as buildings and equipment that do not appear in the same line item of the balance

sheet are assigned to different asset classes. Additionally, there is at least one special asset class

for assets under construction and one for low-value assets.

Asset classes can be created for intangible assets and leased assets. There are functions available

for processing leases.

The application component PM or Plant Maintenance is used for the technical management of

assets. The application component TR which stands for Treasury is used for managing financial

assets.

Depreciation Areas

A depreciation area shows the valuation of assets for a particular purpose.

Various valuation methods can be used for financial statements based on regional requirements,

financial statements for tax purposes (if a different deprecation method is allowed), controlling

(costing), parallel accounting methods for group financial statements as per International

Accounting Standard (IAS), United States Generally Accepted Accounting Principle (US-

GAAP), etc.

Depreciation areas are kept in the R/3 System in order to store more than one valuation basis.

Separate transaction figures are kept per asset and depreciation area and for individual value

components such as balances, depreciation, remaining book value, etc.

The depreciation areas in asset accounting do not exist in the general ledger. These values need

to be posted to various general ledger accounts in the general ledger.

Account Determination

The general ledger accounts into which the values are posted are then used in various

financial statement versions such as, financial statements per GAAP, financial statements

for tax authorities, group financial statements, and so on.

These general ledger accounts are balance sheet accounts, which record the adjustments to the

asset's value and depreciation accounts for depreciation and appreciation.

The assignment of the general ledger accounts to various valuation areas is saved in a single

account assignment key. This is entered in the asset master record. Assets of the same asset

class have the same account assignment key. Their values are all posted to the same

reconciliation accounts.

Group Assets and Sub-Numbers

Parts of an asset can be kept under asset sub-numbers. Asset sub-numbers are numbers,

which in combination with the main asset number uniquely identifies an asset in the system.

Using the asset sub-number it is possible to represent complex fixed assets in the system.

This is usually done for reporting purposes. Assets can be combined in group assets.

The main asset is assigned the sub-number 0000, allowing the asset sub-numbers to be

assigned as desired.

A group asset has its own master data. Several main assets can be assigned to a group. This

is important in the USA.

Overview of Integration with Other SAP Modules Part I

The first part of the Overview of Integration with Other SAP Modules section, will give you

an outline of the organizational structures of cost accounting, such as:

a. Controlling Areas.

b. Country-specific Chart of Accounts.

c. Controlling Objects.

d. Integration of Financial Accounting with Materials Management.

Controlling Area

A controlling area is a self-contained organizational structure for which costs and revenues

can be managed and allocated. It represents a separate unit of cost accounting.

A controlling area can be assigned to one or more company codes. If the assigned company

codes and the controlling area all utilize the same operating chart of accounts, it is possible to

carry out cross-company code cost accounting between the assigned company codes.

Country-Specific Chart of Accounts (COA)

As a great deal of activity takes place between the four European company codes—

Germany, the United Kingdom, Portugal, and Spain — it is significantly important for the

“Internet Demonstration and Evaluation System” or IDES board of directors that all these four

company codes belong to the same controlling area. As a result they had to adopt the

operating chart of accounts International (INT) of the controlling area.

However, in order for it to be possible for external reports to contain the account numbers

usually used in the individual countries, a country-specific chart of accounts was created for the

company codes Germany, the United Kingdom, and Spain. These country-specific charts of

accounts are structured in accordance with the legal requirements of each of these countries.

Group Chart of Accounts

The two companies in North America were originally independent firms, but were later

purchased by the IDES group. Both companies were already live with R/3. They were using

the chart of accounts CAUS as the operating chart of accounts.

Management determined that since cost accounting for Europe and the USA together was not

necessary, it retained the operating chart of accounts CAUS for the two U.S. company codes and

assigned them to a separate controlling area.

For consolidation purposes, a group chart of accounts was set up for the two operating charts of

accounts.

Controlling Objects

A controlling area contains controlling objects. These objects take on various functions

within controlling, such as internal orders, cost objects, networks, projects, cost centers,

and make-to-order sales orders.

Controlling objects are again classified into true and statistical controlling objects. True

controlling objects can allocate their costs to other controlling objects. Statistical controlling

objects cannot reallocate their costs and only bear their costs for information purposes.

Integration with Materials Management (MM)

Materials Management (MM) uses the company code from Financial Accounting (FI), the

plant from Logistics – General, and the purchasing organization and storage location from

Materials Management to define its enterprise structure. Purchasing organizations are

required to enter data specific to purchasing in the vendor master record. Procurement

transactions are posted in Financial Accounting through the three-stage verification

procedure.

Plants

Plant is the central organizational object in Logistics. Many plants can be contained in a

company code. This means that many plants can be assigned to the same company code.

Let’s consider the example of IDES company code 1000 (Germany). The plants in this company

code are 1000 (Hamburg), 1100 (Berlin), 1200 (Dresden), 1300 (Frankfurt), and 1400 (Stuttgart).

All company-code relevant transactions from these plants are posted in company code 1000.

Purchasing Organizations

The purchasing organization purchases for the plants. It’s legally responsible for

completing purchasing contracts. Each country, in which IDES plants operate, has one

purchasing organization. They purchase for all plants in the country and post the purchases

in the company code of that country.

Let’s again consider the example of company code 1000 (Germany). The purchasing

organization 1000 takes care of purchasing for all German plants (Hamburg, Berlin, Dresden,

Frankfurt, and Stuttgart). Postings are made in Germany company code 1000.

Materials Management View of the Vendor Master Record

As depicted in the image above, vendor master creation includes three settings: general

data, company code settings, and purchasing organization settings.

The purchasing organizations purchase goods and services from suppliers, who are paid by

accounts payable. The various purchasing organizations of the group have to enter data specific

to purchasing in the vendor master record before the supplier's master record can be used.

Posting Procurement Transactions in FI

The standard procedure for posting procurement transactions in Financial Accounting (FI)

comprises a three-step verification procedure.

Step one involves creating a purchase order. This transaction is completed in Materials

Management. No postings are made in Financial Accounting.

Step two involves the creation of the goods receipt. To update the inventory, a material

document is created in Materials Management. Simultaneously, a document is created in

Financial Accounting, with which the value of the goods is posted to the materials account

(debit) and the goods receipt/invoice receipt account (credit) in the general ledger.

The third and the final step, in the three-step verification procedure involve the creation of the

invoice receipt. The vendor invoice is posted in Materials Management, which automatically

creates a document in Financial Accounting. The Financial Accounting document contains the

invoice amount that is posted to the goods receipt/invoice receipt account (debit) and the vendor

account (credit).

The last two steps can be interchanged depending on the order the goods and the invoices are

received.

The goods receipt/invoice receipt account ensures that goods were received for each invoice and

vice versa.

Overview of Integration with Other SAP Modules Part II

The second part to the Overview of Integration with Other SAP Modules section, you will

get an overview of the integration of financial accounting with Sales and Distribution.

Integration with Sales and Distribution (SD)

Now you will take a look at the components of Sales and Distribution module such as sales

organizations, distribution channels, and divisions. Then, you will explore how Sales and

Distribution interacts with the Financial Accounting module in SAP.

Sales Organizations

The sales organizations are legally responsible for sales in R/3. One company code may contain

several sales organizations. Let’s again consider the example of IDES company code 1000

(Germany). The IDES company code 1000 includes the sales organizations 1000 (Frankfurt) and

1020 (Berlin). This means that any accounting-relevant transactions in either of these sales

organizations are posted in company code 1000.

Distribution Channels

A sales organization may sell materials through different distribution channels. In principle,

a distribution channel can also be used by two different sales organizations. The distribution

channel represents the channel through which salable materials or services reach customers.

Typical distribution channels include wholesale, retail, and direct sales.

The image above shows the IDES distribution channels in Germany. These are customer sales,

resellers, service, factory sales, store chains, industrial customers, and pharmaceutical customers.

The combination of a sales organization and a distribution channel is called a distribution chain.

Distribution chains sell goods from the plants. For example, both of the IDES distribution chains,

1000-10 and 1000-12 sell goods from the IDES plant in Hamburg and post the sales in IDES

company code, 1000, which is also assigned to the plant.

Divisions

Materials are divided into divisions in the R/3 System. This helps in the easy management of a

large volume of different materials. For example, the IDES group uses the divisions’

motorcycles, paints, and foods as depicted in the image below.

The divisions are assigned to the distribution chain from which they can be sold. The

combination of distribution chain and division is a sales area. Customer-specific arrangements,

like partial deliveries or terms of payment, can be made for each sales area. Statistics can be

created and separate marketing activities can be carried out within a sales area.

Sales Area Data in the Customer Master Record

Customer master creation includes three settings: general data, company code settings and

sales area specific settings.

A sales area, which is a combination of sales organization, distribution channel, and division,

must define sales area-specific settings for a customer before it can start doing business with that

customer. These could be special conditions and terms of payments that the customer has

arranged with the specific sales area.

Sales Process and FI

The sales order forms the basis of the sales process. Once a customer has placed an order, a

sales order must be created at the start of the process. The sales order is generated at the

distribution chain level. The ordered items can be from different divisions. The sales order is a

document in SD and does not cause any postings in Financial Accounting.

When the sales order has been entered, the system carries out an availability check for the

required delivery date. On the day of shipping, an outbound delivery document is created. Billing

for the delivery can only take place when the goods have been taken from the warehouse stock

and posted as a goods issue. The warehouse management function is used for picking. A transfer

order has to be created, which generates the pick order. The requested goods are taken from the

warehouse and prepared for delivery.

The goods to be delivered are posted as a goods issue. A goods issue document is created in

Materials Management, and an accounting document is created in Financial Accounting so that

the goods issue is posted to the correct general ledger accounts.

The last stage in the sales process is billing. A billing document is created in Sales and

Distribution, and a printed invoice is sent to the customer. At the same time, a document is

created in Financial Accounting so that the receivables and revenues can be posted to the correct

accounts.

SUMMARY

Here is a quick recap of what was covered in this book.

You learnt about general financial accounting terms, organizational elements of R/3, and its

basic settings as well as the basics of SAP financial accounting. You also learnt about the fields

of document header and line items and discussed how to open and close posting periods, and

assign posting authorizations to users.

This book also covered the important general ledger features and the characteristics of sub-

ledgers — accounts receivable, accounts payable, and asset accounting.

Lastly, you learned the organizational structures of cost accounting, such as controlling areas,

country-specific charts of accounts, and controlling objects. You also learnt how financial

accounting (FI) integrates with other SAP modules such as Materials Management (MM) and

Sales and Distribution (SD).