You are on page 1of 19

Invoice Verification for SAP R/3

Stephen Birchall

Contents

Preface ........................................................... 5 2.2 Delivery Charges ( Planned and


Acknowledgments ................................ 5 Unplanned ) .......................................... 21
Difference Between Planned and
1 What is Invoice Verification? ............... 7 Unplanned Delivery Charges ................ 21
1.1 High-Level Process ............................... 7 A Third Option ...................................... 22
The Main Steps ..................................... 7 Planned Delivery Charges .................... 22
Capturing the Invoice Details ............... 8 Posting Planned Delivery Charges in
The Use of Invoice Verification ............. 8 Invoice Verification ............................... 24
Processing Mismatched Invoices .......... 9 Unplanned Delivery Charges ............... 25
1.2 Handling Mismatched Invoices ............ 10 A Third Option ..................................... 26
Mismatches During Input ( MIRO ) ....... 10 2.3 Tolerances ............................................. 26
1.3 Processing Blocked Invoices ................ 12 Why Have Tolerances? .......................... 26
Using Workflow when Mismatches What Kind of Tolerances are There? ..... 26
Occur .................................................... 12 Special Tolerances ................................. 27
Using MRBR ......................................... 12 Other Tolerances .................................. 27
Automatic invoice release .................... 13 Configuring the Tolerances ................... 27
1.4 Parking Invoices .................................... 14 Error Messages Resulting from
1.5 Workflow in Invoice Verification .......... 15 Tolerances ............................................. 28
1.6 Summary ............................................... 16 2.4 ERS ( Evaluated Receipt Settlement ) .... 28
How Does ERS Work? .......................... 28
2 Specific Functions in Detail .................. 17 How Safe is the Process? ...................... 28
2.1 The Goods Receipt-Based Invoice ERS for Inter- or Intra-Company
Verification ( GR- Based IV ) Flag .......... 17 Scenarios ............................................... 28
What Does the GR-Based IV The ERS Process .................................... 29
Flag Do? ............................................... 17 The ERS Settlement Transaction ........... 29
The Risks of Setting the Flag Off .......... 18 2.5 Invoice Reduction ................................. 30
The Risks of Setting the Flag On .......... 18 What Does Invoice Reduction Do? ...... 30
On Vs. Off ............................................. 19 The Invoice-Reduction Process ............ 30
How the Flag Works ............................. 19 The Financial Posting of the Difference 31
Entering an Invoice for a Purchase 2.6 Pipeline and Consignment Stock
Order with the Flag Set On .................. 20 Settlement ............................................ 32
Entering an Invoice for a Purchase Order Consignment Stock ............................... 32
that Has the Flag Set Off ..................... 20 Pipeline Stock ....................................... 33
Where is the Flag Set? .......................... 21

www.sap-press.com 1
Contents

2.7 Invoicing Plans ...................................... 33 Running F110 ....................................... 49


Periodic Invoicing Plans ........................ 33 The F110S Transaction .......................... 49
Partial Invoicing Plans .......................... 34 3.7 Summary ............................................... 49
How Does the Process Work? .............. 34
Invoice Verification Relating to 4 Configuration .............................................. 51
Invoicing Plans ...................................... 35 4.1 Basic Configuration. .............................. 51
Basic Configuration for Invoicing 4.2 Define the Attributes of System
Plans ...................................................... 35 Messages .............................................. 52
2.8 Subsequent Debits and Credits ............ 35 How to Configure System Messages .... 53
Posting a Subsequent Credit ................ 35 4.3 Define Tax Jurisdiction .......................... 54
Posting a Subsequent Debit ................. 36 4.4 Configure Automatic Postings ............. 54
Posting a Normal Credit ....................... 36 Account Assignment ............................. 55
2.9 Purchase-Order Texts ........................... 37 Simulation ............................................. 59
The Basic Process .................................. 37 The G/L Accounts Function ................. 60
An Example of How to Use this 4.5 Incoming Invoice .................................. 60
Function ............................................... 38 Number Assignment ............................. 61
2.10 Summary ............................................... 38 Tax Treatment in Invoice Reduction .... 62
Maintain Default Values for
3 Financial Aspects of Invoice Tax Codes ............................................. 62
Verification .................................................. 39 Configure How Exchange- Rate
3.1 Overview .............................................. 39 Differences are Treated ......................... 62
3.2 Automatic Account Determination ..... 39 Configure How Unplanned Delivery
3.3 The Goods Received/Invoice Received Costs are Posted ................................... 62
Clearing Account .................................. 40 Edit PO Supplement Text in
Sample Scenarios of the Use of the Invoice Verification ............................... 63
GR/IR Clearing Account ....................... 40 Define Mail to Purchasing When
Using MR11 to Manage the Price Variances Occur ........................... 63
GR/IR Clearing Account ....................... 41 Configure Vendor-Specific
Regular Maintenance of the Tolerances ............................................ 63
Clearing Account .................................. 42 Maintain Bar-Code Entry ...................... 63
3.4 Tax Processing Within Activate Direct Posting to
Invoice Verification ............................... 43 G/L Accounts and Material Account .... 64
The Calculate Tax Flag .......................... 44 Maintain Item-List Variants .................. 64
The Tax Tab in the MIRO Transaction ... 44 Aggregation .......................................... 64
3.5 Moving Average Price/ Define Start Logo .................................. 65
Standard Price ....................................... 45 Set Check for Duplicate Invoices ......... 65
The Difference Between Standard 4.6 Document Parking ................................ 65
Pricing and MAP ................................... 45 4.7 Invoice Block ....................................... 65
Advantages of Each Option .................. 45 Determine Payment Block .................... 66
3.6 The Payment Run ................................. 46 Set Tolerance Limits .............................. 66
The Parameter Tab ................................ 46 Item Amount Check ............................. 68
The Free Selection Tab ........................ 48 Stochastic Blocks .................................. 68
The Additional Log tab ......................... 48 4.8 Clearing-Account Maintenance ........... 69
The Printout/data medium tab ............. 48 4.9 Invoice Verification in Background ....... 69

