SAP Business All-in-One Solution

Financial & Accounting

Session 4 - Posting Control

Objectives

At the end of this presentation you will:

- Set default values
- Discuss rules governing changes to documents
- Outline the structure of taxes
- Configure payment terms and automatic discount postings
- Configure and post cross-company code transactions
- Perform document reversal
User Defaults

• Parameter ID’s allow users to set default

values for fields whose value does not
change very often e.g. company code,
currency. During transaction processing,
these values will default into the fields
thus saving time, reducing keystrokes
and improving accuracy.
• Editing options allow users to change
their R/3 screens in the following areas:
• Document entry: users can “hide”
fields that may not be relevant for
their jobs like foreign currency or
cross company code transactions.
• Document display: users can set
different display options when
querying documents.
• Open items: users choose line
layout displays and posting
options for processing open items
i.e. users have the option to enter
the amount of a partial payment
or the balance of the new open
item.
• When users log onto R/3, their user id
has particular properties i.e. logon
language, date formatting, decimal
notation, that will follow the user
throughout the system. Users also have
the option to set a default printer for
themselves.
System and Accounting Defaults

• R/3 provides some basic defaults during

document processing. R/3 always proposes
the current date as the posting date and the
entry date during document processing.
However, the entry date cannot be
changed.
• R/3 adheres to the “Document Principle”: all
documents must balance before they can
be posted.
• As you process through various accounting
transactions, default document types and
posting keys are defined per transaction in
customizing. A vendor invoice will have the
document type KR; the credit entry will be
posted using posting key 31. A customer
invoice will have the document type DR; the
debit entry will be posted using the posting
key 01.
• You can also have R/3 propose the value
date and the fiscal year in various
accounting transactions.
• At the company code level, specify the
maximum exchange rate difference
between the exchange rate entered in the
document header of a transaction and the
rate in the exchange rate table If the system
finds a difference which exceeds the
percentage rate specified, a warning
message is given. In this way, incorrect
entries can be recognized and corrected in
Changing Documents

• Users can change documents that have

already been posted. However, based on
different rules, only certain fields can be
changed. These rules are either system
imposed or customized.
• Certain fields in both the document header and
the line items can be changed.
• Document header: only the reference
number and text fields can be changed
• Line items: the system does not allow
changes to the amount, the posting key,
the account or any other fields that
would affect the reconciliation of a
posting.
• As users make changes to documents, the
following information is logged:
• The field that was changed
• The new and old values
• The user who made the change
• The time and date of the change
Document Change Rules

• To differentiate change rules for each field

as follows:
• Account type: The account type
allows users to differentiate a rule
between A/R, A/P and G/L.
• Transaction class: Transaction
classes are only used for special GL
transactions for bills of exchange and
down payments.
• Company code: If the field is blank,
the rule applies to every company
code.
• The conditions for changing a field are
predefined, users may change these
conditions as follows:
• The posting period is still open
• The line item is not yet cleared
• The line item is either a debit on a
customer account or a credit on a
vendor account.
• The document is not an invoice
related credit memo
• The document is not a credit memo
from a down payment
Payment Terms

• Terms of payment are conditions established

between business partners to settle the payment of
invoices. The conditions define the invoice payment
due date and the cash discount offered for early
settlement of the invoice.
• Within R/3, some common payment terms have been
predefined; new payment terms may be created as
required.
• Payment terms enable the system to calculate a
cash discount and invoice due date.
• In order to perform this calculation, the system needs
the following three data elements:
• Baseline date: The date from which the due
date is derived.
• Cash discount periods: The period during
which the discount is allowed to be taken.
• Cash discount percentage rate: The rate
used to calculate the discount value.
• When processing a document, the payment term is
entered in order for the system to calculate the
required conditions of payment.
• The payment term will be defaulted if it has been
assigned on the master record, or can be entered or
changed by the user during transaction processing.
Payment Terms in Invoices

• Payment terms can be entered into the company

code segment, sales area segment, and
purchasing segment of a customer / vendor
master record
• Which payment terms are defaulted when
posting an invoice depends on where the invoice
is created:
• If the invoice is created in FI, the payment
terms from the company code segment are
defaulted.
• If a customer invoice is created in SD, the
payment terms from the sales area segment
are defaulted. When posting the SD-invoice,
payment terms are copied to the FI-invoice
(which is created automatically).
• If a vendor invoice is created in MM,
payment terms from the purchasing
segment are defaulted. When posting the
MM-invoice, the payment terms are copied
to the FI-invoice (which is created
automatically).
• You should ensure that entries in the sales area
segment and company code segment (customers)
as well as entries in the purchasing segment and
company code segment (vendors) are identical.
• When entering a vendor invoice, you can also set
a fixed cash discount amount or a cash discount
percentage rate. That is, the cash discount is
granted independently of the payment period /
date. To do this, you must make the appropriate
entry in the field “discount”.
Payment Terms in Credit Memos

• Invoice related credit memos:

Credit memos can be linked to the original invoice by
entering the invoice number in the invoice reference
field during document entry. In this case, the
payment terms are copied from the invoice so that
the invoice and the credit memo are due on the same
date.

• Other credit memos:

Payment terms in other credit memos are not valid
and are due at the document date. To activate the
payment terms on these non-invoice related credit
memos, enter a “V” in the invoice reference field
during document entry.
Payment Terms: Basic Data

• General:
• The day limit is the calendar day up to
which the payment term may apply, allowing
date dependent payment terms.
• The description of a payment term consists
of three elements: A system determined
explanation which is a sales related
description for printing on invoices, and a
user defined explanation.
• The account type allows for mutual or
exclusive use of a payment term within a
sub-ledger.
• Payment Control:
• An invoice is normally blocked by using a
block key on the line item; however, a
block key may be defined in a payment
term.
• A payment method is normally entered in
the line item; however, a payment method
may be defined in a payment term.
• A block key and payment method defined in
a payment term will default in the line item
if the payment term is assigned in the
business partner master record.
Baseline Date

• Baseline Date
• The baseline date is the starting date the system
uses to calculate the invoice due date.
The following rules apply when defining the
calculation of the baseline date:
• The default values from which the baseline
date can be determined are as follows:
• ‘No Default'; ‘Posting Date';
‘Document Date' or ‘Entry Date’
• Specifications for calculating the baseline
date:
• The specified fixed day used to
override the calendar day of the
baseline date.
• The number of month(s) to be
added to the calendar month of the
baseline month.
Cash Discount

• To calculate the cash discount, a percentage rate

is entered into the payment term. The number of
days that the percentage is valid for is also entered
on the same line. Additional fixed days or months
can be added on as well.

• The days and months specified in the payment

term are used in conjunction with the baseline date
to calculate the correct discount amount for the
payment date.

• Up to three discount periods can be entered.

Day Limits

• Day limits allow date dependent payment terms.

• Several versions of a payment term’s key can be
defined with each version having a different day
limit.
• The day limit is the posting day up to which the
payment term version may apply.
Holdback/Retainage

• An invoice can be paid over several months using

an installment plan, or a portion of the invoice
amount may be retained for payment at a later
date.
• The total invoice amount is divided into appropriate
amounts as per the plan and each separate
amount is then due on different dates.
• The system will perform the above function
automatically by using a holdback/retainage
payment term.
• A holdback/retainage term is defined by setting the
holdback/retainage flag and not assigning discount
days or percentages.
• The holdback/retainage payment term is further
defined using an installment number, installment
percentage rate and an installment payment term.
• The percentage rates specified must total 100%.
• The system will create a line item for each
installment specified.
• Each line item amount will be equivalent to the
installment percentage rate of the total primary
amount, and the sum of the line item amounts will
equal the total primary amount.
• The line items will have payment terms as defined
by the installment plan.
The Cash Discount Base Amount

Depending on the national regulations of your

country, the cash discount base amount will
be the net value (sum of G/L account and fixed
assets line items, taxes not included) or gross
value (including taxes). You must decide per
company code or per jurisdiction code how the
system determines the cash discount base
amount.
Posting Cash Discounts
Posting Cash Discounts – Gross Procedure

• The cash discount amount is entered in the

invoice either manually or automatically by
the system using the rates in the payment
terms. It can be changed even after the
invoice is posted.
• When an open item on a customer or vendor
account is cleared, the possible cash
discount is posted automatically to an
account for “cash discount granted” or “cash
discount taken”.
• The accounts for “cash discount granted” or
“cash discount taken” are defined in
configuration.
Vendor Net Procedure - Invoice

• If you post a vendor invoice with a

document type for the net procedure, the
amount posted to the expense or balance
sheet account is reduced by the cash
discount amount. The same amount is also
posted to a cash discount clearing account
to clear the document.
• When using the net procedure, the cash
discount amount is automatically posted
when the invoice is posted.
Vendor Net Procedure - Payment

• If you post a vendor invoice with a

document type for the net procedure, the
amount posted to the expense or balance
sheet account is reduced by the cash
discount amount. The same amount is also
posted to a cash discount clearing account
to clear the document.
• When using the net procedure, the cash
discount amount is automatically posted
when the invoice is posted.
• When you clear the document, the system
carries out a clearing posting to the cash
discount clearing account.
• If the invoice is paid after the cash discount
deadline, the lost cash discount is posted to
a separate account.
• The cash discount clearing account must be
managed on an open item basis.
Cross-Company Code Transaction

• A cross-company code transaction involves two or

more company codes in one business transaction.
Examples for a cross-company code transaction are:
• One company code makes purchases for other
company codes (Central Procurement)
• One company code pays for other company
codes (Central Payment)
• One company code sells goods to other
company codes
• A cross-company code transaction posts to accounts in
several company codes. This cannot be done by
posting only one document because a document is
always assigned to exactly one company code. Instead,
the system will post a separate document in each
company code involved.
• In order to balance debits and credits within these
documents, the system generates automatic line items
which are posted to clearing accounts, i.e. either
payables or receivables between the company codes.
• The documents which belong to one cross-company
code transaction are linked by a common cross-
company code transaction number.
Example : Central Purchasing

• In this slide you see an example for a cross-company

code transaction (central purchasing): A vendor
delivers equipment to company code 1000 and other
equipment to company code 2000, but sends only one
invoice for all the equipment to company code 1000.
You enter a part of the expense and post the invoice to
the vendor account in company code 1000. When
entering the invoice, you have to post the other part of
the expenses in company code 2000. The clearing
postings and the tax posting are generated
automatically.
• The tax is not distributed between the company codes
according to their expenses. Therefore, this functionality
may only be used if the transaction itself is not tax-
relevant or if the company codes form a taxable entity.
• The tax calculated is always posted to the company
code of the first position. Therefore, to ensure that the
tax is posted to the same company code as the invoice,
the invoice position should always be entered first.
• Certain countries tax regulations (e.g. in Japan and
Denmark) require that the tax amounts are posted in the
company codes in which the expenses occurred.
Therefore, the tax must be distributed from the first
company code to the other company codes according to
their expense amount. This can be done by using the
report RFBUST10.
Clearing Accounts

• The clearing accounts must be defined in every

company code before a cross-company code
transaction may be carried out. The clearing accounts
may be G/L accounts, customer, or vendor accounts.
• In the configuration you must assign clearing accounts
to every possible combination of two company codes to
allow cross-company code postings between these
combinations (, i.e. three company codes need 3*2= 6
clearing accounts)
• To decrease the number of clearing accounts, you can
use just one company code as the clearing company
code. In this case, you only must assign clearing
accounts to every combination of the clearing company
code to the other company codes, ( i.e. three company
codes need 2*2= 4 clearing accounts)
• Posting keys must be assigned to the clearing
accounts to identify their account types.
Cross-Company Code Document Number

• When the cross-company code document is posted, the

system generates a cross-company code document
number to link all of the new documents together.

• The document number is a combination of the

document number of the first company code, the first
company code number and the then fiscal year. It is
stored in the document header of all of the documents
created for a complete audit trail.

• Cross-company code documents may be reversed: the

system can reverse every document that was created
with the cross-company document, or the individual
documents can be reversed separately.
Reversing Documents

• It is possible for a user to make an input error. As a

result, the document created will contain incorrect
information. In order to provide an audit of the
correction, the user must first reverse the document in
error, and then capture the document correctly.
• The system provides a function to reverse G/L, A/R and
A/P documents both individually or in mass.
• A document may be reversed either by:
• entering a standard reversal posting or
• entering a negative posting.
• When reversing a document, a reversal reason code
must be entered to explain the reversal. The reason
code also controls if the reversal date is allowed to be
different from the original posting date.
• Documents with cleared items cannot be reversed. The
document must first be reset.
Standard Reversal Postings, Negative
Postings

• The standard reversal posting causes the system to

post the debit in error as a credit and the credit in error
as a debit. The standard reversal posting causes an
additional increase in the transaction figures.
• The negative posting also posts the debit in error as a
credit and the credit in error as a debit. This time the
posted amount is not added to the transaction figures
but it is subtracted from the transaction figure of the
other side of the account. This sets the transaction
figures back to as they were before the incorrect posting
took place.
• Normally the system uses the standard reversal posting
to reverse documents. The following requirements have
to be fulfilled to perform negative postings:
• The company code must allow negative postings.
• The reversal's reason code must be specified for
negative postings.
• Negative postings can also be used to perform transfer
postings of faulty line items. The item is removed from
the wrong account by a negative posting (resetting the
transaction figures) and posted to the correct account
by a normal posting. This can only be done with a
document type that allows negative postings.