SAP Financial Accounting (FI) delivers the standard Accounts Receivable (FI-AR) module to track accounts receivable transactions. This module is tightly integrated with the R/3 Sales and Distribution (SD) module to enter and process customer master data, shipping, billing, and receivables.

As requirements became more complex and the data volume increased substantially over the last couple of years, SAP developed a module in FI for tracking A/R data. This application component is known as Contract Accounts Receivable and Payable (FI-CA). SAP promotes FI-CA as a subledger application alternative for the FI-AR module and Accounts Payables module (FI-AP). I will focus on the FI-AR capabilities of contract accounting, since SAP developed more new functionality related to A/R than A/P. I will show you the strengths of both functionalities so that you can determine which one best matches your needs.

FI-CA was developed to deal with a large number of different customers and different types of receivables. FI-CA is mainly used in industry-specific SAP components, which by nature have many customers and many different receivable types. Examples are the public sector, utilities, insurance, and telecommunications industries. Even if you do not fall into one of these groups, you can still use contract accounting. The industry solutions for FI-CA have been available since 1999. An industry-neutral version was introduced in 2002.

FI-CA is not only tightly integrated with the core SAP components like FI, Controlling (CO), Customer Relationship Management (CRM), and SD. It also has the capability to deal with customers and payments over the Internet by using SAP Biller Direct, which allows your company to use electronic bill presentment and payment (EBPP).

Tracking Multiple Receivables Types

Assume that the following business scenario exists in your company: You are required to track the receivables by customer/service in different receivable balance sheet accounts. In the FI-AR module, a customer can only be linked to one single receivable account (reconciliation account). Although you could use the workaround of the special G/L indicators to track receivables in different reconciliation accounts, SAP intended the special G/L indictor to be used for special transactions like bad debt or security deposits rather than as a tool to track receivables for different services.

This design that links a single receivable account to one customer makes it impossible to track different receivables for one customer in different accounts. The only solution to the above scenario is to create multiple customers with different receivable accounts, which has the disadvantage that the receivables cannot be tracked in one customer account.

In comparison to FI-AR's singular model, FI-CA has a multi-level master data concept. The highest level is the business partner. A business partner in FI-CA is equivalent to a customer in the FI-AR module. The second level is called a contract account. For each type of receivable, a contract account is created for a single business partner and one business partner can be assigned to multiple contract accounts. Similarly, one contract account can have more than one business partner. In FI-CA, the reconciliation account is determined on the contract account level, not on the customer level like in the FI-AR module.

If you build a master data structure in FI-CA based on the above business scenario, then one business partner would have multiple contract accounts with separate receivable accounts linked to the individual contract accounts. This makes it possible to track different receivable types for one customer in multiple receivable accounts, a task that is impossible using FI-AR.

Master Data Management in FI-CA

As previously described, a single business partner can have multiple contract accounts in FI-CA. In addition, SAP offers a third master data layer within FI-CA. This third object is called a contract or contract object. The purpose of this object is to further distinguish the receivables within a contract account. This is necessary if you need to group receivables from multiple contracts into one contract account and still want to separate the receivables (Figure 1). The purpose and the functionality of the contracts vary within the different industry solutions; however, the concept is always the same. See Table 1 for a list of examples of contract accounts and contract combinations within the different industry solutions.

Figure 1

Master data concept within FI-CA

One interesting feature within master data management is the ability to create user-defined fields or new tabs and combine screens using the Business Data Toolset (BDT) without any modifications. BDT maintains and supports transaction data and master data.

Functional Features of FI-CA

Let's compare FI-CA's functionality with what is currently available in FI-AR. Table 2 compares many aspects of the two modules' functionality. This table may help you decide whether FI-CA could be an alternative for your organization. In the next section, I will describe the features with the most functional differences in greater detail.

Security Deposits

FI-CA's security deposit functionality can be used to manage cash and non-cash security deposits — payment guarantees or a letter of credit, for example. Security deposits have a status of requested, received, or paid. These statuses allow the deposits to be managed. Each security deposit is created with a "valid from" and "valid to" date, which defines the validity period and also influences the interest calculation dates (Figure 2).

Figure 2

Security deposit

For cash security deposits, interest can be calculated for each line item. You can do this individually or in a mass process. In the FI-AR module, you can track security deposits with the help of special G/L indicators and calculate interest on them. The main difference is that there is no easy way to manage security deposit requests and non- cash security deposits. The only option is to use noted items. Noted items (transaction F-38) are statistical items that can be used for security deposit requests or letters of credit. You have to use two FI-AR functions, special G/L indicators and noted items, to cover the same functionality in FI-CA.

Installment Plans

