Вы находитесь на странице: 1из 96

Oona Flanagan

Automatic Payment
Program in SAP®
Accounts Payable:
Running and
Troubleshooting

~ Rheinwerk®

Bonn • Boston
SAP PRESS E-Bites
SAP PRESS E- Bites provide you with a high-quality response to your specific project
need. If you 're looking for detailed instructions on a specific task; o r if you need to
become familiar with a small, but crucial sub-component of an SAP product; or if you
want to understand all the hype around product xyz: SAP PRESS E-Bites have you
covered. Authored by the top professionals in the SAP universe, E-B ites provide the
excellence you know from SAP PRESS, in a digest ible electron ic f ormat, delivered (and
consumed) in a fraction of the time !

Oona Flanagan
Invoice Verification with SAP: Payment Blocks in GR/IR Accounts
ISBN 978-1-4932-1353-5 I $12.99 1100 pages

Janet Salmon
Financial Close in SAP ERP Controlling
ISBN 978-1 -4932-1380-1 1 $9.99 1 89 pages

Marco Sisfontes-Monge
Reporting with CO-PA
ISBN 978-1 -4932-1376-4 I $9.99 I 81 pages

The Author of this E- Bite


Oona Flanagan has more than 16 years of experience implementing and
supporting FICO projects in a number of multinational compan ies. She is
a fellow of the Chartered Institute of Certified Accountants and t he Brit-
ish Computer Society. Oona owns her own company, Jazzmore Solu-
tions Ltd., and continues to work as a FICO consultant. She is also an
SAP Certified Application Professional - Financial Accounting with ERP
6.0 EHP6 and an SAP Certified Application Associate - Simple Finance
On-Premise Edition 1503.
Imprint

This E-Bite is a publication many contributed to, specifically:

Editor Sarah Frazier


Acquisitions Editor Emily Nicholls
Copyeditor Nancy Beckus
Cover Design Graham Geary
layout Design Graham Geary
Production Marissa Fritz
Typesetting SatzPro, Krefeld (Germany)

978-1-4932-1426-6
© 2016 by Rheinwerk Publishing, Inc., Boston (MA)
151 edition 2016

All rights reserved. Neither this publication nor any SA P, the SAP logo, ABAP, Ariba, ASAP, Duet, hybris,
part of it may be copied or reproduced in any form or SAP Adaptive Server Enterprise, SAP Advantage Data-
by any means or translated into another language, base Server, SAP Afaria. SAP Archive Link, SAP Business
without the prior consent of Rheinwerk Publish ing, ByDesign, SAP Business Explorer (SAP BEx), SAP Busi-
2 Heritage Drive, Suite 305, Quincy, MA 02171. nessObjects, SAP BusinessObjects Web Intelligence,
SAP Business One, SAP BusinessObjects Explorer, SAP
Rheinwerk Publishing makes no warranties or repre- Business Workflow, SAP Crystal Reports, SAP d-code,
sentations with respect to the content hereof and spe- SAP EarlyWatch, SAP Fiori, SAP Ganges, SAP Global
cifically disclaims any implied warranties of mer- Trade Services (SAP GTS), SAP Goinglive, SAP HANA,
chantability or fitness for any particular purpose. SAP Jam, SAP lumira, SAP MaxAttention, SAP Max DB,
Rheinwerk Publishing assumes no responsibility for SAP NetWeaver. SAP PartnerEdge, SAPPHIRE NOW, SAP
any errors that may appear in this publication. PowerBui lder, SAP PowerDesigner, SAP R/2, SAP R/3,
SAP Replication Server, SAP Sl, SAP SQL Anywhere,
" Rheinwerk Publishing" and the Rheinwerk Publish ing
SAP Strategic Enterprise Management (SAP SEM), SAP
logo are registered trademarks of Rheinwerk Verlag
StreamWork, SuccessFactors, Sybase, TwoGo by SAP,
GmbH, Bonn, Germany. SAP PRESS is an imprint of
and The Best-Run Businesses Run SAP are registered or
Rheinwerk Verlag GmbH and Rhei nwerk Publish ing,
unregistered trademarks of SAP SE, Walldorf, Germany.
Inc.
All other products mentioned in this book are regis-
All of the screenshots and graphics reproduced in this
tered or unregistered t rademarks of their respective
book are subject to copyright 0 SAP SE. Dietmar-
companies.
Hopp-AIIee 16, 69190 Walldorf, Germany.
What You'll Learn

Learn how to execute the payment process in SAP using the automatic
payment program! Walk through the different payment methods avail-
able, then follow the steps for running a payment proposal. Discover how
to post payments, produce payment media, and process direct debits and
down payments. Finally, since one mistake can send the whole process
out of whack, learn how to interpret system errors and troubleshoot any
problems that arise.

1 The Payment Program at a Glance . . . . . . . . . . . . . . . . . . . . . . . 6


2 Payment Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. 1 Manual and Partial Payments . . . . . . . . . . . . ... .. .. .. . 8
2.2 Bank o r Electronic Fund Transfers . . . . . . . . . .......... 15
2.3 Checks/Cheques . . . . . . . . . . . . . . . . . . . . . . .......... 17
2.4 Di rect Debit . . . . . . . . . . . . . . . . . . . . . . . . . ... .. .. .. . 17
2.5 Credit Cards . . . . . . . . . . . . . . . . . . . . . . . . . ... .. .. .. . 19
2.6 SAP Biller Direct . . . . . . . . . . . . . . . . . . . . . . ... .. .. .. . 19
2.7 SAP AribaPay . . . . . . . . . . . . . . . . . . . . . . . . ... .. . ... . 20
2.8 Bills of Exchange . . . . . . . . . . . . . . . . . . . . . . ... .. . ... . 20
2.9 Payment Method Settings . . . . . . . . . . . . . . . ... .. . ... . 21
3 Running the Automatic Payment Program . . . . . . . . . . . . . . . . . 25
3.1 Status Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Parameter Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Free Selection Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Additional Logs Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5 Running the Payment Proposal . . . . . . . . . . . . . . . . . . . . . 31
3.6 Amending the Payment Proposal . . . . . . . . . . . . . . . . . . . . 35
3.7 Deleting and Rerunn ing the Payment Proposal . . . . . . . . . 37
3.8 Proposal Report Variants . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3 .9 Scheduli ng the Payment Proposal . . . . . . . . . . . . . . . . . . . 41
4 Posting Payments and Producing Payment Media . . . . . . . . . . . 42
4.1 Printout/Data Medi um Tab . . . . . . . . . . . . . . . . . . . . . . . . 43

4
4 .2 Payment Run Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 Payment Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4 Rem ittance Advices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5 Printing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4 .6 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5 Processing Incoming Direct Debits ...................... 50
5.1 Direct Debit Mandate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 SEPA Direct Debit Mandate . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 SEPA Direct Debit Pre-Notification . . . . . . . . . . . . . . . . . . 52
6 Processi ng Down Payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6. 1 Processing Down Payment Requests . . . . . . . . . . . . . . . . . 57
6.2 Clearing the Down Payment . . . . . . . . . . . . . . . . . . . . . . . 61
7 General Ledger Postings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.1 General Ledger Accounts . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2 Bank Statem ents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.3 Clearing the Contro l Accounts . . . . . . . . . . . . . . . . . . . . . . 66
8 Trou bleshooting the Payment Program . . . . . . . . . . . . . . . . . . . 66
8. 1 Mast er Dat a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.2 Checklist to Resolve Issues . . . . . . . . . . . . . . . . . . . . . . . . 75
8 .3 Reversing a Payment or Payment Run 84
9 Miscellaneous ...................................... 87
9. 1 Withholdi ng Tax . . . . . . . . . . . . . ........ . . . . .. . . . . . 87
9.2 One-Time Vendor Accounts . . . . ........ . . . . .. . . . . . 88
9.3 Authorizations . . . . . . . . . . . . . . . ........ . . . . .. . . . . . 88
9.4 Processing Discou nts . . . . . . . . . . ........ . . . . .. . . . . . 89
9.5 In stal lment Payment Terms . . . . . ........ . . . . .. . . . . . 90
9.6 Netting Off Customer and Vendor Payments . . . . .. . . . . . 90
10 What's Ahead for Payments? . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
10.1 Cash Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
10.2 In -House Cash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
10.3 Bank Commu nications Management . . . . . . . . . . . . . . . . . 93
11 What's Next? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5
The Payment Program at a Glance I 1

1 The Payment Program at a Glance


These days, most companies process the majority, if not all, of their pay-
ments through the automatic payment program. The automatic payment
program proposes a list of invoices that are due for payment, which can
be reviewed and approved prior to creating the payments, either printed
or in a payment file to send to the bank.
The automatic payment program (Transaction F11 0) is generally used to
pay vendors and employee expenses, but can also be used to pay custom-
ers if required, or to collect money, usually from customers, where the
appropriate agreements are in place. It can also be used for various other
treasury and financial supply chain management functions. Transaction
F110 is found in numerous places in the SAP menu, for example, under
Accounts Payable, Accounts Receivable, Banks, Cash and Liquidity
Management, Treasury and Risk Management, Foreign Exchange, Deriv-
atives, Commodities, Real Estate, and so on, because it is used by those
different areas.
Just after a go-live, the most frequent support calls raised by financial
users are related to the automatic payment program. Invariably, an error
exists in the master data, however, the system information is not always
clear as to exactly where the problem lies.
In this E-Bite, we explain the various payment methods and review each
of the steps involved in processing payments, as shown in Figure 1. We
explain how payments are posted to the general ledger (GL) and the con-
cepts behind the bank clearing accounts, before delving into trouble-
shooting and suggesting various checks to reduce errors. We explain the
meaning behind some of the more vague error messages and address a
few common issues and what to do if a payment cannot be corrected and
needs to be reversed.

6
The Payment Program at a Glance I 1

Print
Enter parameters remittance
payment
advices

Fi gure 1 Automatic Payment Program Flow

In this guide, we talk specifically about the standard functionality of the


SAP automatic payment program, which is where most of the problems
arise, but we also cover manual payments briefly as well, for occasions
where it may be impractical to use the automatic payment program.
Technically, it is possible to process almost everything using the auto-
matic payment program, but to do so, a document must exist on the ven-
dor/customer account, and have the correct bank and vendor master data
appropriate for the payment method being used. If there is a payment
block, such as an error or a mismatch with the master data, the automatic
payment program will not be able to process the payment. Normally, the
error should be corrected, and the payment rerun, but there can be excep-
tional cases where companies prefer to make a manual payment and
update SAP manually.
Areas where you may not have a complete document on the account for
the automatic payment program to pick up include partial and down pay-
ments. SAP standard functionality is available for both down payments
(see Section 6) and partial payments. However, if they don't occur very
often, some companies may prefer to post them manually, which we
cover in Section 2.1.
The next section discusses payment methods. We begin with those that
are difficult to process with the automatic payment program, and discuss
the options for using manual payment methods.

7
Payment Methods I 2

2 Payment Methods
This section discusses some of the different types of payment methods
available in SAP for both customers and vendors, and their corresponding
payment media formats. We start with how to use Transaction F-53 (Post
Outgoing Payments) ifyou are not using the automatic payment program.

2.1 Manual and Partial Payments


This section discusses how to process both manual and partial payments.
The automatic payment program can produce a payment file to upload to
the banking software, or it can generate printed checks. However, in the
case of a manual payment, the payment must be entered manually into
the online banking software or check raised outside of SAP.

Manual Payments
In cases where it is necessary to create a payment outside of SAP, you can
still use the automatic payment program to post the payment to the
accounts without generating a physical payment. This may be preferable
if the same users are making both manual and automatic payments in
order to keep the same process, workflow, and authorizations. It may also
be useful if a remittance advice still needs to be printed. However, Trans-
action F-53 (Transaction F-31 for customers) is an alternative transaction,
but without any output (such as a remittance, check, or file) that could be
used instead of the automatic payment program to update SAP with the
payment.
When using Transaction F-53 to post a payment against a vendor invoice,
you can pull in invoices to pay from other vendor accounts, or from cus-
tomer accounts to, for example, deduct a customer invoice when paying a
related vendor. (Although some of this can be done with the automatic
payment program, you would first need to link the accounts in the master
data to do so.)

8
Payment Met hods I 2

You can also use Transaction F-53 to manually post a partial payment or a
payment on an account, as well as post bank charges. However, a manual
payment on an account will just be a posting to the vendor; whereas the
down payment functionality in SAP (see Section 6) creates a statistical
document for the automatic payment program to pick up and create the
pay m ent media automatically.
Transaction F-53 consists of three sections: the HEADER, BANK DATA, and
the OPEN ITEM SELECTION (see Figure 2). After you fi ll in the normal fields
(date, company code, currency, amount, bank and vendor or customer
accou nt number, and so on) and press I Enter I (or the PROCESS OPEN ITEMS
icon), you are presented with a list of open items where you can select
w hat you want to clear. If the open ite m amounts appear in black, they
are not selected; double-dick them to select them. If they appear in blue,
they are already selected.

Post Outgoing Payments: Header Data


Process Open Items

Ooc..-nent Date 116.03 . 20161 Type §1 C~any Code 13000


