Lockbox Overview

7/30/2019 Lockbox Overview

1/18

Overview

SAP Lockbox

A company can create lockbox accounts at a bank that are used as payment collection accounts for

customer receivables. The company informs its customers that all payments should be submitted to one

of its established bank lockbox accounts at a designated remittance address. A lockbox account is

usually a designated post office box which has the company name but the customer payments are

actually received by the bank.

SAP lockbox utilization results in two primary business benefits: funds collection and remittance

information delivery. The major benefits are that the company is able to recognize the funds more

quickly, and the customers check is cashed in a timelier manner. The bank collects the payments along

with the customers remittance information which indicates the open items the customer is paying. Data

entry clerks at the bank manually enter the information into an electronic file for transmission to thecompany in groups of checks called batches.

These electronic files are typically transferred nightly to the company which owns the lockbox. The files

can be in one of two standard banking industry formats: BAI or BAI2. They can also be transmitted via

EDI using the ANSI X.12 823 for lockbox remittances. A combination of the two is not uncommon where

a BAI format is delivered within an EDI message.

Customer identification is the primary task of the initial (SAP) data processing of each lockbox payment.

Finding the corresponding document clearing information is the second task. Lockbox programs

RFEBLB00 for BAI and BAI2 formats and RFEBLB30 for EDI format attempt to identify the customer first

by MICR number (ABA/bank account number combination) and then by invoice number. It is strongly

recommended that companies maintain the bank details on their customer master records. The MICR

numbers must be unique across banks configured within SAP. Additionally, the MICR and customer

account number also need to uniquely identify a single customer within the system. If a customer is

identified by the document number but the bank details do not correspond to the MICR number, they

can be added via the optional batch input session. This allows the SAP system to learn customer bank

accounts via repeated use of the lockbox service. Processing statistics in future lockbox remittances will

greatly improve with repeated use of this option.

BAI / BAI2 Formats

The standards for lockbox transmission files are defined by the Bank Administration Institute (BAI). BAI

and BAI2 are the two defined lockbox transmission formats; however, BAI is considered outdated by the

BAI organization and is no longer supported. Many banks still offer BAI format. Refer to note 118470 for

contact information on the BAI institute from which formal documentation can be purchased. Banks

which offer lockbox services frequently supply documentation on the formats they provide.


2/18

BAI and BAI2 formats differ primarily in their level of information detail. BAI does not subtotal the

incoming check line items by invoice reference. One check total amount contains all invoices listed

underneath it. Consequently, in BAI format files, the entire check must match the total amount for all

invoices listed or be within configured payment difference tolerances. If it does not match or fall within

tolerance limits, the entire check will enter into SAP as:

1. an On Account posting the payment and invoice totals do not match or

2. an Unprocessed posting no customer account or document could be identified from the

transmission via MICR or invoice identification

The accounts receivable department will have to perform manual application to clear items which have

received either of the statuses above. This is accomplished in the lockbox post-processing described

below.

BAI2 splits the check total into separate invoice references and corresponding payment amounts per

invoice. Each record type 4 contains only one invoice. It can also contain deduction amounts as well asthe external reason code for the deduction. Within a payment targeted for multiple invoices, BAI2

format files can achieve a processing status of Partially Applied which means that some of the items

within a check have been matched and cleared, and other invoices were not identified so their payment

portion will be placed On Account. As a result, the hit rate or application rate percentage is higher

when using BAI2 format than when using BAI format.

The decision of which format to use (given that your bank is able to supply BAI), is dictated by a cost-

benefit analysis. The BAI2 format is more detailed so it costs more for the lockbox bank to enter and

deliver the data. The BAI format is cheaper, but may not offer a suitable hit rate. The BAI2 format is

recommended for large volume, multiple invoice payments and scenarios where deductions and shortpayments are taken. The BAI format is probably adequate if only a small portion of customer payments

are received via lockbox transmission. In general, a high percentage of checks achieving a status of at

least on-account is targeted to reduce the intervention by post-processing analysts and achieve an

acceptable cash application rate.

ANSI X.12 823 (EDI)

Using EDI, the bank file is brought into the system using the FINSTA01 IDOC with the logical message

type LOCKBX and process code LOBX. This process is slightly different to the BAI2 process which uploads

