Administering Sap R/3: The Fi-Financial Accounting and Co-Controlling Modules

Overview

Upgrading the financial and accounting systems to SAP can be one of the most taxing processes during the SAP implementation. Making changes to the accounting and financial systems can cause havoc in all areas of the business and in dealing with outside businesses and resources. The book is filled with practical examples of how to structure your accounting department and processes to utilize the FI and CO modules to save time and money. In addition, this book also includes tips for accounting and business planning...
See more details below
Available through our Marketplace sellers.
Other sellers (Hardcover)
  • All (12) from $1.99   
  • New (2) from $65.00   
  • Used (10) from $1.99   
Close
Sort by
Page 1 of 1
Showing 1 – 1 of 2
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$65.00
Seller since 2014

Feedback rating:

(164)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing 1 – 1 of 2
Close
Sort by
Sending request ...

Overview

Upgrading the financial and accounting systems to SAP can be one of the most taxing processes during the SAP implementation. Making changes to the accounting and financial systems can cause havoc in all areas of the business and in dealing with outside businesses and resources. The book is filled with practical examples of how to structure your accounting department and processes to utilize the FI and CO modules to save time and money. In addition, this book also includes tips for accounting and business planning managers for coordinating financial data with the corporate headquarters and other locations.
  • SAP is the #1 enterprise-wide computing system used in businesses today. FI-Finance and CO-Control accounting modules are two of the six most popular SAP modules.
  • A fast, concise guide to everything the administrator needs to know to run the accounting modules of SAP.
  • Contains valuable tips and examples that shows financial planning and fiscal control managers how to get up and running quickly with SAP, while saving time and money.
Read More Show Less

Editorial Reviews

Booknews
Demonstrates why and how companies are implementing a sophisticated enterprise-control system with the constituents drawn from the SAP R/3 business object repository. Divided into three parts, the book addresses the preparation of public accounts; planning and controlling; and funding, investment, and development. Annotation c. by Book News, Inc., Portland, Or.
Read More Show Less

Product Details

  • ISBN-13: 9780789715487
  • Publisher: Que
  • Publication date: 3/28/1998
  • Edition description: 1 ED
  • Edition number: 1
  • Pages: 463
  • Product dimensions: 7.63 (w) x 9.45 (h) x 1.51 (d)

Table of Contents








[Figures are not included in this sample chapter]


Administering SAP R/3


Contents



  • Chapter 1 - Reviewing the Processes of Accounting in SAP R/3

    • Outlining This Book
    • Appreciating Developments in Financial Accounting
    • Rendering the External Accounts
    • Using Costing and Revenue Element Accounting
    • Using Special Purpose Ledger Accounting
    • Using Parallel Costing Systems
    • Understanding Treasury and Financing
    • Understanding Controlling
    • Planning and Controlling the Enterprise Business





Part I - Preparing the Public Accounts


  • Chapter 2 - Understanding the General Ledger

    • Understanding SAP Accounting
    • Understanding the Principles of SAP R/3 General Ledger Accounting
    • Understanding General Ledger Account Master Data Areas
    • Implementing GL Financial Accounting
    • Understanding Complex Organizations and the Chart of Accounts
    • Specifying Rules for Administering General Ledger Accounts
    • Planning in the General Ledger
    • Posting Technique in the General Ledger
    • Closing the General Ledger During the Fiscal Year
    • Reporting at Closing
    • Understanding Financial Statement Report Formats
    • Reporting Operational Control Data at Closing
    • Using the Financial Information System
    • Taking Advantage of the FI-SL Functions
    • Using Allocation in Special Purpose Ledgers
    • Planning in the Special Purpose Ledgers
    • Reporting from the Special Purpose Ledgers
    • Using Workflow with the Financial Calendar




  • Chapter 3 - Using Subledger Accounts

    • Understanding Ledgers and Accounting
    • Understanding Accounts Receivable
    • Using the Customer Master Record
    • Understanding Customer Transactions in Accounts Receivable
    • Processing Incoming Payments
    • Using Special Transactions in Accounts Receivable
    • Understanding Document and Account Processing
    • Using Automatic Correspondence from Accounts Receivable
    • Reporting Customer Accounts
    • Managing Customer Credit
    • Using the Accounts Payable Module
    • Working with Vendor Master Records
    • Understanding Transactions in Accounts Payable
    • Using Automatic Payment Functions




  • Chapter 4 - Accounting for Assets

    • Defining Assets
    • Structuring Asset Records in Financial Accounting
    • Developing Asset Classes
    • Maintaining Asset Master Data
    • Using Valuation Techniques
    • Using Depreciation Areas
    • Applying Special Valuation to Fixed Assets
    • Calculating Depreciation
    • Handling Currencies in Depreciation Calculations
    • Simulating Depreciation for Planning Purposes
    • Integrating Asset Transactions
    • Acquiring Fixed Assets
    • Retiring a Fixed Asset
    • Managing Assets Under Construction
    • Using Fixed Asset Special Transactions
    • Reporting Assets Through the FIS
    • Developing an International Asset Management Capability




  • Chapter 5 - Consolidating Company Accounts

    • Combining Financial Statements
    • Using the FI-LC Consolidation Module
    • Interfacing by Design
    • Preparing for Consolidation
    • Meeting Annual Reporting Requirements of Complex Companies
    • Customizing the Consolidation Software
    • Exploring Consolidation Master Data
    • Understanding Methods of Consolidation
    • Preparing Data at the Subsidiary Level
    • Transferring Data
    • Changing the Balance Sheet from Local to Consolidated
    • Consolidating Investments
    • Using the Consolidation Report Tree





Part II - Planning and Controlling


  • Chapter 6 - Controlling by Cost Management

    • Recognizing the Aims of Controlling
    • Assigning the Procedures of Cost Accounting
    • Defining Cost Objects and Cost Centers
    • Planning and Controlling a Business with R/3
    • Accounting with Cost Elements
    • Using Imputed Costs Accruals
    • Implementing Cost and Profit Controlling
    • Understanding the Flow of Control Data
    • Establishing Cost Center Accounting
    • Using Cost Centers in Planning




  • Chapter 7 - Costing on the Basis of Activities

    • Determining the Profitability of Product Lines
    • Introducing Cost Object Controlling
    • Identifying Costing Requirements of Different Types of Companies
    • Organizing Product Cost Controlling
    • Planning Product Cost
    • Viewing Product Costing Results
    • Controlling by Cost Objects
    • Interpreting Production Variance
    • Using Cost Objects in a Hierarchy
    • Using Activity-Based Cost Accounting
    • Using Internal Order Accounting
    • Using Cost of Sales Accounting




  • Chapter 8 - Controlling by the PS-Project System

    • Defining Projects
    • Setting the Project Trajectory
    • Using Different Project Views
    • Placing the PS in the Organizational Structure
    • Planning in the PS
    • Understanding Project Budgeting
    • Executing a Project
    • Using the Project Information System




  • Chapter 9 - Analyzing Profitability

    • Introducing the SAP R/3 Profitability Analysis Module
    • Using the Processes of Profitability Analysis
    • Identifying Profitability Segments
    • Planning Sales Quantities and Profits
    • Using Revenue Element Accounting
    • Operating CO-PA
    • Using Profit Center Accounting





Part III - Funding, Investment, and Development


  • Chapter 10 - Managing the Treasury

    • Using the Treasury Module
    • Managing Liquidity
    • Controlling the Treasury
    • Managing Market Risks
    • Managing Funds Through a Budget




  • Chapter 11 - Managing Investments

    • Controlling Investments
    • Defining an Investment Program
    • Analyzing Investment Proposals
    • Budgeting in the Capital Investment Program
    • Capitalizing Assets Directly
    • Creating Assets Internally by Capital Investment Measures
    • Documenting Internal Value Flows
    • Using Settlement Functions for Capital Investment Measures




  • Chapter 12 - Developments in Financial Management

    • Preparing for Open FI
    • Focusing on Positive Auditing with the SAP R/3 Workstation
    • Networking Workflow
    • Selecting Components for Electronic Commerce
    • Developing the Open Information Warehouse
    • Operating with SAP R/3 Business Objects
    • Raising Standards of Business Programming
    • Accelerating Implementation with the Business Engineer




  • Chapter 13 - FICO Education and Training

    • Introducing FICO Education and Training
    • Structuring a Program
    • Developing Detailed Education and Training Plans
    • Defining Scope of Education and Training





Part IV - Appendixes


  • A - SAP Glossary of Terms and Concepts



  • B - A Consultant's Perspective

    • Analyzing SAP from Consultant One's Perspective
    • Analyzing SAP from Consultant Two's Perspective




  • Index



Read More Show Less

First Chapter

[Figures are not included in this sample chapter]

Administering SAP R/3


- 3 -
Using Subledger Accounts

Understanding Ledgers and Accounting

Various traditions of accounting have developed concepts and assigned titles to the departments responsible for carrying out the work activities. Thus Accounts Receivable or Receivables are recognized as departments that keep track of value owed to your company. These may also be the titles of ledger accounts in your Financial Accounting system.

This chapter sets out the pivotal functions of the FI-AR Accounts Receivable and FI-AP Accounts Payable modules of SAP R/3 that manage these subledgers of the General Ledger. These functions address the following questions:

  • How does money come?

  • How does money go?

  • How can my company organize these processes?

You will find that most accounting activities can be automated without losing control because the FI-AR and FI-AP modules reliably report any difficulties and suggest how you can remove them.

The SAP R/3 system uses the following structure of accounting function entities.

  • General Ledger is the master record maintained using the defined entity type 2107 in the enterprise data model, upon which the R/3 operates.

  • Each account in the General Ledger is recorded in a record of the type General Ledger Account-Transaction Figure.

  • If there are many creditors, a Subsidiary Ledger-Creditor is defined as an entity of type 2108, which is reserved for the company code credits account records.

  • A subsidiary ledger, or subledger, is an integral part of the General Ledger and is regarded as a legal extension of it for balance sheet purposes.

  • A special ledger or special purpose ledger is a grouping of accounts that are held separately from the General Ledger and are used for alternative reporting purposes specified according to the requirements of your company. This type of ledger is not subject to legal restrictions.

