lockbox vishal

LOCKBOX FILE CREATION GUIDE FOR

“BAI” & “BAI2” FORMATS

(known by Bank Administration Institute only as “BAI Lockbox Communication Standards Format”)

SPECIFIC LAYOUTS AND RULES

Understanding SAP Lockbox.doc04/27/23

SAP

Overview

What is a lockbox? A company can create accounts called 'lockbox' accounts at its bank (or banks) that act as payment collection accounts for customer payments. The company then informs their customers that all open item payments for their accounts must be submitted to one of the established bank lockbox accounts. The bank collects these payments along with the customers' remittance information that indicates what open items the customer payments intend to clear. Data entry clerks at the bank manually enter the information into an electronic file for transmission to the company to which the lockbox account belongs. These files are typically transferred nightly to the various lockbox owners (companies). The files adhere to one of two customized, 30-year old Bank Administration Institute banking industry transmission formats. The original, created in 1970, was known as BAI Lockbox Communications Standards. It provided only basic payment details, without invoice details. Since that time, modifications have been made by users to this BAI Lockbox standard format and this modified version has become known as "BAI2". This new 'non Bank Administration Institute' sanctioned format now included full invoice details with payments, and is considered the ‘latest, most robust’ format for lockbox transmissions.

What is BAI? Standards for lockbox transmission files are defined by the Bank Administration Institute (BAI). Founded in 1924, the BAI organization is a partnership composed of its own BAI membership, a Board of Directors, various banking industry advisory groups and a professional staff. The organizational mission is "to help bank administrators achieve high levels of professional effectiveness and to help solve significant banking problems." Activities include the definition of industry file formats, such as for lockbox transmissions. BAI and BAI2 are the two defined lockbox transmission formats, however, both are considered 'outdated' by the BAI organization and are no longer 'actively' supported (ie. standards are no longer updated or improved). Nonetheless, many banks still offer transmissions in the two different ‘BAI Lockbox Communications Standards’ formats.

What is the difference? As defined by SAP, as well as by the lockbox staff at most banks, BAI and BAI2 formats differ in their level of information detail. ‘BAI’ format does not separate out the incoming check line items by invoice subtotal reference. Instead, one check total amount simply has all invoices listed underneath it. Thus, in BAI format files, the entire check amount must match perfectly (or within configured payment difference tolerances) the total amount for all invoices listed. Otherwise, the entire check will enter into SAP as:

1. an "On account" posting (if the payment and invoice totals don't match, but a customer is identified by MICR), or

2. an "Unprocessed" posting (if no customer account and documents could be identified from the transmission).

In these scenarios, your Accounts Receivable cash application clerks will have to perform semi-manual post-processing application within SAP to clear unmatched payments against open items on the proper accounts.

Conversely, ‘BAI2’ format splits the check total into separate invoice references and associated payment amounts. Thus, within a large batch, BAI2 format files will allow a "Partially applied" status in which some identifiable payments within the check total will be matched and cleared, others will land on account. As a result, your 'hit rate' percentage of payment-to-invoice matching from each transmission is likely to be higher when using ‘BAI2’ rather than ‘BAI’ formats.

HOWEVER -- the term 'BAI2' means something very different to the Bank Administration Institute than it does in SAP or common lockbox bank terminology. The 'real' BAI2 format actually denotes the ‘Cash Management Balance Reporting Specifications, Version 2.’ As a result, if you are to contact the BAI organization with questions about your lockbox transmissions, be sure to mention that your 'BAI2' format is actually the BAI Lockbox Communications Standards format (using invoice details), otherwise they will assume you are speaking about the Cash Management Balance Report.

What format should you use? This decision is dictated by a cost-benefit analysis. ‘BAI2’ is a more robust file format, but you pay more for this information richness. ‘BAI’ is cheaper, but may not offer you a suitable 'hit rate' for automatically matching payments to customer open items. If you receive a large volume of lockbox payment transmissions each day, especially if many items are paid per single check and deductions occur commonly, it is recommended that you use BAI2. Otherwise, a significant portion of your A/R staff time and effort will be spent on applying failed lockbox payments. However, if you only receive a small portion of your customer payments via lockbox transmissions, then BAI format is likely to provide adequate results. You will have to inquire with your bank to ensure that they still utilize the ‘BAI’ format.

If you have further questions about the Bank Administration Institute, or its file format standards, you can reach them by phone at 800-224-9889, or on the Internet at http://www.bai.org. The primary contact at the Bank Administration Institute is Mr. Brian Black, Managing Director or Operations and Technology.


THE PURPOSE OF THIS DOCUMENT:

The lockbox file generation programs within SAP (RFEBLBT1 and RFEBLBT2) are designed to create their own open items in the system, and create the corresponding lockbox file that perfectly matches these open items. The result is that the open items are completely cleared by the program. This is useful for illustrating the basic function of reading a basic lockbox file. However, for consultants to test their client’s own unique, complex lockbox import and postprocessing scenarios, a more flexible method of lockbox file creation is needed.

This document is designed to do two things:

1. To clearly explain the elements of a lockbox file (in both the so-called ‘BAI’ and ‘BAI2’ formats)

2. To help consultants to design their own custom lockbox files which enable them to test numerous business scenarios in a quick, repeatable fashion.

At the end of this document are several different examples of .txt files that illustrate how each file can be modified to test different business scenarios. The specific lockbox files in this document were designed as part of the creation of lockbox pre-configuration for the 4.5A release. These files may be modified as often as you need to test each scenario. There are also a few configuration tips included at the back of the document that relate to how to maintain file format consistency with what is defined within lockbox configuration.

This document is written using color-coding to allow easier reading and interpretation of the data than if using variable fonts, underlining, etc. If you intend to print out this document for your reference, you will need to use a color printer. However, the fields also contain number assignments, so a black and white printout will still be readable.

FOR BAI2 FILE FORMAT INFORMATION, SKIP TO PAGE 11 FOR A SAMPLE TRANSMISSION BAI2 FILE FORMAT.


LOCKBOX BAI TEMPLATE FOR USE WITHIN THE LOCKBOX DATA IMPORT PROGRAM

Sample Lockbox file:

100DC026 79960 99102012012DC026 799605001001 79960991020 DC026 7996060010020001000000011000390997755331 00091230218000019 18000020 18000021400100360171800002218000023 18000024 18000025 18000026 18000027400100460191800002870010050012345981215010000100000080010060012345981215001000010000009 1000000 10000009000010Note: this file illustrates a scenario in which only one lockbox transmission is imported, and only one batch exists within that lockbox transmission. A lockbox import file may contain several different lockbox transmissions (from different banks) each contained between their own 1 and 9 records. Further, multiple batches can exist within a single lockbox. The original Bank Administration Institute’s BAI Lockbox Communications Standards format offer records 1 through 9. SAP only requires minimally the 1, 5, 6 and 4 records to function properly. You may choose to include other records simply to ‘visually differentiate’ the data sections within a transmission for later problem resolution if necessary.

The following pages provide a breakdown of the lockbox file components. By identifying what elements go in which place, you can insert your own specific MICR (Magnetic Ink Character Recognition) numbers and invoice numbers, lockbox number, date, payment amount(s), check number(s), and batch numbers to create a valid test file. The record data is color-coded below to make it easier to interpret this file. All files should be saved in a text tab-delimited format (.txt). Next to each Record Name is the (SAP Table Name) within parentheses. At the end of each record field description is the (Field Name) in gray font color within parentheses.

KEY:* Items you must change each time you run the lockbox with this file. * a conditional change item.

Record 1: (Table FLB01) 1 2 3 4 5 6 7

100YPCCDESTINYPCCORIGIN98121512010000011111222223333344444555556666677777888 * * * * 1. This is the first record of the Lockbox. The item in blue is the Record Type indicator.

There will only be one Record Type 1 per Lockbox within the file. (If your transmission contains 5 lockboxes, you will see 5 ‘1’ records in the file). Record Type 1 is the “Lockbox Header Record”. (Field name HR001)

2. The item in green is the Priority Code of the Lockbox. This item will have 2 characters (must fill both spaces, i.e. “1” is “01”). This is often left as ’00’ by banks, and is of no importance to SAP in processing. (Field name HR002)

3. The item in dark red is the Immediate Destination for the Lockbox. This will contain up to 10 characters (use spaces to fill up excess space if less than 10 characters exist in this item). Change this item if you want a different lockbox. The same goes for


the next item. It is recommended to left justify the value and blank-pad right. (Field name HR003)

4. The next item in black is the Origin of the Transmission – transit routing. This item may contain up to 10 characters (again filling up all ten spaces.) Both the Destination and Origin fields are required to help the SAP system identify the proper lockbox and company code in which to perform cash postings. (Field name HR004)

5. & 6. Following that are the File Date in dark blue and the File Time in purple. They will have six and four characters respectively. The program will require that the time be different for each running of the same lockbox number in the same day. Be sure to change the lockbox file date in order to reflect the transmission date of the simulated lockbox file. If you are using the same date on multiple files, you will have to be sure to change the transmission time. (Field name HR005, HR006)

7. The remainder of the record is made up of 47 characters of filler (or blank spaces) marked here in gray. SAP lockbox processing does not care about this field. (Field name HR007)

The total length for this Record 1 is 80 characters. Spacing is critical because the Lockbox program reads the file based on character position. Therefore, use spaces or zeros to make up the excess space not used by an item within the record. For example, if your Origin of Transmission only uses 8 characters, then it should be preceded by two blank spaces. If the spacing is off in any of the records, the program will misread the file and your lockbox process will fail. However, if no data is transmitted in the last field, nothing needs to be entered here.

Record 2: Table FLB021 2 3

2YPCCDESTINYPCCORIGIN * *

1. The item in blue is the Record Type indicator. Record 2 is the “Service Record”. From an SAP perspective, the 2 Record is not a mandatory record for lockbox importing. Some banks will utilize a 2 Record, others will not. Sometimes the information contained within this record will not adhere to the ‘proper’ definition, but rather be a restatement of the Record 1 (as shown above). If used, there can only be one Record Type 2 per lockbox transmitted in the file. There can be many lockbox transmissions within a single file, thus many 2 Records within the file. (Field name SR001)

2. The item in green is the lockbox Destination/Origin reference code. This item will have 2 characters. (Field name SR002)

3. The item in dark red is the Reference Code for the lockbox. It is not generally used, but may be filled with information. This will contain up to 10 characters. (Field name SR003) Because the SAP lockbox program does not read this record, you can really put anything you wish in this record – even if it does not adhere to the ‘specifications’. Such an example is displayed above.

NOTE: SAP does not need the next five fields, but they are listed here for info. The next item in this format is the Service Code for the lockbox, which the banks use

for their own purposes to identify the transfer as a lockbox transfer. This item will use 3 characters/spaces. (Field name SR004)

Following that is the Record Length, which will use 3 characters/spaces. (Field name SR005) Next is the Block Size of the lockbox (3 characters/spaces). (Field name SR006) The Format Code for the lockbox follows in order(1 characters/spaces). (Field name SR007) The remainder of the record is made up of 40 characters of filler. (Field name SR008)

The total length for this record is 80 characters. Be sure to pay attention to spacing!


Record 5: Table FLB051 2 3 4 5 6 7 8

50010010012345981215YPCCDESTINYPCCORIGIN1111122222333334444455555666667777788888 * * * * * * 1. The item in blue is the Record Type indicator. There will only be one Record Type 5 per

batch within each lockbox batch transmitted in the Lockbox file. Record 5 is the “Detail Header Record”. There can be many batches in a lockbox transmission, thus many 5 Records in each lockbox in the transmission. (Field name DH001)

2. The item in green is the Batch Number for the Lockbox. This item will have 3 characters. If you run this particular lockbox numerous times in the same day, you must change the batch number – the system will not allow the same batch to be input twice in the same day. As for ‘real’ bank transmissions, the individual bank will define how many checks may be included per ‘batch’ within a lockbox. It is commonly between 25 and 50 checks. As such, when more than 50 checks are sent in a given lockbox on a single day, there will be at least 2 batches built into the transmission for that particular lockbox. (Field name DH002)

3. The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 spaces). (Field name DH003) This is a sequential numbering of each item (line) within a batch. Batch size (number of checks per batch)is defined between the customer and the bank. A common rule is that one batch may contain up to 50 invoices. Thus, when more than 50 invoices are included in a lockbox transmission, a second batch will be created. One lockbox transmission may contain up to 999 batches.