the statement and posts it immediately. With EDI, the IDOC inserts the statements into the bank tables

and then the posting program, RFEBLB30, is executed to post the statements. The informationreceived in this format is identical to that which is received in BAI2 and is particularly effective in

scenarios where extremely large remittance information is passed with a single payment. As with all EDI

services delivering data to the SAP system, this format will require a translation mechanism for mapping

the bank file in an ANSI format to the SAP IDOC format. This translation is done by an EDI subsystem.

You can find a list of vendors which offer this service in the Complementary Software Program Directory.

While the intent of this process is to translate ANSI X.12 823 files into the IDOC format, you could also


3/18

translate the BAI2 file into the IDOC format. Companies which want to use the IDOC format for all

external file transfer may choose to do this. Additional SAP configuration not described in this document

is required if you wish to use the EDI process within the SAP system.

Benefits

Better control of customer check float time and customer credit management.

Accelerated collection and deposit of checks benefits the payee and allows for better and more

efficient cash management.

The automated lockbox system can reduce your own internal processing costs by automatically

updating your cash postings and cash application to the subledger. Additionally your customer

requirement to maintain data entry staff should be reduced.

Components of the SAP Lockbox

1. Control Parameters (Transaction OBAY)

Procedure

The procedure for payment processing. The system currently only supports the procedure LOCKBOX.

Record Format

The standardized record format of the file which you receive from the bank. The only supported

formats are BAI, BAI2 and IDOC. For record format BAI only, you must also tell the system the length of

the document and the maximum number of invoices which can be contained in record types 4 and 6.

For the BAI format, record type 6 contains the detail per check. If there are more than 3 invoices being

paid by a check, then a record type 4 is required. Record type 4 is the overflow record. The BAI data

needs to conform strictly to this format creating a new overflow record only when the prior record is

filled with the number of entries indicated in the configuration. For the BAI2 and IDOC formats, it is not

necessary to specify this information.

G/L Account Posting Type

You have two options when posting to the GL. You can choose to post one line item per check in both

the clearing account and the GL bank account or you can choose to post one line item per check in the

clearing account and only one line item for the total lockbox amount in the bank account. This reduces

the number of postings to the GL bank account. As of release 4.6, you will also have the option to post

one line item per batch. In the case where you have a file with three batches, each containing 50 checks,

you would have 150 line items to the clearing account and 3 line items to the GL bank account. It is

generally accepted to enable this compression on the GL account either at the bank or the batch level.


4/18

Partial Payments

The Partial Payments option is not recommended for customers with high volume. This box changes

the default behavior of the program to post partial payments rather than creating residual items. The

result is an on account posting with a reference to the original. This increases the number of open

items on the customer account since nothing was cleared. Note that new SAP customers are typicallyaccustomed to partial payments in their view of the lockbox cash application. Residual item creation

and the clearing of the initial customer invoice offers similar processing and capability along with the

reduction of open items on the customer account. Additionally, the link is maintained between the

residual item created and the original customer invoice from which it was created.

Insert Bank Details

The execution of the lockbox program allows you also to create a batch input session which will

update your customer master records with bank account information, allowing the system to learn

customer bank information and improve processing statistics.

2. Posting Data (Transaction OBAX)

Destination / Origin

The Destination and Origin can be almost anything and are agreed upon with the lockbox bank as to

their values. In some cases one of them may be the ABA number of the lockbox bank and the

destination may be a cash account to which lockbox remittances are eventually transferred. They are

both contained in record 1 of the file. The destination is in fields 4 to 13 and the origin is in fields 14 to

23.

House Bank / Account ID

If the lockbox is receiving payments which are of a currency other than the company code currency,

then you have to create a house bank and account id for the lockbox account and specify the alternate

currency in the house bank account. Canadian companies may have a US dollar lockbox for example.

Note that lockbox accounts for each currency of receipt need to be configured. You can not have

multiple currencies in the same file.

Bank (G/L) Account / Bank Clearing Account (A/R)

The automated lockbox posting program uses a two-step posting process. In step one, it posts to a GL

account which is a bank account (House Bank / Account ID) and also to an AR clearing account

commonly called an unapplied cash account. In step two, the program attempts to clear a customer

open item. If successful, it clears the customer open item and also the item in the clearing account

(unapplied cash) which was posted in the first step. *** If you are using the cash management module,


