Security deposits are an integral part of SAP contract accounts receivable and payable (FI-CA). There can be various request reasons to collect security deposits from customers during the year. Utility companies can convert security deposits from one request reason to another request reason during different phases of a service agreement. Normally, there is only one general ledger (G/L) for all request reasons, but in a scenario in which a security deposit is accepted in phases, you need to post the security deposit in a separate G/L for each phase.

Utility companies face a challenge in dealing with such cases as they already have accounted for a security deposit in one particular G/L. Standard SAP security deposit conversion functionality (i.e., a change in the security deposit request reasons) does not provide a method by which G/L accounts can be changed based on the request reason during conversion from one reason to another. We describe a way to enhance the security conversion functionality so that you can use it for the scenario explained above.

Enhancing the security deposit conversion functionality based on security deposit request reasons in FI-CA can help improve a company’s standard deposit conversion process. It enables the company to convert security deposits based on request reasons and also to change financial information (G/L accounts) automatically at the time of conversion. Enhanced functionality provides better year-end or interim reporting on the security deposits based on request reasons. The year-end process is streamlined in terms of having separate G/L information for each request reason. In a standard conversion process in an SAP system, this type of reporting is not possible because the deposit amount is clubbed in a single G/L account for all the request reasons.

This enhancement reduces the complex manual effort of segregating dollar values of each security deposit type from a single G/L account.

Business Case

In a typical US-based water utility company, there is a business segment called land development in which the company provides water service to customers for land development. The agreement or contract to provide water services to a customer for land development purposes for a definite time span is defined as a project. In this service, security deposits are collected from the customer at different phases of the project. This type of customer has a unique account determination ID to segregate the type of customer. (An account determination ID is a characteristic used to segregate customers based on either region or customer group—for example, a domestic customer or an industrial customer). It's a free field in which the SAP system gives you the space for grouping your customers (for example, grouping residential customers in one space and industrial customers in another). This helps in automatic determination of G/L accounts.

The land development process includes collecting a security deposit amount from a customer at the start of a land development project as a land development advance (which is one request reason). This deposit amount is reduced during the project on the basis of certain conditions, normally after a certain percentage of project completion. It is then called a performance bond (another request reason). At the end of the project this deposit is further reduced and named a maintenance bond (another request reason).

In the SAP system, these three types of deposits are configured as different request reasons, but use the same account determination ID as the customer is same. Thus only a single G/L account can be assigned. Because only a single G/L account can be assigned and determined automatically, a business has to use the same posting parameters. All deposits are lumped together and posted as land development advance deposits. Since they are not accounted for individually, the business has no way of reporting on each of the three different kinds of deposits at the end of the year. The finance department finds it difficult to reconcile the amount posted to the G/L account during the year based on the type of deposit received. There were three types of security deposits, but all these amounts were posted in one deposit account.

At the end of the financial year, you can use an SAP standard report (FPD1) to determine a breakdown for different kinds of security deposits. Unless different G/Ls and account determination IDs are assigned to each request reason, these reports do not give exact results to the finance department for the amount of deposits posted to a particular G/L account. Through a configuration change and enhancement of two events, you can achieve the functionality of using a different G/L for each request reason. 

We describe the detailed view of each process starting from the security deposit through its conversion based on the request reason selected.

A Security Deposit Process

When a customer approaches the utility service provider for an initial connection of utility services (water or gas or electricity), the utility company evaluates the pre-connection conditions for the customer. If a security deposit is required from the customer, then a security deposit request is raised initially for the particular request reason (already configured in the SAP system).

The customer has to pay the requested amount of the deposit to obtain service. Once the payment is received from the customer against the requested security deposit, a down payment is created on the customer’s contract account, which is typically retained until the end of services. This deposit is refundable at the end of the service and is taken by the company to offset any loss that the company may incur in case of non-payment of a bill. These deposits sometimes qualify for an interest payout that is paid to the customer at regular intervals by the company. During the final billing or at the request from the customer in certain conditions, this deposit is refunded to the customer. The process flow of a security deposit is shown in Figure 1.

Figure 2

The standard conversion option for a security deposit

When a security deposit is eligible to be converted from one request reason to another request reason, each request reason should have a different G/L account number maintained in the system for accounting and reporting purposes. While using standard SAP transaction code FPSEC2 for conversion of such security deposits, there is no option for changing the G/L account number, which results in incorrect accounting and reporting.

The Enhanced Security Deposit Conversion Functionality

Security deposit conversion has some additional features that differentiate it from the usual way of converting deposits in FI-CA. The enhanced features provide automatic determination of posting parameters and interest key population while converting security deposits from one request reason to another request reason using SAP standard conversion option (FPSEC2). A security deposit can be converted, posting parameters can be automatically changed, and different interest rates can be set as the default while choosing new request reasons during conversion.

Configuration Changes

To enhance the system, the following configuration and technical changes are required:

Step 1. Configure the reason code.

To complete this step, follow menu path SPRO > Financial Accounting (New) > Contract Accounts Receivable and Payable > Business Transactions > Security Deposits > Define Reason Request For Securities. In the initial screen that this menu leads you to (not shown), click the New Entries button. This action displays the screen shown in Figure 3 in which you create new request reasons for security deposits. For example, you can create a request reason for residential customer ZRES.

Figure 3

Enter values for a security deposit request reason

If the requirement mandates creation of new request reasons, then new reason codes should be created in this step. Otherwise, existing reason codes can be used. For this example, enter ZRES in the field under the Reason column and a description (Residential customer) in the field under Text. Click the save icon to save your entries.

Step 2. Create account determination IDs to map the request reasons in SAP configurations.

To complete this step follow menu path SPRO > Financial Accounting (New) > Contract Accounts Receivable and Payable > Basic Functions > Contract Accounts > Define Account Determination IDs for Contract Accounts. In the initial screen that the system displays (not shown), click the New Entries button. This action displays the screen shown in Figure 4 in which you create new account determination IDs for customers. For example, for residential customers RE account determination ID can be created.

Figure 4

Enter an account determination ID for a residential customer

To differentiate between the type of customers, separate account determination IDs can be created. For my example, enter RE in the field under the A... column and enter a description (Residential customers) in the field under Text. Click the save icon.

Step 3. Map separate G/L accounts in the system for the newly created account determination ID.

To complete this step follow menu path SPRO > Financial Accounting (New) > Contract Accounts Receivable and Payable > Basic Functions > Postings and Documents > Document > Define Account Assignments for Automatic Postings > Automatic G/L Account Determination. This path leads you to the configuration where G/L accounts should be assigned for the new account determination ID as shown in Figure 5.

Figure 5

Configuration to maintain different G/L accounts

In this step, main transactions and subtransactions of security deposits configured in the system should be assigned with a G/L account number against account determination IDs. The values in this configuration are dependent on the client system as these values are requirement specific. As shown in Figure 5, a value needs to be entered in the respective columns and then you create a transport to move the value to further systems.

Main and sub transactions are numeric key values available in the SAP system that are used to identify a type of transaction. These keys can also be created as per the company requirement. For example, security deposit transactions can be identified by searching the main/sub combination of 0020/0010.

By maintaining values in this configuration, the system is enhanced to differentiate the G/L account numbers on the basis of account determination IDs, thus helping in automatic determination of accounting/posting parameters at the time of security deposit postings. In the business case explained above, this configuration helps in determining and differentiating the G/L account number for the land development advance, performance bond, and maintenance bond.

Technical Changes

While you are creating a security deposit by using SAP transaction code FPSEC1 or through SAP Customer Relationship Management (CRM), the request reason code is chosen. Modification is required in SAP include LFKK_SECI01 to automatically populate the interest key on the basis of the security deposit request reason code.

Once the interest key is defaulted while creating security deposits, changes are required to ensure the G/L accounts are chosen based on the request reason. Code changes are made in FQEVENTS 800: Security Deposit: Determine Transaction and 2100: Document: Determine Account Determination Characteristic. (FQEVENT is an SAP transaction code required to identify an event. These events are standard SAP transaction codes that are available to integrate customer-specific requirements in to the SAP system without modifying an SAP program. These are enhancements provided by SAP.)

In Event 800, an IF condition should be introduced to check if the request reason code is present to pass a value as memory ID as Account Determination ID. The introduced condition reads the request reason given at the time of creation and captures it as a variable (i.e., a memory ID that is a replica of the account determination ID).

In Event 2100, read the memory ID, if assigned, and pass it to field KOFIZ (account determination ID). The change in this event reads the memory ID as account determination ID and automatically determines the G/L account that was configured in customizing.

Use of a Standard SAP Report

A standard SAP report can be generated directly by executing transaction code FPD1. The enhanced system then generates the output of this report in a way that shows the breakup of all the security deposits based on their request reasons as shown in Figure 6.

Figure 6

Output of report showing the different deposits amount and number of deposits based on the request reason

This report now shows maintenance cash bonds and performance cash bonds separately in the output after the enhancement. Earlier these types of security deposits were extracted by this report cumulatively in the land development developer advance, which was providing incorrect information to the business about the types of deposits. It is important to know the nature and amount of security deposits that a company should receive from its customers. This information also helps in determining the cause as to why the deposit is collected. This information assists companies in formulating their strategies to determine the rate of interest that is given to customers based on their request reasons and how much they owe to customers in different categories such as a request reason for a new connection, load enhancement, or security conversion.

Enhancement Benefits

Here are some of the potential benefits of using this enhanced security conversion process:

• The enhanced conversion process enables security deposit conversion from one request reason to another request reason. This results in the saving of potential manual efforts of taking multiple steps to refund the existing security deposit to the customer and creating a new deposit for another request reason for the same customer.
• Business processes and operations are optimized to capture correct accounting automatically
• Optimized use of the standard SAP security deposit report (transaction code FPD1) as this report extracts information based on request reasons
• Automatic determination of the interest key on different types of security deposits
• No need to develop customized reports
• New conversion process of security deposits from one request reason to another by using standard SAP transaction codes