4. The next item in black is the Lockbox Number. This item will use 7 characters/spaces. (Field name DH004) The lockbox number only needs to change if you are testing a transmission from a new lockbox, or if the transmission contains information from several lockboxes all in one file, you must be sure to change the lockbox number in the appropriate section of the file.

5. Following that is the Deposit Date in dark blue, which will use 6 characters/spaces.(Field name DH005)

6. In purple is the Immediate Destination of the Lockbox (10 characters/spaces). (Field name DH006)

1. In dark yellow is the Origin of Transmission – transit routing (10 characters/spaces). (Field name DH007) AN IMPORTANT NOTE: it has been a recent trend (due to mergers) that some large banks are now moving to 13-digit customer bank account numbers. As a result, you have two options (until SAP makes table/field changes to increase the size of the account field): ask your banks to ‘concatenate’ the number back to a 10-digit number, or make your own field length modification to the related Data Element REID2_FLB with SAP registration. Both carry their own inherent risks, but it is probably best to make a field length change and protect the change until the standard field length is changed by SAP.

7. The remainder of the record is made up of 40 characters of filler in gray. (Field name DH008)


Record 6: Table FLB061 2 3 4 5 6 7 8 9 10 11

6001002000100000001100039099775533100091230218000019 18000020 18000021 01234 * * * * * * * * *2. The item in blue is the Record Type indicator. Record Type 6 can appear numerous times

in the Lockbox file. Record 6 is the “Detail Record” which applies to a particular check in the Lockbox. (Field name DR001) When you have a new check, or a new customer’s information within the same batch, you will create another Record 6.

3. The item in green is the Batch Number for the Lockbox. This item will have 3 characters. As mentioned before the batch number must change when done consecutively in the same day. (Field name DR002) The bank sets the rules for how a batch is defined. For example, some banks will deliver up to a maximum of 50 checks in one batch. If there are 51 checks in a lockbox, thus there would be at least 2 batches.


4. The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 spaces). (Field name DR003)

5. The next item in black is the Remittance Amount for the Lockbox Record. This item will use 10 spaces (use zeros if necessary in front of the amount). (Field name DR004)

6. Following that is the Remitter Identifier: Transit Routing No. in dark blue, which will use 9 characters/spaces. The standard delivered SAP lockbox allows for only a 9-digit bank account number. As with any field that you may need elongated, you will have to submit a modification request for an ABAP consultant to change the number of characters allowed in the field. Such a change must be ‘monitored and protected’ when performing SAP Legal Change Pack implementations or version upgrades.

7. In purple is the Remitter Identifier: Account Number (10 characters/spaces). It complements the Transit Routing No. element of the lockbox identification in what is known commonly as the “MICR” data (Magnetic Ink Character Recognition). This is the data that appears at the bottom of bank checks. Together, they provide a unique identification of the customer sending in the payment. AN IMPORTANT NOTE: it has been a recent trend (due to mergers) that some large banks are now moving to 13-digit customer bank account numbers. As a result, you have two options (until SAP makes table/field changes to increase the size of the account field): ask your banks to ‘concatenate’ the number back to a 10-digit number, or make your own field length modification to the related Data Element REID2_FLB with SAP registration. Both carry their own inherent risks, but it is probably best to make a field length change and protect the change until the standard field length is changed by SAP.

8. In dark yellow is the Check Number (9 characters/spaces). This item must change each time you run a batch. (Field name DR007)