Postng Date
Ooc..-nent l>klrrber
116 . 03 . 20161 Period n Currency{Rate
Translatn Date
[UsD

Reference Cross·CC no.


Ooc.Header Text Tracing l)art.BA
Cleari:l;l text
Bark Data
ACCCU1t 113172 Bustless Area
1
AlllOI.I1t 100 Amount in LC
Bark cha-Qes LC bank charges
Value date
Text
:=====------, Profit Center
Assignment

Open [tern Selection Additional Selections


Account r:-
11o=-=
o-=-
o ---..,
@ None
ACCCU1t Type fKJ O Other accounts Q Amoont
Special G/l ind r - - l0 s tandard Dis Q Document Number
Pmnt advice no. , 0 Posti1g Date
D Dist<ibute by age Q Duming Area
t.: J
0 Automatl: sea-ch Q others

Figure 2 Transaction F-53 - lnitial Screen

9
Payment Methods I 2

Tip
You can change the default settings by selecting the EDITING OPTIONS icon
on the transaction screen, then ticking the box marked SELECTED ITEMS IN I-
TIALLY INACTIVE, and saving (see Figure 3). You wil l then be returned to the
OPEN ITEMS screen.

Accounting Editing Options

Open Item processing


Q Payment reference as selection criterion
0 Process open items with commands
0 Selected items initially inactive
D Enter payment amount for residual items
o use worklists
0 Display net amounts
n inclde invoice reference
O sorti'lg by amcx.nt without+/ · sign

Figure 3 Accou nti ng Editing Options

Notice in Figure 4, that the one item of USD70 has been selected. At the
bottom right you can see that the amount entered on the initial screen
was USD100 leaving a balance of USD30. Until the balance is zero you
will not be able to post the payment. In this case, either you can make a
partial payment against another invoice with the remaining 30 or you can
post it as a payment on account.
If making a part payment, for example, against the amount of 50, you can
choose to either leave the 50 and show the part payment of 30 separately
(go to the PARTIAL PMT tab) or you can clear the 50 and just show the
remaining balance of 20 (go to the RES.lTEMS tab). If using a partial pay-
ment, double click to select the relevant invoice and then amend the pay-
ment amount to the amount actually paid, that is, 30. If posting a residual
item, you need to enter the amount that is left, that is, 20, and you will see
from the NOT ASSIGNED amount at the bottom right if you are correct.

10
Payment Methods I 2

Post Outgoing Pt~yments Process open iten:~s

kl l1!' Distribute Difference Charge Off Difference ~ EdtinQ Options 111 Cash Disc. Due

. /sti'l'lda'd " Partial Pmt Res.Items WHTax I


AA:aJU'lt items 1000 C.E.B. BERLIN
Doc<.ment ... D.. Dorun ... P.. Bu ... Da ... USD Gross CashDiscount CDPer.
5100000074 JU: 20. 04 . 2 ... 31 1000 3. 9_ 70, 00-
510000 0075 JU: 20 . 04 . 2 ... 3 11000 3 . 9 _ 60 , 00-
5100000076 JU: 20 . 04 . 2 - 31 1000 3 . 9 _ 50 , 00-
5100000077 JU: 21. 04 . 2- 31 1000 3 . 9_ 10 , 00-
510000 0076 JU: 11. OS . 2- 3 1 1000 3 . 9_ 997 , 00-
5100000003 JU: 22 .11. 2._ 31 9900 l. 9_
510000 0004 JU: 22 .11.2._ 31 9900 l. 9_
r
L
.
1.150, 00-
?25, 00-
,
J

~

~ @]~ ~ I@J!ro Amo.j I~ Gross<.: jM-currency 11?- uems 111' Items lit Disc:'~~¥' Disc.

Processing Status
Nlmber of Items r1 Amount entered
,.---
100, 00-
Display from item f'll Assigned 70,00-
Reason code I' Difference postings
Display in clearing currency Not assio;1led
,--- 30, 00- l

Figure 4 Open Items to be Selected for Clearing

The easiest way to post a payment on account is to select Goro • Docu-


MENT OvERVIEW from the top menu. Then, at the bottom of the screen
(see Figure 5), manually post the payment on the account by selecting the
PsrKY for the relevant account type and description. For example, posting
key 25 is a vendor outgoing payment and posting key 26 is a vendor pay-
ment difference. They both behave the same, but their difference may be
useful at a later stage for reporting (you can sort and filter by posting keys
in the line item reports). You can also get to the same screen by selecting
the CHARGE OFF DIFFERENCE icon, as shown in Figure 4. After selecting the
posting key, you need to enter the customer or vendor account and press
I Enter 1. On the next screen , enter the amount and any required text.
If the account has no items (you get a warning message, but can still con-
tinue by pressing I Enter I), you can select Goro • DocuMENT OvERVIEW
from wherever you are and repeat these steps.

11
Payment Methods I 2

Post Outgoing Payments Display Overview


~ Process Open Items Ch:lose open items ~"Display Currency Account Model IIJ Taxes
Docunent Date 116. 03 . 20161 Type IKz1 Company Code [3ooo]
Postrog Date 116. 03 . 20161 Period fJl Currency [UsDl
1
Docunent Number [iiiTERIIAil Fiscal Year 20161 Translatn Date 116.03 . 2016\
Reference Cross-CC no. L
Doc.He.ader Text
Items in document currency
Trading pa-t.BA n
PK Bu•A Acct USD AmoWlt Tax aJIUlt.
001 so 0000113172 Cho.•e CDA - lli te OU 1 00,00-

D 0,00 c 100,00 100,00- • 1 Line items

Other lhe Items


PstKy [ I Account I
L
Hype New co.code

Figure 5 Initial Screen for Posting of Payment on Accou nt

After you complete the posting, and tihe NoT ASSIGNED amount is zero,
you can save and post the payment Note that if an invoice is already con-
tained in an open payment proposal, you will not be able to clear it until
the payment proposal is either posted or deleted. The invoice might be
blocked by the proposal as an exception even if it is not going to be paid.

Partial Payments
Most companies normally hold back the whole payment and wait for a
credit note or send a payment on an account rather than partially pay an
invoice. If you did make a partial payment, you would probably post it
manually.
However, if making partial payments is something that occurs frequently,
you have two options, depending on how the partial payment is calcu-
lated. For example, you regularly receive an invoice for X amount and you
always pay 10% right away, then 40% after one month, and the balance
after two months. In this case, you can set up an installment payment

12
Payment Methods I 2

method that allows you to split the vendor side into three line items when
you iPOSt the invoice.
If you find that you are making partial payments for irregular amounts
because of queries that are taking time to resolve, you can use the pay-
ment request functionality. This may not be fully configured as standard,
so you may have to raise a request with your support department/consul-
tant to set it up for you. It has similar functionality to the down payment
process, which is described in Section 6 but a bit simpler.
The first step in posting a partial payment is to post a statistical document
to the vendor account linked to the invoice that you want to partially pay,
so that the automatic payment program has something to pay. This is
done using Transaction F-59, where you enter the invoice number, com-
pany code, and fiscal year on the first screen (see Figure 6). If you have
already made postings against that invoice, a popup will appear listing the
payment requests and partial payments.

Payment Request Initial screen


~ Document Header ~ Line Item oS<r Display n voice

Payment request for n voice


Document Number ~
19,..,-
00,...,.
o.,...,
oo-,-,
oo,.,.,
6l
1
Company Code 2000
Fiscal Year I2016
Ln e item n
Figure 6 Payment Request Initial Screen

The next screen (see Figure 7) allows you to adjust any header items (date,
document type, header text). If all is okay, continue to the next screen by
pressing I Enter 1.

13
Payment Met hods I 2

Payment Request Header Data

Document Date Type ~ Coflllany Code l2ooo


Postilg Date Period fs' Currency/Rate IGBP I
Document Nuni>er Translatn Date 0 1. 05 . 201 6
Refereroce INSTALL
Doc.Header Text

Line It em
1
Vendor 100563
Postilg key 391
Specia I G/L ind

Fi gure 7 Payment Request Second Screen

On the last screen (see Figure 8), you will see the invoice amount or the
remaining amount if there were other partial payments against it. You
need to change this to the amount that you want to pay and then save. At
this point, the normal vendor items will show only the invoice amount.
However, if you select N OTED ITEMS prior to displaying the line items, you
will see a debit of the partial payment amount, but being a statistical doc-
ument there is no entry to the GL.

P11yment Request Add Vendor item


¢ More data

Vendor 100564 ] SubsidiaiY COfl'4)any Lt d G/L Ace 16400 4


1 zooo
Co Code 15 raiway d
BestRun UK watford
Payment request f 39 P
,..
Amount ~o , ool GBP Tax code
Bus. Area 9900
Payt Terms Oaysfpercent
Baseln e Dte 28 . 03 . 201 6] Foced
Disc. b:ase 2. ooo, oo Disc. amount o, oo -----,
InvoiCe ref. 100000002 jt 2016 1 '1l
Pmnt Block 'l Pmt Method 1
Assignment
Text

Fi gure 8 Partial Payment Request - Vendor Item

14
Payment Methods I 2

If you drill down into the document, you will see that it is linked to the
invoice. The final step is to block the invoice itself so that you do not pay
that as well. When you run the payment program, it will pay the statisti-
cal document so that you end up with the two line items afterwards: the
original invoice and the partial payment. The partial payments will stay
on the account until you pay the rest of the invoice, at which point, you
unblock the invoice, and the payment run will pick up the whole of the
final invoice and automatically deduct the partial payments against it and
pay the difference.

2.2 Bank or Electronic Fund Transfers

For the purposes of this E-Bite, we wm use the term bank transfer (also
known as Electronic Funds Transfer [EFT]) as a generic term to refer to all
electronic files containing payment information used by the bank to pay
vendors. The exact format and speed may vary considerably and the
method of transferring the payment to the bank may be more or less
automated. However, there is generally less work involved in producing a
bank transfer; for example, no printing, stamps, envelopes, posting, and
so on.
Generally, most countries seem to have at least two main methods for
transferring money electronically. One is often a free or low-cost option
such as Bankers Automated Clearing Services (BACS) in the UK or the Auto-
mated Clearing House (ACH) in the United States, but these usually take
longer as they go in batches through clearing houses that have been set up
to allow electronic payments to be made across many different banks. The
other method, sometimes known as a wire transfer, tends to be dealt with
individually by the banks, therefore increasing the cost. A wire transfer is
normally used for high value or urgent payments and is usually processed
either immediately or the same day, assuming the transaction is initiated
before the cutoff time.

15
Payment Methods I 2

In the following subsections, we go into more detail about a few of the


different bank transfer methods. In Section 3, we'll discuss how to post
the payments to SAP. In Section 4, we'll explain how to create the pay-
ment media, that is, bank transfer files, checks, and remittance advices.

SEPA
Single Euro Payments Area (SEPA) has been introduced throughout
Europe to provide a consistent, simplified approach to domestic and
cross-border payments in Euro.
The SEPA credit transfer has replaced national Euro transfers in all Euro
countries and will soon be used for Euro payments in all non-Euro coun-
tries as well. More recently, SEPA direct debits have also been introduced.
The SEPA credit transfer uses XML format and requires the bank account
number to be in International Bank Account Number (I BAN) format.

BACS & FPS


BACS is the main UK payment method, originally producing credit and
debit transfer files in text format, which had to be uploaded to a system
connected to BACS. Traditionally, it took up to three days to clear a pay-
ment, but recently they have introduced the Faster Payments Service (FPS),
which allows almost real-time payments between many banks within the
UK. They are usually used for making lots of small value payments, for
example, to suppliers and employees, and are usually free of charge, but
are only in sterling.

ACH
ACH is the US equivalent of BACS. This also produces debit and credit
transfers. Like BACS, the payments are handled in batches through a
clearing house, so it is the cheapest form of payment, but not the fastest.
However, the delay in payment allows more time to detect errors or
fraud.

16
Payment Methods I 2

WIRE
In the UK. wire transfers are known as Clearing House Automated Payment
System (CHAPS), and are used for same day sterling transfers. In the US,
Fedwires (operated by the Federal Reserve) are more common, and in
other parts of the world, the Socie0' for World Interbank Financial Telecom-
munications (SWIFT) is popular.
In most countries , wire transfers are typically used only for urgent or
large payments, particularly when buying property, as they are quite
costly. If rarely used, often companies don't bother to create the file for-
mat in SAP but create the wire directly in the banking system. File for-
mats can be created in SAP, although additional programming may be
necessary if the required format is not pre-delivered.

2.3 Checks/ Cheques

European countries are using checks less as bank transfers tend to be


quicker and more secure. If you are printing checks you need special sta-
tionery that has to be correctly lined up on the printers. There is also a
risk of counterfeit or checks being lost or delayed in the post. Envelopes
are usually required, which is also time-consuming, both putting checks
in envelopes and opening them at the other end. However, some coun-
tries still use them as they may be cheaper and they allow a grace period
before the money actually leaves the payer's account.
In the US and some other countries, you can reduce fraud by providing
the banks with a file that lists the checks that have been issued so the
banks can verity the checks against this list. This file is called a positive pay
file, but the format varies from bank to bank so each company may need
a bespoke program to create the file in the required format.

2.4 Direct Debit

In this section, we discuss both incoming and outgoing direct debits.

17
Payment Methods I 2

Incoming Direct Debits


As mentioned in Section 2.2, methods such as SEPA, BACS, and ACH can
also be used to collect direct debits as well as produce credit transfers,
along with direct debit formats in other countries. The exact process is
detailed in Section 5. Typically, direct debits are restricted to local cur-
rency, although SEPA direct debits are made only in Euros regardless of
the local currency and can be made cross-border, as long as both cus-
tomer and vendor are within (and hold bank accounts within) the SEPA
area.
The automatic payment program in SAP can be used to collect direct deb-
its from customers in much the same way as it is used to make bank trans-
fer payments to vendors. The file format is often fairly similar. The direct
debit payment method will be configured for incoming payments instead
of outgoing, and you may want to send a document at the point of the
payment proposal to notify the customers of what you are collecting. If
they then query the payment, you can still amend the proposal before
making the actual payment collection. Section 5 will go into more detail
abou t processing direct debits and creating pre-notifiications.

Outgoing Direct Debits and Standing Orders


The main difference between outgoing direct debits and standing orders
is that a standing order is initiated by the payer and is for a fixed amount,
and the direct debit is initiated by the payee and can be a variable
amount. There are various ways to post them in SAP. For example, if you
have leases, rents, rates, insurance, or something where the amount is
unlikely to change much, one option is to use a recurring journal to post
the charges directly to the cost account, but if there is VAT, you may pre-
fer to post by way of a vendor account. If you are posting to the vendor
account, you don't want the automatic payment program to pick up the
invoice and try to pay it. Therefore, rather than try to remember to block
each invoice, you can either block the vendor (assuming there are no
other transactions on the account that need to be paid) or set up an out-
going payment method specifically for direct debits and standing orders

18
Payment Methods I 2

without any payment media attached. This allows you to use the auto-
matic payment program to run a payment listing of all invoices that
sholl!ld have been paid this way and check it against the bank statement.
If all payments match the invoices, then all you have to do is click PosT
PAYMENT RuN and all the invoices can be paid in one go, as opposed to
going to each vendor account one at a time and manually clearing the
invoices.

2.5 Credit Cards

It is possible for a company to pay its vendors using a credit card, though
this is probably more common on the sales side where sales are made
directly to the public. This might occur when a company is struggling
with cash flow and requires additional time to pay. In its simplest form,
the physical payment can be made online or over the phone to those ven-
dors that take credit cards. A payment method for credit cards can be cre-
ated for use by the automatic payment program to clear the invoices paid
by credit card. There are probably more automated methods of sending
the credit card payments by way of interfaces to the vendor, but as they
will vary by company and credit card we will not go into the details here.

2.6 SAP Biller Direct

SAP Biller Direct is part of SAP Financial Supply Chain Management


(FSCM). It automates some of the accounts receivable flow by putting
invoices from SAP Customer Relationship Management (CRM) or Sales
and Distribution (SD) onto a portal to be viewed by customers who can
then dispute or approve them for payment, as well as set up or amend any
bank or credit card details. The invoice is automatically blocked until the
invoice is approved. Payment can then be made either by credit card or
collected by direct debit when due. The invoices are cleared at the same
time by using the automatic payment program.

19
Payment Methods I 2

2.7 SAP AribaPay

SAP Ariba is a cloud-based company that was acquired in 2012 by SAP as


a procurement network, but it also covers the reconciliation and payment
side. It is similar to SAP Biller Direct, but from the opposite angle, and
allows suppliers to see the payment status of their invoices.
SAP Ariba now has its own payment process, but some companies still
use SAP Ariba just for the procurement process and continue to use the
automatic payment program for the actual payments, sending the pay-
ment data back into SAP Ariba.

2.8 Bills of Exchange

Bills of exchange are more common in countries such as France, Italy, and
Spain, with slight differences among the countries, and are considered
more secure than an ordinary check. The principle behind the bill of
exchange is that a signed document is issued as a promise to pay a specific
amount on a specific date. The term bill of exchange can broadly cover a
number of different items (drafts, letters of credit, bank drafts, checks,
money orders, and so on), but in international trade it tends to have a
more specific definition.
Checks are usually sent by the payer (customer) on or after the goods or
services have been delivered and are typically restricted to domestic use
in local currency. However, bills of exchange are arranged in advance, are
usually cross-border, and are initiated by the seller. A check might not be
received when the invoice is due (it may be delayed either in the post or
because the payer might try to delay payment), but the bill of exchange is
already there and the bank will pay it when due. Bills of exchange can also
be discounted with the bank to obtain earlier payment.
If, as an exporter, you agree with your buyer to use a bill of exchange as a
method of payment, you will need to monitor the status of the bills of ex-
change (that is, which ones have been presented to the buyer for signature,

20
Payment Methods I 2

which ones have been presented to the bank for payment, and so on). You
also need to mark the invoices being paid so that you do not collect pay-
ment by another method. SAP manages this with the use of special GL
indicators , to allow you to post the bill of exchange against the customer
invoices, but still keeping the liability open on the balance sheet.
On the other hand, if paying by bill of exchange (that is, you are the
buyer), less monitoring is required and you can either post the payment
manually or use the automatic payment program, when the bank con-
firms that the money has gone to the payee. Either way, you may want to
set up a dedicated payment method for bills of exchange to ensure that
payment is not made by another method in error.

2.9 Payment Method Settings


Typically, one payment method is created for each type of payment and
can be linked to a payment media format, such as a bank transfer file (or
check). Historically, changes to a bank transfer file format required an
ABAP programmer, but there is now a new payment media workbench
that is much easier to use for consultants, without the aid of program-
mers.
The bank transfer format contains some mandatory fields. It also contains
some conditional checks that allow one format to be used by similar pay-
ment methods, and can sometimes also confirm that the country or cur-
rency is compatible with the payment method.
Consultants will configure the bulk of the settings. This section provides
information on some of the settings to give a greater understanding of the
options available for each payment method, and discusses the importance
of the payment method settings being consistent with other areas.

21
Payment Methods I 2

User IDs
Before setting up automated bank payments, most banks require you to
register for online banking. Usually some kind of identification is
required. For example, BACS requires a unique six-digit Service User
Number (SUN), which is the number for your specific company at the
bank (not the bank account number). SEPA requires a creditor identifier
of the company collecting payments and a mandate ID for each customer
they collect money from. The creditor ID will have a different format
depending on the country.

Incoming and Outgoing


Although a payment method can be Ulsed for vendors or customers, or
both, it can only be used for either outgoing or incoming payments.
Therefore, if you have a payment method, for example, direct debits, you
need to check that it is for incoming if you want to use it, for example, to
collect payments from customers and outgoing if you want to use it to
clear for vendors.

IBAN, BICS, and SWIFT Codes


The IBAN is mandatory fo r banks in the Eurozone as of February 2016
and comes from the vendor master data.
The Business Identifier Code (BIC) identifies the financial institution, usu-
ally a bank or building society and is often used interchangeably with
SWIFT. From February 2016, as the IBAN becomes fully mandatory for
SEPA payments, at the same time, the BIC/SWIFT will stop being manda-
tory. However, many companies will have it set as mandatory prior to
this date, and it may be required for non-SEPA payments, which means,
particularly if you are working on a global system, and bank master data
may be shared across different countries, you may want to keep the field
mandatory.
The iBIC/SWIFT is pulled into the bank transfer file from the bank master
data that is linked to the vendor bank account. It can be either 8 or 11

22
Payment Met hods I 2

characters; the first four characters identity the bank code, the next two
the ISO country code, then the seventh and eighth a location code
assigned by the Registration Authority. The last three characters are
optional, identifying the branch.
SAP will automatically propose an IBAN, based on the information held
in the SWIFT field of the bank master , together with the bank key/sort
code and bank account number, but you can override the number manu-
ally (see Section 8). You may, therefore, want to keep the SWIFT so that
SAP can propose the !BAN automatically. The user then just needs to dou-
ble check that the IBAN is correct rather than risking typing errors by
entering it manually.
The key point about these fields is that if a bank transfer file format for a
particular bank requires an IBAN or a SWIFT/BIC code, or both, and those
fields are also mandatory fields in the payment method configuration,
then you will see an error in the proposal stage of the automatic payment
program run and can easily fix the problem. If the SWIFT code is required
in the format, but not set as mandatory in the payment method configu-
ration, then the payment proposal will post and clear the invoices, but
exclude the payment from the bank fil e, at which point it will be much
harder to fix , and may not be spotted until reconciling the bank figures
later.
Figure 9 and Figure 10 show some typical payment method configuration
fields, just to give you an idea, although as mentioned earlier, these fields
are normally completed by the consultant or support department.

Foreign payments/foreign currency payments _


0 Foreogn bus 1ess partner alowed
iv) Foreron currency alowed
ncuS': vendor bank abroad allowed?

Fi gure 9 Fields Configurable at Company Code Level

23
Payment Methods I 2

Payme nt met hod for


-
(i) Outgof1g payMents
() 1 1cormg payments

Payme nt met hod classification


-
lolBa •k trans
0Check
OB'Jex
QCheck/bll/ex.

0Post office curr.acct method> 0 81 of exch. accepted


[]Aiowed for personnel payments []ISR Payment Procedure
Oereate b exch.before due date OEU Jnterna Transfer

Requred master record specifications Posti'lg details


nsL eet,P.O.box o P O.bo ~st code Document type for payment
~ Bank detals Clearilg document type
0 Account Uurroer ~equred Sp.G/ L ind.b/ex./ b/ ex.pmnt req.
RJ 18~1 ReQured 0 Pa,ment o aer on
W) S'' 1FT Code Requred
Oco ect10n authorllatiOn
OSEPA Mandate Requred

Fi gure 10 Fields Configurable at Country Level

Collection Authorization/ SEPA Mandate


The COLLECTION AUTHORIZATION and SEPA MANDATE REQUIRED fields are
used for direct debits. These fields wor k with the customer master data,
so if you have either of these fields mandatory in the payment method,
you will not be able to take a payment until you have confirmed in the
customer master that you have a mandate or authorization on file. See
Section 5.1 and Section 5.2 for more information.
In the next section, we will explain how to run the automatic payment
program.

24
Running the Automatic Payment Program I 3

3 Running the Automatic Payment Program


This section introduces the automatic payment program (Transaction
F110) and takes you through the initial steps to produce a payment pro-
posal. In addition to setting up and running the payment proposal, we
also discuss checking, amending, deleting, and rerunning it as required.