Understanding Accounts Receivable

FI-AR Accounts Receivable is a module of the SAP R/3 Basis system. It is specialized to maintain the Accounts Receivable subledger of the FI-GL General Ledger and completely integrated with it at the following levels:

  • Master Data

  • Transaction Data

  • Reporting System

The General Ledger and its subledgers share the common chart of accounts with all applications and also share all the details of master records. Reporting can draw from the General Ledger and the Accounts Receivable subledger.

The purpose of the Accounts Receivable subledger is to keep track of customers and the transactions that involve them. Its job is to collect money, to process cash receipts, and to dun customers who are late in paying. This subledger shares the same accounting needs as the SD-Sales and Distribution module, which is also a core module of the SAP R/3 Basis, and IT is fully integrated with it at the software code level.

Transaction data is stored centrally in the document database, and the corresponding line items and details are stored in the appropriate subledgers. The system automatically updates a subtotal of a balance sheet account for every business transaction and reconciles the account subtotals and the line items to ensure that the financial information is always correct and current.

Every transaction creates an SAP document, and the data is immediately posted to the General Ledger. Every business transaction recorded in this way automatically updates the balance sheet or the profit and loss statement. This is the defining characteristic of an up-to-date accounting and controlling system.


NOTE The SAP system maintains account balances by debits and credits for up to 16 periods.

Using the Customer Master Record

The Accounts Receivable functions are shared with the SD-Sales and Distribution application. The customer master record is maintained as a common reference for all the information about a customer that could be of use within the company. Access to this data can be controlled through the Authorization Profile System, which can also regulate the updating of customer information.


NOTE The central database of customer information is the source for decisions on automatic dunning and automatic payment.

The sales organization need not have the same organizational structure as the legal structure of the company. One sales department can handle products from two or more associated companies. The system of customer master records makes provision for this.

Master data is organized into the following three parts:

  • General data

  • Data applicable only for specific company codes

  • Sales data

General data about each customer is available to every company code and every sales department. It includes such items as the following:

  • Name, address, telephone, fax, and modem number

  • Customer registration number

  • Line of business and business group

  • Bank account data

For each individual company using a shared sales organization, there may be different entries for each company code to reflect their different business methods and any existing agreements. These can include the following:

  • Standard payment terms

  • Data for dunning overdue accounts

  • Data for direct debit or automatic payment

  • Data for correspondence, such as the account number and name

If more than one sales department in your group sells to the same customer, you must specify a General Ledger reconciliation account for that customer. This is identified in the customer master record.

Sales data in the customer master records may be helpful in initiating a relationship between a sales representative and a customer. For example, a sales representative may want to retrieve from the database the name and title of the customer company buyer responsible for purchasing a specific range of products or services. This kind of information can also be held as part of a sales support function.

The sales information section of a customer master record also includes the order processing, shipping, and invoicing data required by the SD-Sales and Distribution application.

Strategic sales data can be held in the customer master record. For instance, you can specify whether a new customer master is to be made available to all your departments or only within specific areas. One alternative is to make the general customer data central and maintain individual database records for the departments, such as accounting and sales.

Making Sales to an Affiliated Company

Among your customers you may have one or more affiliated company code departments of your own corporate group. If you wish to use the SAP Consolidation module in reporting, any intercompany sales achieved through business transactions with such customers must be eliminated from the company accounts before closing. Therefore, the ID code of other members of your group must be entered on the customer master record so that it is automatically transferred to the document when posting.

Processing Master Data Records

Access to customer master data records must be controlled by limiting the staff authorized to modify certain data fields. This method involves using the system of authorizations to restrict certain functions that can affect the critical fields of the customer master records.


TIP Separate functions can be authorized individually to create, change, or simply display customer master records. These restrictions can then be applied to general data, accounting data, and sales data.

When a new or prospective customer is identified, a new master record is created and assigned to an account group. The account group determines whether you may assign account numbers within specified ranges or whether the system does this automatically. Your implementation can include a supporting system that generates account numbers that are then adopted by your SAP R/3 accounting application. Your system is not allowed to assign the same account number more than once, but both customers and vendors can exist within the same range of numbers. The numbers can also be assigned on the basis of a hierarchy or classification of customer accounts.

The account group also controls the fields that are active in this master record. You can pick the fields offered by the account group and assign them to one of three categories:

  • Fields into which the user must make a valid entry

  • Fields the user can either leave blank or make an entry into (optional fields)

  • Suppressed fields that do not appear on the screen

NOTE A whole screen of fields can be suppressed if it is not needed for a particular transaction. You can use field groups to control certain fields of sensitive information within a customer master record to specify authorized users.

The FI-AR Accounts Receivable system makes it easy to create master records by offering various options.

  • By using a search function, you can inspect the master records of customers similar to the one you are entering.

  • You can copy the master record of an existing customer and edit the unwanted details to make it into a new master record.

  • You can copy a master record from a reference record that has been established for the purpose. You must make at least one alteration to it before you post it as a new master record.

  • You can create the new customer master record by entering all the necessary details.

After you enter and store a customer master record, you can call it back again and change almost any of the fields. You have a choice of whether to go through all the fields or work on a single subset of fields, such as the payment details. Master records can be selectively displayed so that you see only those fields of interest to you.


NOTE Any changes you make to any record in the customer master database automatically leaves a change record that can be accessed to form an updated history.

Using One-Time Accounts

If you think a customer probably will not become a regular purchaser, you can set up a one-time account by selecting a special function. This creates a master record that contains only the essential control data, such as the number of the reconciliation account to which this sale will be posted. The system can provide the customer name, address, telephone number, and bank account data when an invoice is entered. This information then arrives in the one-time account master record, where the dunning and payment programs can find it.

Using Customer Head Office and Branch Accounts

Your customer contact may be a branch with its own account, but the head office may foot the bill. In this case, you can enter the head office account number in the master record for the branch customer. When you enter a transaction to the branch account, the system posts the transaction to the head office account, leaving a cleared entry on the branch account to show who received the goods or services.

The master record includes data about the branch and a reference to another record to give details of the head office. By this means, dunning letters can be sent to the head office, the branch, or both.

Receiving Payments from an Alternate Payer

Your customer may not have to deal with his own payments. You can record in his master data the account number of the alternate payer, and the system then processes direct debits, return transfers, and other customer payment business through the banks of the other payer.

If you post customer invoices to an affiliate, you must record in the master data of the branch customer a group-wide company account number to be used during consolidation to eliminate the invoices that would otherwise appear twice in the company accounts. The system is capable of looking at the transaction documents bearing this group-wide company account number and then identifying any entries that are replicated because the payment was made by an affiliate that was not the original customer.


NOTE A customer may have an arrangement whereby any overdue payments must be dunned to an alternative address. This is recorded in the customer master record and is used if dunning is necessary.

Understanding Customer Transactions in Accounts Receivable

As soon as the master data is stored for a customer, a customer transaction can occur. If the master record is for a one-time account, the data will be sparse.

If you installed and configured SAP SD-Sales and Distribution with the SAP FI-Financial Accounting system, invoices entered in the SD system are automatically posted to General Ledger accounts in FI. Otherwise, the route to the FI-GL General Ledger accounts runs through an SAP open interface, which transfers and posts invoice data to General Ledger accounts automatically. If you must manually enter an invoice that has not been posted automatically, SAP R/3 provides all possible help. You can enter and post a check received and match the payment to specific open items in the customer account, all in one operation.

The successful posting of a transaction does not occur until the necessary data is recorded as an SAP document and is complete and error-free. You can set aside a transaction document before it is ready for posting, in which case the system validates any information you have already entered and reports to you any discrepancies.

The SAP document must end up with a document header showing posting date, document date, document reference number, and currency key. The body of the document contains one or more line items that show the amount and identify the product and terms of payment. The system generates certain line items, such as tax entries, cash discounts, and exchange rate differences, as applicable.

You can set up helping routines and use standard data entry functions such as the following:

  • Offering default values that you can edit at the time of entry

  • Recalling for copying and editing a previous screen

  • Retaining data for individual users for several transactions

  • Adapting a copy of a data entry screen so that it is better suited to a set of expected transactions

  • Searching for an account number by using matchcodes to narrow the search

An SAP document that records a previous transaction can be copied to act as a sample or a model to be edited. This sample can be a regular document that has been set aside, perhaps as an incomplete transaction document. The posting date and new values may have to be changed before posting.

Handling Recurring Entries

If you expect to make a series of entries in which the amounts are always the same, you can set up a recurring entry. For example, one of your customers may be paying in monthly installments. The entries will be posted to accounts only when they occur, not when the recurring entry original document was first created.

A recurring entry is a set of data that will not be used until the due dates. Until then, the entries will not update account balances. You must specify the first and last dates and the frequency or time interval, and you must supply a deadline date. The system automatically posts the required transaction on each of the due dates.

Using Invoice and Credit Memo Entry Tools

An invoice, a credit memo, or a transfer cannot be successfully posted unless it is complete and free of errors. However, an incomplete Receivables document can be saved, and you can resume work on it when the required information becomes available. If the document is then posted, it is checked immediately, and adjustments are suggested for your rejection or confirmation. The criteria for accepting a transaction include the following:

  • The debit and credit balance is zero.

  • The assignment account data is complete.

  • The mandatory entry fields are complete.

The assignment account data includes at least the following entries:

  • Document date

  • Posting date

  • Document type

  • Posting key

  • Account number

  • Amounts to be posted

Using Entry Currencies

Any currency can be used for document entry to Accounts Receivable. A local currency will have been assigned to each company code, which is automatically computed. Two other currencies can be indicated, if required, and are handled in parallel. The records store the entered amounts in both local and document currencies. An exchange rate table is consulted to convert between them.

You can also indicate a specific exchange rate when posting. The entry document master will have been coded to control whether the local currency is open to posting in addition to the document currency, which is always open for input during document entry.

A document must have a zero balance in both the local and the document currency before it can be successfully posted. Small rounding differences are automatically taken into account. Transaction amounts are kept only in the local currency of the customer area. The reconciliation account for Receivables From Goods and Services is kept in local currency and in all the foreign currencies used in posting.