9. ,10., & 11. In bright red are the Invoice Numbers (10 characters/spaces each). According to SAP table definition, a maximum 3 invoices can fit into the Record 6. Any extra invoices in that check and lockbox batch must be provided in a subsequent Record 4 that follows immediately after the Record 6. Be careful to check that the invoice numbers are correct, and in the proper spaces. (If you are using SAP document number length of less than 10 digits, it is recommended that you use a left-justified, blank-padded right field value convention (as displayed in the sample Record 6).

12. The remainder of the record is made up of at least 5 characters (depending upon how many invoices are in this record) of filler in gray. (Field name DR011) If the DR006 field (Account number) is expanded later to accommodate more characters, then the number of ‘filler’ characters will be reduced to fit within the total 80 character record limit.


Record 4 Table FLB041 2 3 4 5 6 7 8 9 10 11 12 13

4001003401718000022 18000023 18000024 18000025 18000026 1800002700000 * * * * * * * *1. The item in blue is the Record Type indicator. Record Type 4 can appear numerous times

in the Lockbox file. Record 4 is the “Overflow Record” and it is used to hold invoices beyond the 3 that can be held in the preceding Record 6 for a particular invoice. (Field name OR001)

2. The item in green is the Batch Number for the Lockbox. This item will have 3 characters. (Field name OR002)

3. The item in red is the Record Type identifier(1 character). This record is the overflow record (4 Record) holding the overflow from the 6 Record, and thus the number is a 6 to indicate where its overflow originates. It holds all extra invoices overflowing from the maximum of three allowed in the 6 Record. (Field name OR003)

4. Bright green is the Sequence Number for the record (2 characters). (Field name OR004)5. The item in yellow is the End Indicator for the Lockbox. A ‘9’ indicates the last

record of a Lockbox (1 character). (Field name OR005)6. – 12. The next items in black are the Invoice Numbers (10 characters/spaces each). A

maximum of six invoices can fit into the 4 record. If there are more than nine invoices being sent in one check, you will have to use consecutive 4 Records to handle the overflow. For example, if twelve invoices arrive in one check, three will be held in the 6 Record, six on the 4 Record, and the remaining three on a second 4 Record. (Field


name OR006-OR012) If you are using SAP document number length of less than 10 digits, it is recommended that you use a left-justified, blank-padded right field convention (as displayed in the sample Record 4).

13. The remainder of the 4 Record is made up of at least 9 characters (depending upon how many invoices are in this record) of filler in gray. SAP does not read any of these characters (Field name OR013) .


Record 7: Table FLB071 2 3 4 5 6 7 8

700100500123459812150100001000000000000000000000000000000000000000000000000 * * * * * *

1. The item in blue is the Record Type indicator. Record Type 7 appears only once per batch in the Lockbox file. Record 7 is the “Batch Total Record” which signifies the end of the batch within the lockbox. If you have five batches in a lockbox, you will have five 7 Records. (Field name DH001)

2. The item in green is the Batch Number for the Lockbox. This item will have 3 characters. (Field name DH002)

3. The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 character spaces). (Field name DH003)

4. The next item in black is the Lockbox Number (7 characters/spaces). (Field name DH004)5. Following that is the Lockbox Deposit Date in dark blue, which will use 6

characters/spaces. (Field name DH005)6. In purple is the Number of Remittances Indicator (3 characters/spaces) for the batch

within the lockbox. This should change based on the number of remittances in the lockbox file. (Field name DH006)

7. In dark yellow is the Remittance Dollar Total for this Lockbox (10 characters/spaces – fill with spaces or zeros to take up space). These items should be changed to reflect the batch totals from the checks on the 6 Records in the lockbox. (Field name DH007)

8. Filler spaces or characters may take up the remaining 47 positions. (Field name DH008)

Record 8: Table FLB081 2 3 4 5 6 7 8 9 10 11

800100600123459812150010 10000009 1000000 10000001111122222333334444455 * * * * * * * * *1. The item in blue is the Record Type indicator. Record Type 8 appears only once in the

Lockbox file. Record 8 is the “Service Total Record” which signifies the end of all Lockbox bundles. (Field name ST001)

2. The item in green is the Batch Number for the Lockbox. This item will have 3 characters. (Field name ST002)

3. The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 spaces). (Field name ST003)

4. The next item in black is the Lockbox Number (7 spaces). (Field name ST004)5. Following that is the Lockbox Deposit Date in dark blue, which will use 6 spaces. T005)6. In purple is the Number of Remittances Indicator (4 spaces). This should change based

on the number of remittances in the lockbox file. (Field name ST006)7. In dark yellow is the Remittance Dollar Total for this Lockbox (10 spaces – fill with

spaces or zeros to take up space). These items should be changed to reflect the batch totals from the 4 and 6 records in the lockbox. (Field name ST007)

NOTE: SAP does not require any entries in the fields that are listed below:8. In bright red is the Last Record Indicator(1 space). A ‘9’ indicates the end of the

record. (Field name ST008)


9. – 10. Also in dark yellow are the TM Amount and MTD Amount for the Lockbox (11 spaces each). (10) These are not often utilized by the customer, but are delivered in standard SAP. They can be left blank, or populated with the lockbox remittance total dollar amount.

11. The remainder of the record is made up of 22 characters of filler in gray. (Field name ST011)


Record 9:1 2 3

900001085555555555555lkjasflkj5898800000000000000000000000000000000000000000000 *1. The item in blue is the Record Type indicator. Record Type 9 appears only once in the

Lockbox file. Record 9 is the “Trailer Record” which signifies the end of the Lockbox file. In a file with multiple lockbox transmissions from separate banks, there will be a 9 Record at the end of each transmission. (Field name TR001)

2. The item in green is the Number of Records indicator. This item will have 6 characters. (Field name TR002)

3. Following this record item, there will be a Filler Record of 73 spaces, which can be either filled with characters or left blank. (Field name TR003)

AGAIN – SAP ONLY NEEDS TO HAVE THE 1, 5, 6, and 4 RECORDS – ALL OTHERS ARE ONLY FOR INFORMATION PURPOSES…

NOTES:

1. Whenever you load a particular Lockbox number into bank storage by running the Lockbox program, it will not allow you to run the same Lockbox number at the same time on the same date. Thus, you will have to: a.) change the File Creation Time, b.) change the Lockbox batch number, and c.) change the check numbers.

2. You must be sure to use different Invoice Numbers each time you run the Lockbox file, otherwise the payments will be identified as being already cleared and thus placed “on account”.

3. When a Lockbox file fails, and the item is left “on account” and a payment advice is created, you will have to remove the payment advice by performing lockbox post-processing and clear the item off the account, or else your next Lockbox run will also not apply itself because a payment advice and cash exist on the account to clear the open item(s).

4. When lockboxes fail, they need to be processed under Lockbox Postprocess (FLB1). You will identify the lockbox you just ran by the batch number, and the component items by check number.

Be very careful when making new data entries into the file to ensure that you observe the spacing rules – otherwise you will have data misread by the program and no payments will be applied.

‘BAI’ format issues:

When the customer pays at gross, despite being entitled to discounts under the payment terms, the lockbox will not ignore the payment terms to allow the payment at gross to be applied. It will treat the payment difference as being outside of customer tolerance limits (if the tolerance is not large enough to handle the difference) and post the payment onto the customer account.

All deductions taken in a ‘BAI’ transmission must be manually processed through post-processing, whereas in ‘BAI2’ format all items can be paid with deductions referenced and accompanied by deduction reason codes (using external reason code conversion).


LOCKBOX BAI2 TEMPLATE FOR USE WITHIN THE LOCKBOX DATA IMPORT PROGRAM

Sample Lockbox file:

100YPCCDESTINYPCCORIGIN98121512022YPCCDESTINYPCCORIGIN50020010012345981215YPCCDESTINYPCCORIGIN60020020000090000011000390556677889 0102034194002003601716000002 00000100000000000000gh4002004602918000018 00001000000000000000gh70020050012345981215002000009000080020060012345981215000200000900009 0090000 00900009000002

