SAP Finacial Accounting and controlling
Hello and welcome to this SAP Financials and Controlling (FICO) monster article.
This article has been created for anyone who wants to understand Financials and Controlling. Specifically, this article 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.
The article is 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.
After reading this article, you will be able to:
- Recognize the organizational elements of R/3.
- Describe the basic settings.
- Classify and reconcile R/3 documents with the original documents.
- Open and close posting periods.
- 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:
- Company code.
- 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
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.
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
- 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 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.
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:
- The four digit company code key.
- The address data for correspondence which is also recorded on evaluation reports.
- 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.
- 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.
- 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:
- Chart of accounts.
- Fiscal year.
- Company code defaults.
General Financial Accounting Terms Part II
In this part of the General Financial Accounting Terms section, you will learn about:
- The variant principle.
- Fiscal year.
- The year-independent and the year dependent variant.
Variant Principle [T3]
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.
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.
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.
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:
- The Document Principle.
- R/3 Documents.
- Field Status.
- Control Keys.
- Document Types.
- 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.
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.
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.
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
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.
The two most important control keys are (1) Document Type for the header and (2) the posting key for the line items.
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:
- Posting Key.
- Standard Posting Keys.
- Posting Periods; and its relationships.
- Document Header and Line Items.
- Authorization Groups.
- Tolerance Groups.
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.
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 labelled “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 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.[T4]
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.
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.
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[T5]
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:
- Chart of Accounts.
- Company Code-Specific Settings.
- Account Groups.
- Reconciliation Accounts.
- 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.
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 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.
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.
In this section, you will learn about the sub-ledgers:
- Accounts Payable.
- Accounts Receivable.
- Credit Management Master Record.
- Asset Master Data.
- Account Determination.
- Group Assets and Sub-Numbers.
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.
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 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.
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.
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:
- Controlling Areas.
- Country-specific Chart of Accounts.
- Controlling Objects.
- Integration of Financial Accounting with Materials Management.
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.
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.
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.
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.
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.
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 saleable 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.
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.
Here is a quick recap of what was covered in this article.
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).