Contents

Lockbox process.................................................................................................... 1
FAQ..................................................................................................................... 2
Payment advice processing......................................................................................... 3
Configuration........................................................................................................ 3
Lock Box Configuration....................................................................................... 5
Automatic Posting from lockbox.........................................................................6
Customer Master Data........................................................................................ 8
Customer Invoice Posting................................................................................... 9
Lockbox file processing..................................................................................... 10
Notes............................................................................................................... 14
Payment methods in USA.................................................................................... 16
Tax process USA................................................................................................... 16

Lockbox process
Overview
A company can create accounts called 'lockbox' 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 standard banking industry transmission formats: BAI, BAI2 (Bank
Administration Institute).
Advantages of Lockbox
Following are some of the advantages of using the lockbox:
Manual Handling of checks can be avoided
Checks can be processed in time.
Easy reconciliation
Clearing Errors can be avoided
Difference between BAI and BAI2
BAI and BAI2 formats differ in their level of information detail. BAI 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:
an "On account" posting (if the payment and invoice totals don't match), or 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 manual
application to clear payments against open items on the proper accounts.
Conversely, BAI2 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-invoice matching from each transmission is
likely to be higher when using BAI2 rather than BAI formats.

FAQ

What Bank will do?

Bank Receives the payments, create a data file of the customer remittance information and payment
amounts, and deposit the checks into client bank account. On regular basis, Client Company receives
this data file for processing to update in their accounts.

What lockbox data file contain?

Depending upon the choice of services with the Bank, the lock box file will contain information viz.,
Customer name, Customer Number, Customer MICR number ( Bank routing and Account Number),
Check amount, Invoice number, Payment date, Payment amounts and other information.

What is the Lockbox Data Flow?

Customers send their payments to a lockbox. Then bank collects the data and sends (either through
EDI 820 and 823 formats) to R/3 users EDI server (standard Process). The server translates the
message using as standard EDI interface into an IDOC (Intermediary documents) and sends it to the
SAP Server.

What happens in SAP server?

Once the message is received and stored in SAP table, a program is clicked (RFEBLB30 or FLBP
transaction) to check the information stored in bank statement tables and create payment advices
with Payment amount, invoice numbers and customer number.
Payment advice processing

Matching of customer open items

The lockbox program uses detailed information from the payment advice to automatically search and
match customer open items. The document number on the payment advice is matched against the
document number in the customer open item file. Therefore, accurate payment data is necessary for
automatic clearing to take place.

Payment Advice Status

If the checks were applied or partially applied, the advice is deleted from the system after processing.
If the check was unprocessed or placed on account of customer, the advice is kept on file for further
processing.

Post Processing
The post process function entails reviewing the status of the checks applied through the lock box
function. User must manually clear any checks that were on-account of customer or not applied to
customer account.
The Lockbox overview screen details the number of checks in each category. Depending on the status
of the check, the user determines what needs to occur to apply checks.
- On account: If the bank keyed in the correct invoice number, the Lockbox Import Program posts the
payment on account. In the post processing step, you access the payment advice and correct the
document number and upon saving the changes, the post process function clears the open item, deletes
the payment advice and sets the check status to apply.
- Partially Applied: Checks that are partially applied may require further processing. Ex: Check may
have paid 5 invoices, but one was incorrectly keyed. The first 4 invoices would clear. The payment
amount for the 5th invoice would be put on-account and would have to be post processed to clear.
- Unprocessed: Any payment that could not be identified either by customer MICR number (check) or
the document number would remain Unprocessed. Once the payment is researched and the customer
and invoice is identified, it would be applied during post processing.
Configuration

1. Define House Banks

SAP IMG -> Financial Accounting -> Bank Accounting -> Bank Accounts -> Define House Banks
(Transaction Code: FI12)
2. Define Lockboxes for House Banks
SAP IMG -> Financial Accounting -> Bank Accounting -> Bank accounts -> Define Lockboxes for
House Banks
3. Define Control Parameters
SAP IMG -> Financial Accounting -> Bank Accounting -> Business Transactions -> Payment
Transactions -> Lockbox -> Define Control Parameters
4. Define Posting data
SAP IMG -> Financial Accounting -> Bank Accounting -> Business Transactions -> Payment
Transactions -> Lockbox -> Define Posting data
After preparing the lockbox file (for test purpose) execute the following transaction to test the
lockbox configuration:
FLB2: Import Lockbox File
FLB1: Post processing Lockbox Data

Create House banks

A.

Menu Path: Financial Accounting General Ledger Accounting Bank Related

Accounting Bank Accounts Define House Banks

Transaction Code: FI12

Under the house bank create Bank account from FBZP transaction code.

After creation of House bank and Bank account under company code, it should look like this in FBZP
transaction code.

Lock Box Configuration

A.

Path: IMG Financial Accounting Bank Accounting Business Transactions Payment

Transactions Lock box Define posting parameters

T Code: OBAX

Select highlighted row and click on change item button.

Document Number Length: Field is only applicable for BAI record

A.
B.

Num. of doc numbers in type 6: Field is only applicable for BAI record
Num. of doc numbers in type 4: Field is only applicable for BAI record
G/L account Postings: Activate this indicator to make postings to your cash account in the G/L for
deposits. Activating this field is recommended
Incoming Customer payments: Activate this indicator to make postings to A/R sub ledger in order
to clear customer accounts and create residual postings. Activating this field is recommended
Insert Bank Details: Applicable for batch input session name that updates bank details of master
records for customers who have either changed bank information or did not have bank information
maintained for them
G/L account posting type
1 - Creates posting to G/L account for every check in the file
2 - Creates one posting to the G/L account for entire lockbox file
3 - Creates one posting to the G/L account for entire batch

Automatic Posting from lockbox

I.

IMG Financial Accounting Bank Accounting Business Transactions Payment

Transactions Lock box Define posting data

OBAY

Destination: This field should contain the destination code the bank submits to you in your lockbox
file
Origin: This field should contain the your lockbox number (bank account) number at the bank

IMG Financial Accounting Bank Accounting Bank Accounts Define Lockboxes for House bank

Click on first option

Customer Master Data

Transaction Code: XD03

Maintain Bank details in customer master data which bank will send in lockbox file

Customer Invoice Posting

Post one 600 amount customer invoice. Invoice will display in open state.

T code FB70

Open the invoice

Transaction code: FB03

T code: FBL5N (Customer Report)

Below report shows customer item and its not cleared.

Lockbox file processing

SAP gives option of using one of the two standard algorithms for lockbox processing. A
common misrepresentation is that one can create own algorithm which is not correct. We can only use
the pen delivered by SAP. Program RFEBLB00 is the processing program. Documentation can be

viewed for this program from SE38 transaction code. This program contains lot many user exits
whether one can add any additional business logic.
Two algorithms that are used are 001 and 003. If file contains checks that cannot be applied
against specific invoice but for which customer account is known, SAP posts them on the customer
account without reference to any specific invoice. Using algorithm 003, SAP distributes the check
across open invoices, beginning at the oldest invoice and working its way forward until the check
amount is fully distributed.

File Import:

A.

Menu Path: SAP Easy Access Accounting Financial Accounting Banks Lockbox
FLB2 Import.

Transaction Code: FLB2

Save the lockbox file attached with this document and modify the document number in file with open
customer invoice.

Click on green execute button.

Click on back button.

Transaction Code: FLB1

Enter Lockbox details and click on execute button

Select the one which contains data in file. For example if file contains 1123456 is second session
name will be 1123456. Right click on 1123456 and select Process Checks options.

Right click on Session name and click on Process option.

Vendor Document Clearing Report

Again view customer invoice it will be displayed as cleared from the payment received and posted via
lockbox

Notes

1) If you get below message, modify the following in file. Unique key for each lockbox file is its header
record i.e. Destination, Origin name, Date and time. Modify the seconds part and rerun the file.