The FI-AR module does not provide functionality for the management of installment plans. In FI-CA, installment plans can be created for outstanding receivables for different installment plans, i.e., weekly or bi-weekly installments. The old receivables are then cleared and new receivables are created. This allows for easy tracking of installment line items. You can charge additional costs or calculate interest on the installment items upon creation. In Figure 3 on the next page, a bi-weekly installment plan with four installments is created for all open items of a customer. The system then takes all open items and divides the total amount due into four installments with new due dates.

Figure 3

Create a bi-weekly installment plan

In this example, an installment plan with four installments is created for the total amount of $66.15 (Figure 4). The starting date for the first installments is 07/23/2004. The next installment due dates are based on the interval type, bi-weekly in this case.

Figure 4

Bi-weekly installment plan items

Cash Desk Payments

One of the main features in FI-CA is a robust cash desk component (Figure 5). With this component, you can manually post and assign payments at a cash desk. You can process the following payment types:

• Incoming cash payment
  
  
• Incoming card payment
  
  
• Incoming check payment
  
  
• Postal order (wire transfers)
  
  
• Outgoing cash payment
  
  
• Outgoing check payment

Figure 5

Cash desk payments entry screen

From an organizational point of view, branch offices are created for different departments. Within these branch offices, you can create separate cash desks, which provides a segregation of the single cash desks within an organization.

Within the FI-CA cash desk, you can apply payments to open receivables by selecting open items by business partner or contract account. You can post additional payments directly to revenue accounts by using the TrPostg to key. This key is a short account assignment key for transfer postings. Accounts and account assignments — i.e., cost center or internal orders — are assigned to each key in Customizing. This is advantageous because users only have to know their respective short assignment keys in order to record revenue correctly.

In comparison, the FI-AR module does not have functionality that allows you to process both customer payments and revenue posting from a user-friendly, one-screen transaction. Payments against open receivables can be applied using transaction F-28 (incoming payments) and incoming checks can be deposited using transaction FF68. If you deal with a lot of incoming payments by check, cash, or credit card and need to apply these payments against open receivables or just record the payment as revenue, there is no good alternative in the FI-AR module.

Dunning

With FI-CA's dunning functionality, you can automatically send dunning notices, or payment reminders, to your business partners to remind them of overdue payables and to request payment. You can also trigger user-defined dunning activities, i.e., transfer items to a collection agency.

Dunning takes place in two steps. In the first step, the dunning program determines:

• The contract accounts to be dunned and the items due for dunning
  
  
• The valid dunning procedure and the related dunning levels for the individual items
  
  
• The dunning groupings in which the items are summarized

The dunning functionality uses this information to create a proposal structured by dunning groups.

In the second step, the dunning program triggers the relevant dunning activities for the individual dunning groupings. You are free to choose the criteria by which dunning notices are grouped. For example, you can create a dunning grouping using any or a combination of the following criteria: business partner, currency, company code, or dunning recipient. You can define additional dunning criteria and group them as needed. You can also define dunning activities as required. For instance, a dunning level can trigger the printing of a dunning notice or lead to the termination of a contract. The dunning activities are industry-specific, but you can also customize them based on your requirements.

You can also calculate dunning charges and request them from your business partners. Calculation of interest on items due is also possible during the dunning run. You can post the charges and interest relevant to the general ledger (G/L). By specifying amount limits in Customizing, you can prevent negligible amounts from being dunned. The system records all dunning data for each item in a dunning history.

In terms of creation of dunning notices and charges, no differences exist between the FI-AR and FI-CA module. You can do a lot more than just creating dunning notices in FI-CA by means of the dunning activities. SAP delivers user exits or events that allow you to program your own dunning activities as needed. Table 3 shows an example of multiple dunning levels with different dunning activities.

Collection Agencies

If a customer does not pay his receivables and all measures have been taken to collect the receivables, many companies use collection agencies to prevent losing the receivables. FI-CA enables you to manage postings connected to submitting receivables to a collection agency and the exchange of information with those collection agencies. Files are created for items that are submitted to collection agencies.

FI-CA also allows for the automatic processing of incoming files received by collection agencies for collected payments from the agencies. In comparison, the FI-AR module does not provide any functionality that can handle the automatic exchange of information to and from collection agencies.

Reporting

One of the weak points of FI-CA is its limited reporting functionality. SAP expects that customers who use the FI-CA module also have Business Information Warehouse (BW) installed. The FI-AR module has better and more standard reports available and it will take considerable time and effort to develop these reports in FI-CA without using BW. SAP has recognized these shortcomings and promised improved reporting capabilities in future releases.

Is FI-CA an Alternative for You?

As shown in the previous examples, FI-CA incorporates more A/R functions than just processing invoices and payments and maintaining master data. These functions are necessary if you deal with a large customer base and a high volume of invoices and payments. This is the case with a utility, insurance, or telecommunications company or in the public sector. My description of FI-CA functionality can be a starting point for your decision process. If you determine that the described functions are necessary for your business, than FI-CA could be a valuable alternative to the standard FI-AR component.