ACCOUNT DETERMINATION

IN SAP
Whitepaper by David A. Burns
 White Paper: SAP Account Determinations
by David A. Burns
The Concept

Account determinations in SAP, also referred to as automatic account assignments, are pre-assigned G/L
accounts used in specific business transactions. For practical purposes, account determinations
automatically generate FI line items (for transactions originating in FI) or entire FI documents (for
transactions originating outside FI). In posting FI documents, account determinations provide
consistency, ease of entry, and accuracy.

End  users  don’t  always  know  what  G/L  accounts  are  relevant  to  a  particular  FI  posting,  and  account  
determinations thereby lessen the potential for human error. They provide seamless integration within FI
and between FI and other SAP modules. Transactions originating outside of FI require account
determinations when the SAP transaction has a financial impact.

Before attempting to configure account assignments in SAP, you first need a solid chart of accounts (COA).
Then, and only then, can you effectively blueprint account determinations, business process by business
process, and transaction by transaction.

Configuration is first done and tested in a development instance of SAP. Afterwards, it is transported to a
quality assurance (QA) instance for additional testing. Note that testing account assignments is the
responsibility not only of the finance department but also of the team from which a financial posting
originates, such as Materials Management (MM) or Sales and Distribution (SD).

To achieve high data quality, all account determinations should be fully tested before being transported
into production. This is time consuming but beats the alternative. Fixing account assignments in
production after the fact may require reversing or adjusting entries, additional configuration and testing,
and significant error analysis.

Configuration of account determinations occurs in  SAP’s  IMG  using  transaction  code  SPRO.    SAP  also  
provides transaction codes for most of the configuration for quick and easy access to the configuration
tables. We will cover these transaction codes in detail.
FI Transactions

One of the first account determinations necessary in an SAP system is the retained earnings account.
Before any financial postings can be made, at least one retained earnings account must be specified using
transaction code OB53. Retained  earnings  are  classified  in  the  B/S  under  shareholder’s  equity.    At  year-
end, profit and loss accounts are closed and the net balance (net profit or loss) is carried over to the B/S
vis-a-vis retained earnings.

Example OB53

Unlike retained earnings, SAP fixed asset account determinations are complex and require more planning.
To begin, a logical G/L nomenclature is needed to achieve the best results. In setting up fixed asset G/L
accounts, it’s  important  to  provide  a  nomenclature that aligns with asset classes, thereby enabling ease of
use in creating and maintaining assets.

SAP transaction code AO90 is used to assign fixed asset G/L account assignments. Relevant transaction
types include fixed asset acquisitions, depreciation, gains/losses, revaluations, sales, and transfers. G/L
account master data must be properly setup to allow proper account determinations. For example, SAP
validates that an account assigned to depreciation expense is set up as a profit and loss account.

Example Depreciation Expense Account (FS03)

www.primepsm.com Page 2
SAP also checks fixed asset balance sheet accounts, such as asset acquisitions, to ensure the master data
is set up with the asset reconciliation account type.

Example Asset Acquisition Account (FS03)

Individual consistency checks are routine in the fixed asset configuration. Moreover, SAP provides an
overall consistency check that provides the status of all fixed asset account determinations. The
transaction code used for this purpose is OAK4. All issues and inconsistencies listed in OAK4 should be
resolved before moving fixed asset configuration into production.

Let’s  take  a look at an example of account determinations in fixed assets. Asset classes in SAP are
categories of fixed assets that have distinguishing features, such as useful life and depreciation method.
Much of the SAP configuration for fixed assets centers on these  classes.    Let’s  assume  that  there  is  an  
asset class 160010 for IT assets, and it has the following account determinations:

B/S Account Acquisitions: 160010

B/S Account Accumulated Depreciation: 170010
P&L Account Depreciation Expense: 440010