Typically, you would run a list of proposed payments and review the list
prior to making the payment. Some companies require the list to be phys-
ically printed with all the documents attached or just invoices over a cer-
tain value. Other companies require it be reviewed online , perhaps with
random checks into the detail. Generally, if you were using purchase
order processing, you would expect the purchase to have been approved
before ordering, and the goods to have been receipted. Therefore, no fur-
ther approval should be required for the individual invoices.
Most companies will check the total of the payment run to ensure there is
sufficient cash in the bank account to cover the payment. At this stage,
invoices can still be added or taken out.

The automatic payment program consists of numerous tabs to help create


the payment proposals. The next section explains the STATUS tab.

3.1 Status Tab


When you enter the automatic payment program by way of Transaction
F11 0, the first screen defaults to the STATUS tab. Initially, you see a red cir-
cle with the information No PARAMETERS ENTERED YET and then as each
step is executed you see a yellow triangle with the description of the step
in pr ogress; for example, PROPOSAL Is RUNNING, finishing with a green
square and the appropriate comment as the step is completed. Figure 11
shows a completed proposal with the most common messages, but you
may see others; for example, PAYMENT PROPOSAL HAS BEEN EDITED
appears if you have made any changes to the initial payment proposal.

25
Running the Automatic Payment Program I 3

Automatic Payment Transactions: Status


~Status .lJPayment ~Proposal .lJProposal 'g ' Printrut

Run D<lte
Identification

. /Status -,_ Parameter Free selection Addtional LOQ Printout/data mediLm

Status
0 Parameters have been entered
0 Payment proposal has been created
0 Payment rt.11 has been carried out
Posting orders: 1 generated, 1 coJTI)Ieted

Figure 11 Automatic Payment Program: Status Tab

The flrst step is to assign a code or ID so that you can identify this specific
payment run later. The ID is a combination of the run date and the iden-
tification. Some people use their initials for the IDENTIFICATION field, but
we suggest using something that helps you to find your own payment run
among the payment runs of all other company codes on the same system.
For example, you could have the first two digits identify the company or
country, the second digit could be the type of payment (for example, C for
check, T for transfer, S for SEPA) and the last two digits could be the
sequential number for that day. Therefore, if you have on average two or
three check runs a day, you would keep the same date and the first may
be USC01, the next USC02, and so on, for a check run for the US.

Note
If you are using the Bank Commun ications Manager tool and merging pay-
ments, you may need to reserve the in itial letter of the ID to identify which
payments should be merged.

The next step is to enter the parameters or selection criteria to tell the sys-
tem which vendors or customers you want to pay. This is explained in the
next section.

26
Running the Automatic Payment Program I 3

3.2 Parameter Tab

Parameters are entered in the PARAMETER tab next to the STATUS tab (see
Figure 12). You can either copy the parameters from a previous payment
run (choose the COPY PARAMETERS icon at the top left in Figure 12 and
then select the payment run that you want to copy) or you can manually
complete each field.

Regarding dates, you only need to complete the CuSTOMER ITEMS DUE BY if
you are paying any customers. If, for example, you create a payment run
on March 171h, the Docs ENTERED UP TO will default to March 17th. How-
ever, if for some reason the payment run is not completed until the 18th
or 19th ofMarch and during that time you have posted additional invoices
after the original date, you will need to amend this date in order to pick
them up.
The NEXT P/DATE is technically the POSTING DATE OF THE NEXT PAYMENT
RuN, (if you click on the [TI] help button), but in practice it is used to con-
trol the date up to which you want payments to be selected. If, for exam-
ple, you have a payment run every Wednesday, and you put the date of
the following Wednesday as the next posting date, the system will assume
that you do not want to pay anything late. Therefore, it will pay every-
thing that has a due date up to the day before the next posting date, leav-
ing everything due on or after the next posting date to be paid in the next
payment run. You may decide to pay only items due up until the current
Friday and everything after that in the following payment run, in which
case you would enter an earlier date.

You are able to enter more than one company code only if all those com-
pany codes are in the same country. You can also enter more than one
payment method if required and you do need to give a range of vendors
(unlike elsewhere, a blank means everything), however in practice most
companies prefer to do separate payment runs per payment method,
especially if they are physically different, for example , a bank transfer and
a check.

27
Running the Automatic Payment Program I 3

Autom•tlc P•yment Tr•ns•ctlons: P• riii1Jeters


L0 §, B.ex./pmt request ...

RU1 Dat e [17. 03 . 2016


Identification [usnn I

Status " Parameter Free selection Ad<itklnal Log Pttltoul/data medUn l _[


PosthgDate 117 . 03 . 2016 Oocsentaed<.c:>to
CUstomer ttems due by
Paym&nts control
Corrc>anY codes Pmt meths Next p/date ,J
3000 T t ;.o.;j. Z016 J:l
_:_j

AccOlrlts
Vendor 1000 to 19999-----,
Custaner to

Figure 12 Automatic Payment Program: Parameter Tab

The next section discusses the FREE SELECTION tab, which allows you to
use additional selection criteria to restrict the proposal.

3-3 Free Selection Tab

The FREE SELECTION tab (see Figure 13) features numerous options to filter
and restrict fields found in the vendor or customer master or document.
By d icking on the dropdown, you can choose in which area the field you
are looking for is. Ifyou select, for example, DocUMENT, you will see a list
of fields such as DOCUMENT NUMBER, DOCUMENT TYPE, and SO on. Simi-
larly, if you select VENDOR MASTER RECORD, then you can choose vendor
master data, such as country or account group.

Tip
Field names that begin with LFA1 are items in the global master data and
field names that begin with LFB1 are company-code specific. Fields in the
purchasing data are not available here. KNA1 and KNB1 are similar but for
customer master data. BKPF is document header and BSEG is line item fields.

28
Running the Automatic Payment Program J 3

AuttN7Uitic P•yment Tr•ns.ctions: Free Selection


§,

Rlll D.lt9 l i i i fzo161


Jdentif'catJ::n USTOl

V<I.Jes

AeldN;m>
V<I.Jes r------

AeldN;m> .-~~~~==
V<I.Jes

:®Oocunent
selectt'n a1te:rla 0 Vendc:l" master record
Field Nome Oocl.l'l'Ent fol.trber 0 Cust. master recod
V<I.Jes 0019000001,0019000006

Fi gure 13 Automatic Payment Program: Free Selection Tab

If you have many vendors in the exception list with different payment
methods, you may want to restrict the payment method. Entering it only
in th.e parameters means the payment program still lists all the items that
it is not paying because the payment method is different, and those items
are blocked from being paid in another proposal. If you filter out the pay-
ment method in the FREE SELECTION tab, you should see only items unpaid
because of other reasons, and you can still pay items with a different pay-
ment method in another proposal.

Note
The payment method must exactly match t he entry in the vendor master, so
if t he vendor master has CT (meaning checks and transfers are allowed), but
the free selection only has C, then that vendor will be excluded.

Although you can include a list of items such as 1,9,8,7,10,19, you are
limited to the few that fit on the two available lines (you can't use the sec-
ond block of lines for the same object), and they must be entered in

29
Running the Automatic Payment Program I 3

sequential order with commas, including the leading zeros, such as


0001,0007,0008,0009,010,0019. However, you can enter ranges; for
example, you could enter the above as 00001,(00007,00010),00019.

3.4 Additional Logs Tab

It is not mandatory to complete the tab to run the pay-


ADDITIONAL LoG
ments. However, if there is a problem, then completing this section cor-
rectly produces proposal and payment run logs, which will be invaluable
aids for troubleshooting. The recommendation is to select the first, third,
and fourth boxes as shown in Figure 14.

Autom.Jtic P.Jyment Tr.Jns.Jctions: Addition.JI Log


§,

Run Date ,17. 03 . 2016]


Identification [usTOl]

Status Paramet er Free selectiJn )""Adcitionallog -,, Printout/data mediLrn

Requi'ed logging type


0 01!.19 date ched<
0 Payment method selection h all cases
RJPrmt method selection If not successftJ
R]Ure items of the payment documents

Accounts requi'ed
Vendots (ttoa/to) Custoaets (ftoa/to)
"1ooool "!J:9999 I Ill
I II I
Fi gure 14 Automatic Payment Program: Additional l og

Tip
If the account range is blank, the logs show generic detaiL If you enter ven-
dor numbers, then you will see the exact error for each item as in Figure 15.

30
Running the Automatic Payment Program I 3

Note that the logs are periodically deleted, so you may want to print or
export them (top menu: SYSTEM • LIST • SAVE • LOCAL • FILE, then either
RICH TEXT FORMAT or HTML will probably be easier to read later).

Job Log Entries for F1.1.0-201.601.07-GBE01. -X I 201.1.1.400

Jil ~Lono text ~PrEr<ious Page £)Next page lm [Q)

Job loQ ovecview fot: job : f 110- 20160107-GBE01 -X I 20111400

Date Tiue Message te.xt

19 .03.2016 20:11 : 15 Job st..att.ed


19 . 03. 2016 20 : 11 : 15 Step 001 stoned (progrOll SAPF110S, variant &0000000003075, us•r ID OFLAHACAN)
19 . 03.2016 20 : 11 : 15 Log tor: ptoposal tun for payaent on 07.01.2016 , identificat.ion GBEOl
19 . 03. 2016 20:11 : 15 Ho check can be m.ade in SAP GTS in an automatic payment pt:ocess
19 .03 . 2016 20 : 11 : 15 Run is continued . Syst.e11. writes entries tot subsequent cheek
19 . 03. 2016 20 : 11 : 15 >
19 . 03.2016 20 : 11 : 15 ~ Additional loq fot: vendot 10099 company code 3000 I
19.03. 2016 20 : 11 : 15 >
19 .03 . 2016 20 : 11 : 15) Du e date determination add ition a l l og
19 . 03. 2016 20 : 11 : 15 > Docuaen t 5100000006 line it.e11. 001 via USD 30 . ooo , oo-
19 . 03. 2016 20 : 11 : 15 > Ter•• of payment: 25 . 04 . 2013 14 3,000 % 30 2 , 000 % 45
19.03. 2016 20:11 : 15 > 03 days gz:ace petiod is being consideted
19 .03 . 2016 20:11 : 15 > Payment m.u st take p l ace before 12~ 0 6 . 2 01 3; n ext payment on 31 .01. 2016
19 . 03. 2016 20 : 11 : 15 > Item is du e with 0 , 000 % ca~h discount
19 . 03. 2016 20 : 11 : 15 > Iee.m. is blocked with block key R

Figure 15 Automatic Payment Program Log: Example of Error Message

The last tab deals with payment media, but does not have to be filled for
the purpose of the payment proposal. This will be covered in Section 4
when w e discuss creating the payment media.

After all the other tabs have been filled in you can run the payment pro-
posal by returning to the STATUS tab. If you have not already saved the
parameters, you will be prompted to save at this point. The STATUS tab at
this point should read PARAMETERS HAVE BEEN ENTERED. The next section
will cover running the payment proposal.

3-5 Running the Payment Proposal

You run a payment proposal by clicking on the PROPOSAL icon at the top
of the screen. (Be careful not to click payment run by mistake as this will
attempt to post the payment proposal, but since it does not exist, will pro-
duce no result.)

31
Running the Automatic Payment Program I 3

A popup box (SCHEDULE PROPOSAL) will appear in which you need to


select when you want the proposal to run. Most people will run the pro-
posal immediately, however it could be scheduled to run at a later stage,
or overnight. Depending on the payment method, you may see a box for
payment media. Normally, you would not tick this at the proposal stage
for payments. It is usually reserved for direct debits (see Section 5.1).

After you launch the payment proposal, you should see a yellow triangle
and the message PROPOSAL Is RuNNING. You need to refresh the message
until you get a green square and the message PAYMENT PROPOSAL HAS BEEN
CREATED (see Figure 16). You can refresh the screen either by clicking on
the STATUS REFRESH icon or by pressing the I Enter I key.

Automatic Payment Transactions: Status

~Status ~Payment RLn ~ Proposal ~Proposal D Proposal

RLn Date
Identifk:ation

/ Sta tus , , Pararne-;;-' Free selec~~nal log Printout/data meci.Jm

Status
0 Parameters have been entered
0 Payment proposal has been created

Fi gure 16 Creating the Payment Proposal

You can check which items have been proposed for payment in two ways:
You can either display the summary information on the screen in a table
where you can quickly see the amount by vendor, or you can see a pro-
posal listing showing all documents. To see the summary information in
a table, click on the DISPLAY PROPOSAL icon with the glasses, which can be
seen in Figure 16.

In Figure 17, items with a green square are all right to pay, but items with
a red circle have an error. Items that are not yet due for payment or fall
outside the selection criteria will not be shown. If you want to see the
details of the invoices that are being paid, you will need to drill down,

32
Running the Automatic Payment Program I 3

one vendor at a time to a second table that shows each item being paid.
You can export the table to Microsoft Excel by selecting the appropriate
icon (with the small green arrow) and completing the required fields in
the popup boxes.

Display Payment Proposal: Payments


S Choose DiSPlay Back from find International Adci'ess Ver~on

Run On 117. 03.2016 USTOl I Snd. cc IJooo]

Payments/exceptions

TY... Vak.JeDate t Local Cl.l'r.pomt armt Ocy Vendor N<me Reference Ctr Payment P Hous... House bark key

~-~
264. 962,00· 1000 C.E.B... DE
0 19.03.2016 25.600,00· uso 1111 SlclPt.. US FllOOOOOOl T 3000 134329042
0 19.03.2016 50.6 16.259,00· uso 1444 C&C.. . US F110000002 T 3000 134329042

•• 76.720.789,00·
821.801,95·
uso
uso
2345
3000
M.B .. .
C.E.B...
us
us
•• 21.000,00·
14.590,00·
uso
uso
3005
3015
Abbo.,,
Whit...
us
us
Figure 17 Displaying Vendors in t he Payment Propo:sal Table

To run the detailed proposal listing, go to the top menu: EDIT • PROPOSAL •
PROPOSAL LIST. In the popup, the PROGRAM field will have RFZAL120 as
standard. If you already have variants set up, you can select them from
the dropdown in the VARIANT field, otherwise leave it blank to see the
SAP standard listing (see Figure 18). The complete payment proposal list
will normally show the exceptions first and then the items being paid. For
the items not being paid, you will normally see the vendor information
followed by each item that is not being paid with an error code at the far
right. At the bottom of the listing, you will see a brief explanation of the
errors for example 003 - item is blocked for payment. However, the type
of block may not be clear from the message. Section 8, Understanding
Error Codes in the Payment Proposal, provides a more detailed explana-
tion of some of these errors.
After the vendors that are not being paid (the exceptions), the vendors
that are being paid are listed, plus the relevant master data (address, bank
details) and transaction data (invoice number, document type, document

33
Ru nning the Automatic Payment Program J 3

date, amount, currency, and so on). You can also export this listing to, for
example, Word, Excel, or HTML.

Changing the layout of this report is slightly more complicated than


changing, other line layouts, which most users will already be familiar
with. As it is a global change, you may need to raise a support request;
however, it is normally possible to add additional fields fairly easily and
in particular to choose which summary totals that you require. As a stan-
dard, you often have, for example, totals by business area, totals per
country, totals per currency, totals per payment method, totals per bank
accou nt, but you may not need all of them (see Section 3.8).

Payment Ust
»: ~ 'IV !Ell III I~ ~ ~ ~I

Be~t.Run USA Pe:y:aenc propose.! list. for proposal run 17. 03. 20 16/UST'Ol 26.03.2016 I 16:19:3
New Yor:k Users: OFLAJIACAN
Colllpany Code: 3000 Page: 2

~ Pay.ent. House Bk Acct. ID P Jlaae (in lanquaqe of country ) A.ccount. hol der Aaount pai d ( FC) Ctcy ....:::::;
BusA CoCd DocuaeneNo Type Documen t Dar;e Blin e Date Pay'T PK FC gross am.ount Toe. de d. i n FC N'et 8.llOunt in F'C Crc:y £

3000 1900052075 RR 01. 03. 2013 01 . 03. 2013 HT30 31 l. 950 , 00- 0, 00 1.950, 00- USD
3000 1900052076 RR 01. 04. 2013 01. 04. 2013 HT30 31 2. 077,00- 0, 00 2 .077, 00- USD
3000 1900052077 RR 01. 05. 2013 01 . 05. 2013 HT30 31 2. 310,00- 0, 00 2 . 310, 00- USD
3000 1900052078 RR 01. 06. 2013 01. 06. 2013 HT30 31 2. 650 ,00- 0, 00 2 .650, 00- USD
3000 1900052079 RR 01.07. 2013 01 . 07. 2013 HT30 31 2. 585,00- 0, 00 2 . 585, 00- USD
3000 1900052080 RR 01. 08. 2013 01. 08. 2013 HT30 31 2. 400,00- 0, 00 2 . 400, 00- USD
3000 1900052081 RR 01. 09. 2013 01 .09. 2013 HT30 31 2. 185 ,00- 0, 00 2 . 185, 00- USD
3000 1900052082 RR 01.10. 2013 01.10. 2013 HT30 31 2. 010 , 00- 0, 00 2 .010, 00- USD
3000 1900052083 RR Ol.U. 2013 01. u . 2013 HT30 31 1.805,00- 0, 00 1 .805, 00- USD
3000 1900052084 RR 01.12. 2013 01.12. 2013 HT30 31 1. 450 , 00- 0, 00 l. 450, 00- USD
3000 1900054461 RR 01. 04. 2013 01. 04. 2013 HT30 31 20 , 00- 0, 00 20, 00- USD

• ruooooo
50 .616. 259 , 00- 0, 00 50 . 616 . 259, 00- USD

8estRun USA Payaene proposal usc tor proposal run 17 . 03. 2016/USTOl 26. 03 . 2016 I 16:19:3
New Yor:k Leqend usecs: OFLAHAGAN
Co~ any Code: 3000 Paue: 3

Et< l"'e:ssage Tex t.

003 It.e• is bl ocked tor payaene


016 halt aethods t or this run ate not. specitied in aa.st.er x:eeord or in itt.ll:

Figure 18 Showing Extract of a Payment Proposal Listing

After you have reviewed the vendors to be paid, you can make changes;
perhaps the amount of the proposal exceeds the cash available in the bank
or you have some queries on some of the invoices that are being paid.
Alternatively, you may notice that some invoices that you expected to pay

34
Running the Automatic Payment Program I 3

are either missing from the payment proposal altogether or are there but
have an error message and are not bein g paid.

3.6 Amending the Payment Proposal