1) Sap file generation

Use Test Lockbox Generation Programs RFEBLBT2 to generate BA12 format and
RFEBLBT3 for IDOC format. These programs will generate customer open items and a lockbox file
for processing. Utilize program RFEBKA96 to delete loaded test data

2) Sample File Understanding

100MANGDESTINMANGORIGIN130903123557
20000000000000000000000
56660011123557130903MANGDESTINMANGORIGIN
666600200000600000110003900345205865100000002
466600360191800000023 00000000600000000000
766600411235571309030010000060000
8666005112355713090300010000060000
9000000

File content explanation with help of differnet Color Codes

100000002 =Check Number

666 = Batch ID
1800000023 = FI customer Invoice
123557130903 = Date & time in Header (i.e. first record) and Time & Date in below records.
600000 = Check/Invoice Amount depending on Row
110003900345205865 = Customer Master Record Bank details.

3) Sample file of BAI2 program can also be generated from SAP directly on execution of programs

Same can be downloaded and uploaded with just modification of document number else copy from
below location

100MANGDESTINMANGORIGIN130903123557
20000000000000000000000
56660011123557130903MANGDESTINMANGORIGIN
666600200000600000110003900345205865100000002
466600360191800000023 00000000600000000000
766600411235571309030010000060000
8666005112355713090300010000060000
9000000