The system can be customized in various ways, which include the following:

  • A specific user is obliged to enter amounts in a particular currency, which can be the local currency or the system document currency.

  • A specific user can be permitted to enter amounts in either the local or the document currency.

Whatever the customizing arrangements, the system displays amounts in both local and document currencies. It rounds off minor differences, using rules established for this purpose. These differences can occur when several line items are converted and then added in both currencies.

The system keeps customer monthly debits and credits only in local currency. The reconciliation account for the Accounts Receivable subledger is kept in local currency and in all the other currencies that have been posted.

Dealing with Currency Exchange Differences

A line item can be expressed in a currency other than the local or document currency. You can enter payments to clear such foreign currency line items using either the local or the document currency.

The payment expressed in the document currency will have been converted from the local currency at an exchange rate adopted by the system according to the approved rules for assigning the daily exchange rate. If this rate has changed from the rate prevailing when the invoice was written, the payment amount may not match the open item amount. In such cases, the system automatically calculates and posts an exchange difference entry to a separate account established for this purpose.

Processing Incoming Payments

The usual paper form of a payment is a check, a transfer, or a bill of exchange. Regardless of the form, the processing of an incoming payment must include two processes.

  • Posting the payment to the assigned account

  • Matching open invoice lines for this customer with payment line items and then clearing them if they correspond

Understanding the Basic Procedure for Receiving Payments

A payment for clearing is indicated as a transfer slip or a payment advice note. Credit memos are indicated in a similar fashion.

Your payment receipt actions are best carried out in a logical order. You must perform the following steps:

1. Enter the bank general ledger account number.

2. Enter the amount of the payment.

3. Enter any bank charges.

4. Enter the document numbers of the unpaid items to be cleared by this payment.

5. Apply the rules for cash discount, and deduct it from the total of the indicated invoices.

6. Confirm that the total of the indicated invoice, minus cash discount if appropriate, agrees with the input payment amount.

If the totals agree, the payment receipt is then posted. The cleared items should be annotated to show the clearing date and which incoming payment was responsible.

Searching for Invoices to Be Cleared

If necessary, you can search for all the outstanding unpaid invoices for the customer using any document-specific search term, such as the following:

  • Amount of the invoice

  • Reference number of the invoice

  • Posting date

You can assemble a list of open items by specifying single values or intervals for your search criteria. You can combine the results of several searches, and you can remove items from the list if you do not want to consider them for clearing against the incoming payment.


NOTE It may be helpful to have the list sorted, in either direction, on any of the values that appear in the listing.



NOTE If you are focusing on a single line item, you can call for all the data in summary form, or you can retrieve the entire document.

Minor differences might exist between the payments and the invoices to be cleared against them. In such instances, you can arrange to adjust values less than a certain amount through the cash discount, or you can post them to a separate differences account. You may wish to grant some users permission to exercise more discretion in this respect than others. You can control this through their authorization profiles.

Searching for Open Items

If the customer has not told you which invoices are being paid (by writing their numbers on the check or by including an advice note or an allocation notice), you must use the system to determine this information.

For example, you can call for a search for open items for this customer, but there may be too many to decide which are being settled by this payment. In such a case, you can narrow the search by giving exact values or ranges of values for almost any of the header fields and line item fields that appear on a transaction document.

It is recommended that you use no more than a handful of search fields. The most useful fields for narrowing a search for open items for a customer include the following:

  • Document Reference Number

  • Posting Date

  • Invoice Amount

  • Posting Key

For any of your searching criteria, you can accept a range of values, such as the following:

  • Any document number between two given numbers

  • Any posting date over a specified interval

  • Any invoice amount greater than or less than a given amount

  • Any posting key out of a short list that you specify

The system's first response to a search command is to display a summary screen showing the items found. The summary totals the amounts. If this equals your customer's payment, your search is over. If not, you must refine the search.

You might select a few items from the summary screen and examine their details to find some better entries for a more focused search. The summary screen layout may be more useful to you if you change its display format by moving or replacing some of the columns until you are looking at only the details that interest you.


NOTE At any time, you can switch the display between showing the details of a line item and showing the entire document. This includes the entry offsetting this customer line item, if there is one.

If your search for open items is successful, you arrive at a list of invoices that add up to the same amount offered as payment by the customer. The system calculates allowances for cash discounts, and you can check this from the display. Differences also might arise because of the conversions between currencies.

When your system is being customized, you can specify the limits within which the system posts minor payment differences automatically. You can also establish special rules for each user so that any differences larger than a certain amount must be referred to a user with authorization to deal with them.


NOTE When the selected open items balance the payment, you can post the document.

Dealing with Open Items

The following are several different types of open items:

  • Vendor open items

  • Open items for different customers

  • Open items with different company codes

Because the FI-GL General Ledger accounts are fully integrated, vendor open items can be cleared at the same time as customer payments.

The integrated FI-AR Accounts Receivable component accepts each item as an independent task because each item has access to the complete set of data objects needed to process it. Therefore, open items can be found for several customers and cleared by the appropriate payments in the same session.

Open items bearing different company codes can be cleared at the same time. The system records a clearing document in each company code.

Using Automatic Clearing in Accounts Receivable

If your customer allows you to collect by direct debit, you can use the FI-AR payment program component, which collects all invoices when due. Reimbursing customers with checks or by bank transfers follows the FI-AP Accounts Payable procedures for automatic payment.

If you installed and configured the FI-CM Cash Management component, you can clear payments automatically. A file transfer can provide your bank statement, and the system automatically posts the entries to the FI-GL General Ledger as it clears the matching open items in the customer accounts. Only if the data from the transfer is incomplete must you intervene.

Automatic incoming payment processing can be supported by the following specific techniques:

  • Electronic account statement

  • Lockbox (in the United States)

  • POR procedures (in Switzerland)

  • Check scans and deposit transactions initiated automatically if the checks are valid

The requirements for an acceptable electronic business transaction system are defined in part by the national standards that depend on the legal monetary instruments in that region. The payer must assign value to a check or other instrument that can be taken as a contract. The validation of this assignment must be conducted at the same time as the receiver is notified of the transaction details. The loop is completed when the receiver acknowledges a valid transfer of value.

The SAP organization is developing improved methods of electronic banking to further develop this aspect of business data processing.

Using Payment Procedures for Particular Countries

Variations in the legal payment procedures exist for different countries. These have been encapsulated in the standard business procedures of the FI-AR Accounts Receivable component. For example, there are differences between national accounting conventions concerning whether a transaction should be dated for tax and accounting purposes according to the invoice or to correspond to the confirmation of payment received.


NOTE National payment procedures can be specified for your implementation during the customizing process.

Receiving Partial Payments

If the open items do not balance the payment after cash discounts, you have three options.

  • You can post a payment on account.

  • You can clear an open item and post a residual item.

  • You can enter a partial payment with a reference to the open item that remains open.

If you cannot find any amounts to match with the payment, your only option is to post the payment on account. If you cannot closely match the payment to the open items, the best option remains posting the payment on account.

If you know the open item concerned and the payment is only partial, you can clear the full amount of the open item but open a residual item to cover the difference still unpaid. Alternatively, you can enter the payment with a note that marks the open item as only partially settled.

If many possible open items exist, you can direct the system to pick open items without defining any search criteria. The system will try various combinations of open items to try to match the amount paid. It will suggest a set of items that together add up to an amount as close as possible to the amount paid.


NOTE If a bank charge is associated with a cash receipt, you can enter it at the same time. The system automatically generates and displays a line item for the bank fee.

Understanding the Payment Advice Note Procedure

If the system finds a relevant payment advice note during clearing, it uses that to settle the incoming payments on the appropriate accounts. A payment advice note can be entered manually by copying the details from an existing advice note. EDI (electronic data interchange) can also submit payment advice notes.

If you carry out the manual procedure for receiving payments, you can create a payment advice note to record the current processing status of any items that are exceptions, such as those that cannot be cleared directly. You can configure automatic generation of payment advice notes to take place during the processing of account statements, check deposit transactions, or Lockbox data, if any of the items cannot be directly cleared.

The system requires only the payment advice note number to begin to use it for clearing. If differences exist between the payment advice note and the open items, the system automatically creates residual items and payments on account. You can subsequently cancel these if you assign the differences manually or post them as a total.

Understanding the Debit Memo Procedure

If a customer agrees to operate the debit memo procedure, your system can automatically collect all invoices according to their due date. The payment program generates debit memos in accordance with the agreement. Refunds to customers can similarly be made by automatically generated checks or transfers initiated by the same program. These functions are described in the section on Accounts Payable.

Using Fast Incoming Payment Entry Techniques

Two features are designed to accelerate the processing of incoming payments.

  • Manual check deposit

  • Manual account statement

Neither feature requires user intervention, but the automatic procedure replicates the manual clerical activities used in the absence of computer processing.

The incoming payment is registered as a check identification code, a check number, and a payment amount. The payment is automatically posted to the bank and to the customer account. The payment is settled automatically.

Using Automatic Electronic Banking

The fast entry methods that seek open items in a customer's account and clear them against incoming payments can work automatically until the system detects a difference that exceeds the acceptable limits. At this point, a review by an authorized user is necessary.

Data can be provided by a bank or the post office in any agreed on format. For example, the Swiss POR procedure uses a protocol that can be accepted by the SAP R/3 financial system and posted directly. The United States operates on a Lockbox system from which SAP R/3 can receive payments and post directly to clear open items.

A check scanner can be used to acquire payment data for direct and automatic posting to clear open items.

Using Electronic Account Statements

The purpose of the electronic account statement is to obtain information for clearing from a Note to Payee field. This indicates the document number so that the incoming payment associated with an open item for that customer can be cleared if it balances and is correct in other respects. For example, you can set up a validation procedure that uses a code particular to your industry. This method is used in the insurance industry, where the policy identification code is the key reference.

No limit exists as to the complexity of the security measures in your system. For example, if you have a particular device or software system that carries out your identification and security validation, you can arrange to use an SAP User Exit. This is a software gateway to an external system that can be used as a step in a workflow sequence without disturbing any of the SAP R/3 system's standard business software.