You can either block an invoice by entering a block in the document prior
to running the payment proposal, in which case it will stay blocked until
you physically go in and take off the block (for example, when any query
has been dealt with) or, you can block an item inside the payment pro-
posal, but it will remain blocked only until the payment proposal is
posted, at which point the item will then be free for the next payment
run.
If an item is missing altogether from the payment proposal, due to an
error in the parameters, or the invoice was not posted in time, you will
need to delete the payment proposal and rerun it once the error has been
corrected for it to appear in the payment proposal.

Note
Each time you delete and rerun the proposal, any manual blocks you entered
in the proposal will disappear and w ill have to be re-entered.

Therefore, it is better to deal first with the items that are missing or not
being paid, in case you have to make a correction and rerun the payment
proposal to pick them up . When you are happy that no items are missing
from the payment proposal, you can decide whether you want to pay the
remainder.
To block an item in the payment proposal you need to return to the STA-
TUS tab and select the EDIT PROPOSAL icon, which has a little pencil next to
it. You will then see a popup to enter an accounting cleric This may be rel-
evant if each accounting clerk is responsible for certain vendors or cus-
tomers. If not, click continue, and in the next screen, you will see the

35
Running the Automatic Payment Program I 3

same list of vendor/customer items to be paid as in Figure 17, but with


the additional icon CHANGE.

If you select a vendor/customer and then CHANGE, you are able to change
certain details for all the related invoices (such as payment method, house
bank, due date), although you can only change these for items that are
being paid anyway.
If you double click (or select and then click on CHOOSE) the vendor/cus-
tomer whose items you wish to block, you will now have the choice to
block each invoice/credit one at a time (select the CHANGE icon, which
also allows you to change the discount of individual items) or to block all
items for that vendor/customer (select the BLOCK ALL icon).
If you are blocking an item, a dropdown of different letters is available to
use for blocking, similar to the list for entering a payment block directly
in an invoice. Some companies may decide to use only payment block A
in the proposal and payment block B elsewhere, or vice versa, and set the
configuration accordingly.
After you have saved your changes and returned to the STATUS tab, you
will notice there is now an additional line stating PAYMENT PROPOSAL HAS
BEEN EDITED. In addition, if you go to the payment proposal listing, any
items that you have just blocked should now appear as exceptions.
A common question is how to quickly block, for example, 20 items out of
a list of 100 being paid. Unfortunately, this is not possible from within
the payment proposal (other than blocking one by one). You are able to
select a column and then go to the top menu EDIT • SORT, which might
help, or by adding a total and then going into the sub-totals icon where
you can sort by more than one column.
The best way to do such multiple blocks is prior to running the proposal,
by using the mass change option in the vendor/customer line item display
(Transaction FBL1N or FBL5N). When you are in the vendor/customer
accounts, select the relevant documents and then go to the top menu:
ENVIRONMENT • MASS CHANGE • NEW VALUES and you can enter the new
value, such as a payment block for all the documents in one go.
Running the Automatic Payment Program I 3

Note
Be careful to select the correct items as there is no UNDO button and if you
need to reselect the items to unblock afterwards, you need to be aware of
any other items that were blocked already for different reasons.

3.7 Deleting and Rerunning the Payment Proposal

You may need to delete and rerun the proposal if, for example, you want
to include an invoice that had not been posted at the time of running the
first proposal or if you have made a change to an invoice or master data
such as changing a payment method, payment terms, confirming sensi-
tive bank data, or removing an existing payment block.

From the top menu select EDIT • PROPOSAL • DELETE and select YES in the
popup to SHOULD THE PROPOSAL BE DELETED? At this stage, the parameters
will still exist, but they will not block any new proposals. You can then
rerun the proposal once any errors have been corrected. If you are not
going to rerun the proposal, you can delete the parameters (EDIT • PARAM-
ETERS • DELETE) or you can amend the parameters for a new run by, for
example, changing the next payment date or other selection criteria.

You can create a new proposal with the same parameters, but you will
need to use a different RuN DATE and IDENTIFICATION combination from
any runs that are still in existence (see Section 3 .1).

The next section describes the available variants for the payment proposal
list.

3.8 Proposal Report Variants

This section explains how to change the various layouts and selection
variants for the proposal list, although the same principle/layouts can be
used with the payment list once the payments have been posted (see Sec-
tion 4). Note that not all companies allow users to make amendments

37
Running the Automatic Payment Program I 3

here as some of the settings are global and errors may prevent other com-
panies from running their reports.

First, go to the top menu: EDIT • PROPOSAL • PROPOSAL LIST and then at the
top of the proposal, select the CHANGE LAYOUT icon (resembles a Rubik
cube) and select YES in the popup to go to variant maintenance. The
screen will not change a lot but there will be additional icons available
that allow you to add columns, sort, sub-total, and so on. If you click on
the Rubik cube icon, you will see the CHANGE LAYOUT popup in Figure 19.
On the left side are the fields that already show in the proposal and on the
right side are the fields that are available. You select the item and then
using the arrows either move it from left to right to hide it or from right
to left to add it. Pay particular attention which part of the report you are
in, for example the header or line item 1, 2, or 3.

@ Ch¥1()3 Layout X

LlllB 1 Li1e 2 Line 3 @

Header I Line 1 Hdden fields