The Principle: What is different between the ‘BAI’ and ‘BAI2’ formats?

In the BAI format, the file can use the “6 Record” to hold the first three invoices, and consecutive “4 Records” to hold the overflow of up to 6 invoices each, per check. The payment amount is given for that entire check, not for each individual invoice as well as the check payment total.

The BAI and BAI2 formats use the same record types and formats for Records 1, 2, 5, 7, 8, and 9.

In the BAI2 format, the file uses the “6 Record” as an identifier of the check dollar amount(net), the MICR number and the check number. No invoices are contained in this record. Following the “6 Record” are a series of “4 Records” which contain one invoice each, providing the invoice number, invoice open item amount (gross), deduction amount and external reason code.

This level of detail in the BAI2 record improves the “hit rate” for the lockbox program. Thus, it costs more. Why? Because the bank has its clerks enter in more information into the file, which takes more time/effort. However, cost-benefit analysis should be performed by each customer to justify the decision.

The following pages provide a breakdown of the lockbox BAI2 file components. By identifying what elements go in which place, you can insert your own specific MICR and invoice numbers, lockbox number, date, payment amount(s), check number(s), and batch numbers to create a valid test file. The record data is color-coded below to make it easier to interpret this file. All files should be saved in a text tab-delimited format (.txt).

* All items marked with an asterisk are items that you will change each time you run the lockbox with this file.

* A red asterisk indicates a conditional change item.

Record 1: Table FLB011 2 3 4 5 6 7

100DC026 79960 9910200012 (customer-specific format example)100YPCCDESTINYPCCORIGIN981215120200000111112222233333444445555566666777778888899

* * * *1. This is the first record of the Lockbox. The item in blue is the Record Type indicator.

There will only be one Record Type 1 in the Lockbox file. Record Type 1 is the “Header Record”. (Field name HR001)


2. The item in green is the Priority Code of the Lockbox. This item will have 2 characters (must fill both spaces, i.e. “1” is “01”). (Field name HR002)

3. The item in dark red is the Immediate Destination for the Lockbox. This will contain up to 10 characters (use blank spaces to fill up excess space if less than 10 characters exist in this item). Most customers use left-justified, blank-padded right format.(Field name HR003)

4. The next item in black is the Origin of the Transmission. This item may contain up to 10 characters (again filling up all ten characters/spaces). Most customers will use left-justified, blank-padded right format. (Field name HR004)

5. – 6. Following that are the File Date in dark blue and the File Time in purple. They will have six and four characters respectively. The date is in YYMMDD format and time is in HHMM format. (Field name HR005)

7. The remainder of the record is made up of 47 characters of filler in gray. (Field name HR006)

The total length for this record is 80 characters. Spacing is critical because the Lockbox program reads the file based on character position. Therefore, use spaces or zeros to make up the excess space not used by an item within the record. For example, if your Origin of Transmission only uses 8 characters, then it should be followed by two blank spaces. Most customers do not need the values in HR006.

Record 2: Table FLB02

------SAP Lockbox DOES NOT NEED TO USE RECORD 2 -----1 2 3

2YPCCDESTINYPCCORIGIN * * 1. The item in blue is the Record Type indicator. Record 2 is the “Service Record”. From

an SAP perspective, the 2 Record is not a mandatory record for lockbox importing. Some banks will utilize a 2 Record, others will not. Sometimes the information contained within this record will not adhere to the ‘proper’ definition, but rather be a restatement of the Record 1 (as shown above). If used, there can only be one Record Type 2 per lockbox transmission. There can be many lockbox transmissions within a single file, thus many 2 Records within the file. (Field name SR001)

2. The item in green is the lockbox Destination/Origin. This item will have 2 characters. (Field name SR002)

3. The item in dark red is the Reference Code for the lockbox. It is not generally used, but may be filled with information. This will contain up to 10 characters.(Field name SR003)

NOTE: SAP does not need the next five fields, but they are listed here for info. The next item in this format is the Service Code for the lockbox, which the banks use

for their own purposes to identify the transfer as a lockbox transfer. This item will use 3 characters/spaces. (Field name SR004)

Following that is the Record Length, which will use 3 characters/spaces. (Field name SR005) Next is the Block Size of the lockbox (3 characters/spaces). (Field name SR006) The Format Code for the lockbox follows in order(1 characters/spaces). (Field name SR007) The remainder of the record is made up of 40 characters of filler. (Field name SR008)


Record 5: Table FLB 051 2 3 4 5 6 7 8

501200179960 991020DC026 79960 (customer-specific format example)50020010012345981215YPCCDESTINYPCCORIGIN11111222223333344444555556666677 * * * * * *1. The item in blue is the Record Type indicator. There will be one Record Type 5 in each

batch within the Lockbox file. Record 5 is the “Detail Header Record”. There can be many batches in a lockbox transmission. If there are four batches, there will be four 5 Records. (Field name DH001)



3. The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 spaces). (Field name DH003)

4. The next item in black is the Lockbox Number. This item will use 7 spaces. Most customers prefer to have the number left-justified and blank-padded right. However, the bank may require that you include significant ‘leading zeros’ if that is part of their own internal lockbox numbering scheme. (Field name DH004)

5. Following that is the Deposit Date in dark blue, which will use 6 spaces. (Field name DH005)6. In purple is the Immediate Destination of the Lockbox (10 chars/spaces). Most customers

will use left-justification and blank-padding right. (Field name DH006)7. In dark yellow is the Origin of Transmission – transit routing (10 chars/spaces). DCI

will use left-justification and blank-padding right. (Field name DH007) 8. The remainder of the record is made up of 40 characters of filler in gray. DCI will not

use this field. (Field name DH008) The total length for this record is 80 characters. Be sure to pay attention to spacing!


60120020001800000051000020321654987 CK991412 (customer-specific format example)60020020000090000011000390556677889 010203412 * * * * * *1. The item in blue is the Record Type indicator. Record Type 6 can appear numerous times

in the Lockbox file or in each batch, but only once per check. A new 6 Record marks the start of a new item number. Record 6 is the “Detail Record” which applies to a particular check in the Lockbox. (Field name DR001)

2. The item in green is the Batch Number for the Lockbox. This item will have 3 characters. (Field name DR002) The bank sets the rules for how a batch is defined. For example, some banks will deliver up to a maximum of 50 checks in one batch. If there are 51 checks in a lockbox, thus there would be at least 2 batches.

3. The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 spaces). (Field name DR003)

4. The next item in black is the Remittance Amount for the Lockbox Record. This item will use 10 characters/spaces (use zeros if necessary in front of the amount).(Field name DR004)

5. Following that is the Remitter Identifier: Transit Routing No. in dark blue, which will use 9 characters/spaces. (Field name DR005)

6. In purple is the Remitter Identifier: Account Number (10 characters/spaces). In the event that account numbers are less than 10 digits, customers will use left-justification and blank-padding right. (Field name DR006) AN IMPORTANT NOTE: it has been a recent trend (due to mergers) that some large banks are now moving to 13-digit customer bank account numbers. As a result, you have two options (until SAP makes table/field changes to increase the size of the account field): ask your banks to ‘concatenate’ the number back to a 10-digit number, or make your own field length modification to the related Data Element REID2_FLB with SAP registration. Both carry their own inherent risks, but it is probably best to make a field length change and protect the change until the standard field length is changed by SAP.

7. In dark yellow is the Check Number (9 characters/spaces). If the customer’s check number is greater than 9 characters, then customers will request the last 9 characters of the check number in this field. (Field name DR007)

After the check number is the Data Element for the Article field, a user-defined field. The total length for this record is 35 characters. You may use dummy numbers to fill out this record, or you may leave it blank. It’s best not to use this field. Further, if the customer account number (DR006) is expanded to accommodate account numbers of greater than 10 characters, then this final field will be encroached upon. (Field name DR008)


Record 4: Table FLB241 2 3 4 5 6 7 8 9 10

401200360171800000041 00006000000000000000 (customer-specific format example)401200440171800000065 00012000000000000000 “