5/18

then the GL account in the Bank (G/L) acct field should contain a clearing account for incoming cash

rather than the actual GL account for the bank.

3. Lockbox Addresses for House Banks (Transaction OB10)

You can store different addresses, such as PO box numbers, for the lockbox to which customers mail

their payments. The billing documents will then have the PO address rather than the bank street

address. You must also maintain the lockbox field in the company code payment transaction screen in

the customer master.

Lockbox

This is a 7 digit designation which you can define freely. It is suggested that you use the same name as

the account id at the house bank in order to avoid confusion.

Lbox No

This is the number of the lockbox at your bank.

4. House Bank / EDI Partner (Transaction FI12) Optional

DME Section of the House Bank

EDI Partner Profiles

Partner No. Use the ABA number to designate the partner number for the house bank.

Partner Profile

Header Information

Partner TypeB for Bank

Classification

Partner StatusA for active

Post Processing: Permitted Agents The user entered in this area will receive messages in his or her

inbox if there are problems with the import.

TypUS for User

Lang.EN for English

User user id for the SAP system


6/18

Inbound Parameters

Message TypeLOCKBX for Lockbox

Inbound Options

Process CodeLOBX for lockbox

Trigger Immediately the inbound IDOC is processed immediately

Post Processing: Permitted Agents The user entered in this area will receive messages in his or her

inbox if there are problems with the import.

TypUS for User

Lang.EN for English

User user id for the SAP system

4a. ***EDI Port an EDI port must be created in the system. This topic is not covered in this

document.

5. Examples of possible user exits to increase hit rate.

Cross-company postings. The bank account is actually owned by one company but the customers are

in another company. The cash portion of the posting should be in one company code and the clearing ofthe customer item will be in the other. Since the posting rules for the lockbox are company code

specific, you would need to have the user exit post the other side of the transaction to a GL in another

company code.

Alternate field search. The lockbox programs searches for document numbers (BELNR) and reference

document numbers (XBLNR) to clear open items. With many customers, the billing document number is

placed in the allocation field when the AR invoice is created. You could create a user exit which searches

the allocation field in addition to the document and reference document fields. Post processing of the

lockbox file relies on the document number when creating the payment advice. You could also have the

user exit put the document number in the payment advice rather than the value which is in the

allocation field since the system has already done the search for the allocation field.

6. Execute Program RFEBLB00 (BAI, BAI2) or RFEBLB30 (EDI)

File Specifications (RFEBLB00)


7/18

If you want to store the file in the system, you should check the box. If the file is either on the c drive

of your PC or on a disk, you will need to check the box for PC upload and give the path name.

Lockbox Data (RFEBLB30)

The statements brought in to the system via EDI are processed with this transaction. Enter the origin,

destination, lockbox, and statement date.

Processing Parameters

Invoice numbers

You can tell the system which field to search for the invoice numbers. Your choices are document

number, reference document numbers, or both. The order of the search can be specified.

Enhanced Invoice number check

This parameter ensures that invoices on a line item in the statement are only cleared from the samecustomer account. If the invoice number is transposed, for example, it could erroneously clear an

invoice on another customer account.

Algorithm: checks with and without advice

You can tell the system to post on account those payments which are not able to clear an open item. If

you choose the option to distribute by date, then the system will collect all payments which are on the

customer account and try to clear the open items, beginning with the oldest item.

Account Assignments

The program can assign the value date to the postings based on the file date. If you enter a profit

center or business area, the program will assign it to every document in the ledger and subledger.

Output Control

You can, and typically do, print the posting log from the program run.

7. Post Processing (Transaction FLB1)

Enter specific data for the lockbox selection or select the Lockbox Overview button to view all existingbank files. After entering or selecting the file, you see the status of the checks by batch number. Checks

are categorized as follows:

Applied: The customer was identified and the check has cleared all document numbers provided.

No further processing is necessary. You can not look at the payment advice because the system

automatically deletes it.


8/18

Partially Applied: The customer was identified and the check has cleared some of the documents. The

remaining amount is posted on account for further manual processing.

To process: choose the check and then press the post button. Clearing is done via standard SAP

processing.

On-Account: The customer was identified but none of the documents could be found. The full amount

of the check is posted on the customer account for further processing with via payment advice.