Colurm content Po<. Len ... ~ Col. content Lngth
Pa-yment docunent no. ~ , 10 Paying company coda ~
o;; ..J
House Bank z 8 1\/erdor 10
Account 10 Custcmar 10
Pa-yment method [ffi
• Payment rec.,..,t 16
Name (n lang.Jao;; of cou _ 5 30 (B Business Area
Account holder 35 N<rne 1 3S
Amount paK:I (FC) 18 0
~
N<rne2 3S
[-urrency PostiiiCode 10
P.0. Box Postal Code 10
City 3S
S treet 3S
PO Box 10

li"'re width

List width

Figure 19 Change Layout Box fo r the Payment Proposal

After you have added or removed the fields as required, click on COPY to
disp!ay the fields in the proposal. When you are happy with the layout,
Running the Automatic Payment Program I 3

choose the SAVE LAYOUT icon (usually two icons to the right of the Rubik
cube icon) and enter a new code for the layout. You can make it user spe-
cific (tick the user specific box) or available to everyone, but make sure
that you do not overwrite somebody else's variant by mistake. You can
also change the sorting, filtering , sub-totals, etc., in this area.

The next step is to click on the green back arrow to come out of the vari-
ant layout maintenance. A popup will then appear asking Do YOU WANT
TO MAINTAIN THE DISPLAY VARIANTS FOR CO.-CODE SPECIFIC TOTALS LIST? If
you say No, you will return to the STATUS tab. If you say YES, you will be
taken to a series of screens to change the layout of the different totals
boxes, for example, totals per country, currency, and so on. Here again,
you have a Rubik cube icon that leads to a popup with fields on the left
and right that you can move one way to add them and the other to
remove.

After you have saved any changes, continue out of the transaction using
the green back arrow key and you will see another popup asking: Do YOU
WANT TO MAINTAIN THE DISPLAY VARIANTS FOR CROSS-COMPANY CODE
TOTALS LIST? Select No to return to the STATUS tab.

At this point, you have created a layout variant, but have not fully
assigned it to the payment program, so you will not be able to see the
variant when you first select the proposal list. Most users will not have
access to the Transaction SE38 which allows you to assign the layout vari-
ant to the proposal list, so that you can choose the variant before you go
into the proposal list. If this is the case, you may have to request the sup-
port department to assign the variant for you. They need to assign the
variant code that you saved to the program RFZAL120 .

To do this, they need to run Transaction SE38, enter the program name,
select the VARIANTS icon, and then enter the name of the variant that you
want to appear in the payment program. Choose FoR ALL SELECTION
SCREENS, then on the next screen you can enter the layout that you cre-
ated in the OUTPUT CONTROL section, DISPLAY VARIANT field. On this
screen, (see Figure 20) you can also remove some of the sub-totals if there

39
Running the Automatic Paymen t Program I 3

are too many showing at the bottom of the report and you can also enter
any variants that you saved for the totals. You can have PAID DOCUMENTS
and iEXCEPTIONS both selected, or just one or the other (or you can create
several variants, one for each).

Edit Variants: Report RFZAll2D, Variant OFOO.t.,. Screen .1. of 3

Program run date


ldentiflc.ation fe.attse
2JPI'oposal n.rr only

CClllll<lf'lY code select ion


Paying company code
SErd"rQ corr'l)any code

~ut Control Selections

Une Item Lists


Maxrn.m no. of .-.:!dress lnes rs]

O summ...ize data
~Paid documents
~EXceptions
CAspl ay v...iant OFOl J
-
Totals ists
~Totals per bustless ...eas Display v,..lant : buslress areas Corr'l)any code-specific

Display v,..lant: buslress areas cross Corr'l)any code


SlJTotals per CO\Xltry Display v,..iant: countries company code-specific
Display v...iant: countries cross company code
Sl!Totals per ctsrency Display v,..iant: currencies COII'Vdi1Y code-specific I
rlknl;w v>riont : n rrr....-ri>< rrn<< '"""'""" m do

Figure 20 Saving the Layout and Totals Variant to the Payment Program

In theory, you should also be able to select the exception list, showing
only the exceptions, and the proposal list showing only the items being
paid from within the payment proposal itself. However, in most compa-
nies, this split doesn't seem to work.
As you back out with the back arrow you will be prompted to save the
variant and enter a description. Now when you go to the top menu and
select EDIT • PROPOSAL • PROPOSAL LIST, you will be able to see a dropdown
including the new variant in the popup that appears.

40
Running the Automatic Payment Program I 3

You can delete and rerun the payment program as often as you want, as
long as you remember that any manual changes are lost each time you
delete and rerun it. When you are happy that the proposal listing is pro-
posing the documents that you wish to pay, the next step is to post the
payments and produce the payment media. The payment media includes
any remittance advices and checks as well as any files that you need to
produce to send to the bank.
After the items are included in the payment proposal, you can post the
payments to the vendor and bank account, produce a remittance advice,
and create the related payment media.

3.9 Scheduling the Payment Proposal

Transaction F110S is available to create a variant to automatically sched-


ule the payment program to run on a regular basis. Be careful that one
payment run is cleared before the next payment run is created, and that
you tick the PROPOSAL ONLY box so that you get a chance to review it (oth-
erwise it will post it!).

The selection screen of Transaction F11 OS contains the same data as


Transaction F11 0 Qust all in a single long screen). To create the variant,
you need to complete the selection screen, and click on SAVE to go to the
variant screen (see Figure 21). Give a name and description and then go to
each date field where the date will change, for example the run date, post-
ing date, and so on. Click on the dropdown in the SELECTION VARIABLE col-
umn of each date and choose X and then click on the dropdown of the
NAME OF VARIABLE column and choose either CURRENT DATE or CURRENT
DATE +1- ??? DAYS and insert the number of days if you want any of the
dates to be after the current date.
When this is complete, the program and variant can be added to the
Schedule Manager or whatever tool your company is using to schedule
recurring jobs. On the specified date the proposal will run picking up

41
Posting Payments and Producing Payment Media J 4

either the scheduled date as the current date or whatever date you have in
the selection variant.

V11rlllnt Attributes
' Copy Sct~en Assignment IIJ
n10 'll"ttK
Wte:k.t,o P)yment Prot»Saa Saetn Assignment
('"'Ofllt f« Bactoround Processno L:A outed Sett<:tiGn SCtttn
O PrCitt<t vnnt o(, 1000
O Oo>i o..t.v • Catabo
("'c:. ' ': 't... ,_. T

(~]~~ ~ l fuechnt.l noni)


Objects fOt selection screen
~ SelecOon Saeen Aekl name Type Htle field Hide field 'BIS' ~e fiekl wthout vak/es Swtch GPA lte(juhd field ~lectb"' wrgble Option flame of Yariible (tnput Oroti USilo F4)
l.OOG Run Date p (1 1"'1 !j 1"'1 n x @
1.000 Tdentt'atiOn 0 0 0 (1 ~
1.000 Prop~ NO o r o r 0
@Virant Attrbutcs
1.000 Target COtrlluter 0 (] 0
1.000 P0stt19 Date 0 0
1.000 Docs tnttttd up to 0 0 Current Ont
1.000 CUstomer tems due by 0 (] n OJITt Ot date+/· m days
1.000 COIT'C)any Code 0 0 0 "l I' current date +/· m wotlt days
1.000 P~t Mtdlods o r o r ~ F'rst day of current rronth
1.000 Non Post. D>te
1.000 orect Debit Pte-nottbtlons
o r o r P' ndl wormo day of current month
0 [l 0 Fist day of next month
1.000 ven60f o [1 o r r fflt day of l)rMCHJs t'I"'Gnth
1.000 OJstomer 0 0 0 0 L.a$1: day of pre'WOI.Is t'l'll)(lth
1.000 Exchinge rate type o o r 0 Last Day of the Olnent Mooth

Figure 21 Selection Variable in Transaction F11 S

The next section explains how to post the payments and produce the pay-
ment media.

4 Posting Payments and Producing


Payment Media
After the proposal run, the next step is the payment run, which updates
the GL and the vendor accounts and can produce payment media. The
term payment media covers a number of areas. It includes remittance
advices, which may be physically printed and posted to the vendor or
automatically emailed to the vendor. It also includes checks and any sort
of bank file for payment or to collect direct debits. You can choose
whether to create the payment media at the same time as you post the
payments to the vendor/customer, or to create it later.
Posting Payments and Producing Payment Media I 4

The payment method is initially configured using either the classic pay-
ment setup or the newer payment medium workbench. With the classic
approach, you will need to assign the payment media to the payment run
manually in the payment program. With the newer workbench, a variant
linking the payment media to the payment method should have been set
up as a one-time task in each system.
The next section explains the programs in the PRINTOUT/DATA MEDIUM tab
of the automatic payment program.

4.1 Printout/Data Medium Tab

The program names appearing on the left of the PRINTOUT/DATA MEDIUM


are dictated by the choice of payment method. If you choose SEPA, for
example, SEPA will have been created in the new workbench and you will
not need to enter a variant. But if you have been using the classic payment
media, the relevant programs (usually beginning with RFFO in standard
SAP and followed by a country, or other abbreviation, or both) will
appear. For example, RFFOGB_T indicates bank transfers in some countries
and RFFOUS_C usually indicates checks. However, many companies may
have created their own programs with their own naming conventions, so
if you are not already familiar with this tab you may need to check with
your support department about which programs have been assigned to
which payment methods in each country.

RFFOAV I S or RFFOAVIS_F PAYM are the generic payment programs related to


the remittance advice, unless your company is using a bespoke program.
You may also see a line RF FOAVIS_ DD_P RENOTI F, for direct debit pre-noti-
fications. See Section 5.3 for further information about this. Essentially,
the variant for this is created in a similar way. Variants may already be
available in the dropdown for the older payment methods and remittance
ad vices, but if not you can create one by entering a name and clicking on
the MAINTAIN VARIANTS icon and completing the required fields.

43
Posting Payments and Producing Payment Media I 4

4.2 Payment Run Log

You should have either two or three items appearing on the STATUS tab
(see Figure 22), depending on whether you have made any amendments
to the proposal.

Automatic Payment Transactions: Status


~Status '8 cPayment Run # Proposal &<fProposal D Proposal

Run D'a te [29. 03.2016]


Identification [2ooo J

~ ~me~ ~elect~onaiL~ /Pfirrtout/data medi"Um] ' 0§


@ Schedula Payment x

Status
0 P.arameters have been entered Start date ry,M,MIIji~ 0 Start rnmediately
' J
0 Payment proposal has been created Start time 00 : 00 :001
0 Payment proposal has been edited TarQet COITlJuter

O create payment medium

Fi gure 22 Payment Run Showing the Scheduling Box

The next step is to create the payment r un itself, which will post the pay-
ments to the vendor and GL accounts. When you click on the PAYMENT
RUN icon, you will see a popup where you would normally choose START
IMMEDIATELY to post the payments. See Section 7 for an explanation of the
GL postings.
If the (REATE PAYMENT MEDIUM checkbox on the bottom left of the popup
appears, you can select it to print the payment media at the same time as
posting the payments. Depending on your process, and who is responsi-
ble for each step, you can either print all the payment media at the same
time as posting the payment, or you can have a separate department
responsible for printing and sending out the checks, or remittance
advices, or both, after the payments are posted, and/or a separate depart-
ment for creating the payment file to send to the bank.

44
Posting Payments and Producing Payment Media I 4

Tip
The CREATE PAYMENT MEDIUM box in the popup appears only if there is pay-
ment media to create with the classic payment methods. If you have not
assigned a variant, it will not appear.

If you have decided to post the payment run first and then separately cre-
ate the payment media, such as remittance advices or bank transfer files,
you can go to the STATUS tab and click on the PRINTOUT icon . A popup will
appear where you can select START IMMEDIATELY. In the lower section you
will see a JoB NAME with a question mark after it (Figure 23). The program
won't run until you replace the question mark with another character. It
is better to choose sequential numbers starting with 1 if you run the pro-
gram more than once and want to have separate logs (see Figure 25).

@Schedule Pnnt x

Schectung
Start date ~IIMI§MIID?Ol
L J
O start immeciately
Start time oo: oo: oo!
Target cofT1luter

Pri'lt jlilb
Job name IF110-20160130-UST01-?

Fi gure 23 Popup Showing the Job Name Where "?" Must Be Replaced

Note
Clicking on the PRINTOUT icon will create all avai lable media so if you have,
for example, already created t he bank file and later click on the PRINTOUT
icon to create t he rem ittance advices, it will recreate the bank transfer file as
well.

The next step (for bank transfers) is to check whether the bank file has
been produced correctly, which is explained in the next section.

45
Posting Payments and Producing Payment Media I 4

4.3 Payment Files

To download the bank transfer file, you can access the file from the pay-
ment run, that is, Transaction F110 or using Transaction FDTA. The dif-
ference is that with Transaction FOTA, you have an in-between screen
where you can select one or many payment runs. Transaction F110 will
take you only to the payment media of the run that you are currently in.
From within the payment program from the top menu, choose ENVIRON-
MENT • PAYMENT M EDIUM • DME ADMINISTRATION.

On tihe DATA MEDIUM OVERVIEW screen, you should see the payment files
that were created (see Figure 24). If a file is created more than once, you
will see a sequential number in one of the columns. You can also see if the
payment file has already been downloaded (in the EXPORTED column).
You would normally see only one file per payment method and currency,
and you should check that the total in the DATA MEDIUM OVERVIEW matches
the total of the final payment proposaL

Slift+F6
& t HHJ &::l ~~ ® PJ
Ch;tck data medsn F7
Dilta Medium c Delete data medrn Slift+F2
Display Df.1E ccntents Ct.W:1
~~lilll JJ) IIJ
~elect al Slift+F7
Payln(j Company Code Qeselect all Slift+FS
Bank cCLntry CiflCel F12

Data medium
Rll"l On !dent .. . Prop... Amount paid in loc.JI ... CLrr... Ente<ed by Receiver Format Exported Date created Seq.
00.01.2016 UST01 257.300,85 USO OFLANAGAN 3000 ACH ~ 2 1.02.2016 )
00.01.2016 UST01 257.300,85 USO OFLANAGAN 3000 ACH 01.02.2016 2

Fi gure 24 Data Medium Overview Screen

Note
If your bank transfer file requires a specific field (for example, I BAN number),
ensure that the field is mandatory in t he payment method itself. If it is not
mandatory in the payment method, your payment proposal will appear cor-
rect but when you create the payment file, that item may be omitted from
the bank transfer file.
Posting Payments and Producing Payment Media I 4

At this point, you can either manually download the bank transfer file
and u pload it to the bank, or your company can use an automated proce-
dure, perhaps using encrypted files or additional software that may have
approval levels linked to the banking systems.
If you are missing an entry for the payment run in the DATA MEDIUM
OVERVIEW screen (or you arrive at a different screen instead), return to
the payment run and select the ADDITIONAL LoG tab. Click on the payment
run log, then the relevant job logs for more information (see Figure 25).

Autom11tic P11yment Tr•ns11ctions: Addition•/ Log

Run Date 30. 01. 20161


Identlftcatlon uSTo1]
1

- Sta tus Parameter Free selection l4l'Additional log Prn tout/data medUm ' ITJ@
-------------------
@Select Log
Reql.ired IOQQinQ type
Filished jobs
W]Oue date chec'·
Jobnam.e Couene
0Pav,...,nt method select1on 11 all cases r
._!'110· 20160130-USTOl Payment run
R)Pmnt method selectiOn 1f not successful
Fll0-20160130-USTOl-1 Print job
P!Lne 1tems of the payment documents
Fll0· 20160130-UST01·2 Print job
F110·20160130·UST0 1-3 Print job
[ Accounts requied
Vtndoz:s (tr:om./to) cuseom.ecs (tr;oa/to )
10000 19999
Proposai 1un log
Payment run log

Fi gure 25 Payment Run Logs, Where Media Was Created Several Times

4-4 Remittance Advices

A remittance advice can be either printed and posted , or sent electronically


to the vendor to tell them that a payment is on the way and which docu-
ments you are paying. Normally, you indicate in the vendor master data
whether the invoices are to be posted or sent electronically, but some
companies may use bespoke tables if the vendor has multiple email

47
Posting Payments and Producing Payment Med ia I 4

addresses for different documents such as purchase orders, or as it is a


global field, different company codes may have different email addresses.

To create the remittance advices, you need to enter a variant in the PRINT-
OUT/DATA MEDIUM tab. Either select from the dropdown or enter a name
and click on maintain variants. Select FOR ALL SELECTION SCREENS in the
popup and then enter the data as required. Then go back using the green
back arrow key and save your work.
Recently, enhancements to the NOTE To PAYEE field in the bank file allow
more details to be sent in the bank transfer file, so companies can cut back
on the use of remittances ad vices. Countries like Finland barely use them
for local payments as all information is sent in the bank file, allowing the
recipient to automate nearly all of the matching of payments against cus-
tomer invoices.

4-5 Printing Checks

Unlike creating other media, checks are printed on pre-numbered forms.


That number will eventually be linked to the SAP payment document.
Human error, fraud, and printer malfunctions are some of the reasons the
process may not go smoothly. Therefore, a suite of transactions is
required to manage this, most of which begin with FCH in SAP. The fol-
lowing list includes some examples of t hese transactions:

» Transaction FCHI
Transaction FCHI (Check Lots) is used to enter the initial check numbers
in the system against the required bank account, with each check lot
being a separate check book or range of numbers (see Figure 26).
» Transaction FCH1 and Transaction FCH2
These transactions display check infor mation such as recipient, amount,
creator, bank details, date, documents paid by the check, payment doc-
uments, and so on. Transaction FCH1 is by check number, and Transac-
tion FCH2 is by payment document.
Posting Payments and Producing Payment Media I 4

Oisplily Check Lots


~
1
Paying corrc>any code 3000' BestRun USA
House Bank 3000 I Cdlank
Account 10 3050 I Cdlank current account il USO

Checl< klts
Lot n... Shott i'lfo Checl< no. from O.eck nurrber to ~ext lot Nurrber sotus
10000 19999 1000 1
20000 29999

Figure 26 Transaction FCHI Showing Check Lots

» Transaction FCHN
Transaction FCHN is the check register where you can display a list and
status of all checks and drill down into the detail.
There are other transactions to renumber, reprint, void or cancel a check,
and to create positive pay files to send to the bank, so that the bank can
verity the check data.

It is not possible to go into detail for every check transaction here, but we
will cover the printing briefly. To print checks, you need to select (or cre-
ate) a variant in the PRINTOUT/DATA MEDIUM tab. Enter as a minimum,
company code, house bank, account ID, lot number, and whether you
want to include sample prints at the start to check the printer alignment.
Check forms often include details about what is being paid, so an addi-
tional remittance advice may not be required.

If the variant is in place when you post the payment run and you select
the CREATE PAYMENT MEDIUM checkbox, the checks will print at the same
time, otherwise you will need to click on the PRINTOUT icon later. After
the check is created, you can go to the invoice or payment document and
drill down to the check details by selecting ENVIRONMENT • CHECK INFOR-
MATION from the top menu.

49
Processing Incom ing Direct Debit s I 5

4.6 Reports

When the payment run is complete, assuming you print to spool (if not,
the reports will have gone directly to the printer), you can see the various
documents in the spool logs in Transaction SP02 shown in Figure 27. In
the example shown, the error log is only there because we reran the cre-
ate payment media part of the program.

Output Controller: Ust of Spool Requests


~9>~! '@ s ~~ ~ .§, H ~ ~ ~I @ .§,~ l].l]. ')p' ~

Spool no . Type Date Time Sta tus Pages Title

0 4666 63 liT! 01 . 0 4 . 2016 09 : 59 - 1 Ettot l oq


0 466662 liT! Ol. 04 . 2016 09 : 59 - 3 Pe..yment sUJDaty
0 466661 ~ Ol. 04 . 2016 09 : 59 - 2 Payment aelvices
0 466660 ~ Ol. 04 . 2016 09 : 59 - 3 DM! accoll.panyi nq sheet. 3000

Fi gure 27 Different Reports Produced by the Payment Run

The p ayment summary will list all of the payments, but will not show the
details of the individual invoices. The payment ad vices are the remittance
advice that can be sent to the individual suppliers by post. Any remittance
advices that are sent automatically by email will not be included in this
list, as they will have gone straight to the vendor. Finally, there is the
DME accompanying sheet, which just shows totals.

5 Processing Incoming Direct Debits


This section covers payments that are automatically collected from cus-
tomers by direct debit using the automatic payment program. The non-
SEPA direct debit process is similar to a payment run for vendors (see Sec-
tion 3), in that you create a payment proposal, verify it, and then send it
to the bank. However, in this case, you receive money instead of paying
it, and may need to notify the customer first.
With a bank transfer, the paying company usually initiates the payment,
whereas with a direct debit, the paying company allows the vendor to

50
Processing Incoming Direct Debit s J 5

initiate the payment. This process is subject to a strict code of conduct


according to country rules, and the payer must first authorize a direct
debit mandate, and be notified in advance of the amount and date.

5.1 Direct Debit Mandate

This is a document signed by the customer giving the vendor authoriza-


tion to collect sums of money directly from the customer's bank account.
The money collected will normally relate to invoices for goods or services
prevjously issued in accordance with agreed-upon payment terms, but
could also be for utilities, telecommunications, rentals, leases, and so on,
and can be for variable or fixed amounts.

In SAP, you have the option of blocking collection if an authorization has


not been received. If the COLLECTIO N AUTHORIZATION check has been set
in the configuration of the direct debit payment method, then you will
get an error in the payment proposal for that customer stating "collection
authorization does not exist," unless the COLLECTION AUTHORIZATION box
in the master data has been selected to indicate that it has (see Figure 28).

~ddress Control Data "' Payment Transactions i~--------------------9


Bank Detais
ctty Bank Key Bank Account Acct holder C•.. !... !BANValue Bk.t ... Reference detail; Col.. Mand. Bank name fiD
GB 2 0 67 59 1 2354 678 I£JGB53BARC20675!i12354 678 0 ~Barclays Bank
~ 0
Fi gure 28 Customer Master Data Payment Transacti on Screen

For some countries, if the information on the invoice or contract is suffi-


cient to notify the customer that you are collecting the direct debit, you
can simply run the payment program as usual and send the bank transfer
file to the bank to collect the payments for you. You could also, at the pay-
ment proposal stage, select the CREATE PAYMENT MEDIA box and print a
notification to the customer of the amount payable using the same pro-
cess as for printing a remittance advice (see Section 4.4). (Although in

51
Processing Incoming Direct Debits I 5

practice you would probably review the proposal first and then delete it
and rerun it to print/send the notifications.)

5.2 SEPA Direct Debit Mandate

SAP provides the possibility to create and print SEPA mandates to send to
the customer for authorization. There are separate transactions for SEPA
mandates (Transactions FSEPA_M1, M2, M3, and M4), but you can also
access them in the payment transactions screen of the customer master
(see Figure 28 under column MAND) or in the business partner if appli-
cable.

Note that if you do not change the status field to ACTIVE, the payment pro-
posal will error with the message THE SYSTEM COULD NOT DETERMINE A
VALID SEPA MANDATE.

5.3 SEPA Direct Debit Pre-Notification

You can use the pre-notification functionality in SAP (rather than inform-
ing the customer on an invoice or contract of the amounts and due dates)
to create a payment run with the automatic payment program using a
SEPA direct debit payment method (that is, one requiring a SEPA man-
date). This will cause additional fields to appear on the payment program
screens. In the PARAMETER tab, selecting the DIRECT DEBIT PRE-NOTIFICA-
TIONS box (see Figure 29) converts the payment run into a pre-notification
run, which will block items selected for payment from being cleared by
any other method. You will also see additional information in the STATUS
tab (see Figure 30).

52
Processing Incom ing Direct Debits I 5

Automatic Payment TransactJons: Parameters


§, B.ex./pmt request...

Run D:ate 30 . 0 4.20 161


Identfution IO£Y01

Status ..-Parameter ~. Free selection Additional Loo I Prntout/_,

PosU'Ig Date 30 . 0 4.201 6 Docs entered up to


0 Direct Debit Pre-notfutions Customer items due· by
Payments control
Cofll)any codes Pmt meths
1 000 y

Fi gure 29 Pre-Notification Box in t he Payment Program Parameters

~ Status ~ 'Parameter v Free selection / Additional Log

Status
-
Drect Debit Pre-notfutions
0 Parameters have been entered

Fi gure 30 Status Tab of Automatic Payme nt Program

On the PRINTOUT/DATA MEDIUM tab you will need to assign a variant to


the program RF FOAV I S_ DD_ PRENOTI F (see Figure 31), assuming you have a
valid pre-notification letter set up. Pre-notifications can be printed out
and .sent or sent by email/fax and are similar in structure to remittance
ad vices.

1-.-;:.
Stl=
tu~s_,_.!..
P,ara,me
= te"'-r_,,_:fc.cre,_,e'-'se
""le"c'"'tio
'"'n'--1.-.!.'A""
dd,it,io,na,_l""'
Log Pmtout/data medium...J_

Form pmmg/data medium exchange


Program Variant Variant variant variant
RFFOAVIS_DD_PRDIOTIF DD_VliRIAIIT
RFFOAVIS_FPAYM
RFFOEDil I
Figure 31 Pre- Notification Variant

53
Processing Incom ing Direct Debits I 5

First, run the payment proposal and review it. You will notice that instead
of the payment run icon there is now a DIRECT DEBIT PRE-NOTIFICATIONS
icon at the top of the screen when you are on the STATUS tab (see Figure
32).

~Status ~' Dtect Debit Pre-notiflcations If Proposal ~Proposal

Run Date 3 0 . 0 4 . 2016


Jdentlfoc:aliln [ot:YOll

Parameter Free selection Addt ional Log Prlntout/data medi.Jm

Sta tu~S

Dr ect Debit Pre-not ifiGitions


0 Parameters have been entered
0 Payment proposal has been created

Fi gure 32 Status of Aut omat ic Payment after the Pro posal Run

When you click on the DIRECT DEBIT PRE-NOTIFICATIONS button, you will
see a similar popup to the normal payment run but it will be called SCHED-
ULE DIRECT DEBIT PRE-NOTIFICATIONS and when completed the line in the
STATUS tab will say RUN FOR DIRECT DEBIT PRE-NOTIFICATIONS EXECUTED
(see Figure 34). Either the pre-notification will be emailed direct to the
customer, or it will go to the spooler or printer, depending on which set-
tings you have chosen. At this point, in the additional log you will see an
icon for the DD PRE-NOTIFICATION LoG and you can display an overview of
the pre-notificatio n run by selecting ENVIRONMENT • DIRECT DEBIT PRE-
NOTIFICATION • DISPLAYOVERVIEW.
The invoice is now blocked for any other payment, and if you display the
vendor line item, you will see the reference to the direct debit pre-notifi-
cation, and can double click to drill down for further details (see Figure
33).

54
Processing Incoming Direct Debit s I 5

Lne Item 1/lnvoice I 01


Amount . s"'o::-
r.1t-: "o,-:-oo:-----'--,1 EUR
Tax code rAil

Addtlonal Data
Bus. Area r---'
Disc. base 0, 00 Disc. aroount 0, 00 EUR
Payt Terms 0001 Davs/percent o o, ooo ' o o, ooo ' lo'
Bine Date 30 .04 . 2016 Invoice Ref. t lol
Pmnt Block
Payment cur. 0, 00
Payment Ref.
Contract Fbw Type ....---,
Assignment Doect Deb~ Pre-notlfbtion
Text Long text

Figure 33 Customer Line Item Showing Direct Debit Pre- Notification

After the pre-notification has been sent to the customer, if there is no


query, click on the PAYMENT RUN icon (see Figure 34), which will create a
new payment run (see Figure 35), which will contain the bank file and the
payment logs and reports.

Automatic Payment TraiJSilctions: Status


~ Status iJ Direct Debt Pre-notflcations ~Proposal iJ Proposal ~ Priltout "8' Payment Run

Run Date b o.o4.2o161


Identification (DEYOt l

~ Parameter Free sele~nal Log Priltoutldata med"!iii!J

Status
Direct Debt Pre·nott'otions
0 Parameters have been entered
0 Payment proposal has been created
0 Ru n for Direct Debt Pre-notlfications Executed
Posti"lg orders: I generated, 1 cort1)1eted

Figure 34 Status Screen Awaiti ng Direct Debit Posti ng Run

If the customer comes back with a query, or is paying the invoice directly,
you must remove the related invoices, by chooosing ENVIRONMENT •
DIRECT DEBIT PRE-NOTIFICATION • DELETE. You can filter to select the pre-
notification you wish to delete and run in simulation mode first. If the

55
Processing Down Payments I 6

amount changes, you will have to create a new pre-notification, or wait


until the next direct debit run. You can schedule the run using Transac-
tion F110S_DD_PRENOTIF.

TY... Message Text


0 Payment run 30.04.2016 DEY02 has been created
0 1 d irect d eb~ pre-notlfic:ations selected 1:1 30.04.2016 DEYD1
0 1 payments have been transferred to t he new payment run 30.04. 21)116 DEY02
0 Payment run 30.04 .2016 DEY02 has been exeC\It ed

0~1!\f TechniCal Informa~n I! I fHelp I@

Figure 35 Log Showing the Direct Debit Details Are Transferred to Another Run

6 Processing Down Payments


Down payments can be anything paid in advance without a document.
They can range from small subscriptions, where the invoice follows
almost immediately, to large capital payments for machinery or a market-
ing campaign. The supplier may require the full amount or a percentage
of the overall value to start work, especially if the item is personalized or
the initial materials are expensive.
Some companies pay and post the payment to the vendor manually (see
Section 2), but SAP has a specific down payment functionality to facilitate
this. It allows users to post the down payment to a vendor, linked to a dif-
ferent balance sheet account, rather than as a reduction of trade payables
(whkh may be inappropriate if the amount is large in comparison to the
total payables), and the payment can lbe made with the automatic pay-
ment program.
First, a statistical document, like a dummy invoice, is posted to the ven-
dor account for the automatic payment program to have a document to
pay. The GL is only updated when the payment is posted. When the
invoice is received and posted against the down payment, the entry to the
Processing Down Payments I 6

down payment account is reversed and posted to trade payables, clearing


the invoice. The next sections take you through this process, step-by-step,
including eventually clearing the down payment.

6.1 Processing Down Payment Requests

When creating the down payment request, you choose a single character
SPECIAL G/L INDICATOR, which may vary from company to company
depending on what has been configured. For example, you may wish to
use different GL accounts in the investment range of the balance sheet for
tangible and intangible down payments, and a different account for down
payments on current assets. Note these accounts must be set up as recon-
ciliation accounts. Each account will have a different indicator, but you
cannot use the letter F, because this will denote the initial request.
A down payment request is created in Transaction F-47 (see Figure 36).
Once the down payment request is posted, it will be picked up by the
automatic payment program, so similar controls should be in place to
authorize the request as if it was a purchase order or invoice.

Down P11yment Request: He~~der D11tll


New Item

Docume nt Date 129. 04.20141 Type lKiJ Company Code


Postitg Date 129. 04. 20161 Period n Currency/Rate
Document Number I I Translatn Date
Reference I
Doc.Header Text ?oi
D=ow=n=pay
=me
= n=t = L - - - ,
Tradhg part.BA I Tax Report Date l
vendor
Account § - V!:lll
Trg.sp.G/Lh d. fAl

Figure 36 Down Payment Request

After filling in the dates, company code, currency, texts, and the vendor,
choose a letter from the dropdown in the TRG.SP.G/L IND. field and press
I Ente r I.

57
Processing Down Payments I 6

If local laws require taxes to be split out at this stage, you can also enter
taxes. The two mandatory fields on the next screen (see Figure 37) are
AMOUNT and DUE ON, but you can add additional text or other codes if
required. You will see that the GL account in the top right of the screen is
not the normal payables reconciliation account linked to that vendor, but
a temporary account instead.
The posting is now complete and can be saved. However, if you click on
the DocuMENT OVERVIEW icon (top left), you will see that there is no dou-
ble entry to the document, just a "one-sided" posting to the vendor account.
You can also link the down payment to a specific purchase order, or a spe-
cific fixed asset (though additional configuration may be required).

Down Payment Request Add Vendor item


.Q £) [} [(] New Item

Vendor us-VEN1
1
Universal Cherricai St:abiizer Co. G/ L Ace 196300!
1
Company Code Jooo] 1234 Westchester Pi<e
BestRu n USA PHn.ADELPHIA
Item 1 I Dow n payment request I 39 F
Amount 1000 I GBP Amount rn LC USD
0 calculate tax
Bus. Area ~
-~-----.,

Due On
Pmnt Block Prrt Method fJ
Order
Purch .Doc.
Proft ctr
WBS Element

Assignment
Text P Long Texts I
Fi gure 37 Down Payment Request Second Screen

When you click on SAVE you will see that a document is created, which
can be displayed with the Transaction FB03 but which has only one line
item. If you want to display the document in Transaction FBL1N (Vendor
Line Item Display) you will need to select NOTED ITEMS on the initial
screen (see Figure 38), otherwise you will see only "normal" documents.
Processing Down Payments I 6

Type

~ Normal items
0 Special G/ L transactions
R] Not ed il::ell\$
0 Parl<ed items
O customer items

Fi gure 38 Lower Selection Crit eria in Transaction FBL1 N, Vendo r Li ne Items

When you display the vendor line items, you will see the letter F in the
special GL indicator column (see Figure 39). Don't worry, although you
will have chosen a different letter when you requested the down pay-
ment, F appears for all down payment requests to indicate that at this
stage it is only a statistical item, and it is only after the next steps that you
will see the true letter in Figure 40.

Docwnen~N'o Type Doc . Oat: ~ S DD Amount: in loca l cur . I.Cilrr

1 700000001 KA 29 . 04 . 2016 F4 1.000, 00 - USD

1.000, 00- USD

Fi gure 39 Vendor Line Item Display Showing the Not ed Item/Request F

The next step is to run the automatic payment program. These steps will
be the same as in Section 3 and you can use the same payment method
that you would normally use. After the payment run has been posted, if
you return to the vendor line item display and select both the noted items
and t he special GL indicator at the bottom of the selection screen and also
select all items (not just open items) , you will now see two postings as per
Figure 40:
» The first document is the open down payment document that will have
the special GL indicator that you originally chose, and a double entry
between the vendor and the bank control account. However, the ven-
dor line item will be linked to down payments instead of trade pay-
abies.

59
Processing Down Payments I 6

» The second item is the cleared down payment request with the special
GL indicator F. Note that the real balance on the vendor account is not
zero as shown, but the debit amount of the down payment (plus any
oth er normal transactions with the vendor). Although the cleared item
is included in the total in this example, it is statistical and will not affect
the real balance of the account.

Vendor Une Item Displlly


I~ 4 ~ ~I ~ # !! II ~ &J B-J 'iP ~'il I!Ei o§ 4; ~ ~ ~@]~ ill Selectoons D

Vendor US-VEN1 us
llau Universal Chemical St abili z.-r Co .

0 ..
. ..
St As•iqn..,.,.,nt Docwr:entNo Type

2000000002 ZP
Doc . Date

29. 0 4 . 20 16A
S DD Amount in l ocal cur. LCurr Clrnq doc.

1. 000,00

1. 000 , 00
USD

USD

0 0 1. 000 , 00- USD

.
1700000001 KA 29 . 04 . 201 6 !' 200000000

0 1. 000,00- USD

** .Account. US-V"'Ull o, 00 USD

Figure 40 Vendor Line Item Display Showing Cleared Down Payment Request and Open Down
Payment

If you try to post an invoice to the account of the vendor, you will be noti-
fied by a popup that a down payment exists on the account so that you do
not accidentally pay the invoice as well. The down payment is blocked
and you can continue to pay any invoices not related to the down pay-
ment. When you receive the related invoice, you will first need to post it
as usual and then link the down payment and the invoice together.
Note that there is another option to post the payment using Transaction
F-48, similar to a manual payment. However, most companies seem to
prefer either using a straightforward manual posting or using the auto-
matic payment program.

60
Processing Down Payments I 6

6.2 Clearing the Down Payment

After the invoice has been posted to the vendor account, Transaction F-54
will dear or link the two documents, depending on whether the invoice is
the same amount as the down payment or if the down payment was just
a percentage and now the balance is due for payment with the automatic
payment program.
In our example, we have posted an invoice for 5,000 which we wish to
link to our original down payment so that the automatic payment pro-
gram picks them both up and pays the balance of 4,000.
In Transaction F-54 (see Figure 41), you enter the dates, company code,
currency, and any fields you would normally enter, plus the invoice num-
ber that you wish to link/clear the down payment against. Then, click on
the PROCESS DOWN PMENTS icon. This will take you to a second screen (see
Figure 42) where you select the available down payments - in this case,
there is only one.

Process down pmnts

Document Date 129 . 04 . 20161 Type !i<i1 Company Code


Postilg Date 129. 04.20161 Period !41 Currency/Rate
Document Number I I Translat n Date
Referernce
Doc.He;~d er Text
Tradng1part.BA D Tax Report Date

Vendor
Account lus-VEm

Releva nt invoice
Invoice l19ooooooo21 tile item Q Fiscal year

Transf;er posting item(s) detals


Assignment
Text

Figure 41 Transact ion F-54 Clear Vendor Down Payment

61
Processing Down Payments I 6

Clear Vendor Down Payment Choose down payments


~: Display CUrrency g 'i'
Account lus-1/!:Nl 1
Om ency rusii"l
Down Payments

Document ... u... s Purchasilg... Item Order WBS Element AITI)unt Avalable Amount Transf
2000000002 1 A 0 1.000 , 00 1.000,00

Fi gure 42 Selecting the Down Payment in Transaction F-54

If you go to the top menu, DocUMENT • SIMULATE, you will see a debit and
a credit for the amount of the down payment. The credit is against the
vendor, linked to the original balance sheet for down payments and the
debit is against the vendor linked to the normal vendor payables reconcil-
iation account. You can check this by double clicking on each line and
looking at the related GL account in th e top right corner (see Figure 43).
You will also notice that the invoice that you entered on the first screen is
now appearing in the INVOICE REF. field, and you may be prompted to
enter additional text.

Clear Vendor Down Payment Co"ect Vendor item


.a.s ~ I} ltl Supplement ~ More data ~ Reset

Vendor [us-VDI1 J Universal Chem cal Stabizer Co. GI L Ace 1160000


Company Code (3000 1234 W estchester Pb
BestRun USA PHILADElPHIA
Item 2 I Payment difference I 26
Amount ~o - , USO
Tax amount (o , oo
OC>oo. ~te tax Tax cod e n
Bus. Area n r=c-J I r-----,
Payt T enms
Sine Date
c
129 . 04 .20 161
Days/p ercent
Fixed
r----' 0 , 000 I

Disc. b ase (o, oo Disc. amount 0,0 0


1 1
Invoice ref. 1 900000002 I [2016 I [1'
Pmnt Block [l Pmt Method
Assignment I I
Text Idp clearing
Fi gure 43 Down Payment to Payables Account with Reference to the Invoice

62
General Ledger Postings I 7

Now, when you run the payment program it should pick up the invoice
and the down payment and pay the difference, as shown Figure 44.

..
St Ass i qnment. Docwr.-entNo Type Doc . Da te S DO Alr.ount i n local cur. LCurr C1rng doc .

~ •• 1700000002 10\
1900000002 KR
29 . 04 . 2 016
29 . 04 . 2 016 ~
1. 000, 00 USD
5 . 000, 00- USD

.• 4 . 000, 00- USD

8 0 1700000002 10\ 29. 04.2016 A 1 . 000, 00- USD 1700000002


0 2000000002 ZP 29 . 04 .2016 A 1 . 000, 00 USD 1700000002
0 1700000001 10\ 29. 04.2016 F 1. 000, 00- USD 2000000002

Fi gure 44 Documents on the Vendor Line Item Display

7 General ledger Postings


This section explains the postings to th e GL, how they link in with the
bank statements, and how the bank control/clearing accounts can be
cleared.

7.1 General ledger Accounts

Because of timing differences, if all postings were made directly to the


bank GL account, the bank GL account would be permanently out of sync
with the bank statement. This is especially true, for example, with checks.
The vendor and bank account may be updated in the system at the same
time as printing the check. By the time the check is put in the post,
received by the vendor, and banked, it may be several days, even weeks
later by the time the cleared check appears on the bank statement, which
may affect your period end reconciliations.
If this applied to a lot of items, you would probably keep duplicate
records of the GL account and bank statement outside of SAP, for exam-
ple, in Microsoft Excel, to help you reconcile the two and monitor the
items that have not yet cleared on the bank statement and those that have
appeared on the bank statement but have not yet been posted to SAP.
General Ledger Postings I 7

To keep the GL account in sync with the bank account, automate the bank
reconciliation, and enable you to upload the bank statements automati-
cally, SAP uses special accounts known as bank clearing accounts, bank
suspense accounts, or bank control accounts. By clearing, we mean that
SAP "marks" the item as cleared so that it does not show up on any open
item reports. For example, if you clear an invoice with a payment, then
run an open item report on the account, only the un-cleared items will
show, i.e. those not paid or cleared against a payment yet. This applies to
all types of account, including relevant GL accounts such as the bank con-
trol accounts as well as the customer and vendor accounts.
Depending on the type and quantity of transactions and payment meth-
ods you have, you may have one incoming and one outgoing control
account, or you may have a separate incoming and outgoing account for
each type of payment. For example, you may have one account for outgo-
ing checks, one for outgoing bank transfers, one for outgoing miscella-
neous, such as direct debits, bills of exchange, etc., and then similar
accounts for all the relevant incoming methods.
Normally, you would pay the vendor prior to the payment appearing on
the bank statement, so that any amounts on the outgoing control account
will represent un-cleared payments. On the other hand, for incoming cus-
tomer payments, you would probably wait until you had received the
payment in the bank (i.e. when it appears on the bank statement) before
you would clear any customer invoices.

The next section explains how SAP does the bank reconciliation for you.

].2 Bank Statements

When you upload a bank statement to SAP, the system will post the bank
statement into the bank GL account exactly as it is, with an offsetting
posting to the relevant control accounts. You can also configure items that
do not have to match to anything such as bank charges, commissions,
interest, etc., to go directly to the expense account and have only vendor/
General Ledger Postings I 7

customer items going via the clearing account. When you initially pay the
vendor account with a payment, you n ormally debit the vendor account
and credit the relevant outgoing payment account. Similarly, when you
receive payment from the customer you will credit the customer account
and debit the incoming control account.
Therefore, SAP provides your bank reconciliation for you. You take the
actual bank balance on the bank GL account, which should be identical to
the current bank statement, then you deduct the total of any credits on
the outgoing clearing (this represents un-cleared payments to vendors)
and add back any debits on the incoming payments account. This would
represent any amounts that have not yet been posted to the customers
(perhaps because it is not clear which customer or what the payment is
for).

This process will be more or less automated depending on the company.


Bank statements can be automatically downloaded from the banking sys-
tem and uploaded to SAP using, for example, the Bank Communication
Management. A monitor will let the user know which statements have
been fully uploaded and which, if any, have failed. In an ideal world, if
your customer has entered the correct information directly to the banking
system, you can fully automate the clearing of payments against invoices
on the customer account. In Finland and some of the Nordic countries, it
has been customary for a while, even mandatory, to assign a payment ref-
erence to each invoice, which is then included in the bank file. Now, with
the advent ofSEPA, the NOTE To PAYEE field has been enhanced to enable
more references to be entered than were previously available. Some com-
panies still download statements from their internet banking and upload
them manually to SAP, which does not preclude automatic matching,
although it is often still manual, and/or in a separate step.
The next section goes into more detail about clearing the different control
accounts and the customer accounts.
Troubleshooting the Payment Program I 8

7-3 Clearing the Control Accounts

The vendor account in SAP will be cleared when you initiate the payment,
but the customer account will only be cleared once you receive the infor-
mation that the customer has paid. For outgoing payments, it is a rela-
tively simply step to run the automatic clearing Transaction F.13 on the
clearing account, as long as you have the correct criteria to match on, for
example, the AssiGNMENT field, and you can always manually clear any
items not matching.
Invariably with the incoming payments, they tend to have a one to one
relationship in the clearing account. H!owever, with outgoing payments
done by bank transfer, SAP posts one or more payment documents per
vendor, but only a single total amount will show on the bank statement
for all vendor payments. For example, if you paid 50 vendors one day,
totaling 100,000 you would see one d ebit on the bank control account
from the statement and 50 credits from the payment program (which
debits vendor, credits bank control).
This can be a bit trickier to clear. The key is to ensure that the date the
payment is run is the same as the date that it will appear on the bank
statement, usually this would be the posting date, which would also make
sense from an accounting point of view. This way, assuming other pay-
ment methods have their own clearing account, you can then clear the
account by using a date range on the selection screen of the clearing trans-
action.
In the next section we'll discuss how to troubleshoot the automatic pay-
ment program.

8 Troubleshooting the Payment Program


This section presents a list of problems you may encounter in the auto-
matic payment program. First, we look at the key areas of the master data

66
Troubleshooting the Payment Program I 8

that are relevant to the automatic payment program. Then, we suggest


what to do if the items you want to pay are either missing from the pay-
ment proposal or are listed as an exception, and what some of the error
codes actually mean. Finally, we explain how to correct a payment that
was made in error.

8.1 Master Data


In a live environment (that is, after the configuration has been properly
tested), nearly all errors in a payment run are usually due to either miss-
ing or incompatible master data, but it is not always easy to work out pre-
cisely where the error lies.
In this section, we discuss how to handle issues in bank, vendor, and cus-
tomer master data.

Bank Master Data


In SAP, bank data is held in a register, which is linked to areas such as
vendor and customer master data, so that you do not have to re-enter data
if numerous vendors and customers use the same bank for their accounts,
you just select the relevant bank from the dropdown list.
Each bank in SAP is identified by a bank key, also known as a sort code.
Some companies use the SWIFT or BIC code as a bank key. Usually, the
initial bank data is uploaded to SAP, either by purchasing an up-to-date
register of banks for a particular country, or by transferring the existing
bank data from a legacy system. Some companies regularly update this
data automatically; others create new banks manually in SAP as they are
required. The create/amend bank data transactions (FI01/FI02) are
straightforward, containing only the name, branch, and address details,
plus the SWIFT/SIC code.
Depending on the structure of the organization, you may have a separate
person creating and amending bank data, but in many cases, it is done at
Troubleshooting the Payment Program I 8

the same time as creating the vendor if the bank does not already exist.
The bank master data transaction can ibe called from inside the vendor/
customer master data, global payment transactions screen, (see Figure 45)
by clicking on the BANK DATA icon.
In addition to the banks used by the vendors, you also need to create
your own "house-banks," either in the Transaction FI01 (Create Bank), or
during the banking configuration. The house bank will then be linked, in
the configuration, among other things to a GL account.

Vendor and Customer Master Data


In Section 2.9, we saw that when configuring each payment method, you
could choose to have various fields set as mandatory or optional, such as
the Bank Account Number, IBAN, SWIFT code, Collection Authorization,
SEPA mandate, and so on. The precise combination will depend on local
country or bank regulations and company preferences, but you need to
ensure that the settings in each vendor and customer match the require-
ments of the payment method.
In this section, we will cover these and other key fields required for the
payment run to work properly. Keep in mind that the address and bank
details are global and if a vendor is used by multiple company codes,
especially if the companies are in different countries, you will need to
reach an agreement on how discrepancies are dealt with.
Note that fields may be overwritten in the document, or the payment pro-
posal, or both. For example, the vendor master data may state that the
payment method of a vendor is a standard bank transfer, which normally
takes three days to reach the vendor, but because an invoice is urgent,
you may decide to change the payment method in the invoice to a wire
transfer. The payment method in the invoice will override the payment
method in the master data. Similarly, a vendor may default to a specific
house bank, which you then override in the payment proposal.

68
Troubleshooting the Payment Program I 8

Global Settings - Address Details Screen of Vendor/Customer Master


The country of the vendor may be relevant to some payment methods but
also the language may be important if you want remittance advices to
appear in different languages and if you have configured them accord-
ingly . The language may also be used for purchase orders (or customer
statements), as well as remittances so if a vendor is shared by several com-
pany codes with different languages, you will need to agree on one lan-
guage to be used by all or set up separate vendor accounts. Some compa-
nies set up custom tables so that they can keep one vendor but use
different languages for different company codes.

Global Settings - Payment Transactions Screen: Vendor/Customer Master


Some payment methods may be restricted to certain currencies or coun-
tries, so it is important to choose the correct currency, otherwise you will
get errors in the payment proposal. For example, some companies have
the BACS payment method set to allow only GBP payments to vendors
with UK bank accounts.

Bank Key and /BAN


Historically, only the bank key and bank account number were required
but the IBAN (International Bank Account Number) is now mandatory in
many places. SAP is able to derive the IBAN from most bank keys and
account number combinations, (provided that the SWIFT code is set up in
the bank master data), and perform a validation check. Some companies
no longer have the bank key and account number mandatory and enter
only the IBAN.
To en ter an IBAN manually, see Figure 45. When you click on the arrow
in the IBAN column, if a bank key and account number have already been
entered, SAP will try to derive them. If you want to override this, choose
the CHANGE IBAN icon and click on the SWITCH INPUT TYPE icon to the
right of IBAN and you will be able to enter the IBAN manually.

69
Troubleshooting the Payment Program I 8

Noe Food COI'np;rly LESTER

8.rlc Detals
C... 8.rlc Key 8.rlc Act<ll.flt Actt Holder A.. !BAN IBANVal.le

r~fl759 70?72690

••

8.rlc Details
c
8.rlc COUntry GB "
Bank Key ~59
Bali< n..rrber 206759
SWIFT{BIC BARC~B22

art Account 70772690 !BAN


Control key !BAN Gi77BARC2067S97077269oj
Validfrom J 13 . 12.2007
!BAN
!BAN ()877 SARC 2067 5970 7726 90
Valid from 13.12. 2001 ~~ Chinge Docunents I~

Figure 45 Validating or Entering an I BAN M anually

Partner Bank Type


When a business partner such as a vendor or customer has more than one
bank account, perhaps for different currencies, you can use the PARTNER
BANI< TYPE field to choose which bank account to use for each invoice. To
use this functionality, you will need to enter the PARTNER BANK field first
in the master data, for it to be visible in the INVOICE field dropdown. Then
you either enter the same code manually in the invoice (see Figure 46), or
if invoices are posted by way of an interface, you will need to use a for-
mula to derive the correct code. The partner bank type can usually be
changed once the invoice is posted, although some companies may have
changed this field to be unavailable.

70
Troubleshooting the Payment Program I 8

Bank [)etails
c... Bar* Key Brt Account Acct Holder A.. IBAN lBANValue
Enter Vendor Invoice:
GB 2067 59 70772690 ~B77BARC20675970772690 n Tree on IIDi)company Code

til ·~'"'""'"""
GB 206759 67894567
Transactn
Basic data

BasetleDt 02 . 04 . 2016

I Bank Data... ~~ Delete Bank De ta IOJ !BAN I Dueon n . oS . 20l6 l

PmntCurrcy I
lnv.ref.
Pat. Bank :c-~ __
BnlcT Ctry Bani< Key Bani< Account Reference details IBAN
EUR GB 206759 67894567 GB79BM\C20675967B94567
GBP GB 206759 70n2690 GB77BARC20675970772690

Figure 46 Partner Bank Type

Alternative Payee
When paying the vendor, you may be requested to make payment to a
bank account other than the vendor where, for example, a vendor has fac-
tored their invoices to a factoring company. Technically, you could just
use the factoring company bank details (especially where a company does
not wish to indicate that it is factoring its accounts). However, for better
control, especially if a number of vendors use the same factoring com-
pany, you can set up the factoring company as a vendor, perhaps in a spe-
cial account group so that documents cannot be posted to it directly and
then link the vendor to it. This means that all the documents will still
appear on the vendor account, but they will be paid into the bank account
of the alternative payee.
If the vendor wants all invoices for all companies in the group paid to the
same alternative payee, then you can enter the alternative payee number
in the ALTERNATIVE PAYEE field that is just below the vendor bank details
on the global payment transaction screen in the vendor master. However,
if the alternative payee only applies to one company code on the system,

71
Troubleshooting the Payment Program I 8

then you can choose instead the ALTERNATIVE PAYEE field, which is in the
company code-specific payment transactions screen (Figure 47) in the
vendor master. The company code setting will override the global setting
for that company.

If you tick the INDIVIDUAL ENTRIES field in the global payment transac-
tions settings (see Figure 47) you can enter an alternative payee either
when entering the document, or by going to the document in change
mode and selecting EXTRAS • ALTERNATIVE PAYEE from the top menu. How-
ever, we recommend either having this field hidden or making it a sensi-
tive field that has to be confirmed when changed, to ensure that only the
appropriate permitted payees are entered next to it, to ensure that a
fraudulent payee cannot be added later.

Payment transactions Different Payee ~ Document


Abmative payee AP123------, ~ !r d "' • E tl ,.,
DME Indicator nert'"'s for Referen. Permtted Payee
Instruction key n
,..-!---.
!SR Number

Figure 47 Alternative Payee Section in the Global Payment Transactions Screen

Alternative Payer
The same applies on the customer side, but with an alternative payer
instead of payee.

Company Code Settings in the Payment Transactions Accounting


The key fields in the company code area (see Figure 48) are the PAYMENT
TERMS, which will tell the payment program when the invoice is due, and
the PAYMENT METHOD, for example by bank transfer or check. Note that
the payment terms in the company codes specific area apply only to
invoices that are not posted via the purchase order process. The screen for
the payment terms for invoices posted using the purchase order process is
the purchasing data screen.
The PMT ADV. BY EDI (on the company code payment transaction screen)
tells the payment program whether to send the remittance advice by EDI

72
Troubleshooting the Payment Program I 8

or print. If you want to pay each invoice in a separate payment, you can
tick the INDIVIDUAL PAYMENT box, but most companies usually group the
payments , (particularly where bank charges are by item rather than a flat
fee) as there will be fewer items to reconcile later. Finally, if a payment
block is entered here it will block payment for all invoices for that vendor
but still allow invoices to be posted to the account.

i'i¢ll l.l Display Vendor: Payment transactions Accounting


~ &J~ (j]

~endor 110099 p~~~oe Food Comp;ny LESTER


~an,y Code h oool BestRun USA

Paymernt data
Payt Terms ZBOl l Tolerance groop n
Chi< dol.ble IIW. 0
Cli< ca:shng tine lo'

Automatic payment transactims


-
Payment methods IC
r===i
Payment block r Free for payment
Alternat. payee I Hoose Bank 13000 I
lnciv1dual prmt 0 Grooping key 11
B/ exch .lirnit o,oo IUSD
Pmt adv. by ED! 0

Fi gure 48 Payment Transactions Screen

If you want to see which vendors have an alternative payee, you can run
the vendor list by way of Transaction S_ALR_87012086 and tick the PAY-
MENT DATA checkbox under the FURTHER SELECTIONS section. The equiva-
lent transaction for customers is Transaction S_ALR_87012179.

HO/Branch
Entering the HEAD OFFICE account number for branches in the AccoUNT-
ING INFORMATION section of the vendor master (see Figure 49) will result
in the invoices and payment being assigned to the head office account in
the system, although you can still see the original branch account number
when running open item reports if you add that column to the layout.

73
Troubleshooting th e Payment Program I 8

Vendor [ 100564 Subsidiary company Ltd


Company Code [ 2000 I BestRun UK

Accounting information
Recon. account 1.,...,
60-,-
r1 00,.,..
0_ ,- Sort key fl
Head office [100565 Subsidy indic. n
Figure 49 Vendor Master Data Head Office Field

If you post an invoice to the subsidiary company and then go to the ven-
dor line items for the branch account number, you will see the message
pop up in Figure 50 and the branch invoices will be under the HEAD
OFFICE account number. Note that this will not apply to invoices posted
before entering the HEAD OFFICE number in the master data, as the infor-
mation is transferred to the document line item itself. When displaying
the HEAD OFFICE account, you can add the BRANCH column to the line
item display for added information.

Account 0000100564 Subsidiary company Ltd


Comp. code 2000
The account is a branch

Ln e items are also managed at head office:


Account 0000100565 Head Office Company Ltd
(i)Aiso ist line items from head office

fi' Contllue Jl Never dlspiayag~ini~


Figure so Vendor Line Item Display Message for Branch

Taxes

If withholding tax is applicable, you will need to complete additional tax


fields. These include, for example, the tax number, withholding tax code,
and so on. However, these tax fields differ from country to country.
Therefore, we will not go into the details here, other than to mention that
without the correct setup the withholding tax may not be calculated cor-
rectly, or may not appear correctly on the period or yearend tax reports,
or both.

74
Troubleshooting the Payment Program I 8

8.2 Checklist to Resolve Issues

This section reviews the various problems you may encounter while run-
ning the automatic payment program and suggests what to check to
resolve them.

Nothing Found in the Proposal


If, when you try to display the proposal, you see a message such as CoM-
PANY CODES 3000/3000 DO NOT APPEAR IN PROPOSAL 30.01 .2016 UST01;
CORRECT, this means that the payment program was unable to find any
items meeting the selection criteria e ntered, or any items found are
locked in another proposal and cannot be paid.
Ifyou are expecting items for payment, double check the selection param-
eters; there may be an error in the range of vendors or one of the dates.
If not, it may be that another payment proposal already exists. After a
payment proposal is run, it "locks" those invoices in so they cannot be
paid in another proposal, even the invoices not being paid.
To find out which payment proposal is blocking yours , look at the list of
payments using the dropdown by the payment program RUN DATE or
IDENTIFICATION. They should both give the same result. The dropdown list
will show the status of all payment runs , for example, whether parame-
ters have been entered, proposal creat ed, or payments posted. You are
looking for one that states PAYMENT PROPOSAL HAS BEEN CREATED; the oth-
ers will either be completed or not started yet, so should not lock any-
thing.
This is where the naming convention can be helpful. As the dropdown list
is global, you will see all the payment proposals of all the companies on
the system, so if you do not have a sensible naming convention that indi-
cates the company or country in the IDENTIFICATION field, you may have
to check all of them to find one that is relevant to your company code/
country.

75
Troubleshooting the Payment Program I 8

If you have access to Transactions SE16 or SE16N (or can request your
support department to run it if you are really stuck), you can display the
table of payment runs, and their contents. The table name is REGUP and
you can choose to display only runs that contain payment proposals. The
table will show which vendors and which invoices are contained in which
payment proposals, so if you filter by company code and vendor, this
shoUJld help you identifY which payment proposal is blocking yours.
After you have found the relevant proposal, you need to liaise with the
owner of the other proposal as to how to proceed: either you wait until
they have finished or they delete theirs and wait until you have finished,
before rerunning. Or, it may be possible for one of you to exclude the rel-
evant range of vendors from one of the proposals.
To prevent this from happening in the future, you could ensure that the
prevjous payment proposal is posted before the next is run. By posted, we
mean that the payment run is executed - you may still need to create pay-
ment media, but this should not block the proposal.
However, this is not always practical if you have a number of payment
runs in one day or even a week. It may be that you pay certain vendors,
such as trade vendors, employees, and inter-company vendors separately,
in which case restricting the range in the selection parameters should
avoid overlap. If you do not have a separate number range for different
types of vendors, but do have them set up in different account groups,
you can try entering the account group in the free selection screen.
If you have several payments running at the same time for different pay-
ment methods, you may wish to enter the payment method in the free
selection screen. But if a vendor has more than one payment method in
the vendor master, or there is a different payment method in the docu-
ment, some documents may be omitted from the right proposal.
Troubleshooting the Payment Program I 8

Using the Proposal or Payment Run Log to Understand Errors


The logs can be found under the ADDITIONAL LOG tab. If you have selected
the correct logging type and entered a range of vendors (see Section 3.4),
this should give detailed information about what the exact problem is. If
you didn't select the right options, you can delete the payment proposal,
change the parameters and rerun. However, if you cannot delete the pay-
ment proposal (you may have too many amendments in the payment pro-
posal that you do not want to lose), continue to the payment proposal list-
ing.
The payment proposal log is quite detailed and if you have a number of
invoices that only have a payment block, it may be easier to see them in
the payment listing rather than try to find them in amongst other items in
a long log. Sometimes you have to use t he log to understand a more com-
plicated error, but in the case of a simple payment block, it may be easier
to look at the proposal listing.

Using the Payment Proposal Listing


You can set up a variant to see all items, just those being paid, or just
exceiPtions (that is, those not being paid ; see Section 3.8). Sometime those
not being paid may be as important as those being paid, so it is vital to
review all items.
If the invoice appears in the proposal listing as an exception, you should
see an error message number at the right side of the item not being paid.
In addition, near the bottom of the proposal listing you should see a sum-
mary and brief explanation of all the errors relevant to that proposal (see
Figure 51). The messages are not always clear, for example, is the item
blocked because the invoice didn't match the goods receipt or purchase
order, or has it been subsequently blocked, either in the document or the
proposal? In the next section, you will find a table of some error codes
with a slightly more detailed explanation.

77
Troubleshooting the Payment Program I 8

Err Messaqe Text

001 No pymt possible because items with a debit bal . still exist; see job loq
003 Item i~ blocked f or payme nt
006 No valid paYltent ~thod found
016 Plr..nt: zr.et:hods for t his run are not specified in zcast.er record or in item

Figure 51 Proposal Listing Error Box

Understanding Error Codes in the Payment Proposal


Before we review the most common error codes, one particular error
code causes more trouble than most. This is error code 006 No VALID PAY-
MENT METHOD FOUND (you can see it in Figure 51). This code is used for
almost every situation where an incompatibility exists between some-
thing in the payment method and something else. The trick is finding
where if you are unable to check the payment logs in Section 8.2, for more
detail.
The error 006 appears, for example, if you have entered a payment
method involving a bank transfer where the bank details are required, but
have not been entered in the vendor master (or the alternative payee), or,
if you have a payment method that does not allow a bank in a foreign
country or currency and the vendor has such an account. Even if the pay-
ment is outside of the limits allowed for that payment method specifically
(or the limits have not been set up), you will get message 006 rather than
012 as you might expect. Message 012 is the company code limit rather
than the payment method limit.

Note
Surprisingly, if you do not enter the payment method in the master data but
enter it in the invoice instead, the maximum amount is by-passed.

Table 1 shows the most common error codes, although you may find that
006 is used instead of the message that you would have expected.
Troubleshooting the Payment Program I 8

-
000
Message Text

adjustment active (BAdl)


Explanation/Comment
> SEPA individual lead times: Relates to bespoke changes around the
basel ine date to be able to run the pro-
posal several days early for checking.
001 No pymt possible because There may be an overpayment or credit
items w ith a debit bal. still note on the vendor account that exceeds
exist; see job log the invoice amount to be paid.
002 No pymt possible because Similar to message 001 above, but on the
items w ith a credit bal. stil l customer side .
exist; see job log
003 Item is blocked for payment A block has been entered in the document
line item.
004 Account is blocked for pay- A blod has been placed in the vendor
ment master.
006 No valid payment method See explanation about error 006 at begin-
found ning of checklist.
007 Error in creating the payment Best to read log, but often related to GL
document; read job log accounts. Examples include payables GL
account is not set up as a reconciliation
account, discount account has wrong tax
setting, or doesn't exist, inter-company
accounts missing if different paying code.
012 Min imu m amount for pay- This message refers to the company code
ment has not been reached limit, which may be different from that set
at payment method level.
016 Payment methods for this Payment method in proposal is either dif-
run are not specified in mas- ferent from or missing from master datal
ter record or in item invoice. Cou ld also be missing from the
alternative payee master data.
020 +1- sign for local/for.curr.bal- Normally if an invoice and credit together
ances are different, payment were debit in one currency and credit in
not possible another, the difference would be written
off to exchange differences.

Table 1 Error Codes and Explanat ion

79
Troubleshooting the Payment Program I 8

Message Text Explanation/Comment


031 Account has been flagged for Needs to be investigated. Maybe the
deletion account is a duplicate and the flag needs
to be removed so that you can clear the
account, or the vendor is not valid in
which case their account should not be
paid.
032 Payee flagged for deletion Where there is an alternative payee in the
vendor master and the alternative payee is
flagged for deletion .
033 Unconfirmed change to mas- Need to confirm changes to the master
ter record data.
034 Unconfirmed change to Refers to alternative payees.
payee master data
040 Account is blocked by Generally, you will not be able to get as
another run far as the payment proposal if the account
is in another run.
070 No valid house bank found Check that vendor master does not have
an incorrect house bank-otherwise if at
the beginn ing of a project this may be a
configuration error.
080 Item maturity date too early Only applies Orbian payments.
for Orbian payment
081 Item excluded by BTE Functional module allowing insertion of
00001830, readjoblog bespoke programming.
082 Items locked due to the GTS =G lobal Trade Services (SAP module)
check result in SAP GTS
083 Items locked due to SAP GTS GTS = Global Trade Services (SAP module)
check result of a different
item in payment
084 Item locked due to technical GTS =G lobal Trade Services (SAP module)
problem during the check
made in SAP GTS

Table 1 Error Codes and Explanation (Cont.)

80
Troubleshooting the Payment Program I 8

-
086

099
Message Text
The system could not deter-
mine a valid SEPA mandate
Item was blocked later
Explanation/Comment
The SEPA mandate may exist in the
customer master, but not be confirmed.
A payment block has been added to a
document in the payment proposal.

Tab le 1 Error Codes and Explanation (Cont.)

The next section addresses what to check when you've narrowed down
the error to an item in the master data but are not sure what it is.

Master Data to Check


The following subsections look at the typical master data that must be
checked.

Bank Data
If you think you have a master data error, the first thing to do is check that
the bank details are valid for the payment method and currency in the
proposal. You may not need the bank details if paying by check, but if
paying into a vendor bank account, you may require not just the bank
sort-code and bank account number, but also the IBAN. Also, some pay-
ment files require a SWIFT code to be available in the bank data (see also
Section 2.9 about payment method settings).

Payment Method
Check that the payment method in the vendor master data matches that in
the payment proposal. Also confirm that there is not a different payment
method assigned in the invoice that will override the master data. Check
also that the currency matches the payment method, for example, BACS
must be in GBP, and SEPA must be in Euro.

81
Troubleshooting the Payment Program I 8

Parameters

If an invoice does not appear in the payment proposal at all, check that
the parameters are correct (that is, the vendor or customer is in the range
selected), and the correct due date is selected (see the payment terms sec-
tion). If you have deleted and rerun the payment proposal on a later date,
check that you have amended the Docs ENTERED UP TO field. If you are
paying or collecting money from customers, check that you have entered
a date in the CUSTOMER ITEMS DUE BY field and also entered a range of cus-
tomers.

Payment Terms

Check that the invoice due date falls before the date of the next payment
run in the parameters. Remember that there are two places in the master
data where the payment terms are stored (company code and purchasing)
and that if there is a different payment term in the invoice, this will over-
ride the master data.

Free Selection

Ifyou have restricted the vendor master data payment method in the FREE
SELECTION tab (see Section 3.3), then the proposal will not show any ven-
dors that do not have a payment method exactly matching that in the Free
Selection. Note that if the vendor has more than one payment method in
the master data, but you restrict the free selection to just one payment
method, the system will not find a match.
If the free selection is restricted by document number, you may want to
check that you have the correct number of leading zeros in the free selec-
tion - it may not necessarily match the number shown in the open item as
that will not include leading zeros (see also Section 3.3).

82
Troubleshooting the Payment Program I 8

Payment Amount Exceeded


A discussion of exceeding payment amounts merits its own section because
sever al areas exist where you can enter minimum and maximum amounts.
The fi rst place is at company code level, which can be both minimum and
maximum. If, for example, you decide not to make a payment for any-
thing under USD10, and a vendor has an invoice for USD8, you will see
the error code 012 in the payment proposal listing.
If the maximum and minimum levels have been set by payment method -
maybe a wire costs a lot more so you don't want it to be used for small
amou nts, but you are happy to pay small amounts by a cheaper method,
the error code that appears is number 006, which is the generic message
regar ding the payment method.

Finally, you can set a limit at bank account level, regardless of payment
method, over a specified number of days. Usually, 999 days is used but
you can set it for whatever you require. Again, if you exceed the available
amou nt in that bank account, the error message is 006.

Payment Run Canceled by the System


Everything appears fine, you are happy with the proposal, but when you
click on the PAYMENT icon to post, suddenly the payment run is canceled
and you see a red message in the STATUS tab (see Figure 52). Clearly the
documents are alright to pay and there is no problem with the master
data otherwise you would have had errors in the proposal. Go to the
ADDITIONAL LOG tab and check the PAYMENT RUN LOG. You should see the
reason for the problem. It is likely to be linked with the ability of the sys-
tem to carry out the posting itself, for example, a document range may be
missing. Once you have resolved the issue, you will find that the PAYMENT
RuN icon is no longer available to rerun the payment, and if you try to
create a new payment run, the items are still locked in the old one. You
need to go to the top menu and select EDIT • PAYMENT • AFTER TERMINA-
TION • DRAW UP AGAIN , which will allow you to rerun the payment run.
Troubleshooting the Payment Program I 8

/ Status ' · Parameter Free selection

Stltus
0 Parameters have been entered
0 Payment proposal has been created
0 Payment proposal has been edted
• Payment run has been Glnceled

Figure 52 Payment Run Has Been Canceled

8.3 Reversing a Payment or Payment Run

On occasion, the bank details in SAP for a particular vendor may be incor-
rect. This may not be picked up until the payment is returned from the
bank, or it may be picked up in the bank communication software before
the payment is sent to the bank. However, often by the time it has been
picked up, the payment is already posted in SAP and the related invoices
cleared.
On rare occasions, you may be obliged to cancel the whole payment and
reverse out all the postings, for example, the whole payment was rejected
by the bank for whatever reason, or it was posted in the wrong period, or
posted to the wrong bank account. In the next two sections, we will cover
reversing out a single correction and correcting an entire payment run.

Reversing a Single Correction


You can correct an error for a single payment in a number of ways.
Although not ideal, one way is to leave the postings in place and send a
manual payment to the bank if the error is caught quickly enough. How-
ever, the audit trail from the payment proposal to the bank statement will
be slightly inaccurate.
In most cases, you probably want to reverse out the posting, correct the
master data, and pay the vendor in the next payment run or by another
payment method if urgent. The assumption in this case is that the pay-
ment has either not gone to the bank or been rejected by the bank. You
Troubleshooting the Payment Program I 8

wou[d not normally reverse a payment if it has already been paid to the
vendor, unless correcting the GL or bank account, but you could run into
problems if you have check numbers linked to the first run. If you have
assigned check numbers, various transactions are available for voiding,
reprinting, renumbering, and so on.
First, you need to know the payment document number. This can be
found in one of two ways. Either by going into the payment run and
choosing from the top menu: EDIT • PAYMENT • PAYMENT LIST. In the stan-
dard SAP variant, the payment document number is the first piece of
information under the vendor name and address. Or, you can also find
the document number from the vendor account by displaying the cleared
items. Note that you need the clearing document number, which is usu-
ally document type ZP, not the invoice document number. You can also
check the clearing document by going to the top menu: ENVIRONMENT •
CLEARING TRANSACTIONS as this will group the payment with the docu-
ments being cleared and show the clearing, which is the payment docu-
ment.
You cannot reverse the payment without resetting the clearing first, so
you will need to use Transaction FBRA. In Transaction FBRA, enter the
payment clearing number, company code, and fiscal year, and then click
on the ITEMS icon to double check on the next screen that you are indeed
reversing the correct document. If the document is correct, return to the
initial screen by clicking on the green back arrow key and clicking on the
SAVE icon, which will post the reversaL
Sometimes you have the option to just reset the clearing or reset and
reverse the posting. If this is the case, ensure that you choose the reset
and reverse option. However, if there is an exchange rate posting
involved you may not have this option and will have to reverse the docu-
ment as well. Even if the payment was not in a foreign currency, you may
still have a foreign exchange difference if you have a group currency set
up in a different currency in the background.
Troubleshooting the Payment Program I 8

Next, you will be asked for a reversal reason. The SAP standard reversal
reason 01 is usually described as REVERSAL IN CURRENT PERIOD and rever-
sal reason 02 is described as REVERSAL IN CLOSED PERIOD. This may sound
confusing-obviously you will not want to actually post in a closed
period, but it just means in the second case that the original posting was
in a period that is now closed for postings. With reversal reason 01, the
system will reverse using the same date as the original posting. With
reversal reason 02, you will be able to enter the posting date of your
choosing, usually the current date. After clicking on the ENTER icon a
popup will state CLEARING xx RESET where xx is the clearing document
number, followed by a popup message that DocuMENT YY WAS POSTED IN
COM!PANY CODE zz, where YY is the new document that is posted in com-
pany code ZZ to cancel the original payment.

Something else to consider when a payment has been rejected by the


bank is whether a remittance advice has been sent out, in which case you
probably have to notify the vendor that the payment has not yet been
sent.

Reversing a Whole Payment Run


Although a document mass reversal transaction is available in SAP, you
are not able to use this as it does not reset the clearing and no mass reset
clearing transaction exists. Depending on the size of the payment run, it
may be easier to run Transaction FBRA repeatedly for each document to
be reversed, but this could be time-consuming, with risk of error if you
have a large number of documents.
Although there is no transaction code available to the user, there is a pro-
gram (available since 2015) that your su pport department should be able
to use in an emergency. This program is normally for use by the support
department, but as it is a relatively new program not all support staff may
be aware of it. SAP issues on a regular basis OSS notes that can be small
program changes or information. Details about the payment reversal pro-
gram can be found in OSS note 2125220. The two steps are to install the

86
Miscellaneous I 9

program and then run it, but the program has also has an option for a test
run first, and may need to be run in background if you have a lot of doc-
uments to reverse. Also, it will not let you reverse the payments if you
have already created a payment file, so the payment medium has to be
deleted from within the payment program and the payment run reorga-
nized first.

9 Miscellaneous
This section describes some issues that merit attention but that don't fall
into the standard payment processing workflow.

9.1 Withholding Tax

Withholding tax is when a company is required by law to deduct tax, prior


to paying non-incorporated vendors or individuals such as plumbers,
electricians, builders, lawyers, accountants, architects, translators, and so
on. ft is more prevalent in some countries than others, and different tax
percentages may be deducted on different percentages of the invoice,
depending on the type of service. Tax may be calculated when posting the
invoice, or when the payment is made, but is paid directly to the tax
authorities.
The automatic payment program is only affected by withholding tax
deducted at the point of payment. For example, 100 is owed to a vendor
with a withholding tax of 20. The invoice will be posted as normal for
100, and the payment program will clear the full invoice of100, but only
send the vendor 80. It will post the difference to withholding tax and only
80 will be posted against the bank account.
M iscellaneous I 9

9.2 One-Time Vendor Accounts

You might have a process in place to check the reliability and legitimacy
of new vendors, prior to opening up a vendor account. However, if the
purchase is only a one-off, small amount, the company may decide not to
set up a vendor account in the system. If VAT is involved or payment
needs to be made by the automatic payment program, the invoice can be
posted to the one-time vendor account. At the point of entry of the invoice,
the user will be prompted to enter the name, address, and payment
details against the invoice so that the invoice can be picked up and paid
by the automatic payment program in the normal way. If two unrelated
one-time vendor invoices exist on the account then each one will have
separate name, address, and bank details and will be sent out as two sep-
arate payments.

9-3 Authorizations

Mostt companies have more sophisticated authorizations built in to their


encrypted automated transfer to the banking software to approve pay-
ments. However, the automatic payment program offers an additional
authorization split not found in most other transactions. It allows differ-
ent departments to use parts of Transaction F11 0 without having access to
all of it. For example, one person can create a payment proposal, but not
post it; another person can post and create payment media. You can see
the various options or keys in the top menu ENVIRONMENT • AUTHORIZA-
TIONS (see Figure 53) although the configuration will be done as part of
the normal authorization setup.

88
M iscellaneous I 9

Act:Nitles
Key Action
02 Ed~ parameter$

03 Display parameters

11 Execute proposal
12 Edt proposal
13 Display proposal
14 Delet e proposal
15 Create payment medl!m proposal
16 Create Direct Debt Pre-notifbt . [@
21 Execute payment run
23 Display payment run
24 Delete payment run payment data
25 Create payment me d~ of payment run
26 Delete payment orders of payment run

31 Prilt payment medi.lm manually

Figure 53 Authorization Keys in Transaction F11 0

9.4 Processing Discounts

For the purpose of this E-Bite, we are referring to cash or prompt pay-
ment discounts on vendor invoices that should normally be taken only
when payment is made in advance of the standard payment terms. For
example, an invoice would normally be paid in 30 days, but if paid in 15
days, the payer can deduct 2% discount.

SAP allows companies to process the VAT on cash discounts, as well as


the cash discount itself in many different ways according to local legisla-
tion. VAT can be calculated on the net amount after discount (as was the
case in the UK until April1 5 t 2015) or on the gross amount. Now, in the
UK suppliers have a choice whether to charge the full VAT and issue a
credit if the discount is deducted, or if a statement is issued that the payer
is allowed to deduct only the lower VAT if the discount is taken, then
both sides can adjust the VAT accordingly without a credit note.

The discount can be calculated on the net or gross amount after VAT. The
discount can be posted to a discount clearing account when the invoice is
Miscellaneous I 9

first entered, by selecting the net document type (for example, KN or RN


in standard SAP). This allows the full amount to be posted to the vendor
account. However, the amount posted to the expense or stock account is
reduced by the discount. Or, if you use a normal document type, the full
amount will be posted to expenses or stock and the discount posted to
discounts received (that is, financial income rather than a reduction of
costs) when deducted at the payment stage.
If the invoice is paid on time, the discount clearing will automatically be
zeroed by the reduction in payment. If payment is not made on time,
then the amount in the discount clearing account will automatically be
posted to a P&L account for discounts lost. You can also toggle the VAT
settings on the GL account to allow the VAT to be adjusted on a payment.
The discount can also be manually amended in the payment proposal (see
Section 3.6).

9.5 Installment Payment Terms

Installment payment terms is a useful tool, as opposed to using down pay-


ments or manual payments, if you want to post a single invoice, which
needs to be paid in three elements; for example, 20% up front, then a pay-
ment of 30% after one month, and finally 50% after three months.
The relevant installment payment terms are linked to the payment terms
available in the vendor master, so when the invoice is posted, the system
will automatically split the vendor posting into three for three separate
payments, but will calculate VAT on the whole amount and post the
whole amount to the relevant costs/stock or asset account as a single doc-
ument.

9.6 Netting Off Customer and Vendor Payments

If you just want to include, for example, the customer line items when
you display the vendor line items or vice versa, then you need to enter

90
M iscellaneous I 9

the vendor number in the customer master data in the CONTROL DATA sec-
tion of the vendor and vice versa (see Figure 54). Note that the data in the
CONTROL DATA section is shared globally, so if a vendor is shared among
several company codes then you must all agree on the customer that it
should be linked to.

~ Change Vendor: Control

~ ~ [!]

Vendor I100563 1 UK Company Ltd

Account control
customer I300548 Aut horiz<ltion
Tradn g Partner r-- Corporate Group

Figure 54 Customer Field in Vendor Master Data

However, if you wish to be able to deduct the customer invoices when


paying the vendor, then you also need to select the CLRG WITH CUST.
checkbox in the vendor master data (PAYMENT TRANSACTIONS ACCOUNTING
section) and the C LRG WITH VENDOR checkbox in the customer master data
(see Figure 55).

~ Ch11nge Vendor: P11yment tr11nSIICtions Accounting


~ [} [!]

vendor f lo0563 I UK company Ltd Harrow


Company Code j2ooo' Sest!tun UK

Payment data
Payt Terms 0003 Tolerance group r---'
Chk double inv. R1
Chk cashno ttne fl
AutomatiC payment trans<~Ctions

Payment methods [crt Payment block fl Free for payment


A~ernat.payee I ! House Sank r--j
Individual prmt 0 Groupn g key r:l
cto with cust. or=------,
8/exch.lmt I IGSP
Prrt adv. by EO! 0

Invoice verifotion
Tolerance group r
Figure 55 Vendor Master Data: CLRG WITH CUST Field

91
What's Ahead for Payments? I 10

10 What•s Ahead for Payments?


One of the biggest changes in SAP's history is currently under way with
SAP S/4HANA. On its own, the SAP HANA database is pretty impressive
and many of the existing transactions have been rewritten to optimize the
speed and efficiency of SAP HANA. In addition, SAP HANA brings a new
suite of functionality. We won't go into all the details here, as extensive
information is available elsewhere (in particular, the SAP PRESS book,
SAP S/4HANA Finance - An Introduction, written by Jens Kruger, is a good
starting place). More specifically, a lot of new functionality is on the mar-
ket r·elating to payments, which is enhanced by SAP HANA. The following
sections look at some of this relevant functionality.

10.1 Cash Management


As part of SAP S/4HANA Finance, a new centralized Cash Management
component has been introduced, which covers bank account manage-
ment as well as cash flows and liquidity planning. Bank account manage-
ment includes a number of changes, for example, the creation of a com-
pany's own bank is now done by the users with a workflow and does not
have to be configured by the consultants (although they still have to com-
plete the related links). The related reporting is more sophisticated and
relies less on the GL accounts. Historically, many companies were obliged
to create ranges of numbers for every bank account, which, globally,
could be thousands of GL accounts. Going forward, you still need the
clearing accounts, but different company codes will be able to use the
same GL accounts for different banks, substantially reducing the number
of GL accounts.
Part of the concept of SAP HANA is to offer users a consumer-grade expe-
rience. In other words, instead of having to search through a complicated
menu path or remember the transaction code itself, users can use the SAP
Fiori apps to find detailed summarized data. So for cash management,
when you log in to your SAP system, without having to navigate any

92
What's Ahead for Payments? I 10

further you can instantly see not only a summary of the cash position for
all banks, but you can drill down to country, bank, company code,
account, and so on. You can also see on the "face" of SAP Fiori tiles which
bank statements have been successfully imported, which bank data or
transactions need approval, and you can see the status of any payment
documents, whether payment has been processed and so on, and make
bank transfers.
Two newer areas that affect payments are In-House Cash and Bank Com-
munications Management.

10.2 In-House Cash

The benefit of In-House Cash is to reduce external charges by banks, by


introducing the concept of virtual bank accounts, particularly for inter-
company payments. If a branch in the US needs to pay a subsidiary in
continental Europe, which needs to pay the UK, and the UK needs to pay
the US, you could end up with a series of payments. These might involve
a n umber of banks, bank transfer charges, overdraft charges, foreign
exchange charges on the purchase of the different currencies, hedging,
loss of interest while the money moves around, and so on. Using virtual
banks, money stays in-house and gathers interest, the number of external
payments are minimized, economies of scale are realized, and there is
greater visibility of the overall cash position and short-term liquidity.

10.3 Bank Communications Management

Bank Communications Management, as the name implies, manages the


incoming and outgoing communications with the banks, usually by way
of the SWIFT network. Multi-nationals frequently had to configure a
number of different payment formats as local banks often had different
formats, even when part of the same banking group. Where payments
were semi-centralized in a shared service center, and approved of by a

93
What's Next? I 11

central team, that team sometimes needed a separate security device (keys
or card) to allow them to log in to each bank separately, to set up and
authorize payments and manage the accounts. With Bank Communica-
tions Management, payments can be gathered, merged, and securely and
centrally approved prior to sending to the bank, and, depending on the
exact setup, can be sent in a standard format to the SWIFT network to be
distributed around the world. Bank statements can be imported automat-
ically, so that all the controllers need to do is to look at the SAP Fiori
application monitoring the bank statements to check whether they are all
correctly imported and only investigate those with an error, or where the
bank statement could not fully clear the relevant documents (for example,
when there was a discrepancy between the customer payment and the
invoice).

This brings us to the end of our E-Bite. You should now have a better
understanding of the automatic payment program and how to avoid var-
ious pitfalls by ensuring that the master data is consistent with the config-
uration. Standard functionality is available for things like direct debits,
down payments, partial payments , cross-company code, or inter-com-
pany payments, although depending on your company's setup and pref-
erences these items can also be posted manually.

11 What's Next?
Now that you've mastered the automatic payment program in SAP ERP
Financial Accounting, you're ready to tackle the many other Fl-related
transactions. Beyond the payment program, you'll need to perform tasks
and transactions to conduct your daily work in the New G/L, Asset
Accounting, Accounts Payable, Banking, and more. In addition, you'll
want to learn how FI integrates with other SAP ERP modules, such MM
and SD , to gain a broader, holistic view of SAP ERP Financial Accounting
and how it forms a piece of a larger puzzle.

94
What's Next? I 11

Recommendation from Our Editors

Interested in expanding your SAP ERP Financial Accounting


knowledge? If you want to gain the skills to divide and con-
~~~~ttl quer accounts payable, accounts receivable, asset accoun-
ting, fi nancial close, and more, visit www.sap-press.com/
3978 and check out Financial Accounting in SAP: Business
User Guide!

In addition to this book, our editors picked a few other SAP PRESS publi-
cations that you might also be interested in. Check out the next page to
learn more!

95
More from SAP PRESS

Configuring Financial Accounting in SAP: Master the processes, subcom-


ponents, and tools you need to align your FI system with unique business
requirements. Get the tips and tricks to handle global settings configura-
tion, SAP ERP integration, and General Ledger use!
907 pages, 2nd edition, pub. 11/201 4
E-book: $69.99 I Prin t : $79.95 I Bundle: $89.99
www .sap-press.com/3 665

Accelerated Financial Closing with SAP: Navigate the complex last mile
of finance with speed, efficiency, and .ease with this end to end process
guide for closing your books. Develop a single financial close workflow
and maximize the potential of SAP's financial solutions!
296 pages, pub. 10/2013
E- book: $59.99 I Pri nt: $69.95 I Bundle: $79.99
www.sap-press.com/3227

Financial Accounting with SAP: 100 Things You Should Know About.. .:
If you're an SAP ERP Financial Accounting user or super-user, this book
offers you 100 tips and workarounds that can be used within your SAP
systems to increase productivity and ease-of-use.
343 pages, pub. 06/2011
E- book: $44.99 I Print: $49.95 I Bundle: $59.99
www.sap-press.com/2458

Похожие интересы