The first question you might ask is, "Why in the 21st century should I be at all interested in a medieval method of payment?" Although this form of payment is never seen in the US or the UK these days, it is still common in France, Italy, and Spain, and is occasionally encountered in Austria (where a bill of exchange is known by its German name "Wechsel").

I am often asked how to set up this very effective means of getting paid in SAP FI. SAP consultants who have never worked in France, Italy, or Spain are often stuck when they come across this requirement and do not know where to start. After I give you some background about the bill of exchange, I'll show the detailed configuration steps.

What Is a Bill of Exchange?

France uses the traditional bill of exchange in paper form. Italy uses electronic bills of exchange called Ricevuta Bancaria or RiBa, and Spain uses a mixture of the two, called Recibo. Processing for all of these is similar in R/3, the main differences being the SAPscripts required for the French and Spanish bills of exchange on paper. Standard forms exist in these two countries, which the SAPscripts must complete. You can buy these forms at specialist stationery shops.

The main difference between a bill of exchange and a check is the body of law behind them. A person or company accepting a bill of exchange by signature is saying in law that they are good for the money. Not honoring the bill of exchange by non-payment on presentation is therefore evidence of bad faith and is considered an act of bankruptcy. A creditor may apply for receivership of the debtor on the strength of the dishonored bill of exchange without further evidence of the debtor's financial position. By contrast, an unpaid check is evidence of a debt and the creditor may sue, but may not normally put the debtor into receivership on that basis alone.

Therefore, bills of exchange have some advantages over checks when it comes to getting paid. French and Italian accountants love them. They make cash flow forecasting easier and a bundle of bills of exchange in the A/R clerk's bottom drawer represents almost certain future cash that can be used as collateral for borrowing if necessary. Processing, when properly set up, is slick, painless, and effective. A bill of exchange is not a payment in itself. It represents a promise to pay at some future date, so it is another form of receivable.

An added refinement in Italy is that a company often asks customers to give a blanket authorization in advance to collect money in this way, so that it does not have to accept individual bills of exchange. This makes the bill of exchange into a form of direct debit (called Rimessa Diretta or RiD), but with that all-important legal protection behind it. You can "stop" a direct debit, but stopping a bill of exchange is a greater risk to your credit rating and is not done lightly.

Getting Started

You start by creating payment methods as usual, via transaction FBZP. Associate an appropriate print program with the payment method (R/3 provides several). Use new posting keys and special G/L indicators by means of which bills of exchange created for customer payments are reclassified to a separate reconciliation account. There you switch on line item display so that you can see your bill of exchange holdings with transaction F.75 (Figures 1 and 2).

Figure 1

Bill of exchange holdings

Figure 2

Detail of bill of exchange holdings with buttons for sorting by usage, due date, commitment bank, and customer (vendor)

The customer line items are cleared, but the bill of exchange shows up as a receivable item on the customer's account, because you do not have the cash yet. The opposite entry is to a "bill liability account" in the G/L, so-called because the bank will hold the company liable for any bills of exchange that fail on presentation.

A refinement in France is that the payment program creates a bill of exchange request, which is sent to the customer for acceptance and return. The request is a noted item in R/3 and does not clear the line items. When the customer returns the signed bill of exchange, you manually process it and convert it from a request to a bill of exchange receivable. At this point you can change the bank details if the customer has written different bank details on the face of the bill. You also enter indicators that are passed to the bank in the data medium exchange (DME) file later so that the bank knows what kind of bill it is and how to process it.

France has three types of bills of exchange — the "accepted LCR" for a single line item, the "accepted LCR with statement" for paying off all items in the customer's monthly statement of account, and the "order bill," or BOR. A BOR is the customer's own bill of exchange, which the customer has substituted for the company's request. Should the customer be tardy in returning the request, a dunning procedure can chase him. Shortly before the due date (the timing varies according to how efficient your bank is) you send all the bills of exchange due on the same day to your bank for collection. In France and Spain, you send both the paper and a DME file. In Italy you send only the DME file. You may or may not be required to send a paper list with it. You process the bill of exchange in R/3 using the standard transaction FBWE. It creates the DME file and updates the bill of exchange status by means of a batch input session so that they cannot be presented a second time. You select a house bank for the collection. The DME file tells the bank what to collect and from whom and then gets the money and credits your account with it.

When a company has the money on its bank statement, it can clear the open items from its bank sub-account to the main account as it normally would when processing a bank statement manually. It also has to clear the bills of exchange themselves. It reverses them against the bill liability account, using standard transaction FBW4.

Should a bill fail, you can use a standard transaction to recreate the debt. You use the transaction S_ALR_87001405 and update the TINSO table. You recreate the debt from there. This does not recreate the individual line items but it sets up the failed bill as a normal receivable (which of course is automatically overdue). Then it is up to credit controllers and maybe lawyers to chase the debtor.

Vendors will also send a bill of exchange for acceptance. The company can set up a payment method and process these in a similar way but without the presentation procedure. Table 1 shows the bill of exchange receivable accounting entries.

Configuration Steps

Now I'll briefly describe the configuration steps in R/3 for bill of exchange functionality.

Step 1. Go to transaction FBZP for payment program configuration. At least three payment methods are needed in France (e.g., LCC, LCR, and BOR) and two in Italy (e.g., RiBa and RiD).

In the company code configuration of payment method, check 1, Accepted LCR, Single payment for line item, because you want the payment method to select individual invoices. In the paying company code configuration, check one bill of exchange per due date. This allows payment method 2, Accepted LCR with Statement, to select multiple invoices.