Relationship between EBS and Lockbox

Assume on Day 1 company receives Lockbox file from bank and on Day 2 receives EBS file.
Day 1 When the bank receives a check from customer with remittance information its sends it in
Lockbox file. Lockbox file when processed will generate below accounting posting
Dr Bank Clearing account - incoming
Cr Lockbox Clearing Account
Dr Lock box clearing account
Cr Customer account (customer sub ledger)
Day 2 when the check is cleared in bank, it appears in EBS. EBS when processed produces below
accounting entry
Dr Bank Main GL
Cr Bank Clearing Account - incoming

Payment methods in USA

1) ACH (takes 2 days to transfer funds. Electronic file generates to send file to Bank)
2) Wire transfer (Transfer Funds immediately. Electronic file generates to send file to
bank)
3) Credit Card Payment

Tax process USA

Sales tax Vs Use Tax:
The sales tax is imposed on retail transactions. It applies to all retail sales of tangible personal
property, and in some states services, in the state. The use tax is imposed on consumers of tangible
personal property that is used, consumed, or stored in this state. Consumers use tax applies to
purchases from out-of-state vendors that are not required to collect tax on their sales. Sales and Use
tax generally applies to most leases of tangible personal property. The sales tax and the use tax are
"mutually exclusive", which means either sales tax or use tax applies to a single transaction, but not
both.
Vertex:
It is a third party tax solution for SAP FICO. Usually it gets integrated with SAP system using RFC. It
gives integrated solution for various kind of tax such as income tax, sales tax, consumer use tax, value
added tax (VAT), payroll tax etc.
It is tax compliance software which makes sure tax compliance for income tax, corporate tax, VAT,
service tax, use tax and other types of taxes. It gets integrated with SAP FICO system and
automatically calculates tax liabilities to government.
Data flow:

SAP Vertex dataflow

SAP VERTEX O - Series Integration:
We do need tax procedures and pricing procedures for integration.

Tax procedure: For this purpose, we need to create a new tax procedure based on SAP country
templates with Vertex tax conditions. Tax procedure assigned to country for output and input tax.

Vertex tax procedure

Pricing Procedures: We can define new or use existing pricing procedure with Vertex defined
condition types.
Tax interface configuration:
External tax interface is appended to receive and pass data between VAT O series and SAP.
SAP code need to be changed to enable other countries to call the external tax interface.
Change:
Vertex O series and SAP interface component (SIC) must be installed for the SAP tax interface
Remote function call (RFC). Establish the communication through RFC and transnational RFC.
RFC destination:
Program ID links RFC to SIC.

Vertex RFC destination

SIC:
SIC links RFC to Vertex O series.

SIC link RFC to Vertex O series

