The main SAP electronic bank statement (EBS) program RFEBKA00 is the program called when you enter transaction code FF_5 to import a bank statement. Several standard enhancements have been added over the years to support a growing SAP EBS customer base. With a growing customer base comes increased demand for flexibility to accommodate a myriad of requirements, mostly stemming from variations in industry practices, bank data formats, bank reconciliation practices, and enterprise structures. When it comes to bank reconciliation processes, one size does not fit all, and built-in flexibility is essential. 

SAP enhancements give users greater flexibility than standard programs allow. Standard enhancements are intended to be strategically placed within the code to maximize their potential use in fulfilling customer-specific requirements. This is certainly the case with enhancement FEB00001.

According to SAP, FEB00001 is intended for companies to use to:

• Analyze and change clearing information for each bank transaction
• Change posting rules
• Use account modifications to influence account determinations
• Distribute postings to different batch input sessions

I discuss these uses of FEB00001in greater detail in the remaining sections, with examples given for greater emphasis.

First, I begin with a technical overview of FEB00001. Implementation of SAP enhancements is best realized with a complete understanding of the mechanics behind it. Therefore, I describe the technical makeup of FEB00001, including enhancement assignments, components, and includes. I provide real-world examples of user requirements and solutions using FEB00001 and discuss the enhancement’s relationship with other EBS functionality.

Technical Makeup of Enhancement FEB00001

To access enhancement FEB00001, execute transaction code CMOD or follow IMG menu path Financial Accounting > Bank Accounting > Business Transactions > Payment Transactions > Electronic Bank Statement > Develop Enhancements for Electronic Bank Statements (General).

Click the execute icon beside Develop Enhancements for Electronic Bank Statements (General) and you are taken to the Project Management of SAP Enhancements screen in Figure 1. To view the enhancement, you must create and activate (click the match icon circled in red) an enhancement project. Doing so is beyond the scope of this article and, here, I assume you already have an active project created.

Figure 1

The Project Management of SAP Enhancements screen

To view the enhancement in your project, click the Attributes button in the Subobjects window and click the Display button. After you access the enhancement project, two buttons appear on the next screen for Enhancement assignments and Components (Figure 2).

Figure 2

FEB00001 attributes

After you click the Enhancement assignments button, you see the assignment of enhancement FEB00001 (Figure 3). If you are creating the enhancement project for the first time, this is where you assign FEB00001 while in change mode.

Figure 3

Assign enhancement FEB00001 in an enhancement project

With FEB00001 assigned, click the Components button. Contained therein is the specific function module and user exit name (e.g., EXIT_RFEBBU10_001) as shown in Figure 4. This defaults in this screen after you assign FEB00001 to your enhancement project.

Figure 4

Components view

Double-click EXIT_RFEBBU10_001.In the screen that appears (Figure 5), click the Source code tab. In this tab key information is provided on the relevant import parameters, export parameters, and tables. Trying to do anything outside these parameters is a clear indication that you are not using the enhancement properly.

Figure 5

The Source code tab for function module EXIT_RFEBBU10_001

The tables shown in the code in Figure 5 are described in Table 1.

The following transaction codes are also used by or relevant to function module EXIT_RFEBBU10_001:

• FF_5 (import electronic bank statement)
• FEBA (bank statement subsequent processing)
• CMOD (project management of SAP enhancements)

As you can see in Figure 5, the source code tab for EXIT_RFEBBU10_001 contains Include ZXF01U01. Double-click the Include ZXF01U01. This action displays the screen shown in Figure 6 in which coding for enhancement FEB00001 is entered and activated. After ABAP code is entered, click the match icon to activate the code (Figure 6).

Figure 6

Inside Include ZXF01U01

Strategic Placement of EXIT_RFEBBU1

Function module EXIT_RFEBBU10_001 is called in program RFEBBU10 (Figure 7). Program RFEBBU10 is where bank statement information is interpreted — most notably, the Note to Payee field (FEBRE-VWEZW). It interprets the reference records from table FEBRE and transfers the clearing information to table FEBCL.

Figure 7

EXIT_RFEBBU10_001 call point in program RFEBBU10

In Figure 7 EXIT_RFEBBU010_001 is strategically placed in the code directly after filling table FEBCL. This is the table that contains clearing data for individual bank line items after interpreting bank statement reference records in table FEBRE. The placement of the exit is strategic in that it allows you to access clearing data and to change it as needed.

Implementation Examples

This section provides real-world EBS challenges and shows how FEB00001 can be used to solve them.

Change the Internal Transaction 

First, I’m going to give an overview of EBS internal and external transactions to lay the groundwork for why an internal transaction might need to be changed. The examples used are in BAI2 format.

BAI (Bank Administration Institute) format is used by some banks for transferring financial data. BAI2 is an electronic bank file format used widely in the United States. MutiCash, SWIFT, and other country-specific formats tend to be used outside the United States. BAI2 specifies the file layout, and within that layout, code 16 at the beginning of a statement line represents an individual detail transaction. Each individual 16 record is followed by a three-digit transaction code (i.e., type code) that identifies the type of transaction. These transactions are all encoded by the bank.

The problem many SAP users face is that the incoming BAI2 type codes may not have a 1-to-1 relationship with how they need to post to the general ledger (G/L) or sub-ledger. For example, in the mock BAI2 file in Figure 8, the type code 142 represents incoming Automated Clearing House (ACH) credits.

Figure 8

A mock BAI file

It’s not uncommon for a business to have multiple types of incoming ACH payments that need to be accounted for separately. This is where internal SAP posting rules come into play. Each external transaction type (i.e., BAI2 type code) is mapped, once and only once, to an internal posting rule (Figure 9).

Figure 9

Map external transactions to internal posting rules

These posting rules, in turn, determine how the bank entry is posted to the G/L (Figure 10).

Figure 10

Posting rule details

Defining posting rules is beyond the scope of this article. Suffice it to say that posting rule ZB03, which is linked to the incoming ACH type code 142, posts a debit to the G/L main bank account and a credit to a G/L sub-bank account. When you have two transactions that need to be uniquely identified for G/L posting purposes, but share a common BAI2 type code (e.g. 142), the use of FEB00001 can solve the problem.

For example, consider a scenario in which an incoming ACH (type code 142) with the string 8003762195 (Figure 11) needs to post to a different G/L sub-bank account from the other incoming ACHs that use posting rule ZB03.

Figure 11

A mock BAI2 file with incoming ACH type codes

In this example, the posting rule needs to be ZB07 instead of ZB03. This is accomplished by coding FEB00001 as shown in Figure 12.

Figure 12

Coding in FEB00001 to change the posting rule

In Figure 12, the code first looks in the bank statement header record table (i.e. FEBKO) for the house bank (i.e., field HBKID with value SUNTR). With AND conditions, it also looks in the bank statement line item table (i.e., FEBEP) for the BAI type code (i.e. field VORGC and value 142) and reference number (i.e., field VGREF and value 8003762195). If all those conditions are met, the code changes the posting rule value in field FEBEP-VGINT to ZB07.

Add Default Values 

Another common problem with EBS is that there is a required field on the G/L account field status for which no value exists in the bank statement transaction detail. The most common examples I’ve seen are with the Business Area and Segment fields.

If the incoming bank transaction is executing as a post with a clearing transaction and document splitting is active, the values should be inherited. If not, or if you need to change the value of a field instead of inheriting the value, you can do so using FEB00001.

Starting with the code in the example shown in Figure 12, you can build on it with additional logic to add a default value for Business Area (Figure 13).

Figure 13

Coding in FEB00001 for Business Area

This code adds the Business Area value of 0001 during processing of the batch data communication (BDC) and therefore defaults 0001 into the line items of the new posting. With this logic in place, as the BDC session runs, the enhancement knows that when all the conditions are met, it should populate 0001 in the Business Area field in the line item postings.

Other EBS Functions 

Over the years, additional EBS functionality and enhancements have been added. It’s a great idea, when enhancing EBS, to make sure you use the best tool for the job. Although this article is on enhancement FEB00001, I want to brief you on other EBS capabilities to ensure you make the most informed decisions possible when enhancing EBS.

When you are evaluating multiple options to solve an EBS problem, some considerations are how much time and effort are required, and how often the requirement is likely to change. As a general rule, use the most nontechnical approach. That means that if a configuration option is available, use it. The bottom line, however, is that you need to choose the solution you know will work consistently and produce the desired outcome without fail.

In the remainder of this section, I introduce you to search strings, interpretation algorithms, and document number or reference document number selection values.

Search Strings

Search strings provide functionality that allows you to search for characters in the note to payee field of a transaction, and to define target values and how they are used.

To access search strings, go to IMG menu path Financial Accounting > Bank Accounting > Business Transactions > Payment Transactions > Electronic Bank Statement > Define Search String for Electronic Bank Statement. Click the execute icon beside Define Search String for Electronic Bank Statement. This action opens the screen shown in Figure 14.

Figure 14

Search string definition

The search string definition, as shown in Figure 14, defines characters to search for in the note to payee field. The definition also contains target values. If the character string is found, the target values are used in the manner defined in the search string use.