The account statement facility enables you to post payment transaction information in any of the supported languages and to transmit this information to any country for clearing against the appropriate items. Transaction information can be transmitted and received in any of the following international formats:

  • BACS (Great Britain)

  • ETEBAC (France)

  • SWIFT MT 940 (United States)

  • MultiCash (United States)

  • CODA (Belgium)

  • CSB43 (Spain)

  • FIDES (Switzerland)

  • ZENGINKYO (Japan)

  • Various formats (Czech Republic)

  • Various formats (Sweden)

NOTE The SAP R/3 architecture allows additional transaction information formats to be defined and used in an integrated manner without difficulty.

Using Special Transactions in Accounts Receivable

Transactions that are posted to a customer's account automatically update the FI-AR General Ledger Accounts Receivable (a reconciliation account) if they are invoices, credit memos, or payments. Some transactions posted to the customer account can update FI-GL General Ledger accounts other than FI-AR Accounts Receivable.

A special operation or special transaction is so named because the item is posted to the customer but does not cause an update in the General Ledger's Receivables From Goods and Services line-item account. The value is not actualized in the reconciliation account from the customer master record but in a general ledger account set up specifically for this purpose.

These accounts are a type of Special General Ledger Account. They are reconciliation accounts recording business that is neither a sale to a customer nor a purchase from a vendor. Special General Ledger Transactions include the following:

  • Down payments

  • Bills of exchange

  • Security deposits

  • Guarantees

Using Down Payments

A down payment is a payment for a product or service not yet supplied or performed. Down payments must be reported in the balance sheet separately from other Receivables or Payables. Down payments made are reported as assets; down payments received are reported as liabilities.

A request for a payment that is the first of a series of partial payments can be identified as a down payment and is recorded as such. The item remains open, and the amount is posted to an account established for the purpose of accumulating such payments until full payment is received. Only then is the item cleared and the holding account cleared by the same amount.

The receipt of a down payment from a customer is entered into the system as a down payment request, which is a statistical posting. A down payment request is recorded as a note that is displayed with other open items for each customer. As a note, this request does not update account balances. However, as with any other open item, you can dun the request for a down payment with the dunning program and collect the down payment by direct debit.

The payment program automatically generates a down payment posting for each bank collection. When a down payment request is posted, the system assigns the line items to a special General Ledger account. You can call for a list of all expected down payments.

A customer down payment account can display net of tax or gross:

  • Net display shows the down payment minus the tax.

  • Gross display shows the tax included in the line item, but an additional line item is generated in the tax clearing account as a clearing entry.

When a final payment is posted, an automatic note appears detailing the existing down payments. The down payment total can be transferred in full or in part, but the invoice is not cleared unless the full payment is received.


NOTE The down payment facility can also be used to assign values to accounts set up for internal orders, cost centers, and projects.

Using Bills of Exchange Receivables

A bill of exchange is a document with a written promise to pay a certain amount on a certain date in exchange for a specific business transaction that has taken place. A Bill of Exchange Receivable is a promise that payment can be collected from a customer on the expiration date record on the bill. This is a form of IOU ("I owe you") with a date set for payment. When a customer submits a bill of exchange, you can use the search facilities to find open items to match it if you have any doubt regarding the invoice to which it belongs.

A Bill of Exchange Receivable is an open item until the bill itself is deposited at the bank and discounted there against your account. Alternatively, your customer could pay cash to the amount of a bill of exchange. Either method of concluding the payment permits you to close the open invoice item.

Because the Bill of Exchange Receivable is a promise and not a payment, it is posted to a special General Ledger account set up for this purpose, the Bills of Exchange Receivables account. If the customer offers you a cash or check payment before the Bill of Exchange Receivable has expired, you can reverse the deposit in the Bills of Exchange Receivable account and post the cash against the open item in the normal way.

Using the Bills of Exchange Discount Ledger

Discounting is the process of depositing bills of exchange that are not yet due. The system can prepare a deposit slip for bills of exchange. Discounting also refers to the process of depositing a post-dated check and deducting interest on the amount (the discount) until the due date.


NOTE Commission or collection fees can be charged on both bills of exchange and checks.

The system can prepare the discount ledger, a journal in which all bills of exchange are entered. The following data fields are mandatory:

  • Due date

  • Amount

  • Name and address of the drawer

  • Name and address of the previous holder

  • Place of payment

  • Name and address of the drawee

  • Discount

You can specify default values for each company code for the following:

  • Discount percentage

  • Collection fees or charges

  • Bill of exchange tax indicator

The charges must be posted to separate accounts in the General Ledger. The system can prepare a bill for the customer that details these charges.

Bills of exchange deposits can be recorded and annotated as follows:

  • Discounted before the due date

  • Collected on the due date

  • Factored--an exporter gets cash immediately from a bank or other financial institution that takes responsibility for collecting the receivable amounts or the amounts due on the bills of exchange

Using Security Deposits and Guarantees

A security deposit is a payment made in advance against the possibility of poor performance by one of the parties to a transaction. Some examples are the payment by the buyer or the performance of the seller.

Security deposits are reported as noted items in the financial statements.

A guarantee is a contract entered into by a third party to pay up to a specified limit if one of the parties to a transaction either fails to deliver the contracted materials or service or fails to pay the amount due.

Guarantees are reported as noted items in the financial statements.

Understanding Document and Account Processing

An SAP R/3 business transaction is posted to an assigned account in which the account balance is immediately updated. At the same time, the system records the items on the transaction document that contributed to the update. If you later query the balance of this account, you can inspect the document items that formed it, right back to the beginning of the accounting period. Furthermore, you can display an overview of the transaction figures, separated into debits and credits, for each period.

You can also inspect sales totals per period, as well as the General Ledger accounts for special transactions such as down payments and bills of exchange. In each case, you can drill down to see the individual line items.

A line item display provides a summary of open and cleared items. The format of the summary display of line items can be customized by the user at the time.

Understanding Item Display in Accounts Receivable

Within each line item, it is possible to select the constituent document items and display a variety of totals, such as separate summations for each type of document. Documents can be selected according to their account in a company code, or as related to a group of accounts in a group of company codes. Totals can be displayed to this structure.

You can switch between a display of all line items and a view of the constituent documents of any chosen item. If necessary, you can search for a specific document according to posting date or document type.

If you want to view transactions that cross company codes, the system offers you a list of relevant documents. You can alternate between displaying all line items belonging to a particular transaction and all line items on individual documents.

Standard summary displays are available for the most frequently used analyses and reviewing tasks. These include the following:

  • Displaying the credit limit for one account or a group of accounts

  • Tabulating a set of items by the number of days in arrears

  • Displaying an overview of the net and cash discount situation

  • Displaying a customer's payment history to assess liquidity

  • Simulating a payment history by entering trial values and assessing the consequences

The most helpful screen display can be saved so that you can use it again. You can save the exact display with the data, or you can save the pathway or analytical route used to arrive at it. If you save the pathway as a report design, you can use the same analysis on other data next time because the totals will be generated from the data you specify.


TIP The quickest way to access account documents is to begin at the individual account display and then drill down in whatever direction is most fruitful.

Changing Documents Already Posted

The procedures for controlling the display on your screen can also be used in preparation for changing a document. There are four main methods of accessing documents for the purpose of making changes.

  • Display an individual document by selecting it according to one or more data fields in it.

  • Display a document that involves more than one company code by choosing from the list offered by the system when you identify a cross-company code transaction.

  • Select a document from a list of all the documents for a specific vendor.

  • Select all the documents for a specific vendor and perform a mass change for certain fields, such as a release of payment.

You cannot make any changes to a data field on a document if that field has already been used to update the transaction database. For example, the following fields are not open to alteration after the document in which they appear has been posted.

  • Account number

  • Posting key

  • Amount

  • Tax information

Some fields in a document are locked against updating only if your system has installed and configured a certain SAP R/3 component. For instance, a cost center field cannot be changed if your system has already used it to update a cost center account in the cost accounting component.

The status of a document can also affect the fields that are amenable to alteration after posting. For example, you cannot alter the terms of payment after an item has been cleared.

In addition to the logical rules that prevent you from changing a document to invalidate SAP R/3 compliance with the Generally Accepted Accounting Principles (GAAP) standards, you can institute other rules that make sense for your particular business.

If you have set up additional account assignments for a special purpose ledger or for a particular controlling reason that requires an accumulation of values, you can declare a rule that prevents anyone from changing an additional account assignment unless the document is still open for posting. After the month or other accounting period is closed for accounting purposes, the posting data may be relayed to other systems for evaluation. In these circumstances, you probably won't want anyone to alter the originals and destroy the validity of the audit trail or any other operation that referenced the posting documents. Such rules that should be obeyed across your system can be established through adjustments of the system settings, which are permitted only to suitably qualified users.

Dunning Accounts Receivable

Each customer's master data includes a field to indicate what is to be done about overdue invoices. This dunning code identifies an established dunning procedure. This procedure has the task of preparing a dunning proposal, which it does in the following related stages, not necessarily in this order:

  • Identifies the accounts and the items to be dunned

  • Establishes the dunning level of the account

  • Selects the text of the dunning letter or dunning notice according to the dunning level of the account

  • Computes the interest on arrears and any charges due

  • Edits the text to include interest and charges

  • Adds the details of the items overdue

  • Adds the totals in the document currency and the local currency, as required

  • Addresses the dunning proposal to the customer's head office or to another addressee the customer approves

  • Submits the dunning proposal for approval

  • Prints or otherwise dispatches the dunning notice

  • Stores the dunning particulars in the records of the items and the dunned accounts

  • Compiles lists and reports of the dunning activities

A standard dunning procedure can be independent of company codes. This procedure records the grace period, the dunning level principle, and the number of dunning levels.