4002003401716000002 000001000000000000004002004402918000018 00001000000000000000gh * * * *1. The item in blue is the Record Type indicator. Record Type 4 can appear numerous times

in the Lockbox file. Record 4 is the “Item Record” and it is used to hold one invoice each. (Field name OR001)

2. The item in green is the Batch Number for the Lockbox. This item will have 3 characters. (Field name OR002)

3. The item in red is the Batch Item Number for the Lockbox. This item will have 3 characters/spaces. (Field name OR003)

4. The item in purple Type of Overflow record (1 space). In this case, it is a ‘4 record’ because it contains only its own item, not an item overflowed from a preceding 6 Record. SAP does not pay particular note to the value in this field. (Field name OR004)

5. Bright green is the Sequence Number for the record (2 spaces). SAP does not pay particular note to this field. (Field name OR005)

6. The item in yellow is the End Indicator for the Lockbox. A ‘9’ indicates the last record of a Lockbox (1 space). SAP does not pay particular note to this field. (Field name OR006)

7. The next items in black are the Invoice Numbers (16 characters/spaces each). Only 1 invoice is placed into each 4 Record. (Field name IVCNR) The best field format convention would be to use left-justification, blank-padding right for the invoice number(as shown in the Record 4 above). Customers will sometimes receive payments for SAP document numbers (10-digit) and also legacy system invoice numbers.

8. In dark yellow are the Payment Amounts per invoice (10 chars/spaces). (Field name PYAMT)9. The items in gray are the Deduction Amounts per invoice (10 chars/spaces). Customers

will not use these fields. (Field name DDAMT)10. Dark Blue is the External Reason Code for the payment. Customers do not have to use these fields. (Field name RESTG)

Up to the next 30 character spaces are available for short text. They may be left blank if desired. Most customers will not use these fields (Field name OR011)


701200579960 9910200020001800000 (customer-specific format example)

700200500123459812150020000090000 * * * * * *1. The item in blue is the Record Type indicator. Record Type 7 appears only once per

batch in the Lockbox file. Record 7 is the “Batch Total Record” which signifies the end of the batch within the lockbox. If you have five batches in a lockbox, you will have five 7 Records. (Field name DH001)


3. The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 character spaces). (Field name DH003)

4. The next item in black is the Lockbox Number (7 characters/spaces). Customers will often use a left-justified and blank-padded right value. (Field name DH004)

5. Following that is the Lockbox Deposit Date in dark blue, which will use 6 characters/spaces. (Field name DH005)


6. In purple is the Number of Remittances Indicator (3 characters/spaces) for the batch within the lockbox. This should change based on the number of remittances in the lockbox file. (Field name DH006)

7. In dark yellow is the Remittance Dollar Total for this Lockbox (10 characters/spaces – fill with spaces or zeros to take up space). These items should be changed to reflect the batch totals from the checks on the 6 Records in the lockbox. (Field name DH007)

Filler spaces or characters may take up the remaining 47 positions. Customers don’t often use this field. (Field name DH008)

Record 8: Table FLB081 2 3 4 5 6 7 8 9

801200679960 99102000020001800000 (customer-specific format example)

80020060012345981215000200000900009 0090000 0090000 * * * * * * * * 1. The item in blue is the Record Type indicator. Record Type 8 appears only once in the

Lockbox file. Record 8 is the “Service Total Record” which signifies the end of all Lockbox bundles. (Field name ST001)

2. The item in green is the Batch Number for the Lockbox. This item will have 3 characters. (Field name ST002)

3. The item in dark red is the Batch Item Number for the Lockbox. This will contain up to 3 characters (and must fill all 3 spaces). (Field name ST003)

4. The next item in black is the Lockbox Number (7 characters/spaces). (Field name ST004)5. Following that is the Lockbox Deposit Date in dark blue, which will use 6

characters/spaces. (Field name ST005)6. In purple is the Number of Remittances Indicator (4 characters/spaces). (Field name ST006)7. In dark yellow is the Remittance Dollar Total for this Lockbox (10 characters/spaces –

fill with spaces or zeros to take up space). (Field name ST007)

The following fields in the file are optional – the file will function without any data provided in these fields, although they may appear in some files and thus will be read:

8. Last Record Indicator(1 space): A ‘9’ indicates the end of the record. (Field name ST008)9. TM Amount and MTD Amount for the Lockbox (11 spaces each). (Field name ST009-ST010)10. The remainder of the record is made up of 22 characters of filler in gray.

(Field name ST011) The total length for this record is 79 characters. Be sure to pay attention to spacing!

SAP does not require that these fields be filled in.

Record 9:1 2 3

900001085555555555555lkjasflkj5898800000000000000000000000000000000000000000000

1. The item in blue is the Record Type indicator. Record Type 9 appears only once in the Lockbox file. Record 9 is the “Trailer Record” which signifies the end of the Lockbox file. (Field name TR001)

2. The item in green is the Number of Records indicator. This item will have 6 characters. (Field name TR002)

3. Following this record item, there will be a Filler Record of 73 spaces, which can be either filled with characters or left blank. (Field name TR003)

Following this record item, there will be a Filler Record of 73 spaces, which can be either filled with characters or left blank. (Field name TR003)


Closing notes:

In the beginning, it is usually easiest to have the Lockbox program look for the lockbox file in the pathway C:\temp\ . If you are using the lockbox to test scenarios, it is advisable to use the same base file name and simply modify the name with a unique end identifier, ie. saplockboxbai-a.txt ; saplockboxbai-b.txt; and so on… Eventually, when you intend to test the ability to acquire the file from the network, place the file into the directory and network drive that will hold your lockbox file as imported from the bank transmissions into the mainframe.

When you run the lockbox program, it is advisable to have a program variant set up for running your files. Give it a default file name that you must modify for running each file. Otherwise, it will perceive that it has already read the file. Thus, it may be best to simply enter in: c:\temp\saplockboxbai- . Then each time, enter in the a.txt, or the b.txt.

Attached with this file are several sample ‘BAI’ and ‘BAI2’ format lockbox files. Each one must be spaced properly for testing various scenarios. Make sure that the spacing remains the same when you input new file information, otherwise the program will not read the file properly.

The type of scenario will be listed above the actual file. Simply copy the file (Records 1 through 9) and paste into another new MS Word document or text editor screen. Verify that the spacing is correct (by reviewing your file with the earlier field definition information) before running the program with this file. Enter in your own specific origin, destination, date, time, lockbox, invoices, check numbers and amounts in your file. Save the file as a .txt file which the lockbox program can read to help you test out various scenarios for your lockbox configuration. Follow the logic in this document to make the necessary changes for your own scenarios.

Later on, when running the lockbox in production, it is always advisable (security and data integrity) that you receive the file into a mainframe/UNIX environment and then set the lockbox program up to import from this location. For testing, reading from the hard drive or a local network drive is acceptable.

In truth – in SAP lockbox processing, the system only requires that you receive the following records: 1, 5, 6 and 4. All other records are simply for additional information, and for helping to ‘visually break-up’ the lockboxes sent in a file for later review by SAP team members to investigate any transmission problems. It is common for customers to use only the 1, 5, 6, 4, 7, and 8 records.


BAI TESTS:

Scenario 1: Lockbox file perfect match to multiple open invoices on customer account

Documents:

SAP Invoices # 18000022 - 18000031 / Gross Amount $10,000.00

Incoming lockbox file:

100YPCCDESTINYPCCORIGIN98121512012YPCCDESTINYPCCORIGIN50010010012345981215YPCCDESTINYPCCORIGIN60010020001000000011000390556677889 00091230318000022 18000023 180000244001003601718000025 18000026 18000027 18000028 18000029 18000030400100460191800003170010050012345981215010000100000080010060012345981215001000010000009 1000000 10000009000010

Result: should match and clear open items-------------------------------------------------------------------------------------------------------------------------------------------------------

Scenario 2: Lockbox file match to open invoices and customer account, invoice payment at discount, and reference to a credit memo to explain a short-payment (invoices at discount/credit memo at gross)