For this status, you must first change the payment advice. Select the check and you can insert or

delete clearing information. You can also classify deductions with reason codes. After the changes, the

advice must balance to zero. Save the advice and then post it.

Unidentified: The customer was not identified. These are truly unapplied cash and indicate

inadequate customer identification either by MICR / Account number in the lockbox data or via invoice

remittance information. The check remains in the unapplied payment clearing account. The payment

advice is used to clear the item once the customer is identified.

This is similar to the on-account status. You must first identify the customer in the payment advice

before making other changes.

8. Test Lockbox Generation Programs RFEBLBT2 and RFEBLBT3.

These programs will generate customer open items and a lockbox file for processing. Utilize program

RFEBKA96 to delete loaded test data. Refer to the online support system on this program for further

information and extreme caution on its usage.

File Name

The program produces a BAI2 (or IDOC) file which is stored in UNIX. You can use any name you wish.

Once the file is displayed on screen, a menu command allows PC download of it which facilitates

repeated usage of the file with minor modification.

Customer fields (6 Fields)

You must enter customer numbers in the first four fields in order for the program to work. You can use

the same customer number in all four fields if you wish. You can generate complex parent-child

relationships which test the worklist configuration via multiple customer entry.

Dummy Account

This is the offsetting account to the customer invoices and credit memos that the program creates.

Deduction ($100 each Invoice)


9/18

If you place an X here the program will generate a file in which all the amounts paid in the invoices

differ by $100 from the actual invoice amount. In other words, the customer is paying $100 less on each

invoice.

Deduction not related to invoice

If you insert an amount here, the program generates line items on the file for that amount which do

not have a document number associated to them.

Credit Memo

If you place an X here, the program creates credit memos on the customer account which are half of

the invoice amounts. No credit memo appears on the file.

Credit Memo with Number

If you place and X here, the program generates credit memos with numbers and puts them in the

file also.

Check Difference

If you place an X here, the program generates line items which total more than the check amount.

Run the Lockbox import program, using the filename which you chose for the test tool. Since the file is

in the UNIX directory, make sure the PC upload box is not checked.

Basic Steps in Configuring the Lockbox

Maintain Control Parameters

Maintain Posting Data

Create Lockbox Addresses for House Banks

Optional:

For EDI processing: Create EDI Port, EDI Partner with Inbound Parameters

Create user exit.

Menu Paths

The menu paths for setting up the lockbox:


10/18

Financial Accounting Bank Accounting Business Volume Payment Transactions Lockbox Define Control

ParametersorTransaction Code OBAY.

Financial Accounting Bank Accounting Business Volume Payment Transactions Lockbox Define Posting

DataorTransaction Code OBAX.

Financial Accounting Bank Accounting Bank Accounts Define Lockbox Accounts at House

BanksorTransaction Code OB10.

Financial Accounting Bank Accounting Bank Accounts Define House BanksorTransaction Code FI12.

1. Financial Accounting Bank Accounting Business Volume Payment Transactions Lockbox Define Control

Parameters

2. Press the New Entries button.

3. Insert LOCKBOX as the procedure and either BAI, BAI2, IDOC as the record format.

4. For BAI record format, enter the document number length, and the number of documents in the 6

and 4 records.

5. Check the boxes G/L Account Postings and Incoming Customer Payments.

6. Choose whether you wish to update the general ledger with one posting per check or one posting per

lockbox file in the G/L account posting type field. As of release 4.6, you also have the option to post

per batch.

7. You can also choose whether to update the customer master records with bank details by clicking on

the Insert bank details box and filling in a name for the batch input session.

8. The Partial Payments option is not recommended for customers with high volume.

9. Press the save icon.

10. Financial Accounting Bank Accounting Business Volume Payment Transactions Lockbox Define

Posting Data


12. Enter the Destination and Origin information from the file which you received from the bank.

13. Enter the company code.

14. If the lockbox account has a currency other than the currency of the company code, you must

maintain it as a house bank and and account id and enter that information here. Otherwise, you can

leave it blank.


11/18

15. Enter the Bank (G/L) acct and Bank clear.acct(A/R) as descrbed above.

16. Maintain the posting parameters. The most common settings are indicated in the screen print to the

right.

17. Financial Accounting Bank Accounting Bank Accounts Define Lockbox Accounts at House Banks