Understanding Dunning Levels  The dunning level principle is the formula or logical conditions used to determine a set of dunning levels. A debt is allowed a number of days of grace before it is dunned. If the debt is not cleared after the grace period, the dunning begins at the first level. Subsequent levels of dunning are assigned to the debt according to the dunning level principle so that the text of the dunning notice reflects the seriousness of the overdue payment. You can establish the dunning levels on the basis of number of days in arrears, and you can add other conditions based on such factors as the following:

  • The absolute amount of the overdue item

  • The percentage of overall sales to this customer represented by the open item overdue

  • The absolute amount of the total of all overdue items on this account

  • The total of all overdue items on this account as a percentage of the sales on this account

Each item in arrears on a particular account can be assigned to a separate dunning area and, for this reason, can be subject to the dunning notice and procedure for that area. A dunning area is confined to a single company code. Several dunning areas in a company code can correspond to the profit centers or sales organization of that company.

Preparing and Using Dunning Letters  The SAPscript word processing program is available to design and change the format of dunning letters. During customization, the system provides you with some model letters at each dunning level. You can change and edit the text of the letter and also the company logo, position of the address window, and footers. You can give open items referred to in the letter a special format and content for this purpose.

A dunning proposal is a set of suggestions assembled by the system, which you can accept as is or alter in various ways. The system initially creates a dunning proposal by using due dates and some method of selecting the accounts to be dunned. You may have defined these methods previously and specified dunning levels and dunning areas.

You can then edit the dunning proposal list online. You can target the dunning letters at particular individuals in your customer's organization. You may decide to change the dunning level of an item. The dunning level of the whole account is changed automatically to the highest dunning level of any open item. You can release specific open items and accounts to be referenced in the dunning letters. The system records all changes to open items to be dunned.

The dunning data in an individual item is not changed, nor is the customer account updated when you generate a dunning proposal. You can generate a proposal several times and reject it without affecting the accounts. However, if you accept a proposal, the dunning data is updated in the item and in the account as soon as you release the printing proposal and therefore dispatch the letter to the customer.

You can use the same letter forms throughout the group, or you can customize different forms for each company code. If your customer is recorded as a business partner, you can instruct the system to automatically consult a master to determine details of the dunning procedure. In particular, your system can be configured to issue dunning notices in the language specified in the business partner master.

Certain text may appear only for particular company codes. You can decide for each company code whether an individual dunning letter is to be prepared for each dunning level. If this is to be the case, only the items with that dunning level appear on the dunning letter.

Individual accounts can have their own dunning letters. Customer items can be assigned to different dunning areas, each of which receives a separate dunning letter.


NOTE If the SD-Sales and Distribution System has been installed and configured, the dunning areas can be made to correspond to the areas of the sales organization, the distribution channel, or the division.

Refunds overdue from a vendor can be dunned, and you can instruct the dunning program to subtract vendor items from customer items when they concern the same company, if the master records specify that this is permitted.

The dunning program can direct dunning letters to the EDI system on the basis of individual customer or vendor accounts, or in accordance with a group or dunning area policy. You can also use the office system to send the letters by telex, messenger, or postal delivery.

The system always prepares a standard processing log. It can also offer the following reports pertaining to dunning:

  • Lists of blocked items

  • Lists of blocked accounts

  • Lists of items with special dunning keys

  • Dunning statistics

  • Reports of dunning runs

Using Automatic Dunning  Automatic dunning can be initiated if you have determined the key date for a maturity check and identified the accounts to be scrutinized. The automatic dunning program checks the due dates of open items in these accounts.

If you have installed and configured the Financial Calendar, you can schedule dunning runs and assign the proposal lists they generate to the appropriate person for editing and release. This person is notified automatically when a dunning proposal list is about to be generated.

Using Automatic Correspondence from Accounts Receivable

Dunning notices are a type of automatic correspondence that must be first submitted as a dunning proposal to a person authorized to edit and release the dunning notices. This causes the dunning data to be updated in the records of the dunned items and accounts.

You can call for a proposal for automatic correspondence at virtually any time while you are processing accounts and documents. You can set up a cycle of automatic correspondence, and you can initiate individual items manually.


NOTE Any type of correspondence can be generated in the language of the business partner.

Sending Automatic Payment Notices to Business Partners

The business partner who has submitted a payment is automatically notified by a notice that details the items cleared by this payment. If the system detects a discrepancy, the business partner can be automatically asked to clarify the discrepancy or pay the differences. Should it prove impossible to identify an item that could be cleared by the payment received, the customer again can be automatically asked to clarify.

You can use an automatic reply slip to permit payments on account to be assigned to specific open items. This procedure can also be used to deal with any credit memos that cannot be automatically assigned to items and posted in the clearing procedure.

The automatic payment notice also lists any customer items still open after the payment has been assigned. The payment program can be used to identify the open items to be paid and can append additional remarks that are standard phrases or text entered by the supervisor.

Using Account Statements and Open Item Lists

The customer account statement is a standard report generated by the system and addressed to a business partner. The account statement shows the following entities:

  • The balance carried forward

  • All items, both open and cleared, for the selected time period

  • The account closing balance

An open item list is a form of account statement that includes only the open items up to the specified date. This can be sent as a reminder, for reconciliation, or simply for information.

Both account statements and open item lists specify the following information:

  • Document number

  • Document date

  • Document type

  • Currency

  • Amount for each item

  • Balance of open items on the key date

  • Clearing document number, if applicable

  • Addresses of the customer's head office and branch offices, as appropriate

NOTE The number of days in arrears per item can be included in the account statement or the open item list.

Using Standard and Individual Letters

A standard letter can be added to an account statement or open item list automatically. You may wish to notify customers of a relevant change in your organization that could affect their payment and reconciliation activities. This could be the occasion to use a standard letter.

You can use the accounting events of the SAP R/3 system to trigger the insertion of standard texts in a standard letter. You can also assign specific texts to particular segments of your business; some of your customers could be sent particular forms of your standard letters. Furthermore, an individual letter can be added and edited to suit each customer.

Using Other Types of Automatic Correspondence

A balance confirmation is a standard report mailed to a customer. You can operate conditions that automatically arrange for the customers with the highest balances to be notified first. In addition, you can arrange for a random selection of the remaining customers to be notified of their balances.

A document extract is a standard report in which you inform customers of specific line items that you have extracted from a transaction document. For example, you might inform a customer of a credit memo and append a listing of the line items involved.

A customer can clear invoices by submitting a bill of exchange. This incurs charges that you can notify and explain in the form of an automatic letter. This is generated from a master form in the language of the business partner.

Interest can be charged on items that have not been paid and are overdue, or on items that were not paid before the due date for net payment. Interest also can be charged on the account balance and notified by an automatic letter. This could arise, for example, in cases when employees have loan accounts on which interest is charged.


TIP The SAP R/3 system contains a form letter for interest notification. You can modify this letter and store it as the standard.

With appropriate authorization, an in-house or internal document that contains any data fields in your system can be generated. You might want to create an internal document using customer or product data, for example, because no suitable original document was entered. All the standard text phrases and word-processed free text stand at your disposal. An internal document can be saved and used as a standard.

Reporting Customer Accounts

SAP R/3 reporting is executed by identifying the source records and subsequently processing them. This two-stage process means that any standard reports can be run virtually in parallel to a file that identifies the set of sources. Memory considerations do not usually allow online storage of all information, so a separate file is assembled containing only information from customer line items.

This line-item file is typically sorted so that all the cleared items appear at the beginning of each account. Clearing transactions are sorted by clearing date and clearing document number so that the context can be ascertained. Items still open on the key date appear at the end of each account. Reconciliation totals are output for each customer account and for each reconciliation account. This means that the Accounts Receivable position can be integrated with other R/3 modules.

The online reporting facilities of the Accounts Receivable module can be supplemented by printed outputs in single or batch modes. These reports can be sent to file or to a printer. Three main classes of reports exist.

  • Standard master record lists

  • Customer account statements and open item lists

  • Audit trails of individual accounts

Customers can be selected by various criteria, singly or in the form of logical expressions that isolate customers on the basis of one or more attributes of their master records, combined with attributes computed from their accounts up to a key date.

The content of a report falls under your control. You can mix master data and account data, subject to authorization. If the items remain in the system, you can call for reports of customer open items that sort the items by ranges of due dates or by values according to the report specification that you build or copy from a previous design.

A legally valid financial accounting system must have a method of demonstrating all the transactions that contributed to each of the balances on the balance sheet. The system must show the balance at the beginning of the accounting period and all the debits and credits applied to the account to reach the balance at the close of the period.

Every computer system has limits to the amount of storage space that it can make available for any particular purpose. The SAP approach to the management of storage space is to archive all the line items needed for a balance audit trail separately from the document data that recorded the transactions. When a balance audit trail is required, usually at the end of the accounting period, the line-item archive can be scanned without also having to read all the document data.

The balance audit trail report contains a list of customer line items and a control total for each customer account. Reconciliation account totals are also shown so that the accounts can be matched with accounts in other parts of your accounting system.


TIP The customer line items for accounts that are not managed on an open-item basis can be sorted in chronological order to assist in tracking.

When open-item accounting is in practice, the balance audit trail procedure sorts the cleared line items to the beginning of each account, arranged in clearing date order and then by clearing document number. This helps the auditor trace how and when an item was cleared. The uncleared open items fall at the end of each account listing.

Managing Customer Credit

A credit limit is assigned to a customer based on an assessment of his or her creditworthiness. If an order leaves the customer balance within the credit limit, the order is accepted.


NOTE Customers can have a credit limit of zero.

The Sales module checks the credit limit when the order is posted, as does the Financial Accounting module. If the limit is exceeded, the system either issues a warning or an error message, depending on the key held in the customer master. The document can still be posted, but precautionary measures must be taken by examining the customer position, and possibly by blocking the account at the master record.

You can set up a credit control area that covers one or more company codes, and you can specify a standard credit limit for each credit control area. Under these circumstances, a new customer master record is assigned the credit limit according to the credit control area of the company code in which the account is opened.

You can assign a credit limit to a single customer or to several customers according to specific criteria. For example, you can assess customers and potential customers according to your estimate of the business risk of associating with them. You can assign your business partners to risk classes and check their position in a certain way before accepting an order.

A customer can also be assigned to a group of companies that define an industry or industrial sector. A customer can also be classified according to the country in which it operates or according to the area of the world that shares its business conventions.