It is OK to do this, but single payment for line item in payment method 1 is effective only if the payment method is in the open item (the R/3 document representing the invoice that the customer has to pay). The moment the system goes to look in the customer master record for a permitted payment method, the one bill of exchange per due date key overrides the single payment for line item key and items are grouped by due date. The switch in the customer master record described below solves this problem.

It is usual to assign a print program to the payment method. R/3 provides RFFOD__W as the international standard for bills of exchange. Documentation is available when you use transaction SA38 to access it. Create a suitable variant with SA38.

Assign a SAPscript form that the print program can use. F110_FR_CLIENT2, for example, is the standard R/3-supplied form for an LCR with statement. You can customize these forms with your company letterhead. Most companies use them as the starting point to produce their own forms.

Step 2. Use transaction FD02 to maintain the customer master record for payment transactions. The indicator, Pay all items separately?, determines that every open item of the customer/vendor is paid separately during automatic payment transactions. This means that open items are not grouped together for a payment. In payment program configuration, a switch in the paying company code data for line item groups the bills of exchange. The three options are:

• One bill of exchange per due date interval
• One bill of exchange per due date
• One bill of exchange per invoice

Step 3: Define and control status codes. Use transaction OB06 to define status codes used by F-39. F-39 controls the codes that are passed to the DME file identifying the bill of exchange to the bank as LCC, LCR, BOR, RiBa, RiD, etc.

Step 4. Define additional days for remaining risk using transaction OBA8. You define them for a particular postal/zip code area. The days entered here are added to the due date of the bill of exchange during the remaining risk posting, depending on the postal/zip code area to which the customer belongs.

Step 5. Set automatic posting procedures using transaction OBYH. Here you link posting keys to processes for automatic postings, as shown in Figure 3. Double-click on any of the lines to see more detail (Figure 4).

Figure 3

Link posting keys to processes for automatic postings

Figure 4

Detail of the transaction WBW, arrived at by double-clicking a line in Figure 3

Step 6. Define bank sub-accounts for bills of exchange via transaction OBYK. Table T045W aligns the bank sub-account with the customer reconciliation account and the bank sub-account for liability. It is not necessary to enter the customer reconciliation account unless several are involved.

Step 7. Create bank IDs for DME with transaction OBBD. If you do not know the bank ID or do not have one, use 999999. It is important for vendor payments but not so important for incoming (customer) payments.

Step 8. Define an alternative reconciliation account for bill of exchange receivables via transaction OBYN. (See the reference to FS00/FSS1 below.) You can also create new special G/L indicators here and put the accounts behind them by double-clicking on them to descend to the next level. R and W are used for bill of exchange request and bill of exchange. (R means request and W represents the German word "Wechsel.") These are the standard R/3-supplied special G/L indicators. The numbers in the right window in Figure 5 are the G/L account numbers of the reconciliation account for customers and the corresponding special reconciliation account for bills of exchange. This example is from a French company and the accounts used conform to French accounting law.

Figure 5

Detail of configuration of special G/L indicators and the account determination behind them

Step 9. Maintain posting keys and special G/L indicators 09 and 19 for customers with transaction OB41. Special G/L indicators R and W need to be maintained, as shown in Figure 6.

Figure 6

Maintain posting keys 09 and 19. Double-click on the line to see the detail and attach the Special G/L indicators.

Step 10. Prepare bill of exchange charges statement (if applicable) via transaction OB73 (bill discount note). This is rarely seen except in Austria, where charges by the company's bank are recharged to the customer.

Step 11. Set the payment period for the bill of exchange via transaction OB86. This is not needed in most cases. It is an additional period before expiration of the liability after presentation, and rarely occurs.

Step 12. Configure the house bank via transaction FI12. Define G/L account for discounting bills.

Step 13. Maintain house bank details via transaction F.92 (Treasury). Define G/L account for discounting and collection of bills. This is really duplication of the step above, for cash management purposes in the Treasury module.

Step 14. Maintain account determination for bill of exchange presentation via transaction F.78. This is used for charges arising at usage of a bill and is not essential to bill of exchange processing unless charges are common (e.g., in Austria).

Step 15. Create a G/L account with transaction FSS1 (or FS00 for more recent releases) (Treasury). For posting bills of exchange, you have to define the numbers of the corresponding special G/L accounts in the system. The accounts must be indicated as reconciliation accounts for the account type "customer" in the master records. These accounts are used to reclassify the receivables for the balance sheet and are therefore different from the G/L account I described under FI12, which is essentially a bank account.

A distinction can be made for bills of exchange receivable between rediscountable and non-rediscountable bills of exchange using the special G/L indicators. If this distinction is necessary in your country, the bills of exchange should be displayed separately on the balance sheet. You should therefore use separate special G/L accounts for the bill of exchange posting.

You should manage the accounts with line item display so that you can always retrieve a list of all the bills of exchange. In the master records of the special G/L accounts, you can determine your own sort sequence for the display via the field Sort key. In the standard system, sorting by the bill of exchange due date is used.

Step 16. Use the standard SAP procedure for dunning bill of exchange payment requests. You run it with the standard program RFWMAN00. You can modify and customize the standard layout set F_RFWMAN00_10 as required. Run the program with transaction SA38 or with the new Enjoy transaction S_ALR_87012212.

Roy Brookes

Roy Brookes is a senior consultant in SAP FI/CO and a qualified accountant and business consultant. He has worked for many years in accounting, finance, and business consulting. He is an SAP expert and has designed and implemented FI and CO solutions at the European and country level during the European rollouts of SAP R/3 in a number of multinational companies. He has also worked in the US and Turkey.

You may contact the author at Roy.Brookes@Hamburg.de.

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