Documents:

SAP Invoice # 18000032 for $1000.00/ SAP Invoice #18000033 for $1000.00 with 2% discount/ One SAP Credit Memo #16000001 for $200.00 / Net Amount $1760.00


100YPCCDESTINYPCCORIGIN98121512022YPCCDESTINYPCCORIGIN50020010012345981215YPCCDESTINYPCCORIGIN60020020000176000011000390556677889 00091230418000032 18000033 1600000170020050012345981215003000100000080020060012345981215000300001760009 0176000 01760009000003

Result: should match invoices and credit memo, deduct discount allowance, and clear open items-------------------------------------------------------------------------------------------------------------------------------------------------------


Scenario 3: Wrong MICR information on the customer account; account identified via invoice numbers on the account.

Documents:

SAP Invoices # 18000034, 18000035, 18000036 for $3000.00 / Gross Amount $3000.00On customer #1000001; incorrect MICR listed on master record.Incoming lockbox file:

100YPCCDESTINYPCCORIGIN98121512032YPCCDESTINYPCCORIGIN50030010012345981215YPCCDESTINYPCCORIGIN60030020000300000011000390556677889100091230518000034 18000035 1800003670030030012345981215003000030000080030040012345981215000300003000009 0300000 03000009000003

Result: lockbox program searches for customer by invoice numbers. It identifies the customer, and creates a batch session to update the correct MICR number onto the customer’s master record for future transmissions. The items are cleared.-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

Scenario 4: Invoice payment via Alternate Payer Worklist

Documents:

SAP Invoices # 18000037-18000039 for $1000.00 each / Gross amount $3000.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512042YPCCDESTINYPCCORIGIN50040010012345981215YPCCDESTINYPCCORIGIN60040020000300000011000390556677889 00091230618000037 18000038 1800003970040030012345981215003000030000080040040012345981215000300003000009 0300000 03000009000003

Result: the system will find reference in the transmission for three open items on two customers. The payment will arrive with the MICR information of the parent customer. It will check the master records of both, recognize that one customer (parent) pays the bills for the other (subsidiary), and use the payment to clear the open items from both customer accounts.-----------------------------------------------------------------------------------------------------------------------------------------------------


Scenario 5: Short payment allowed under customer/user tolerances

Documents:

SAP Invoices # 18000040-18000041 for $1000.00 each / Gross amount $2000.00 / Payment $1995.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512052YPCCDESTINYPCCORIGIN50050010012345981215YPCCDESTINYPCCORIGIN60050020000199500011000390556677889 00091230718000040 1800004170050030012345981215002000019950080050040012345981215000200001995009 0199500 01995009000002

Result: the result depends upon the tolerance rules set for this customer. If there is no payment difference tolerance, then the extra deduction taken will cause the lockbox to fail and the payment will be placed on the customer’s account for post-processing. If the strictest tolerance (between customer and user) is set for $5 or more, than the lockbox will automatically apply the payment to the open items and clear the account. In this scenario, you the system should allow you to post with the difference under set short-pay tolerances.

Scenario 6: Short payment refused under customer/user tolerances / post-processing required

Documents:

SAP Invoices # 18000042-18000043 for $1000.00 each / Gross amount $2000.00 / Payment $1990.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512062YPCCDESTINYPCCORIGIN50060010012345981215YPCCDESTINYPCCORIGIN60060020000199000011000390556677889 00091230818000042 1800004370060030012345981215002000019900080060040012345981215000200001990009 0199000 01990009000002

Result: the result depends upon the tolerance rules set for this customer. If there is no payment difference tolerance, then the extra deduction taken will cause the lockbox to fail and the payment will be placed on the customer’s account for post-processing. If the strictest tolerance (between customer and user) is set for $5 or more, than the lockbox will automatically apply the payment to the open items and clear the account. In this case, the payment difference exceeds the tolerance limits, and thus the user must perform lockbox post-processing to write-off the excess difference to a G/L account or back to the customer’s account as an open item.

Any extra deduction beyond tolerance limits must be written off to a payment differences G/L account maintained in the AR incoming payments configuration**** Scenario 6 may be used to test the customer’s business scenarios for lockbox post-processing in dealing with

unauthorized payment differences, such as: ability to apply a check, generate a deduction with any reason code that doesn’t generate correspondence,

dispute or write-off ability to apply a check, generate a deduction with a reason code that generates a letter ability to apply a check, generate multiple deductions to specific different ship-to numbers, then process a

partial payment ability to apply a check, generate multiple deductions, with several residual items, allowing discount under the

customer’s tolerance & user’s tolerance, and also using a reason code to write-off to discount performing the same process as above, but write-off to disputed balance ability to apply a check, generate multiple deductions, several partial payments with reference to closed items,

or items which cannot be located ability to apply a check which pays an item which belongs on an account that is in a worklist, and another item

which belongs on an account which is not in a worklist ability to distribute payment differences by age ability to charge off differences within the customer/user tolerance


ability to redirect a check which has been identified to the wrong account

Scenario 7: Lockbox transmission received with multiple customer payments in one batchDocuments:

SAP Invoices # 18000044-18000045 for $1000.00 each / Gross amount $2000.00 / Payment $2000.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512072YPCCDESTINYPCCORIGIN50070010012345981215YPCCDESTINYPCCORIGIN60070020000100000011000390556677889 000912308180000446007003000010000001100039055667788910009893091800004570070040012345981215002000020000080070050012345981215000200002000009 0200000 02000009000002

Result: the payments will apply to the items on both customers. The ‘print statistics’ function of the lockbox program will create a page that shows the two batch items separately and the impact upon the individual accounts.

Scenario 8: Lockbox transmission received with multiple batches in one lockboxDocuments:

SAP Invoices # 18000046-18000049 for $1000.00 each / Gross amount $4000.00 / Payment $4000.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512082YPCCDESTINYPCCORIGIN50080010012345981215YPCCDESTINYPCCORIGIN60080020000100000011000390556677889 000912309180000466008003000010000001100039055667788910009893091800004770080040012345981215002000020000050090010012345981215YPCCDESTINYPCCORIGIN60090020000100000011000390556677889 000901231180000481800004970090030012345981215002000020000080090040012345981215000200004000009 0400000 04000009000004

Result: the payments will apply to the items on both customers. The ‘print statistics’ function of the lockbox program will create a page which shows the two batch items in one batch, and another batch item on another batch, and the impact upon the individual accounts.

To modify the file to fit each of these scenarios, make sure to change the check dollar amount, and referenced invoices and credit memos, as well as batch number and time.

These scenarios also provide a good test of the Document Flow functionality in the SAP Deductions Management Component (DMC).------------------------------------------------------------------------------------------------------------------------------------------------------


BAI2 TESTS:

Scenario 1: Lockbox file perfect match to multiple open invoices on customer account

Documents:

SAP Invoices # 18000022 - 18000031 / Gross Amount $10,000.00


100YPCCDESTINYPCCORIGIN98121512012YPCCDESTINYPCCORIGIN50010010012345981215YPCCDESTINYPCCORIGIN60010020001000000011000390556677889 0009123014001003601718000022 000010000000000000004001004602718000023 000010000000000000004001005603718000024 000010000000000000004001006604718000025 000010000000000000004001007605718000026 000010000000000000004001008606718000027 000010000000000000004001009607718000028 000010000000000000004001010608718000029 000010000000000000004001011609718000030 000010000000000000004001012610918000031 0000100000000000000070010050012345981215010000100000080010060012345981215001000010000009 1000000 10000009000010

Result: should match and clear open items-------------------------------------------------------------------------------------------------------------------------------------------------------

Scenario 2: Lockbox file match to open invoices and customer account, invoice payment at discount, and reference to a credit memo to explain a short-payment (invoices at discount/credit memo at gross)

Documents:

SAP Invoice # 18000018 for $1000.00/ SAP Invoice #18000033 for $1000.00 with 2% discount/ One SAP Credit Memo #16000002 for $200.00 / Net Amount $1760.00


