The benefits companies get by knowing their cash position at their bank are obvious. Using the electronic bank statement functionality (EBS), companies can reconcile R/3 business transactions in real time with transactions that have cleared at their bank. (See the sidebar, “What EBS Does.”) Many companies that did not include the EBS functionality in their original project are now planning to implement it.

However, even with the most thought-out cash-management strategy, transactions in EBS can fail or post incorrectly for many reasons, causing users to process transactions manually after they have failed in the EBS upload. If you limit yourself to the standard configuration screens and techniques, many of these problems seem impossible to prevent or solve.

The solution is a little-known process called “search strings,” which helps increase the percentage of EBS transactions that post correctly through the EBS upload process. Many companies that have implemented EBS aren’t aware of this advanced configuration technique, which can keep problematic business transactions and scenarios from failing or posting incorrectly.

Technically, a search string is a grouping of text and special symbols that is searched for in the Note to Payee field text information sent by the bank in the EBS. Before Release 4.6B, search strings were an often-confusing combination of configuration and user exits. As of 4.6B, search strings are solely a configuration task.

You can use search strings to help your EBS upload find the correct document to clear or find the correct cost center, profit center, or business area to post to, as well as many other scenarios. This article focuses on using search strings to solve the EBS problem in which a single Bank Administration Institute (BAI)¹ code represents two totally different business transactions for a single bank.

BAI Codes

In the United States, the EBS is a flat file that uses BAI codes to transmit balance and transaction details to the receiving system. BAI codes are three-digit codes used in electronic banking files to signify different types of transactions and balances.

The BAI has done a good job of standardizing the codes. Most banks have adopted BAI file formats, such as the correct header record, detail record identifier, and trailer record.² Unfortunately, not all banking institutions have adopted the standard use of the codes as defined by BAI. To demonstrate the functionality of search strings, I’ll use sample lines from BAI files with the correct format, but differing uses of a standard BAI code 175. (See Table 1.)

The BAI specifications define code 175 as a check deposit. In my example, Bank A uses BAI code 175 as a check deposit transaction. Bank B uses BAI code 179 as a check deposit and doesn’t use BAI code 175 at all. Bank C uses BAI code 175 as both a check deposit transaction and as an incoming foreign wire deposit.

Of the three, the last scenario is the most difficult to resolve, and this is where search strings come in. The standard configuration tables require a one-to-one relationship between a BAI code and a posting rule for a given bank account. A posting rule is configured to carry a specific journal entry in R/3. For example, posting rule ZCDP might be configured to debit the confirmed cash G/L account and to credit and clear the check deposit-clearing G/L account. In the example of Bank C, the check deposit transaction for BAI code 175 should use posting rule ZCDP. However, the incoming wire deposit for BAI code 175 should use posting rule ZWDP. How can you get one BAI code to use two different posting rules? By using the EBS search string functionality.

Besides helping out in this scenario, the electronic search string functionality can be used whenever the Note to Payee field³ allows you to uniquely identify one of the following target fields:

• Posting Rule
• Business Area
• Cost Center
• Profit Center
• Account Modification
• Fees in Account Currency
• Note to Payee
• Interpretation Algorithm
• Bundle Number for Grouping Line Items
• Additional Information 1 and 2
• BDC Field and Account Types

As you can see, the Note to Payee field is available as a target field. You might ask why, if you are searching the Note to Payee field, you would want to overwrite the same field based on a search string. The answer is that in addition to the EBS configuration transactions, several user exits are available for EBS processing. Some of these user exits kick off after the search string executes. Therefore, if you are using a user exit that reads the Note to Payee field and executes after the search string, it might be useful to manipulate the field for processing your user exit.

Using the scenario for Bank C described in Table 1, I will show you how to configure search string functionality. As you can see from the BAI file excerpts in Figure 1, both types of deposits use BAI code 175 to signify different business events. However, you can differentiate between the two types by analyzing the Note To Payee field. To do this, you choose between two methods. Both are correct, but one is more efficient from a system-processing perspective.

The first option does not map BAI code 175 in the BAI code to mapping rules configuration under the EBS. Instead, you configure two electronic search strings—one to search for the check deposit text in the Note to Payee field and the second to look for the foreign wire deposit text in the Note to Payee field.