19. Enter the company code, freely defined Lockbox (recommended to use the account id from the

house bank), house bank, and Lbox no from the bank.

20. Financial Accounting Bank Accounting Bank Accounts Define House Banks

21. Choose the appropriate house bank from the list.

22. Press the DME button.

23. Enter the Partner Number. Common practice is to use the ABA number.

24. Press the Partner Profile Button.

25. Press the New Entries Button.

26. Enter the Partner number (same as previous screen).

27. Enter Partner type B for Bank.

28. The partner status is A for active.

29. Enter the data for the user who will be receiving error messages in the inbox.

30. Press Save.

31. Go back one menu.

32. Highlight your new entry and press the Inbound Parameters magnifying glass.


34. Leave Partn.funct., Message Code, and Message function blank.

35. Enter LOCKBX for the message type.

36. Enter LOBX for the process code.

37. Check the Syntax check box.

38. Choose the Trigger immediately radio button.


12/18

39. Enter the data for the user who will be receiving error messages in the inbox.

40. Press Save.

41. Accounting Treasury Cash Management Incomings Lockbox Import (RFEBLB00)

42. Check then Import into bank data storage to update the appropriate tables which store bank file

data.

43. Click on PC upload if you are uploading the file from your PC.

44. Enter the path of the file you are going to import.

45. The procedure is LOCKBOX.

46. The Input record format is BAI, BAI2, or IDOC.

47. Choose the search rule for the invoice numbers from the drop down menu.

48. Check the Enhanced invoice check box if you wish to use it.

49. Choose the algorithms for checks with and without advice.

50. Click on Assign value date if you want the postings to have an associated value date.

51. Enter a business area and / or profit center if you wish.

52.

53Accounting Treasury Cash Management Incomings Lockbox Post (RFEBLB30)

53. This program is used for the EDI Process. EDI files are imported into the system and stored in the

bank buffers. This program is then run to post. Follow the suggestions above except that you enter the

destination, origin, and statement date rather than the lockbox procedure.

54.

55Accounting Treasury Cash Management Incomings Lockbox Postprocess

55. Enter specific data to a lockbox import or select the Lbox overview button to display all files.

56. Transaction SE38. Program name RFEBLBT2.

57. The function of each of the fields is explained in the previous section.

Related Documents


13/18

Appendix A Tolerances and Reason Codes

User Exit Examples

Note 45436 - Lockbox Specific Transactions and Tables

OB55 - Worklist

Appendix A Tolerances and Reason Codes

Overview

Tolerances

The use of tolerances is required by the system for clearing purposes. Tolerances can be set up for users

and for Customer/Vendor payments. You can set up blank tolerance groups for customers, vendors, and

users so that newly created customers and vendors will automatically be assigned this tolerance group.

The system requires at least one tolerance group per company code. If you set up a blank tolerance

group, then you dont have to maintain that field in the customer and vendor master records. You can

also set up a blank tolerance group for users. This way you dont have to assign each user to a tolerance

group. Users who are not specifically assigned to a tolerance group in transaction OB57 are

automatically assigned to the blank tolerance group. Both sets of tolerances work together when

clearing open items through the lockbox processing. The stricter of the rules will always control whether

the item is cleared or not.

Reason Codes

The 4 record in the BAI Lockbox file may contain an external reason code indicating the reason for the

payment difference. This external reason code must be linked to an internal reason code which is used

to charge off the payment differences to a separate account. This allows you to clear customer items

completely rather than having items posted on account which need to be post processed. If the

payment difference is within the tolerances set, the difference will be posted to the charge off account.

The external reason codes are linked to internal reason codes per a conversion version. The conversion

version is assigned to the customer master record on the payment transaction screen.


14/18

Components

1. Define Customer/Vendor Tolerances (Transaction OBA3)

Permitted Payment Differences

This section refers to the total payment. In other words, you could be receiving one check which is

paying 10 invoices. The total amount of differences for all ten invoices has to be within these tolerances.

Example:


Amount

Percent

Gain

100.00

5.0 %

Loss

100.00

5.0 %

The two fields amount and percent work in conjunction. Given the configuration above, and an invoice

of 1000. The 5 percent would be used since 5 percent of 1000 is 50 which is lower than 100. The actual

payment could be between 950 and 1050 to be within tolerance.