The procedure for monitoring customer credit limits in a credit control area automatically assembles and summarizes the following information for each customer account:

  • The Receivables from sales not in dispute

  • The Receivables from special General Ledger transactions that affect the credit limit calculation, such as down payments

  • The total order value comprising open orders, open deliveries, and open invoices

These totals are added to yield the total liabilities for each customer. When a customer invoice is posted, the total liabilities display increases automatically by the amount of the invoice. When a payment is received, the total liabilities display decreases. If the posting of a customer invoice will cause an increase that exceeds the credit limit, a warning is issued and the system records the date on which the credit limit was exceeded.

Each credit control area has a credit limit currency in which all credit calculations are conducted. This currency is independent of the local currency of the company code. The system updates the credit limit data using an amount calculated by converting the invoice amount to the credit limit currency. This control currency update does not affect the transaction figures or the posting to the General Ledger.

Using Credit Limit Displays

The detailed monitoring of credit generally is focused on one customer account at a time. For example, you might find it helpful at times to use one or more of the following standard reports:

  • Changes in the master record reflecting some aspects of the customer account history

  • Oldest due items to see whether there is a reasonable explanation or a pattern to the items still owed

  • Customer order value distributed among open orders, open deliveries, and open invoices

  • The date and details of the most recent payment

  • The line items of some or all unpaid orders

  • The dunning history and the payments in response to dunning

One of the best ways to discover unusual patterns in your customers' payment behavior is to have alert people use the display facilities and think about possible interpretations of what they see. You can use an internal memo that references a stored display or a display specification, along with a more detailed examination of customer data. This could come from other sources, such as sales support, perhaps with a block imposed on further orders from this customer until the payment situation is resolved.

One of the benefits of an integrated accounting system is that you can move effortlessly from credit control to financial information. You can display the sales and payment histories. You can perform due date analysis and ask for a calculation of day sales outstanding (DSO), a figure that combines the time overdue with the magnitude of the amount outstanding. DSO represents the seriousness of the debt from the cash flow perspective of your company.

Any combination of variables and display features can be deployed to help you facilitate business intelligence. Business intelligence is defined as the capability of discerning relationships in the data and the capability of working out what they mean and what should be done. If you find a particular display or computation useful, you can identify it and save it for future use.

Creating a Credit Master Sheet

As you move through the process of interpreting a customer credit situation, you can build a credit master sheet to inform others or to document your decision processes. The system enables you to assemble the line-item display, the account analysis, and the credit management data on a document that also is automatically annotated with the following information:

  • The address and data for communication with the customer

  • The credit limit and the date when the customer was last notified

  • Selected fields from the credit management master record

  • The totals of open deliveries, invoices, and orders

  • The balance, the days in arrears of each item, and the texts sent to the customer for each item

  • The customer's payment history

Your credit management module generally is integrated with the SD-Sales and Distribution module, so it is possible to access any sales information and use it to amplify the credit master sheet. The integration with SD enables you to perform what may be complex credit checks in at least the two most critical moments:

  • Before an order is accepted

  • Just before the goods are delivered

If the customer has been assigned to a risk class or a credit control area, the following checks can be mandated:

  • A statistical check on the credit limit

  • A dynamic check on the credit limit that takes into account the delivery deadlines and the due date for all open items on the customer account

  • The absolute value of the order

  • Changes in critical fields, such as terms of payment during the customer's payment history

  • The structure of overdue items in terms of amounts and time patterns

The credit limit management functions of FI-AR Accounts Receivable require a policy to be elaborated and recorded as a set of master records for one or more credit limit control areas. Standard dunning notices and credit limit documents are available for editing. In total, a comprehensive and flexible system ensures that no customers can deplete the value flows in your company by failing to settle.

Using the Accounts Payable Module

The role of the SAP R/3 FI-AP Accounts Payable module is to maintain and manage accounting data for all vendors of goods, materials, and services and to pay for them in support of an integrated purchasing system. Information about orders, deliveries, and invoices is stored according to vendor.

Accounts Payable is a subledger of the General Ledger and is completely integrated with it at the following levels:

  • Master data

  • Transaction data

  • Reporting system

Master data entered or modified in one application is available to all the others. Transaction data is accessible to all. Reporting can draw from the General Ledger and the Accounts Payable subledger.

Transaction data is stored centrally in the document database, and the corresponding line items and details are stored in the subledgers, as appropriate. The system automatically updates a subtotal of a balance sheet account for every business transaction and reconciles the account subtotals and the line items to ensure that the financial information is always correct and current.

Every transaction creates an SAP document, and the data is immediately posted to the General Ledger. As such, every business transaction recorded in this way automatically updates the balance sheet or the profit and loss statement. This is the defining characteristic of an up-to-date networked accounting and controlling system.

Understanding the Business Functions of Accounts Payable

Accounts Payable includes a program that records orders, deliveries, and invoices for each vendor. Operating transactions automatically update accounts in the FI-GL General Ledger system. When you post a vendor transaction, the system immediately updates the Accounts Payable account.

Accounts Payable is directly integrated with Cash Management, which supports cash planning and dunning. An automatic payment program can be called from Accounts Payable. SAP Purchasing is a group of components used by the MM-Materials Management module that can be installed and configured to integrate with Accounts Payable.

Reporting on matters concerned with FI-AP Accounts Payable follows the SAP standard business functions to yield the following reports, for example:

  • List of due dates for Accounts Payable

  • Currency lists

  • Hit list

Correspondence concerning Accounts Payable can be set to provide automatic letters and messages for the following purposes:

  • Balance confirmation

  • Information

  • Interest calculation

You can also customize correspondence to suit individual vendors.

The Accounts Payable module is designed to maximize available cash discounts. You can set up an invoice receipt with information that is incomplete or that has not been assigned to an account. The necessary details can then be added when they become available.

FI-AP is also integrated with the business workflow functions so that invoices can be routed automatically to those who are authorized and qualified to complete or release them. The payment process sequence can be partly or completely computerized. The module supports all customary payment modes for the countries for which your implementation is configured.

Complying with GAAP

The methods used by SAP FI-AP Accounts Payable to adhere to GAAP standards are the methods used throughout the SAP system. These methods also comply with the account conventions of most industrial nations.

Vendor information is stored in vendor master data records, which are the only source of this information and which are kept up-to-date by all users and applications with reason to interact with them. The master data is entered once and stays in only one place. Everyone knows where to find the data and can discover when it was last updated.

Transactions concerning vendors automatically create SAP documents that can be used to keep track of the transactions and any resulting actions. These SAP documents can be used to compile a legal audit trail for each balance amount in the balance sheet. The documents can also be used to record other information used by controlling systems with interests in vendor transactions.

SAP documents must comply with GAAP in the matter of capturing information essential to the proper and legal analysis and control of business. These documents, which are automatically created during vendor transactions under the Accounts Payable system, can be displayed and altered in a controlled manner using the SAP standard business functions for manipulating SAP documents.

The vendor accounts and other accounts such as Payables and down payments integrated with the Accounts Payable system are updated in accordance with GAAP recommendations, and the proper record must be created whenever any changes are made to the account balances by the SAP documents that record such activities. In particular, a company must be capable of disclosing its debts when closing an accounting period.

The R/3 Accounts Payable accounting system uses balance confirmations, journals, balance audit trails, and custom valuation reports to document and manage transactions with vendors. The main activities of deadline analysis are as follows:

  • Revaluation of foreign currency items

  • Identification of vendors with debit balances

  • Lists of the calculated balance amounts on the vendor accounts, sorted according to the terms of payment still obtainable

A thorough Accounts Payable accounting system not only meets legal obligations, but it can also serve as a database for optimizing purchases. If they are directly linked to Cash Management and Cash Forecasting, the Accounts Payable functions can provide valuable support for efficient liquidity planning.

Working with Vendor Master Records

In accordance with the SAP principle of redundancy-free data storage, standard practice involves using master records for the control of basic data that seldom changes. The system designers have ensured that a vendor master data object has a data field for every item of information needed to record and post business transactions with vendors.


NOTE If the information you require for any business process can be supplied by the system, you should not have to enter it by hand every time you attempt to carry out a transaction. SAP should obtain it from the master data object and supply it for you to confirm or edit.

Information in a master record is not necessarily available to anyone interested in it. Certain data objects can be closed to a user who does not have access authorization. The vendor's bank balance is an example of data that is not available for scrutiny by just anyone.

The Purchasing components of MM-Materials Management must be installed and configured to make use of information directed at a Purchasing department. In these circumstances, both the Purchasing department and the Accounting department use the vendor master record at times. Data fields must be present to suit them both, including the following data.

  • General vendor data that any company code in your enterprise might need, such as vendor address, telephone number, and telex and network addresses

  • Company code data about the vendor, such as terms of payment and other arrangements that have been agreed upon only between that company code and the vendor

  • Purchasing organization data about the vendor that might vary from one purchasing department of your company to another, such as the products of interest and the relevant section of the vendor accounting structure

The vendor master record stores the data needed to control payment transactions, and this record can provide the basic information needed to generate a preliminary invoice posting without waiting for final details. Vendor master data for each of your company codes includes the following:

  • Payment terms agreed upon with the vendor

  • The vendor account number under that company code

  • The reconciliation account number in Payables

  • The payment methods agreed upon

  • The dunning procedure

  • Correspondence information and prepared texts

  • How the vendor line items are to be sorted on displays under that company code

Creating and Maintaining Vendor Master Records

If your enterprise has more than one purchasing organization, each one could maintain information that is of no particular interest to the other. For example, both organizations could be responsible for the purchasing of different types of materials and services. They might have a different set of purchasing contacts and might operate through different sales departments of the vendor organization. Each purchasing organization may need to maintain separately such items as inquiry information, order information, and data required to verify invoices.

If your Financial Accounting and Materials Management applications are integrated, the following possibilities are available for maintaining vendor master records:

  • Maintaining company code data on vendor masters separately at each company code

  • Maintaining purchasing organization data on vendor masters separately in each purchasing area

  • Maintaining all data on vendor masters from a central location

When a new or prospective vendor is identified, a new master record is created. This record must be assigned to an account group.