In SAP, asset acquisitions can be made using either F-90 or ABZON. In our example, an asset acquired
using asset class 160010 will automatically post a debit to G/L account 160010 (i.e. IT assets) and credit
accounts payable. After capitalization, the asset is depreciated using SAP transaction AFAB. When
executed, depreciation will automatically generate an FI document with a debit to G/L account 440010
(i.e. depreciation expense) and credit to account 170010 (i.e. IT assets - accumulated depreciation).

In addition to retained earnings and fixed assets, FI has a substantial number of additional account
assignments. The more commonly used ones include taxes, gains/losses, goods receipt/invoice receipt
(GR/IR), discounts, exchange rate differences, interest, split ledger, payments, banking, and clearing
accounts. Listed below are many of the transaction codes needed to make your account determinations.

www.primepsm.com Page 3
Common FI Account Determinations
GSP_KD Split ledger zero balance account
AO90 Fixed assets
OAK4 Asset consistency check
OB40 Taxes
OB53 Retained earnings
OBB0 Discounts
OBO9 Exchange rate differences
OBV1 A/R Interest in arrears
OBV2 Interest
OBWW Extended withholding taxes
OBXA Net method
OBXB Tax clearing
OBXD Bad debt
OBXK Vendor bank charges
OBXL Clearing differences
OBXL Over/under payments
OBXR Customer down payments
OBXT Alternate Vendor reconciliation accounts
OBXU Cash discounts taken
OBXV Lost cash discounts
Alternate customer reconciliation
OBXY accounts
OBXZ FI Clearing differences
OBYP GR/IR
OBYR Down payments received
OBYS Withholding tax
OBYT A/R for HR
OBYU A/P for HR
OBYY Tax exchange rate differences

It’s  important  to  put  account determinations into perspective. Many account determinations are required
by SAP. Among these are taxes, payments, banking, and GR/IR. Other account determinations are helpful
but not absolutely required from a configuration perspective. These include clearing accounts, rounding
differences, and alternate A/P and A/R reconciliation accounts. The point is that to effectively blueprint
your account assignments, you will benefit from bucketing them as follows:

1. Those required by SAP;

2. Those that are not required by SAP but are essential to your business process;
3. Those that are nice to have; and
4. Those that are irrelevant.

www.primepsm.com Page 4
This will help you to sift through the plethora of possibilities and allow your SAP implementation to focus,
first, on  what’s  necessary  to  run  the  business. Additional account assignments can always be added or
changed in the future.

Transaction Originating Outside FI

Any SAP module that provides seamless integration with SAP FI requires account determinations. This
includes MM, SD, Human Capital Management (HCM), Real-Estate, Travel Management, Investments, and
more. Here, MM and SD will be covered in detail.

First,  let’s  begin  with  MM. Purchase requisitions and purchase orders have numerous follow-on
transactions which have a financial impact. Our first example is a receipt of goods. These transactions are
processed through transaction code MIGO. The account determination for GR/IR (i.e. OBYP) enables
MIGO to automatically create an FI document with a debit to inventory or expense and a credit to GR/IR.
Without  the  GR/IR  specification,  a  goods  receipt  entry  cannot  post  because  the  system  doesn’t  know  how  
to record the financial impact.

Along the same lines, the GR/IR account determination enables an invoice, processed using transaction
code MIRO, to automatically create an FI document that debits GR/IR and credits accounts payable. This
does not apply to FI invoices posting using FB60. Again, as with goods receipts, the invoice entry cannot
post without the GR/IR account assignment because  the  system  doesn’t  know  how  to  record  the  financial  
impact.

GR/IR and other MM account determinations are configured with transaction code OBYC. Within OBYC,
MM account assignments are clustered via a Group Key. This key is predefined by SAP as a means of
grouping business transactions. All the MM account assignments are assigned to group RMK.

Example OBYC

As shown in Example OBYC above, the Procedures area consists of numerous transaction keys and their
descriptions. Here, you select by double-clicking on a transaction, and on the next screen, enter your
account assignments.
www.primepsm.com Page 5
In the example below we see the account assignments for stock transfer revenues and expenses. Notice
that the account assignments are separated by valuation class. The valuation class is an MM object
allowing materials to be classified into groups, thereby allowing different G/L account assignments.

Example Account Assignment Stock Transfers

Here, once again, we emphasize that not all account assignments are needed to run your business. For
MM account determinations, the list below provides some of the common ones used for a manufacturing
company.

Common MM Account Determinations

(Listed by OBYC Transaction Code)
Transaction Description
AKO Consignment
AUM Stock Transfer
BSV Change in stock account
BSX Inventory posting
FR1 Freight
GBB Offsetting inventory posting
KON Consignment payables
PRD Price differences
UMB Gain/Loss from revaluation
UPF Unplanned delivery costs
WRX GR/IR

Some account determinations, such as those for SD, are not as simple as plugging in a G/L account
number into a configuration table. In fact, there  may  be  several  “puzzle  pieces”  that  need  to  fit  together.

www.primepsm.com Page 6
In SD, the first puzzle piece to consider is the condition types, which represent a pricing element, such as
base price, discount, or tax. There are many settings within a condition type, as shown in the example
below.

www.primepsm.com Page 7
Example Condition Type

Condition types, in turn, are wrapped into pricing procedures. Each condition type within a pricing
procure is assigned an account key. This account key is the link to a G/L account, as we will see further
down.

Example Pricing Procedure

A pricing procedure is automatically assigned to an SD transaction based on configuration setting for

customer, sales document type, and sales area. Within the control data portion of the pricing procedure,
as shown above, an account key (e.g. ERL for Revenue) is assigned for each condition type. The specific
G/L account assigned then depends upon access sequences. These are maintained using transaction
code VKOA.

Example Access Sequences

www.primepsm.com Page 8
The access sequence, while it looks complex, is nothing more than an SAP search sequence strategy that
goes from the most specific criteria to the most general. Meaning, if the conditions are met in the most
specific search, the system selects it. If not, it moves on to the next most specific search, and so on.

In the example below, the most general access sequence, 5 (Account Key) has revenue account 30000
assigned to account key ERL (i.e. Revenue).

Example VKOA Account Assignment

In summary, G/L accounts for SD are assigned using transaction code VKOA. Within VKOA there are
access sequences. For the relevant access sequences (those needed to support your business), G/L
accounts are assigned to an account key. The account key is then linked back to a specific condition type
and pricing procedure which are assigned to the SD document.

It is worth noting that sales orders themselves do not have a financial impact. The time of billing is when
the financial impact occurs. SD creates an invoice (i.e. billing document) during a billing run, and the SD-FI
interface creates a corresponding invoice in FI using document type RV. It is at this point (i.e. billing) that
the account determinations are used.

Toolbox

In this are some of the best tips and tricks that we have used over the years. We hope you find them
useful.

Transaction code FBKP: Selected parts of FI configuration.

FBKP is one of the single most useful tools in FI. It provides quick access to critical parts of FI
configuration. Most importantly, it provides a central link to account determinations. Not all FI account
determinations are in FBKP, but a substantial portion of them are. FBKP is an excellent tool to ensure you
have your account determinations universally covered.

www.primepsm.com Page 9
Example Transaction Code FBKP

Groups Inside FBKP Automatic Posting Groups

Transaction code OBL1: Error analysis/automatic postings.

OBL1 provides error analysis in your account determination settings. It checks for consistency, posting
keys, and posting rules. Simply enter your chart of accounts and company code and press enter. On the
next screen, you are presented with groups to select from. As you see in the example below, group RMK
is selected for MM.

www.primepsm.com Page 10
Example OBL1

Groups Inside OBL1

Transaction Code S_ALR_87101048: Account Detective.

Analyze and output various account determinations using the account detective. This is a great way to
troubleshoot posting problems.

Example Account Detective

www.primepsm.com Page 11
© David A. Burns, 2014
All rights reserved.

We welcome your feedback. Please send comments on this paper and suggestions for future ones
to: [email protected]

Disclaimer: David A. Burns and/or Prime LLC shall be have no liability or responsibility for any damages or
losses of any kind that may result from information contained in this article.

www.primepsm.com Page 12