It helps automating tax solution for any organization. It can automate tax system as well provide
accuracy and smooth processing. It automates mostly every aspects of personal property tax,
corporate tax, compliance cycle and other management efforts. With vertex, its easy to get up to date
tax data so an organization can stay informed about it. Moreover, it provides complete set of tools to
help in consumer tax liability and audit purposes.
Vertex Q series:
We implemented SAP ECC 6.0 about 3 years ago, including all core modules, as well as SCM ICH ,
APO/DP and BW. As part of the implementation, we chose Vertex Q Series for the Sales Tax
Jurisdiction and Tax rate determination functions since it was one of the SAP certified offerings
available in the market.
At the time of selecting the software, we had a choice between Vertex Q series and Vertex O series
product lines. We were assured by Vertex that both these products were fully capable of meeting our
needs. We were also told that the 'O' series implementation was more involved while the 'Q' series
product was easily installed and implemented.
We were on a very aggressive implementation schedule, due to various business considerations,
including the fact that our business by nature is very seasonal and our window of going live were
between the months of July through September, otherwise, we would have to wait a whole another
year.
We started the project in December '07 and were to go live August 1, '08! In addition to Vertex, we
had to also implement other packages such as Open Text Livelink, Paymetric PCI and also build
custom interfaces to other legacy systems that would continue to exist post-SAP go-live. In addition,
we had to interface a ton of EDI transactions as well.
Given this backdrop, we opted to implement the 'Q' series from Vertex. As advertised, the install and
implementation of this product were fairly straight forward. We did have some issues integrating with
SAP, but that was mainly due to the SAP implementation team's inexperience in this regard.
We went live on Oct 1, '08 and had a very difficult first 6 months thereafter as is quite common with
any ERP implementation and especially with projects like ours, with such aggressive implementation
times. We immediately started facing numerous issues with the Vertex Q series, almost all of them
relating to US City/Zip codes that when entered on SAP Customer Masters / Vendor Masters or ShipTo addresses in Sales Orders returned 'No Jurisdiction Determined' error, even though these were
either 'Actual' city names or 'Acceptable' city names according to the United States Postal Service
official web site.
We called Vertex support and each time, we were told that the cities in question were not supported in
their database because those cities did not meet their 'criteria' for inclusion. They always also made it
a point to tell us that the Q series was not an 'Address Verification' system, even though we were not
using it for such purposes.

Initially we asked users taking the orders to enter a suitable city for that zip code that was the one
stored in Vertex for that zip-code and in the same county as the 'missing' city. However, we ran into
problems with this because we had shipments going to the wrong place when the same street name
existed in both cities!
We then implemented a workaround via user exit and z-table to pass the actual city name to Vertex,
for such instances and adding entries to this table as and when users reported new instances. This was
manageable for a while, but over time, we are seeing more and more entries being added to the table
as our company begins collecting taxes in more states.
Recently we ran a listing of such missing cities in the Vertex database using a zip-code database we
subscribe to for our Dealer location calculation and found almost 7000 missing cities that USPS
considers Acceptable. We also found more than 100 cities that USPS terms as the Actual cities for
those zip codes.
We also discovered that the Vertex Q series only stores first 25 characters of the city name, even
though SAP allows up to 40 characters and there are a number of cities in US / Canada whose city
name exceeds 25 characters.
We have sent this list to both Vertex and SAP. We had conference calls with Vertex , including
personnel from their Research department and Product Development and while sympathizing with
our problems and admitting that there is a gap in the core functionality, they have refused to add any
of the cities in the list provided and also refused to add any expansion of the functionality to
accommodate these cities. Instead, they are asking us to implement an address verification software
(3rdparty) that will sit between SAP ECC and Vertex and provide Zip+4 codes that may find a hit in
the Vertex Q series database. They do not have a solution using this approach that they can demo and
have been very vague as to what kind of custom development will be needed to interface this
additional software to either SAP or Vertex. Alternately, they want us to implement their O series
product which would involve additional acquisition costs and would be a full implementation
project, since there is no automated upgrade path from Q series to O series. We would need to use
their consulting services to accomplish this as well.
We have not heard back yet from SAP; our Rep tells us that the matter has been referred to Germany.
He has also started talking about the Business Objects Address Verification services, leading us to
believe that SAP will not be forcing Vertex to close the gap in functionality.
We cannot be the only ones facing these issues and we feel quite strongly that the Q series should
not be certified by SAP and Vertex should not be marketing this product for use with SAP.
I would like to invite those of you who have experienced the same problems and would like to hear
how you are handling this.