2 © Galileo Press 2006. All rights reserved.


Contents

4.10 Electronic Data Interchange ................. 69 4.14 Maintain Customer Exits and
4.11 Message Determination ....................... 69 Business Add-Ins ................................. 70
4.12 Define Document Life .......................... 70 4.15 Logistics Invoice Verification: Index ..... 70
4.13 Authorization Management. ................ 70 4.16 Summary ............................................... 70

Index .............................................................. 71

www.sap-press.com 3
Preface

There are many organizations that have implemented Whether you are about to implement the invoice veri-
SAP and suffered from problems and confusion relat- fication function, or you have already done so, you will
ing to the invoice verification functionality. Many of the find this book informative, even if you don’t believe you
implementations I have seen get it very wrong and the are having any problems with the functionality.
result is a function that is seen as inefficient, complex
and time consuming. This does not have to be the case.
Acknowledgments
If you spend time understanding exactly what the SAP
functionality is trying to achieve and how to use the stan- This book is dedicated to my grandchildren: Stephen,
dard functionality to the fullest, you will reduce the risk Harvey, Rupinder, Balvinder, George, and one more
of problems and find that the functionality is better than who's on the way. To my precious wife Joan, and to all
it appears to be initially. of our children, who constantly make me so glad to be a
This book begins by explaining the basic process in a part of their lives. And to all of my colleagues, who have
non-technical manner. Other chapters focus on the func- endured my terrible sense of humor. I would also like
tionality in detail and show how to configure each option to thank my editor, Jawahara Saidullah, for the help and
to obtain the maximum benefits. It shows the many use- occasional crack of the whip that helped me complete
ful features available that are often overlooked and it the book.
explains some common misconceptions about certain
options that are available and guides you to the correct
choices.

www.sap-press.com 5
1 What is Invoice Verification?

Invoice verification allows you to capture the details of important to include as few steps as possible in the pro-
vendor invoices. If the details of an invoice match the cess, considering that the process of handling payments
expected details that are specified by any related pur- does not in itself add value to the company or to the
chase order and goods receipts, the invoice can be vendor.
automatically made available for payment. Unmatched
invoices are excluded from the payment run and need The Main Steps
to be investigated and released before payments can be The main steps included in the process are:
made. If this process is overly complex or conducted inef-  The capture of the vendor’s invoice details
ficiently, payments made to vendors will be late. Possi-  The matching of those details to the details that we
ble consequences of this include a loss of cash discounts believe to be correct
and even losing the vendor account and having purchase  The investigation of any mismatches
orders rejected by the vendor.  The release for payment of matched invoices
It is essential, therefore, to understand the basic pro-  The accounting entries involved ( including taxes and
cess of invoice verification before you design or modify delivery costs )
it. The standard process provided by SAP is very likely  The details recorded for audit purposes
suitable for most businesses, though this may not appear
to be the case at first. The standard process has many It is important to keep these steps to a minimum and the
configuration options and is normally more than flexible SAP processes do achieve this. Additional steps are coun-
enough to cater to the needs of an invoice-verification ter-productive and add little or no additional value.
department. You are most likely to succeed if you adopt Capture and matching occur in one transaction ( trans-
the standard SAP process, rather than trying to alter action MIRO ). This also includes the automatic release
the SAP process to fit your current functionality. Most for payment if the match is successful. Figure 1.1 shows
problems are caused by a misunderstanding of the stan- the main screen of the MIRO transaction.
dard SAP Invoice Verification process, and this leads to a The handling of mismatched invoices occurs in transac-
design that is a compromise. So we will start with a high- tion MRBR, which also includes the release for payment if
level view of the process. the invoice is successfully matched. Figure 1.2 shows the
main selection screen of the MRBR transaction
The accounting entries are updated when the values
1.1 High-Level Process
are posted ( in both transactions ), as are the records of
The main aim of any invoice-verification process is to events for audit or inquiry purposes. Effectively these two
ensure that vendors are paid the correct amount at the transactions are the main steps involved. The only other
right time ( not too late but also not too early ). The pro- transactions needed to manage the process are inquiry or
cess should have a high incidence of first-time matching, cancellation transactions. If you have built your process
to ensure that as little time as possible is spent trying to to include more steps than this, you may be adding extra
manually match invoices that appear to be incorrect. It is complexity for little or no extra value.