Tolerances for Payment Advices

This section refers to each invoice. In other words, each invoice is checked against these specifications.This section and the one described above work together, further restricting the clearing procedure.

The fields work in conjunction exactly as the other set.

Example:

Tolerances for Payment Advices


15/18

Amount

Percent

Outst.receiv.from

100.00

5.0 %

Outst.payable from

100.00

5.0 %

It is possible that you could have 3 invoices which each are within tolerance and then be out of

tolerance for the entire payment. Given the configuration above and 3 invoices for 1000 each. The

payment received is for 880 (customer deducted 40 from each invoice). Each invoice is within tolerance

because it is less than the 5 percent (50). Adding up the 3 invoices, however, we have a difference of

120. This is not within tolerance for payment differences because it is more than the 100 (amount).

This is less than the 5 percent (150) but the program always uses the lower amount. In the example

above, the percent was used because it was lower; in this example, the amount was lower.

2. Define Tolerance Groups for Employees (Transaction OBA4)


This section refers to the total payment. In other words, you could be receiving one check which is

paying 10 invoices. The total amount of differences for all ten invoices has to be within these tolerances.

These tolerances are used along with the tolerances from the customers and vendors to even further

restrict the clearing process.

Example:


Amount

Percent


16/18

Gain

200.00

10.0 %

Loss

200.00

10.0 %

The two fields amount and percent work in conjunction. The lower limit is the one which takes affect.

Given the configuration above and an invoice for 3000. The amount of 200 would be used since 10

percent of 3000 is 300 which is higher than 200. The actual payment could be between 2800 and 3200

to be within tolerance.

Tolerances defined here work with tolerances defined for customers and vendors. Again, the strictest

tolerance will be used in the clearing procedure. Given the configuration above for both users and

customers/vendors, the parameters in the customer/vendor tolerance configuration would be used

since they are more restrictive than the configuration for the users.

3. Assign Users to Tolerance Groups (Transaction OB57)

If you create a blank tolerance group in the step above, you can skip this step. Users will automatically

be assigned to it. If you wish to have more than one tolerance group, you will have to assign users

accordingly in this transaction.

4. Define Reason Codes (Transaction OBBE)

The 4 record in the BAI file may contain an external reason code which indicates the reason for the

payment difference. You can have the program automatically charge off the differences to other

accounts.

C Charge off Difference

This check box indicates whether the payment difference will be charged off to another GL account or

charged back to the customer account as an open item. Checking the box means that you wish to charge

it off to another account.


17/18

5. Define Accounts for Reason Codes ( Transaction OBXL)

For transaction ZDI, you can define the charge off accounts by reason code.

6. Maintain Conversion Version for External Reason Codes (Transaction OBCR)

Define here the versions for converting external reason codes to internal reason codes.

7. Assign External Reason Codes to Internal Reason Codes (Transaction OBCS)

In this table you map internal reason codes to external reason codes by conversion version. It is

possible to map different external reason codes from different conversion versions to the same internal

reason code.

8. Change Customer Master Record ( Transaction FD02)

In the company code data, payment transaction screen, enter the conversion version and tolerance

group for each customer.

1. OBA3 Define Customer/Vendor Tolerances

2. Enter tolerances for permitted payment differences.

3. Enter tolerances for payment advices.

4. OBA4 Define Tolerance Groups for Employees

5. Enter tolerances for permitted payment differences.

6. OB57 Assign Users to Tolerance Groups

7. Assign users to tolerance groups if necessary.

8. OBBE Define Reason Codes

9. Check the Charge off box for each reason code you create.

10. OBXL Define Accounts for Reason Codes

11. Assign GL accounts per reason code which will be posted for payment differences.

12. OBCR Maintain Conversion Version for External Reason Codes


18/18

13. Create conversion versions which will be used to map external payment difference reason codes to

internal reason codes.

14. OBCS Assign Internal Reason Codes to External Reason Codes

15. Assign internal reason codes to external reason codes by conversion version.

16.

17

18FD02 Change Customer Master Record

17. Enter the tolerance group for the customer.

18. Enter the conversion version for the customer.

OSS Note 45436 Lockbox Transactions

R/3 note no. 45436 19.01.2000 Page 1

________________________________________________

Lockbox Overview

Documents

Transcript of Lockbox Overview