The account group determines whether you can assign account numbers within specified ranges or whether this is done automatically by the system. You cannot assign the same account number more than once, but you can have both customers and vendors within the same range of numbers.

The account group also controls which fields are active in this master record. You can pick the fields offered by the account group and assign them to one of three categories:

  • Fields into which the user must make a valid entry.

  • Fields the user can either leave blank or make an entry into (optional fields).

  • Fields suppressed so they do not appear on the screen. An entire screen of fields can be suppressed if they are not needed for a particular master record.

Field groups enable you to subdivide the control over groups of fields such as address and bank information. Accounts Payable also can add fields that contain specific information about the supplier.

The FI-AP Accounts Payable system makes it easy to create vendor master records by offering various options.

  • You can copy and edit a master record from a reference record established for the purpose.

  • You can copy the master record of an existing vendor and edit the unwanted details to make it into a new master record.

  • You can create the new vendor master record by entering all the necessary details.

After you have entered and stored a vendor master record, you can recall it and change almost any field. Master vendor records can be selectively displayed so that you can see only those fields of interest. You have the choice of whether to go through all the fields or to work on only one set of fields, such as the product or service details.


NOTE The system automatically maintains a log of all changes made to vendor master records.

Using One-Time Transaction Accounts

If you think a vendor probably will not become a regular supplier, you can set up a one-time account by selecting a special function. This creates a master record that contains only the essential control data, such as the number of the reconciliation account to which this purchase is posted.

You can supply the address and the bank account data when you enter an invoice received. This information then arrives in the one-time account master record, where the dunning and payment programs can find it.

Using Vendor Head Office and Branch Accounts

Your supplier could be a branch with its own account, but the head office may want to receive your payment. In this case, you can enter the head office account number in the master record for the branch vendor. When you enter a transaction to the branch account, the system posts the transaction to the head office account, leaving a cleared entry on the branch account to show who supplied the goods or service.

The master record includes data about the branch and a reference to another master record to give details of the head office. By this means, dunning letters can be sent to the head office, the branch, or both for overdue refunds, for example.

Sending Vendor Payments to an Affiliate

Your supplier may not have to deal with his payments due. You can record in his master data the account number of the alternative recipient. The system then processes return transfers and other vendor payment business through the banks to the alternate recipient.

If you have a credit balance in one or more affiliates of a vendor and you post vendor invoices to an affiliate account, your accounting system also must record the single head office vendor company account number to be used during consolidation to eliminate the invoices that would otherwise appear twice in the accounts. The system can look at the transaction documents bearing this group-wide company account number and identify any entries that are replicated because the payment was made to an affiliate that was not the original vendor.

Understanding Transactions in Accounts Payable

When you post a transaction to a vendor account, the reconciliation account for Accounts Payable is updated immediately in the General Ledger. The system updates a separate account for each type of vendor transaction, such as the following:

  • Purchases

  • Down payments

  • Bills of exchange payable

  • Guarantees

Orders to and invoices from vendors also update financial planning and cash management data.

Using Vendor Invoices

The SAP FI-Financial Accounting system can be integrated with the MM-Materials Management system. An invoice with an order and delivery data can be entered and validated in Materials Management. Validated invoices are posted automatically to the General Ledger accounts in the FI-Financial Accounting system, if the two systems are suitably configured.

If your financial system is not integrated with a Materials Management system, you can carry out the invoice receipt function in the Financial Accounting module using the following steps:

1. Enter the invoice document header.

2. Enter one or more line items.

3. Verify the line items entered automatically by the system, such as input tax postings.

4. Correct any details on the invoice receipt document.

5. Post the invoice receipt.

Using Electronic Data Interchange

Vendor invoices can be received by EDI. Data entry starts automatically, and the system creates an SAP document that receives the incoming data and is posted when complete. If any errors are detected, the invoice receipt document is forwarded to a suitable person for verification.

One of the advantages of this kind of system is that the invoices can be processed at off-peak times, and the problem items can be presented in batches when a suitable person is available.

Scanning Invoices

The ArchiveLink standard interface can be used to scan incoming invoices. The interface will have been customized to recognize the type of document and the vendor company. The scanning will also be primed to identify standard materials and services, with the corresponding quantities. If the recognition cannot be completed automatically, the system forwards each image to an appropriate person for verification.

Supporting Manual Invoice Entry

If you must manually enter or edit an invoice that has not been posted automatically, SAP R/3 provides all possible help. The successful posting of a transaction does not occur until the necessary data is recorded as an SAP document and is complete and error-free. You can set aside a transaction document before it is ready for posting, in which case the system validates any information you have already entered and reports any discrepancies in the form of a detailed list of the error sources. If you have the authority, you can access the source document to seek clarification.

The SAP document must end up with a document header showing posting date, document date, document reference number, and currency key. The body of the document contains one or more line items showing the amount and identifying the product and terms of payment. The system generates certain line items such as tax entries, cash discounts, and exchange rate differences, as applicable.

You can set up helping routines and use standard data entry functions such as the following:

  • Setting default values that you can edit at the time of entry

  • Recalling for copying and editing a previous screen

  • Retaining data for individual users for several transactions

  • Adapting a copy of a data-entry screen so that it is better suited to a set of expected transactions

  • Searching for an account number by using matchcodes to narrow the search

An SAP document that records a previous transaction can be copied to act as a sample or model to be edited. This sample can be a regular document that has been set aside, perhaps as an incomplete transaction document. The posting date and new values may have to be changed before posting.

Handling Recurring Entries

If you expect to make a series of entries in which the amounts are always the same, you can set up a recurring entry. Monthly service charges under contract would be one example.

A recurring entry is a set of data that is not used until the due dates. Until then, the entries do not update account balances. You must specify the first and last dates and the frequency or time interval. The system automatically posts the required transaction on each of the due dates.

Using Account Assignment Models

An account assignment model is a document entry template that can take a variety of forms. Unlike a sample document, a document entry template need not be a complete and valid document. You may have to add or edit details before posting it.

The advantage of using an account assignment model is that you can enter invoices and credit memos quickly and safely. For example, you may have to repeatedly divide amounts between several company codes, between accounts, or between cost centers. If you have a suitable document entry template, you can arrange for the General Ledger account items to be in place so that when you enter the total amount, the system can apportion it automatically between the various receiver accounts. Your account assignment models can include fixed distribution ratios to control the assignments between General Ledger items.

You do not have to accept the suggestions of an account assignment model. You can amend any details before you release it by entering the total and posting the template as a complete document.

Using Control Totals and Checks for Duplication

If you post any document that is in error, the system immediately reports it and suggests a correction. Control totals are maintained at suitable levels that are entered, automatically where possible, on the basis of the expected values. A built-in function ensures that you do not generate duplicate invoices. Should you mistakenly post a transaction to the wrong vendor, you can reverse this transaction and the associated SAP document. The system automatically generates a reversing entry for each item wrongly posted.

Working with Incomplete and Preliminary Documents

If you are interrupted before completing a transaction document, or if you want to set the document aside for the moment, you can save it as an incomplete document and recall it when you are ready to resume work on it. If you have an invoice that needs to be reviewed or assigned to an account, you can enter it as a preliminary document. Creating a preliminary document does not update transaction figures, even if the document is complete. However, the posting of a preliminary document is treated as a statistical transaction and is displayed along with other accounts.

The data in a preliminary document, or in a set of preliminary documents, can be analyzed and used in various ways, as long as you do not try to update the transaction database with them. For example, you could create a preliminary invoice to calculate and print an advance sales tax return, perhaps in response to a question from a business partner. Another use of preliminary invoices might involve payment requests to assure that your customer or your accounting department pays on time and qualifies for a cash discount.

A preliminary or incomplete invoice receipt document can be generated by one person and then forwarded to a cost center for payment release by someone with the required author-ization. The document could then be returned to the originating person for completion and posting.

Another main use for a preliminary document is to register an invoice when there is insufficient information to have the amount correctly assigned in cost accounting, for example. The invoice can still be recorded and reported for tax purposes, ensuring there is no loss in cash flow resulting from taxes levied on supplier invoices.

The task of processing incoming invoices can be summarized in the language of the SAP workflow system, as follows:

1. A trigger event arises on receipt of an EDI invoice, a scanned invoice, or a manual invoice entry.

2. Accounting entry is affected by posting a preliminary document with the payment-blocking indicator set.

3. The responsible organizational unit releases the preliminary document for payment.

4. The responsible employee workplace processes the document through to completion.

The authority for actions at each stage of the workflow is defined in terms of authorization paths that represent the stages of approval for payments of different kinds and amounts.

The flexibility of the workflow concept, as it is elaborated in the SAP R/3 system, is demonstrated by the infinite variety of workflow paths that can be established to ensure that your work activities are performed in the correct order and with the utmost dispatch.

Using Centralized Open Items

You can support centralized open items by allowing more than one company code to post to them. For example, you might wish to hold a central stock of a material and permit each company code to draw on it as planned or as required. Under these circumstances, an invoice can refer to goods and services destined for different company codes. The invoice must be entered in the Accounts Payable of only one company code. The General Ledger account items must therefore be distributed among the various company codes that make withdrawals of the central item.

When a multicompany open item of this kind is posted, the system automatically creates line items for Payables and Receivables arising between the individual company codes. The system also generates a separate document for each so that their individual accounts can be correctly updated to record their particular withdrawal from the central open item. Each document carries its unique document number, but they all refer to a joint transaction number that links them. This joint transaction number can be used to acquire a summary of the joint transaction data.

Understanding the Net Posting Procedure

A net vendor invoice records the liability to the vendor after the cash discount. When you process a net vendor invoice, you must enter the gross amount. The system calculates the net amount on a line-by-line basis.

When this type of invoice is posted, the General Ledger entries in the Accounts Payable subledger include the offsetting amounts net of the cash discount. The amount of the cash discount is automatically posted to a discount clearing account. This figure remains there until you pay the invoice, at which time it is released.

When a vendor invoice is entered using net posting, the cash discount is taken into account at the time the vendor invoice is entered. A net posting anticipates that the payment will be made before the due date and will attract the cash discount. The cost of the goods or services bought on a net posting transaction is recorded in the materials or expense account, with an additional line item to allow for the discount.

If you use the payment program to pay invoices, the system applies the cash discount rate when the payment is made and posts the net amount. This discount therefore might differ from the discount anticipated and posted when the invoice was received. If this difference arises, it is posted to a separate expense account.

The gross posting procedure and the net posting procedure are used side by side in the SAP R/3 system. In both cases, even after posting, you can make changes to the cash discount terms in the invoice document or in the payment proposal. In both types of posting, you enter gross values and the system automatically corrects the line items and posts any differences to the clearing account.

The purchase of a fixed asset can be recorded as a net vendor invoice. By this means, the amount representing the value of the fixed asset is net of the cash discount and can be depreciated in the normal way. The discount clearing account carries the amount of the cash discount, but it does not have to be cleared later because it was released when payment was made for the fixed asset.

Using Credit and Debit Memos

A transaction that reduces Amounts Receivable from a customer is a credit memo. For example, the customer could return damaged goods. A debit memo is a transaction that reduces Amounts Payable to a vendor because, for example, you send damaged goods back to your vendor.

When you post credit memos, the payment program processes them automatically. If the credit memo is specifically related to a particular open invoice item, the payment program automatically attempts to offset the credit memo against the open item. If it is not possible to completely offset the credit memo against an invoice, you can post a debit memo to the vendor, who is to reimburse the amount. Then you can apply a multilevel dunning program.

Dealing with Down Payment Requests

The standard general-purpose data-entry function can be called from the Accounts Payable module to General Ledger entries such as credit memos and adjustments. However, down payments, bills of exchange, and security deposits are examples of special General Ledger transactions. Separate account balances are maintained for them.

A down payment to a vendor can be made by the payment program if you have entered to the system a down payment request document that includes all the necessary payment data and the due date before which the down payment must be made. The system stores the request without updating any account balances. At any time, you can call for a report to display an individual request, all requests for a given vendor, or all requests for down payment entered.

You have the option to display down payments in the vendor or General Ledger as either gross (including sales tax) or net (excluding sales tax). The net amount is reported in the balance sheet, and the tax appears in the tax account.

When the payment program carries out all the down payments requested and you receive the final invoice from the vendor, you can enter it. The system displays all the down payments made on this invoice, and you can apply them to offset the invoice in whole or in part. The payment program then pays any amount outstanding to the vendor.

Using Automatic Payment Functions

Manual entering of payments is necessary, for example, if a vendor is to collect from you by direct debits. The most effective time-saver in Accounts Payable, however, is the automatic payment program. The payment program proceeds in three stages:

1. Generating a payment proposal list

2. Presenting a payment proposal for editing

3. Executing the approved payment proposal by posting payment documents to clear the Payables and link them to the payment, creating payment forms and other payment media as required

You can also have a payment triggered automatically without considering a payment proposal.

Editing a Payment Proposal

The purpose of a payment proposal is to maximize cash discounts within the constraints set by the control strategy specified in the vendor master records and also by the way the payment program has been set up. The following options are available for editing a payment proposal:

  • Replace the proposed payment procedure with another

  • Substitute a different bank to receive the payment

  • Change the cash discount terms for the items to be paid

  • Block certain payment items

  • Add open items to the payment proposal

Displaying vendor open items shows you who is yet unpaid; you must decide who to choose for payment. You can choose who to pay on the basis of due dates, according to the outstanding amounts of magnitude, according to your preferred vendor policy, and so on.

The system checks the due dates of vendor open items and proposes a method of payment for each, depending on the vendor master data and the requirement to maximize cash discount. The system also chooses one of your banks to provide the funds for each payment, as well as a bank to receive it on behalf of the vendor.

The system can generate a form for a check or automatic payment medium, such as disk or an online electronic transfer. You must assign a medium of this kind for each payment, either individually, based on the default values suggested by the system, or based on the data in the vendor master records. You can directly specify the choice of medium prior to a batch of payment proposals.

Execution of a valid payment proposal is largely automatic. The payment program generates SAP payment documents and posts payments to the appropriate General Ledger accounts. The vendor items in the payment proposal are marked as cleared and are given a reference number that links them to the SAP payment document.

For each country and payment method combination, a specific program prints the checks or payment forms in the language and accounting style for that country and, if a disk or other electronic payment notification channel is used, in the format for that medium. The system compiles a log of each payment run and all payment methods applied so that you can see the effects and exercise control.

Maximizing Cash Discounts

The default payment principle operated by the system is to pay open items as late as possible without losing any available cash discounts. Each vendor open item carries a base amount, which is the payment due before applying cash discounts. Each vendor master record contains information about the payment terms that that vendor has agreed upon with the purchasing company. Under the control of the purchasing group, different payment terms can be negotiated between a vendor and each business entity defined by the company codes.

The payment terms for each company code purchasing from a vendor each include at least one cash discount term, expressed as a percentage discount, and a cash discount date related to the date of the invoice. For example, the following are cash discount payment terms:

  • 3% if paid within 14 days of the date of the invoice

  • 2.5% if paid on or before the 15th of the month following the date of the invoice

For each open item, you can enter one or two payment terms and a date for net payment. The system can calculate the due discount date by referring to the payment terms and the invoice date. You might wish to enter a date for net payment within a discount period on a date that suits your requirements.

You may find national differences in the practice of settling accounts. In France, for instance, it is customary to pay an invoice with a bill of exchange immediately so that the due dates of the bill of exchange and the invoice are the same.

Controlling the Payment Program

The SAP payment program can be set to pay, by bill of exchange, all invoices due within a specific time period. Many other different payment methods could be available in the system. The payment program can also be used to make payments by check, by bank transfer, by postal check, and by other methods such as notes payable that are specific to particular countries or trading areas.

Multinational accounting is supported by the SAP INT-International Development module that manages accounting according to the areas of legal force listed in Table 3.1.

Table 3.1  SAP Accounting Areas of Legal Force

Abbreviation Area
IN-APA Asian and Pacific Area
IN-EUR Europe
IN-NAM North America
IN-AFM Africa and the Middle East
IN-SAM South America
No limits exist as to the number of different payment methods you can use for each country. Many of the forms are supplied via an SAP script, which is then used to control the printing in the language of the destination country.

NOTE You can edit the forms that are supplied so that they precisely suit your payment format.

You can ask the system to select the payment method from a list of up to 10 methods that have been nominated in the vendor master record. The automatic selection of payment method can be governed by such factors as the following:

  • Amount to be paid

  • Number of open items paid

  • Currency of the receiver

  • Location of the vendor

  • Amount available in the bank account

Open items can be grouped for payment, and individual items can be marked to be paid separately. You can nominate a specific open item to be paid in a particular way.

Your system may be set up to choose one of the vendor's banks on the basis of the bank's capability of paying, for example, by bills of exchange. The choice could rest on your bank's capability of making a direct transfer to the vendor's bank. Banks are given group codes to indicate who can transfer to whom.

The payment system can be asked to choose one of your banks from which to make a payment. You can rank-order your banks and have the system work down the list to look for sufficient cash and the appropriate means of paying. You can instruct the system to choose one of your banks because it has a branch near the vendor. You can also override the automatic selection by commanding it through an entry in the open line item or by changing the vendor master data.

If payment must go to a recipient other than the vendor, you can arrange it in various ways:

  • All payments in all company codes can be redirected by entering the new account number in the general data of the vendor master record.

  • All payments in a specific company code can be redirected by entering the new account number in the company code section of the vendor master record.

  • Payments for specific open items can be redirected by marking each open item by a code, but only if this is expressly permitted by an entry in the vendor master record that specifies the alternate account number.

Receiving Intercompany Payments

One vendor might supply several company codes in the same group. The payment system can make one payment and then settle the intercompany accounts by calculating and posting Receivables and Payables between company codes.

The transaction requires you to define one of the company codes and enter it as a normal paying company. The system assigns the document a unique intercompany identification number used to ensure that the other members of the company code group pay their shares.

Clearing Sales Contra Purchases by Offsets

If a vendor is also a customer, you can offset vendor and customer open items against each other via a Contra account. The vendor and customer master records must be capable of identifying each other by holding the respective account numbers in the company code areas. This sort of dealing must be explicitly permitted by the appropriate master data items, which enable you to control which of your company codes is permitted to operate offsets between sales and purchases. This practice is forbidden in certain countries by their insolvency (bankruptcy) laws.

Using Reverse Documents

Should you mistakenly post a transaction to the wrong vendor, you can reverse this transaction and the associated SAP document. The system automatically generates a reversing entry for each item wrongly posted.

Managing Data Media

Standard forms printed for particular banks or countries can be supplemented by custom forms created by word processing through SAPscript. A disk for data medium exchange is made from a file that contains all payment information the destination country requires. The system includes a data medium management function to support the data media created during payment transaction runs. You can ask for an overview of each data medium object that includes the following elements:

  • Payment run identification

  • The house bank

  • The clearing center

  • The calculated amount

A data medium comprises a collection of stored documents that can be individually inspected or selectively output to screen or printer.

Managing Checks

The significance of the check management function is that it can issue checks without using the payment document number. There are two situations of relevance:

  • Where banks supply checks that are uniquely prenumbered, such as in Australia, Canada, France, Great Britain, and the United States

  • Where the banks or the company require checks to be numbered in a particular way, such as when the payment document number is too long or where there is a possibility of check numbers recurring over the years

Checks or payment document forms from a printer are divided into stacks, which are assigned number ranges. The check print program chooses the next available check number or payment document number and stores the details of the payment assigned to this number.

Posting from the outgoing checks account to the bank account is an automatic process. The check register file stores the date on which each check was cashed. Checks that have been cashed or voided can be archived and recalled for subsequent scrutiny through the check or payment document number, or by a search for other attributes such as payee or date of issue.

If the bank supplies electronic information about the checks that have been presented and canceled, the system updates automatically. If the bank returns a hard copy of canceled checks, you must use the Manually Cashed Checks input function.


NOTE The system can be set up to generate a list of all incoming checks for each house bank and a register of all check information stored in the database.
Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)