www.sap-press.com 7
1 What is Invoice Verification?

Figure 1.1 Main MIRO Transaction Screen

Capturing the Invoice Details


This step uses transaction MIRO and is the main step in
the process. If the details on the invoice match the details
of what we believe to be owed to the vendor, then this
transaction completes the process and passes the details
to the payment run to ensure that the vendor is paid
at the correct time. No further steps are required if the
invoice matches here. While this is an important trans-
action, it does not need to be carried out only by senior
financial staff. This is a common misconception.

The Use of Invoice Verification


This transaction is designed to be used by any member
of the financial staff, however junior that person may be.
The reason for this becomes clear when you see exactly
what this transaction is doing. Its main purpose is simply
to capture the details from the invoice sent in by the ven-
Figure 1.2 Main MRBR Transaction Selection Screen
dor, even though it appears to do much more than this.

8 © Galileo Press 2006. All rights reserved.


1.1 High-Level Process

Figure 1.3 Sample Completed MIRO Screen

Figure 1.3 shows the MIRO main screen with the details cess as a method of capturing the invoice details, with
completed. the rest happening automatically. If the invoice matches,
The system will then use those details to attempt a then it is passed for payment. If it does not match, the
match against what we believe the vendor is entitled to; details are still captured but the payment is blocked.
only if this matches will a payment be proposed. Figure
1.4 shows the traffic light icon and zero balance that indi- Processing Mismatched Invoices
cate that the invoice match is successful. The standard way of managing mismatched or blocked
invoices in SAP is to use transaction MRBR. Mismatched
invoices are those where the details on the invoice do
not match the details expected according to the purchase
Figure 1.4 Traffic-Light Icon and Zero-Balance Indicating Successful order. This transaction lists all of the invoices that have
Invoice Match been blocked for payment. It gives full details of what is
blocked, what value is involved, why it has been blocked,
Some people assume that selected finance staff should when, and by whom. Figure 1.5 shows a typical list of
use this transaction only because the operator can change mismatched invoices displayed using transaction MRBR.
details on the screen to match the details on the vendor’s If investigation shows the vendor’s details were cor-
invoice. This occurs when the operator is entering the rect, then the details of the purchase order or goods
details and the vendor is asking for more ( or less ) than receipt should be corrected so that the invoice details
the amount we believe is due. But if you remember that match. MRBR will automatically release that invoice for
this transaction is really just capturing the details from the payment once the reasons for the block are no longer
invoice, then you realize that changing the details is not valid, but only if you schedule MRBR as a regular job to
actually authorizing any payment. In fact, this transac- release all invoices that no longer mismatch.
tion doesn’t even require human input; it can be carried If the blocks are still valid—that is, if we disagree
out using scanning equipment and appropriate software with the vendor’s details—then the invoice can remain
( in fact several organizations already use this method to blocked for as long as required, or until a credit note has
enter invoices into SAP ). So you must think of this pro- been posted. If, in certain unusual circumstances, the

www.sap-press.com 9
1 What is Invoice Verification?

Figure 1.5 MRBR List Screen Showing Mismatched Invoices

vendor’s invoice details are correct but we cannot change When posting an invoice, the system will fill in most
the purchase order or goods receipt details to ensure a of the data for you. The data normally is taken from the
match, we can use MRBR to remove blocks manually purchase order referenced in the purchase order field on
and release invoices even though they do not match. For the main screen of transaction MIRO, and so this may
this reason, MRBR is a transaction that must be limited not match the actual details from the invoice. This means
to selected people in the business. These must be peo- that when the system adds up the line items and com-
ple with authority to write a company check, as they are pares the result against the total value you entered in
effectively paying a vendor for something that we have the Amount field of the basic data tab, it will not add up
indicated that we do not owe them for. mathematically.
To post the invoice, you must make sure that the
value of the line items adds up to the Amount field value
1.2 Handling Mismatched Invoices
( with taxes considered ). This means that you will have to
There are two main situations in which you have to deal change the quantities and values that the system has pro-
with mismatched invoices. These are: posed in order to match the quantities and values speci-
 During input ( in MIRO ) fied on the vendor’s invoice. Figure 1.6 shows the MIRO
 After the input of the invoice main screen with the Amount field entered and the line
details proposed by the system, based on data taken from
Mismatches During Input ( MIRO ) the referenced purchase order.
The MIRO transaction performs two main checks: This is where some people mistakenly get the idea
 The first ensures that the details entered add up that changing these values is somehow authorizing the
mathematically. payment. In reality, it is simply ensuring that the system
 The second checks to see if the invoice should be knows the details of the invoice so that a match can be
blocked or made available for payment. attempted. Think of it this way: If the system did not try
to help by filling in the expected quantities and values,
The second check relies on the majority of the configu- then you would have to enter them manually every time.
rable invoice tolerances. After all, a mathematical check All that is happening is that the system is trying to save
is not meant to deliver approximate results. Having said time for you by filling in what it thinks the invoice should
this, there is one tolerance that relates to the first check, contain. So changing these values is not authorizing pay-
and is known as the manage-small-differences tolerance. ment, merely indicating what the vendor is asking for.
This is designed to control the allowed rounding errors The second check is where the main tolerances play a
( mainly during tax calculations ). So, if the documents part. If the differences are within the tolerances, then the
mathematically match within the configured tolerance, invoice is posted and the payment is not blocked.
the system can then accept this as a rounding error and If the differences are outside the tolerances, then the
allow the process to continue to the next stage, where invoice is still posted but the payment is blocked. So tol-
the remainder of the invoice tolerances can be checked. erances really only control whether the payment is to be

10 © Galileo Press 2006. All rights reserved.


1.3 Processing Blocked Invoices

blocked; they do not control whether the invoice can the VAT is 350, but the value from the purchase order
be posted ( apart from the rounding tolerance, i.e. small ( price multiplied by un-invoiced receipts ) does not add
differences ). Figure 1.7 shows an invoice that does not up to this value. Therefore, the invoice cannot be posted
balance mathematically. The invoice total is 2,350 and because of this mathematical discrepancy.

Figure 1.6 MIRO Screen Showing Data Obtained from Referenced Purchase Order

Figure 1.7 Invoice Failing Mathematical Check

www.sap-press.com 11
1 What is Invoice Verification?

1.3 Processing Blocked Invoices Caution: Only use MRBR to process blocked invoices,
to avoid corrupting the data used by MRBR.
When an invoice has been blocked for payment due to a
mismatch that is outside the invoice tolerances, all that
is different from an invoice that has not been blocked for Using Workflow when Mismatches Occur
payment is the setting of the payment blocking flags. Fig- Someone will have to investigate when an invoice is
ure 1.8 shows an invoice with a payment-blocking flag ( In blocked during MIRO, but how are they informed that
this case an R to indicate an invoice-verification block ). there is a problem and what caused it? Many organiza-
The financial postings are the same. The value is still shown tions simply photocopy the invoice and pass it to the
as an open item on the vendor account, so any effect appropriate department with a handwritten explanation
on the moving average price ( or price variance account ) of the problem. This works well enough if the volumes of
will still occur, even if the document is blocked. The only invoices that are posted are low and only a few people
action that is required to process blocked invoices is to are involved in the investigations. This keeps it simple
decide if the blocks should be removed. There are two and is often the best way.
ways to remove the blocks, both using transaction MRBR However, if the volumes are large and/or many people
These are: are involved in the investigations, then a more sophisti-
 Manually, by indicating which block or blocks are to cated solution is required. This is where workflow plays a
be removed very useful part in the process. MIRO can trigger a work-
 Automatically, by running MRBR with the automatic flow message ( normally an SAPmail or email message
release flag set on that can be formatted to suit your needs ) to an appropri-
ate user whenever a mismatch occurs. This is normally a
request to correct a price or complete a goods receipt to
make the details match the invoice.
The usual response to these messages is to carry out
the change or to reply stating that the details are cor-
rect and the vendor’s invoice should not be paid. This is
a standard option in SAP and requires minimal configu-
ration and setup, ideally with the help of your workflow
consultant.

Using MRBR
MRBR should be checked regularly, and this transaction
should be seen as the sole transaction for managing the
release of blocked invoices. You can list blocked invoices
Figure 1.8 Payment-Blocking Flag by vendor, by date, by purchasing group, or by user,
among other criteria. The system will then display the
Many people make the mistake of simply removing the blocked invoices that match the selection options, and
blocks using a financial transaction such as FBL1N. This you will then be able to release invoices manually. Figure
removes the flag and allows a payment to be made, 1.10 shows an example of the screen used to manually
but it does not process the blocked record properly, so manage blocked invoices.
the items still appear in the blocked invoice transaction This should only be necessary when you do not wish to
( MRBR ) even after they have been released. Figure 1.9 change the purchase order to correct the price or when
shows the FBL1N screen that should not be used to man- you wish to pay for the items even though a receipt may
ually release invoices. not be have been fully posted. To release an invoice, you
can either select individual blocking reasons ( quantity,

12 © Galileo Press 2006. All rights reserved.


1.4 Parking Invoices

Figure 1.9 Initial FBL1N Transaction Screen

Figure 1.10 Mismatched Invoices Displayed Within Transaction MRBR

price, date, etc. ) and remove the block, or simply release because the goods receipt has not yet been posted and
the whole invoice. then the goods receipt is posted, the invoice will not be
automatically released for payment. However you can
Note: You cannot release part of an invoice for pay- use transaction MRBR in a scheduled job with the flag
ment. The invoice is either blocked or available for Release automatically set on, and this will then release all
payment in total. invoices where the blocking reason is no longer relevant.
This will then act the same as an automatic release, but
Automatic invoice release will only release when the job has run. Ideally, this should
There is actually no setting for automatic invoice release be at least once a day. Figure 1.11 shows the position of
for payment as such. If you have an invoice that is blocked the flag on the initial screen of transaction MRBR.

www.sap-press.com 13
1 What is Invoice Verification?

There are two main ways to park an invoice. The most


common is to decide partway through posting an invoice
that you wish to exit and save your work done so far
without processing the invoice. To do this, you can use
the menu option Edit > Switch to Document Parking.
This will allow you to save the work you have done so far
without the document being posted.
The other option is to start off by using the Invoice
Parking function directly, instead of MIRO, using trans-
action MIR7. This is used in situations where you know
that you will not want to process the invoice at this stage.
Figure 1.11 Release Automatically Flag in MRBR Initial Screen
Figure 1.12 shows the initial screen of the MIR7 invoice-
parking transaction. Note how similar this is to the MIRO
1.4 Parking Invoices screen.
This is where some implementations misuse the func-
The Invoice Parking functionality provided by SAP has a tion. Sometimes people interpret the Invoice Parking
very specific purpose, and if you are using it for this pur- function as an integral step in the process. It does appear
pose then it functions well. If, on the other hand, you are that all invoices could be posted as parked first, and then
using the parking process as a specific step in the nor- someone else ( perhaps someone more senior ) could
mal processing of invoices, then you may find that it is process the parked invoice into a fully processed invoice.
not designed for this purpose and you may experience This can be done, and I have seen it used in this way in
problems. some implementations, but you have to keep in mind
The function has been provided to address situations that it was not designed to be used in this way and so is
where, for whatever reason, the user does not wish to unlikely to function in the way you hoped. In the imple-
complete the invoice-verification transaction but wishes mentations I have seen, parking was excessive because of
to keep the data entered so far. This is ideal if a complex overuse of the goods receipt-based invoice verification
invoice is being processed and there is not enough time flag ( covered in detail in Section 2.1 ).
to complete the transaction. The data entered so far can For instance, you can view and monitor parked
be parked and returned to at a later stage. invoices using transaction MIR6, the Invoice Overview

Figure 1.12 Initial Screen of the MIR7 Transaction

14 © Galileo Press 2006. All rights reserved.


1.5 Workflow in Invoice Verification

function, but there is no ideal transaction that ensures The workflow function can be used throughout the
that all parked documents are processed in a timely fash- SAP functionality and is not restricted to certain events
ion. This can result in some invoices being overlooked. or transactions. However, you will find that in some stan-
This is not a failing of the SAP system, but occurs because dard transactions SAP has integrated basic workflow
this is not the purpose of the function. Figure 1.13 shows functionality. Invoice verification is one example of this.
you how to view or manage parked invoices with trans- SAP has a pre-defined workflow template WS20000397,
action MIR6. specifically for the management of mismatched invoices.
Some implementations then tie in workflow functions The standard workflow function in invoice verification
to manage the processing of parked invoices, and this is designed to be used to send a workflow message ( there
adds to the complexity. is no specific layout for this message; you can word and
However, if the whole Invoice Verification function is format it as required ) via email or SAPmail to a user The
fully understood, then you are unlikely to find any ben- user would be informed that the invoice did not match
efit from using it in this way. The incorrect use of the GR and be told if it was due to a price or quantity variance.
based Invoice verification flag often leads to a need to Full details of the purchase order can be included in the
park far more invoices than necessary. message, and further processing can be carried out within
the message ( to go to the purchase-order change func-
tion or the goods-receipt function, directly from within
the message ).
This function can be very useful when several people
are responsible for purchase orders and goods receipts.
If staff requirement are low, then it may be easier to just
send a photocopy of the invoice in the internal post with
the details of the problem.
The workflow process can be configured to use various
methods of determining to whom the message should
be sent. It could be the user who created the purchase
order, the requisitioner, or the person responsible for
posting goods receipts at the plant or storage location on
the purchase order. If there are complicated rules to be
followed, then this can be achieved by basic Advanced
Business Application Programming ( ABAP ) coding. ABAP
is SAP’s programming language.
All in all, the workflow function is seen as being very
Figure 1.13 MIR6 Transaction Used to Display and Manage Parked useful. It should be considered not only a user-friendly
Invoices
function, but also a good method of ensuring that mis-
matches are handled quickly and by the appropriate
1.5 Workflow in Invoice Verification person, without the possibility of omissions due to lost
paperwork, or other issues.
Workflow is a very useful tool within SAP. Some people As for developing workflow solutions in other areas
describe it as event-triggered messaging, but I prefer to of invoice verification, or anywhere else in SAP, I have a
refer to it as event-triggered events. Basically, you can word of warning. The functionality offered by workflow
use workflow to send a message when an event occurs, can dramatically improve many processes, and it can be
or you can trigger an action or another transaction when used to make the system capable of other very useful
an event occurs. functions, but it does have an overhead and that is the
technical maintenance. This is a small price to pay, but

www.sap-press.com 15
1 What is Invoice Verification?

it has to be considered when determining if workflow is ageable, but the biggest problem with workflow is that it
appropriate. is so useful that many areas can benefit from its use. This
It is possible for workflow records to occasionally have can result in delays during implementations due to the
technical problems, and this may result in the message additional design, building, and testing involved.
not being received or processed by the user. This will
leave an unprocessed record that has to be resolved by
1.6 Summary
someone with significant workflow skills. If you multiply
this possibility by the number of messages that are trans- Invoice verification in SAP is a solid and efficient process.
mitted, then this problem-resolution can become almost But do try wherever possible to use the standard SAP
a full-time task. functionality as covered in this chapter. This will ensure
Other problems, such as unexpected combinations of that you gain maximum benefits for the least effort.
data, can also result in unprocessed messages. Thus, the In Chapter 2, we will be looking at the functionality
more workflow you use the more need you will have for in more detail, and this should enable you to design an
appropriate support when it goes wrong. This is all man- invoice-verification process to suit your needs.

16 © Galileo Press 2006. All rights reserved.


Index

A B Configure Automatic Postings 52


consignment stocks 32
ABAP 15 BACS 47
correction ID 30
account assignment 55, 56 balances 24
credit note 9, 30, 31, 35, 36, 41, 62
account assignment category 22 bar Code 63
credits 58
account check 59 basic data 10
Customs 21, 39
account configuration 58 Basic data tab 31, 44
accounting documents 61 batch job 19
accounting processes 54 batch runs 52
D
accounting view 45, 59 bill-of-lading 19 dates 26
account modifier 58, 59 blanket purchase order time limit date variance 68
account numbers 54 exceeded 67 deadlines 47
actual payment date 61 blocked 9, 10, 19, 24, 26, 28, 29, 30, Debit/Credit 58
additional charges 26, 36 40, 41, 65 debits 58
additional invoice 26 blocked for payment 9, 17, 18, 60 default codes 44
additional lines on the invoice 64 blocked invoices 12 default tax codes 62
additional Log 48 blocking flags 12, 39 Define Attributes of System Messages 52
aggregation 64 blocking reasons 12 define tax jurisdiction 54
allocations 22 block parked invoices 65 delivery 19, 20, 21, 24
allowed invoice interval on the purchase BOMs 33 delivery-note 17, 19
order 67 bulk materials 42 delivery charges 21, 22, 24, 25, 36
amount field 36 delivery costs 24, 45
delivery date 26, 68
amount for item with order reference 67
C delivery note 64
amount for item without order reference
66 calculate tax 44 delivery surplus 42
amount of blanket purchase order 67 calculate taxes automatically 62 delivery tab 34
Application area 59 Calculate tax flag 36, 44 different tax codes 44
archiving 70 cash-flow 27 Direct Posting to G/L Accounts and Mate-
authorization 70 cash discounts 61 rial Account 64
authorized 28 chart of accounts 57, 59 discounts 47
authorizing the payment 10 check-limit flag 63 document types 61, 63, 69
automatic account determination 22, 31, check for Duplicate Invoices 65
39, 55 check of Referenced G/L Accounts 59
automatic clearance 42 city 54 E
automatic credit note 62, 63 clearing account 31, 40, 42, 69 early payment to a vendor 68
automatic date calculations 35 clearing document 43 EDI 69
automatic invoice reduction tolerance 63 clear manually 42 email 12, 15, 63
automatic invoice release 13 company code 26, 27, 43, 46, 55, 59, error-message 28, 52
automatic payment 66 60, 62, 63, 65, 66, 68, 69, 70 ERS 19, 28, 32, 42, 43
automatic postings 31 complaint document 62 exceed amount, quantity variance 67
automatic release 19 complex invoice 14 exchange rate 47
condition types 22, 23, 24

www.sap-press.com 71
Index

exchange rate differences 62 H Maintain Variants for Aggregation List 64


exchange rate table 62 manage small differences 44
Handling Mismatched Invoices 10
exclude items due for payment 48 manage small differences tolerance 10
header conditions 24
exclude values 48 manual blocks 66
header delivery costs 24
MAP 27, 30, 32, 36, 43, 45, 46, 52, 59,
header text 38
68
F header text types 63
matched invoice 39
help-text 51
F110 46, 49 material 21, 64
F110S 46, 49 material document 20
FBL1N 12 I material master 45
Financial Accounting menu 52 material master record (Accounting View)
identification code 46
financial postings 12, 39, 42 22, 56
IMG 52
form small differences automatically 27, material price 21
IMG Projects 52
67 materials-management postings 39
Info Record 21, 29, 32, 33
free Selection 48 material types 56
“information” message 54
freight 21, 22, 39, 42 maximum cah discount 70
input mode 59
freight provisions 54 memos 37
input of material number 59
full payment run 49 message-determination configuration 63
input of valuation class 59
Message Determination 69
insurance 21
message number 53
G inter- or intra-company purchases 28
messages 52
G/L account 55, 58, 59 invoice-relevant notes 38
MIGO 19, 24
G/L account number 56, 58 Invoice amount acc. to vendor 31
MIR6 14
general-ledger account 25, 31, 39, 59 invoice overview 14
MIR7 14
general ledger 39, 54 Invoice qty acc. to vendor 31
MIRO 7, 8, 10, 29, 43
general modification 58 invoice quantity 27
mismatch 12, 30, 65
goods-receipt 15, 23, 29, 32, 35, 45, invoice reduction 30, 62, 63
mismatched invoices 9, 15
46, 60 invoices posted in the background 69
modifications 70
goods-receipt-based invoice verification invoice surplus 42
movement type 58
17 Invoice tab 34, 43
moving average price 12, 25
goods-receipt/invoice-receipt clearing invoice tolerances 10
Moving average price variance 68
account 39 invoice value 28
Moving average variance 27
goods-receipt flag 34 Invoice Verification text 38
MR11 41, 43
goods receipt 9, 12, 13, 17, 18, 19, 20, invoicing plan 34
MRBR 7, 9, 12, 19, 30, 69
24, 28, 41 item category 68
MRIS 34, 35
goods receipt-based invoice verification item conditions 24
MRKO 32, 33
14 item List Variants 64
MRRL 29
goods receipt/invoice receipt (GR/IR) item text 37
multiple companies 46
clearing 54 multiple company codes 65
goods receipt/invoice receipt (GR/IR) L multiple tax codes 44
clearing accounts 25
last movement before key date 42
goods receipt/invoice receipt clearing
layout of the line display 64 N
account 40
leases 33 net 45
GR (Goods Receipt) flag 68
liability account 32 net price 35
GR-based IV flag 18, 20, 40
line items 10 net proposal 45
GR/IR clearing account 40, 41, 43, 58
Logistics Invoice Verification 52 next payment run 47
GR based IV flag 19, 20
GR flag 35 No ERS flag 29
non-invoiced receipts 40, 42
group similar plants 56 M non-valuated receipt 34
Maintain Number Assignments for notifiable texts 38, 63
Accounting Documents 61

72 © Galileo Press 2006. All rights reserved.


Index

notifiable text window 38 profit and loss 45 SAP Reference Implementation Guide 52
number ranges 61 proposal flag 49 scanning 9
proposal run 49 schedule the payment run 46
proposed payments 49 scheduling the payment run as a batch
O purchase order 9, 10, 12, 15, 17, 19, 20, job 49
21, 23, 24, 25, 27, 28, 32, 33, 37, 43 self-billing 19, 32, 35
open account item 70
purchase order header 37, 38 Set Item Amount Check 68
open item 12, 32
purchase order header text 38 settlement program 29, 32
Options 59
purchase order history 36 set value payments 33
output type 29
purchase order price 18 simulate postings 59
overcharge 30, 44, 66
purchase order reference 37 simulation 55, 58, 59, 60
overpaid 18, 26, 28
purchase prices 45 small differences 11, 26
overpayments 66
purchasing configuration 24 small differences account 63
purchasing data 29 small variances 42

P purchasing group 12 spot check 68


SPRO 51
paid on time 18 staged payments 33, 34
parameter tab 46 Q stages 34
park 18, 20, 69 Qty Var. Less Than/Equal To 42 standard accounts postings 39
partial delivery 40 quantity 20, 21 standard messages 53
partial invoicing plans 33 quantity invoiced 40 standard price 43, 45, 59
partial payments 33 quantity received 28, 40 Start Logo 65
payment 24, 27, 39 quantity variance 15, 19 status 69
payment block 65 quantity variance when GR qty = zero 67 status screen 49
payment differences 70 status tab 49
payment logs 48 stochastic block 68
payment methods 46 R stock account 22, 25, 26, 32, 36, 39, 40,
payment run 8, 29, 46, 47, 61 41, 43, 45, 46
random block 68
payment run date 46 storage location 15
rate type M 47
payment schedule 35 subsequent credit 35
RE 61
payment terms 28, 30, 61 subsequent debit 26, 35, 36
receipt 22, 39
Percentage OPUn variance with IR before summarized invoices 17
reference 46
GR 67 summary reports 49
reference document 19
periodic invoice plans 33, 35 switching off a message 52
reference document number 65
pipeline liabilities 33
regular payments 33
pipeline materials 32, 33
release automatically 13
planned delivery charges 21, 22, 25
released 21 T
planned delivery cost 67
release invoices 10, 12 tax 19, 27, 31, 43, 62
plant 15, 54, 55, 56, 58, 59
rentals 33 tax accounts 39
posting date 30
requisitioner 15 tax amount 44
postings 39
RN (net) 61 tax calculations 10
price calculation schema 24
rounding 11 tax code 43, 44, 62, 69
price control 45
rounding errors 10, 27, 44 Tax Jurisdiction 52
price differences 44
royalty and license payments 33 tax procedures 43
prices 26
rules 57, 58 test mode 35
price variance 36, 39, 54, 62, 63, 67
rules of accounting 54 test runs 48
price variance, estimated price 67
price variance account 12, 32, 43, 45, 46 text element 38
pricing conditions 21 S three-way matching 17, 18, 19, 22, 24,
pricing scales 24 26, 28
SAP help 70
printout/data medium 48 tolerance 27
SAP Invoice Verification process 7
print program 48 tolerance group 63, 70
SAPmail 12, 15, 63

www.sap-press.com 73
Index

tolerance keys 27 unplanned delivery costs 21, 62 VAT 27, 29


tolerance limits 66 upper and lower limits for percentage and VAT code 43
tolerance percentage and/or value 63 value 66 vendor 12
tolerances 10, 20, 26, 63, 65 user exits 70 Vendor-Specific Tolerances 63
too early 26 Vendor-Tolerance Group 63
total value 18 vendor account 12, 32, 39, 40
traffic light 9 V vendor master record 29, 63
transaction/event key 56, 58, 59 valuation area group 55, 56, 58, 59, 60 vendors invoice number 65
transaction event key 31 valuation class 55, 56, 58, 59
valuation modifier 55, 58 W
U value-only h credit 36
warning message 27, 52
value only invoice 36
undercharged 44 workflow 12, 15
Value Variance Less Than/= To 42
unmatched invoice 39 write-offs 39
Var. from condition value 67
unplanned delivery charges 25, 26, 36 WRX 58
variances 25

74 © Galileo Press 2006. All rights reserved.

You might also like