100YPCCDESTINYPCCORIGIN98121512022YPCCDESTINYPCCORIGIN50020010012345981215YPCCDESTINYPCCORIGIN60020020000176000011000390556677889 0102034124002003601716000002 000002000000000000004002004602718000033 000009600000000000004002005603918000018 0000100000000000000070020060012345981215003000017600080020070012345981215000300001760009000003Result: should match invoices and credit memo, deduct discount allowance, and clear open items-------------------------------------------------------------------------------------------------------------------------------------------------------


Scenario 3: Wrong MICR information on the customer account; account identified via invoice numbers on the account.

Documents:

SAP Invoices # 18000034, 18000035 for $450.00 each / Gross Amount $900.00On customer #1000001; incorrect MICR listed on master record.Incoming lockbox file:

100YPCCDESTINYPCCORIGIN98121512032YPCCDESTINYPCCORIGIN50030010012345981215YPCCDESTINYPCCORIGIN60030020000090000011000390556677889 0102034134003003601718000034 000004500000000000004003004602918000035 0000045000000000000070030050012345981215002000009000080030060012345981215000200000900009000002

Result: lockbox program searches for customer by invoice numbers. It identifies the customer, and creates a batch session to update the correct MICR number onto the customer’s master record for future transmissions. The items are cleared.-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

Scenario 4: Invoice payment via Alternate Payer Worklist

Documents:

SAP Invoices # 18000037-18000039 for $1000.00 each / Gross amount $3000.001 invoice on customer 1000000, 2 invoices on customer 1000001Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512042YPCCDESTINYPCCORIGIN50040010012345981215YPCCDESTINYPCCORIGIN60040020000300000011000390556677889 0102034144004003601718000037 000010000000000000004004004602718000038 000010000000000000004004005603918000039 0000100000000000000070040060012345981215003000030000080040070012345981215000300003000009000003Result: the system will find reference in the transmission for three open items on two customers. The payment will arrive with the MICR information of the parent customer. It will check the master records of both, recognize that one customer (parent) pays the bills for the other (subsidiary), and use the payment to clear the open items from both customer accounts.-----------------------------------------------------------------------------------------------------------------------------------------------------


Scenario 5: Short payment allowed under customer/user tolerances

Documents:

SAP Invoices # 18000040-18000041 for $1000.00 each / Gross amount $2000.00 / Payment $1995.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512052YPCCDESTINYPCCORIGIN50050010012345981215YPCCDESTINYPCCORIGIN60050020000199500011000390556677889 0102034154005003601718000040 000010000000000000004005004602918000041 0000099500000000000070050050012345981215002000019950080050060012345981215000200001995009000002

Result: the result depends upon the tolerance rules set for this customer. If there is no payment difference tolerance, then the extra deduction taken will cause the lockbox to fail and the payment will be placed on the customer’s account for post-processing. If the strictest tolerance (between customer and user) is set for $5 or more, than the lockbox will automatically apply the payment to the open items and clear the account. In this scenario, you the system should allow you to post with the difference under set short-pay tolerances.

Scenario 6: Short payment refused under customer/user tolerances / post-processing required

Documents:

SAP Invoices # 18000042-18000043 for $1000.00 each / Gross amount $2000.00 / Payment $1990.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512062YPCCDESTINYPCCORIGIN50060010012345981215YPCCDESTINYPCCORIGIN60060020000199000011000390556677889 0102034164006003601718000042 000010000000000000004006004602918000043 0000099000000000000070060050012345981215002000019900080060060012345981215000200001990009000002Result: the result depends upon the tolerance rules set for this customer. If there is no payment difference tolerance, then the extra deduction taken will cause the lockbox to fail and the payment will be placed on the customer’s account for post-processing. If the strictest tolerance (between customer and user) is set for $5 or more, than the lockbox will automatically apply the payment to the open items and clear the account. In this case, the payment difference exceeds the tolerance limits, and thus the user must perform lockbox post-processing to write-off the excess difference to a G/L account or back to the customer’s account as an open item.

Any extra deduction beyond tolerance limits must be written off to a payment differences G/L account maintained in the configuration**** Scenario 6 may be used to test the customer’s business scenarios for lockbox postprocessing in dealing with

unauthorized payment differences, such as: ability to apply a check, generate a deduction with any reason code that doesn’t generate correspondence,

dispute or write-off ability to apply a check, generate a deduction with a reason code that generates a letter ability to apply a check, generate multiple deductions to specific different ship-to numbers, then process a

partial payment ability to apply a check, generate multiple deductions, with several residual items, allowing discount under the

customer’s tolerance & user’s tolerance, and also using a reason code to write-off to discount performing the same process as above, but write-off to disputed balance


ability to apply a check, generate multiple deductions, several partial payments with reference to closed items, or items which cannot be located

ability to apply a check which pays an item which belongs on an account that is in a worklist, and another item which belongs on an account which is not in a worklist

ability to distribute payment differences by age ability to charge off differences within the customer/user tolerance ability to redirect a check which has been identified to the wrong account

Scenario 7: Lockbox transmission received with multiple customer payments in one batchDocuments:

SAP Invoices # 18000044-18000045 for $1000.00 each / Gross amount $2000.00 / Payment $2000.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512072YPCCDESTINYPCCORIGIN50070010012345981215YPCCDESTINYPCCORIGIN60070020000100000011000390556677889 0102034154007003601718000044 000010000000000000006007004000010000001100039055667788910102034164007005602918000045 0000100000000000000070070060012345981215002000020000080070070012345981215000200002000009000002Result: the payments will apply to the items on both customers. The ‘print statistics’ function of the lockbox program will create a page that shows the two items within the same batch displayed separately, as well as the impact upon the individual accounts.

Scenario 8: Lockbox transmission received with multiple batches in one lockboxDocuments:

SAP Invoices # 18000046-18000049 for $1000.00 each / Gross amount $4000.00 / Payment $4000.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512082YPCCDESTINYPCCORIGIN50080010012345981215YPCCDESTINYPCCORIGIN60080020000200000011000390556677889 0102034174008003601718000046 000010000000000000004008004601918000047 0000100000000000000070080050012345981215002000020000050090010012345981215YPCCDESTINYPCCORIGIN6009002000020000001100039055667788910102034184009003601718000048 000010000000000000004009004602918000049 0000100000000000000070090050012345981215002000020000080090060012345981215000400004000009000004

Result: the payments will apply to the items on both customers. The ‘print statistics’ function of the lockbox program will create a page which shows the two batch items in one batch, and two items in another batch, and the impact upon the individual accounts.


Scenario 9: Partial application status achieved based upon one invoice applied and one invoice unprocessed (unidentifiable)

SAP Invoice # 18000113 for $1000.00 / Unidentifiable document #99009999 for $995.00

100YPCCDESTINYPCCORIGIN98121712072YPCCDESTINYPCCORIGIN50070010012345981217YPCCDESTINYPCCORIGIN60070020000199500011000390556677889 0102034074007003601718000113 000010000000000000004007004602999009999 0000099500000000000070070050012345981217002000019950080070060012345981217000200001995009000009

Result: the first payment will be applied against the correct SAP document. The second payment will arrive into SAP in an “unprocessed” status. Thus, the check status will be “partially applied”. Post-processing will be required for the unprocessed item.

Scenario 10: Payment made with deductions taken using reason code references

Documents:

SAP Invoices # 18000098-18000099 for $1000.00 each / Gross open item amount $2000.00 / Deductions $100 each/ Net payment amount $1800.00Incoming lockbox file:100YPCCDESTINYPCCORIGIN98121512052YPCCDESTINYPCCORIGIN50050010012345981215YPCCDESTINYPCCORIGIN60050020000180000011000390556677889 0102034154005003601718000098 00001000000000010000HR24005004602918000099 00001000000000010000SHP70050050012345981215002000018000080050060012345981215000200001800009000002