One of the best features of search strings is the flexibility in how to use the defined target values. As shown in Figure 15, you have a host of selection options to choose from in search string use. The target value can populate payment notes, business area, profit center, and any other selection available in the drop-down list.

Figure 15

A drop-down list in search string use

The downside in using search strings is that you can only search for characters in the note to payee field, which means that the field must contain a unique character string to work with.

Interpretation Algorithms

Speaking in ancient vernacular, I’d say know thy interpretation algorithms. An interpretation algorithm is assigned to each external transaction type and is the crux of automatic clearing. In essence, it is the clearing logic for EBS.

No single mistake happens more often in EBS than assigning the wrong interpretation algorithm. Before seeking out a solution using an enhancement, make sure you understand the available interpretation algorithms and validate that you have assigned the correct ones, based on your data and clearing requirements.

SAP documentation for interpretation algorithms exists at the link provided below:

https://help.sap.com/saphelp_erp60_sp/helpdata/en/4d/c5efb40c381c36e10000000a42189b/frameset.htm

Document and Reference Document Numbers on the Selection Screen

In the selection screen of the import bank statements program (i.e., RFEBKA00), there is a section to enter parameters for document numbers (i.e., BELNR) and reference document numbers (i.e., XBLNR) as shown in Figure 16.

Figure 16

The selection screen for the import bank statements program

Values entered in BELNR and XBLNR are used for clearing purposes. Values outside the range entered are ignored and not used in clearing. These fields are used, primarily, with interpretation algorithm 001. What follows is the standard SAP documentation for this algorithm:

“001 (Standard algorithm).

Algorithm 001 interprets the values in the note to payee fields of the electronic account statement as either document numbers or reference document numbers. In the process, it checks whether the values are in the document/reference document number ranges you entered when importing the account statement. If (and only if) they are, it then tries to find the items to be cleared in the system.”

Impact on Automated Match Rates

In 1996 I walked into a large open room in the accounting department at a major grocery retailer to find a mass of accountants and clerks, all manually doing bank reconciliations. At the time, it wasn’t unusual for large companies like this retailer to have 20 to 30 different bank accounts, with most bank reconciliations being done manually.

Since then, companies have focused on reducing the number of their bank accounts, managing cash through cash concentration, improving cash forecasting, investing excess funds, and implementing ERP-based bank reconciliation. However, even with the intent focus to improve cash management, in the realm of EBS, high automated match rates don’t always come easy.

Outgoing checks are typically the easiest to match because you have a check number on the general ledger to match the check number on the bank statement. ACH transactions, incoming checks, cash, and wire transfers are more challenging to clear automatically, and a lot of companies use the document number or reference document, when possible, to match book to bank data.

Over the years, I’ve implemented electronic bank reconciliation systems at more than 15 companies. Some of the most important lessons I’ve learned to make a company successful are:.

• Focus on improving the timeliness of the business process. In large part, this translates into ensuring the timely entry of journal entries. The goal is to have all relevant accounting entries on the books (i.e., G/L) prior to importing a bank statement.

• Know the data, inside and out. Here, I’m not only referring to transactions on the G/L, but also to bank statement transactions. The US uses the BAI2 format for EBS. Educate yourself on the bank statement format in your country and make sure you understand the transaction types, addenda records, and file layouts. Your ability to achieve high EBS match rates is directly proportional to your understanding of the data.

• Use enhancement points such as FEB00001 to automatically clear the more difficult to reconcile items, if they currently require manual matching.

• Provide good documentation on the EBS process. This should include all transaction types, posting rules, and match criteria.

Reconciling bank accounts daily is a best business practice and requires vigilance in entering journal entries as close to real time as possible. Moreover, if done correctly, electronic bank reconciliations have enabled companies to achieve automated clearing rates of up to 90 percent to 95 percent, with few errors.

As with any technical tool, FEB00001 must be considered for use only in the context of other potential solutions available, such as search strings, interpretation algorithms, and document/reference document screen selections. Choosing the right tool for the solution is the only way to optimize your EBS design. Furthermore, it’s important not to use an enhancement if a configuration option is available.

The goal in EBS is to maximize automatic clearing rates. By doing so, you reduce manual effort and maximize efficiency. Use FEB00001 to resolve the hard to clear bank transactions and make sure to completely document EBS processes.

David Burns

David Burns is owner and managing partner of Prime, LLC. David has specialized in SAP Financials since 1998. Since founding Prime, LLC in 2008, he focuses on techno-functional consulting on a cross-modular basis, with a special emphasis on SAP configuration optimization and FI integration.

You may contact the author at david.burns@primepsm.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.