The second and more efficient option, in my opinion, is to map BAI code 175 to the check deposit posting rule in the electronic bank statement configuration. This assumes that the majority of the company’s deposits are check deposits; if the majority are wire deposits, map the BAI code to the wire deposit posting rule. You then configure a single search string to look for the foreign wire text (FRGN WIRE DEP) and change the posting rule from the check deposit posting rule to the foreign wire deposit posting rule.

Given this problem, most companies will map BAI code 175 to the check deposit transaction (since the majority of BAI 175 codes are check deposit transactions) and then correct the postings for foreign wire deposits manually.

The steps below show what happens when a search string isn’t used:

1. Transaction with BAI code 175 with FRGN WIRE DEP in the Note To Payee field is included in the EBS.
2. The EBS program tries to carry out the check deposit transaction based on the mapping of BAI code 175 to the posting rule ZCDP.
3. The transaction fails because posting rule ZCDP requires an exact dollar match in the deposit clearing account.
4. The Cash Management staff has to manually post-process this transaction making sure to select the correct posting rule and clearing item.

Instead, here’s how to configure the second option. Go to the search string configuration via IMG menu path Financial Accounting>Bank Accounting>Business Transactions> Payment Transactions>Electronic Bank Statement>Define Search Strings Electronic Bank Statement. Figure 2 shows the New Entries screen for search strings.

Figure 2

Entry screen for search strings

Configure the fields in Figure 2 as follows:

1. Srch String Name: The text entered in this field is used as the identifier (key field) for the search string.
2. Name: Enter a descriptive name for the search string in this field. This is an additional text field only, not a key field for the search string entry.
3. Search String: Enter the Note to Payee text that you are looking for in this field, in this case, FRGN WIRE DEP.

As an example of a more complex requirement that would use special characters, assume that your requirement is that the Note to Payee field say FRGN WIRE DEPOSIT, FOREIGN DEPOSIT WIRE, or vice-versa. In this more complex scenario, you enter the search string (FRGN|FOREIGN) ((WIRE DEPOSIT)|(DEPOSIT WIRE)). For the purposes of this article, I’m continuing with the simpler requirement that the Note to Payee field only contain the text FRGN WIRE DEP. See the configured search string in Figure 3.

Figure 3

Configure search string

The mapping section of the screen (along the left side) is now populated. The mapping field brings over the characters you entered in the Search string field. By default, each character is mapped to itself. Change the default mapping to the value that you want to enter or replace in your target field. Map the first four characters as ZWDP and erase the mapping for the rest of the characters. See Figure 4.

Figure 4

Change default mapping

Under the simulation section of the screen, enter test text to see how your search string and mapping will work. Click on the Test button for the results, shown in a table on the bottom of the screen in Figure 4.

Keep working with your search string until you see on the screen that you have a correct hit with all your unique business scenarios. Once your search is ready, activate it by clicking on the Search string use folder.

In the activation screen, specify the company code, house bank, and bank account for which the search string is valid. Enter an interpretation algorithm in the Int algthm field. You must enter an algorithm whether you need to use one or not. (If you are trying to find a clearing document, you need an interpretation algorithm.)

If you do not need one, choose interpretation algorithm 000: No interpretation. (See Figure 5 for valid interpretation algorithms.) However, there is a trick. If you select this option on the first attempt and then try to save your entry, you get a hard error stating that an algorithm is required. You must next select a valid algorithm and then tab over or select the next field with your mouse (do not press the Enter key). Go back to the algorithm field and select algorithm 000: No interpretation. You can now save your entry. I didn’t make this up; see OSS note 372767.

Figure 5

Select interpretation algorithm

Enter the search string (configured earlier) in Figure 5 and choose Target Fld. Click on the Activ field to activate the search string. You also have the option of entering a prefix that will be added to the beginning of your search string mapping. This feature is useful if you are looking for, and mapping, document numbers to clear. The last field, which is optional, is the ID field. If you activate the ID field, the search string is carried out only if the business partner in the transaction can be identified successfully. This setting is useful for finding customer or vendor document numbers to clear. It is not useful in this scenario. Figure 6 shows the completed activation of your search string, just one example of the numerous configuration options that exist to solve different electronic bank statement problems.

Figure 6

Completed activaton

² In the small possibility that your bank doesn’t use the BAI format, you can have your ABAP group write a pre-processing format that takes the bank file and reformats it into BAI.

³ The Note to Payee field contains text entered by your bank that is included with each transaction in the electronic bank statement.

⁴ For more detail on how to use special characters, review the SAP-provided documentation in the search string configuration via IMG. It also shows and explains special characters that can be used in mapping.