Result: the result depends upon the internal-external reason code mapping, and whether or not the internal reason codes perform deduction write-off or residual item posting. The key to remember – the payment amount in the 6, 7 and 8 Records are net (minus the deductions), but the open item amounts listed in the 4 Records must the be gross item amount, followed by the deduction amounts, and completed with the external reason code. If you inadvertently enter the ‘net’ amount in the first item amount field of the 4 Record, and then include the deduction amount in the next field, the system will ‘double-deduct’ cash and you will run into payment totals discrepancies.

There are certainly other scenarios that can be tested using these variable lockbox files. These are just a few of the ones commonly encountered on a client engagement. Files are very flexible. You may use SAP invoice numbers, customer legacy system document numbers, or a combination of both, within a lockbox file. You must maintain configuration for the program to know what to expect in the file.

The file used for testing a user exit program (you have to develop this separately) which acts upon lockbox files that omit invoice numbers is the same. Such files can be used to test: matching by account gross owing, matching by account owing minus credit memos, matching by account owing net of discounts, matching by aging bucket, and so on. The only difference in the file is that no invoice numbers are provided.

Once you have these basic templates, you can test different scenarios simply by changing dollar payment amounts, invoices, short payments, etc.

IMPORTANT CONFIGURATION NOTES:Understanding SAP Lockbox.doc

04/27/23

When you are creating the files, you must be aware of the lockbox configuration in the system. Of particular importance is the configuration accessed via the following menu path in 4.0B:

Financial Accounting Bank Accounting Business Volume Payment Transactions Lockbox Define Control Parameters

In the BAI format entry, you must be aware of the document number length specified. This number sets the number of spaces the lockbox program will read for each document number. All document numbers must fit within the allowed maximum number of spaces defined here. The system will read documents which are shorter, if they have been configured for that document length within SAP.

Second, you must define here how many documents will be attached to the 6 Record and to the 4 Record. The file must then adhere to this specification. If you define the 6 Record to have zero documents, then you should ensure that the incoming lockbox file also has no documents in the 6 Record. You will need to specify this requirement to the client bank for them to incorporate it into the lockbox files that they send. Further, the 4 Record has a maximum number of documents specified in the configuration. If the configuration dictates to the program that each 4 Record will have 5 documents, then you may use up to 5 documents in each record. If there are more than 5 documents to be sent for that customer, then you must “overflow” into a series of consecutive 4 Records. However, you must utilize all 5 document spaces within a 4 Record before overflowing into a new 4 Record. Otherwise, the program will fail as it attempts to create payment advice notices, and the lockbox will not apply the payments to the specified open items.

Third, if you wish to activate the program’s logic for creating the MICR number from lockbox information for customer’s that are missing this data in their master record, then you must click the box for Insert Bank Details and create your own batch session name (ie. MICRCREATE) into the blank field. When running the lockbox for a customer in this scenario, a batch session will automatically be created with the name you define in this screen. Executing the batch session will automatically create the MICR information on the customer’s master record.

If you wish to increase the number of spaces possible for a particular field, for example document length, you will have to perform a table modification. For example, if you wish to expand the bank’s ABA number field from 9 to 16 (maximum) spaces, you will have to have the field definition modified in the table. This will require SAP approval.

For handling lockbox files which lack document numbers, you will need to have a special User Exit program written to provide logic for such selection algorithms as account gross owing, account net owing, account net owing less credits, gross aging buckets, net aging buckets, etc.

From a G/L perspective, you can limit the number of postings into the Lockbox cash account by selecting ‘2’ in the G/L postings field. This indicates that the program should create one posting per lockbox, rather than per check. This is particularly valuable for companies who have high-volume lockbox transactions and don’t wish the Lockbox cash account to become inundated by lots of individual check postings.

If you want to be able to utilize the Alternate Payer logic within lockbox, you must make a change in the G/L bank account master records, as well as the lockbox A/R G/L accounts. On the second screen of the G/L master record, you should click on the box labeled ‘Relevant to cash flow’. This will enable the lockbox to post to items across customers on a worklist.

Important Procedural Tips:

1. Handling a lockbox payment that the customer intends to use to clear open items on more than one company code.

In the event that payments are received into a lockbox that exists in one company code, but are intended to pay open items that exist on the same customer in multiple company codes, a work-around solution must be designed. This is because a lockbox in SAP is defined as being specific to a single company code. It cannot handle the splitting of payments across company codes during autocash processing. While one option may be to attempt to include complex logic in a user exit that uses external table look-up for company code identification, a better semi-manual approach is suggested.

The proposed solution would utilize a reason code for movement of the payment portion that belongs on a different company code. For instance, a reason code WLP (Wrong Lockbox Paid) could be created. This is important because it allows you to ‘close’ the On Account posting that exists in the lockbox bank storage records. By using the FLB1


transaction for post-processing, the cash application clerk can go to the customer’s account, clear the payment portion against the open item in the first company code, and assign the WLP reason code to the incorrectly assigned payment portion (to flag it for cross-company posting). As far as the lockbox tracking is concerned, this is now a ‘closed’ item and it will have the status Applied. Now, the AR clerk must perform the Transfer with Clearing function (F-30) to search the correct company code for the open item to be cleared, and associate it with the payment residual item that exists in the incorrect company code. This function will utilize the company code clearing function and thereby not cause any intercompany problems. Reports may be generated to list all payments that have been received into the wrong company code (by the WLP reason code) and may also be connected to a user-defined SAP Script correspondence that requests that the customer remit separately all payments to their appropriate remit-to address and lockbox.

Please note: you may attempt to put in some ‘additional code’ in the second user exit spot within the RFEBLB20 program in order to begin a ‘cross-company clearing’ search. However, this can add significant processing time to your program and increases the risk of misapplication of cash.

2. Dealing with the issue of multiple external reference invoice numbers (BSEG-XBLNR) per company code

When dealing with legacy-created documents that are imported into SAP, sometimes duplicate reference document numbers will exist in SAP simultaneously. Up through release 4.0B, user exit logic must be incorporated to prevent the system from matching a lockbox payment with an open item if the MICR has not enabled the proper identification of the proper customer. Otherwise, the system can erroneously apply the cash to the wrong account based upon which open item was created most recently. (In the event that a customer is found by MICR, and duplicate XBLNR values exist, the system will select and clear the appropriate open item). It is also key to realize that SAP reads the remittance document numbers as ‘text’ not numbers – because it is attempting to match against either the Document number (BELNR) or Reference number (XBLNR) fields. If there are no leading zeros or spaces in the document within SAP, then the transmission needs to avoid leading spaces or zeros (otherwise no clearing will occur).

Further, no +/- signs should be used in the transmission. If the customer is referencing a credit memo on their account in their payment (as a reason why they are paying less than the sum of the open invoices referenced), the SAP system will recognize the credit memo by document number range. All payment netting will occur automatically, without plus or minus signs.


Testing!!!:

It is critical that you meet face-to-face with representatives of the banks from whom you will receive transmissions. It may help to give them this document in order to understand how SAP imports, reads and processes lockbox files. You should also receive several ‘live’ lockbox transmission files (first into DEV, then QA, then a copy of PROD) in order to ensure that the proper document numbers exist in both the AR documents and the bank lockbox transmission as necessary for proper cash application. Don’t just assume that the bank will have it perfectly matched to SAP-required formats on the first try…

Valuable Cash Management Services Available from Banks:

As of summer 1999, a handful of banks now offer an online lockbox status tracking service. Among the few, SunTrust Bank offers customers an Intranet-accessible (via secure server connection) lockbox activity tracker that is updated every five minutes to show all incoming cash postings to their lockbox account. This enables customers to view check images, review a list of all posted items (up to 45 days in past), and download a current lockbox account extract. Such a service can be used for simple cash management tracking functions, verifying payments, and viewing remittance information. This service will soon be Internet-based.

Not all matching algorithms are possible in the standard lockbox program RFEBLB20. Thus, you may see the need to create a ‘customized lockbox program’ to handle such scenarios as shown below.

Example of a customer-specific lockbox matching logic:
