When an invoice is blocked, Financial Accounting cannot pay the invoice. Invoices can be blocked either automatically or manually.
You can park invoices or credit memos. This means that you enter the invoice data or credit memo data in the system and save it in a document, but the system does not post this invoice initially.
soory i m not understand
ok i m asking some quesplz reply me
1.accounting entries will be generate in parked invoice or bloked invoice or in both?
2. we have to post the invoice in both the situation?
3.whether no range will be change in both the invoicing as compare to original invoicing
4.in which situation we are able to pay the vendor
-For park invoice there's no accounting entries since we don't post the document yet,but for blocked inv its already contain FI doc.
-You need to post the parked inv , Before you can pay a blocked invoice, you must release it in a separate step. You do so by canceling the blocking indicator that was set when the invoice was posted.
Block invoice is due to varainces in invoice quatity,value with PO quantity ,value.You have to unblock this invoice for further processing.
Parked invoice may be incomplete data which you have received in invoice,so you park that invoice insead of deleteing the already entered data .When you receive the complete data you enter that in the parked invoice and post it.
12 © Galileo Press 2006. All rights reserved.
1 What is Invoice Verifi cation?
1.3 Processing Blocked Invoices
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
payment is the setting of the payment blocking fl ags . Figure
1.8 shows an invoice with a payment-blocking fl ag ( In
this case an R to indicate an invoice-verifi cation block ).
The fi nancial postings are the same. The value is still shown
as an open item on the vendor account , so any effect
on the moving average price ( or price variance account )
will still occur, even if the document is blocked. The only
action that is required to process blocked invoices is to
decide if the blocks should be removed. There are two
ways to remove the blocks, both using transaction MRBR
_ Manually, by indicating which block or blocks are to
_ Automatically, by running MRBR with the automatic
release fl ag set on
Figure 1.8 Payment-Blocking Flag
Many people make the mistake of simply removing the
blocks using a fi nancial transaction such as FBL1N . This
removes the fl ag and allows a payment to be made,
but it does not process the blocked record properly, so
the items still appear in the blocked invoice transaction
( MRBR ) even after they have been released. Figure 1.9
shows the FBL1N screen that should not be used to manually
Caution: Only use MRBR to process blocked invoices,
to avoid corrupting the data used by MRBR.
Using Workfl ow when Mismatches Occur
Someone will have to investigate when an invoice is
blocked during MIRO, but how are they informed that
there is a problem and what caused it? Many organizations
simply photocopy the invoice and pass it to the
appropriate department with a handwritten explanation
of the problem. This works well enough if the volumes of
invoices that are posted are low and only a few people
are involved in the investigations. This keeps it simple
and is often the best way.
However, if the volumes are large and/or many people
are involved in the investigations, then a more sophisticated
solution is required. This is where workfl ow plays a
very useful part in the process. MIRO can trigger a workfl
ow message ( normally an SAPmail or email message
that can be formatted to suit your needs ) to an appropriate
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 correct
and the vendors invoice should not be paid. This is
a standard option in SAP and requires minimal confi guration
and setup, ideally with the help of your workfl ow
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
by vendor , by date, by purchasing group , or by user,
among other criteria. The system will then display the
blocked invoices that match the selection options, and
you will then be able to release invoices manually. Figure
1.10 shows an example of the screen used to manually
manage blocked invoices.
This should only be necessary when you do not wish to
change the purchase order to correct the price or when
you wish to pay for the items even though a receipt may
not be have been fully posted. To release an invoice, you
can either select individual blocking reasons ( quantity,
14 © Galileo Press 2006. All rights reserved.
1 What is Invoice Verifi cation?
Figure 1.11 Release Automatically Flag in MRBR Initial Screen
1.4 Parking Invoices
The Invoice Parking functionality provided by SAP has a
very specifi c purpose, and if you are using it for this purpose
then it functions well. If, on the other hand, you are
using the parking process as a specifi c step in the normal
processing of invoices, then you may fi nd that it is
not designed for this purpose and you may experience
The function has been provided to address situations
where, for whatever reason, the user does not wish to
complete the invoice-verifi cation transaction but wishes
to keep the data entered so far. This is ideal if a complex
invoice is being processed and there is not enough time
to complete the transaction. The data entered so far can
be parked and returned to at a later stage.
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 transaction
MIR7 . This is used in situations where you know
that you will not want to process the invoice at this stage.
Figure 1.12 shows the initial screen of the MIR7 invoiceparking
transaction. Note how similar this is to the MIRO
This is where some implementations misuse the function.
Sometimes people interpret the Invoice Parking
function as an integral step in the process. It does appear
that all invoices could be posted as parked fi rst, and then
someone else ( perhaps someone more senior ) could
process the parked invoice into a fully processed invoice.
This can be done, and I have seen it used in this way in
some implementations, but you have to keep in mind
that it was not designed to be used in this way and so is
unlikely to function in the way you hoped. In the implementations
I have seen, parking was excessive because of
overuse of the goods receipt-based invoice verifi cation
fl ag ( covered in detail in Section 2.1 ).
For instance, you can view and monitor parked
invoices using transaction MIR6 , the Invoice Overview
Figure 1.12 Initial Screen of the MIR7 Transaction
You are blocking the Invoice for payement to vendor based on various reasons like qulity and quantity or payment date is 45 days but ur doing invoice at 30 days.
Parking the Invoice means you got the Invoice and entring to systems but during that you find , there some mistakes and want to edit it, so u inform the vendor and park it. later u got modified vendor invoice and now u can edit that Invoice (parked).