“GR IV”, or not “GR IV”: that is the question

By Orsolya Islik

A lot of organisations have taken the popular decision to go NO PO – NO PAY for Indirect spend. This means: in an ideal world, every invoice is related to a PO.                     

BUT what kind of PO?

We know there are looooots of different options to choose from, some more commonly used and some just created with people’s best intentions and knowledge at the time.

There is a group I call “2 way POs”. They are commonly known as Framework or Blanket orders but they do not require any kind of GR flag, so let’s leave them for another post.

“NOT GR IV”

Here we have a PO with GR selected on Delivery Tab, but without GR IV flag on Invoice Tab. There has been no Goods Receipt (or not sufficient receipted quantity).

The expectation is that the invoice will not be released for payment until someone confirms that the items have been received.

Invoice comes in, no GR, invoice POST and BLOCK as per standard SAP. Once the GR is created a scheduled background job checks if the block still valid: in our example the GR is now sufficient so the invoice released for payment.

Happy times.

Let’s spice it up.

In this scenario we have the same kind of PO with multiple – partial GRs. First Invoice arrives, there is enough GR-ed quantity so the invoice is posted. Additional invoice arrives, there are GRs in place but not enough for this invoice total. So the invoice will block. Another invoice arrives which could match to the GR that was “used up” by the second invoice, so this invoice also blocks until enough quantity is Goods Receipted.

Often AP finds that invoices should have been matched to a specific GR instead of to the GR total.

Option one can be more careful invoice matching and checking GR proposals; or a bit of automation whereby invoices are forced to match against specific GR/Deliveries:

“GR IV”

IF your company needs to match invoices against specific deliveries instead of letting the system match against the total (cumulative) GR quantity, let the system select the specific GR to match the invoice. To use this option the solution seems to be the “magical” GR IV flag.

This powerful little check box prevents invoice posting when there is no direct match to a GR.

The GR IV flag can be defaulted from the vendor master record and forced onto the PO.

If a PO has the GR IV flag ticked, invoices can NOT be POSTED against the PO item if the matching GR is missing or does not have sufficient quantity. In VIM such invoices are usually captured with an exception and routed to business users for action. This exception can be configured to wait certain amount of time before raised allowing time to i.e.3rd parties to enter GR and transfer it to the organisation’s ERP system.

Another good use of the GR IV flag linked to ERS (Evaluated Receipt Settlement) invoices.

ERS is used with vendors with whom the organisation have built strong, trusting relationship over time, and the volume of invoices could hit hundreds per day. Instead of the vendor bombarding the organisation with invoices, (which consumes a lot of processing resource) the organisation self-sufficiently raise an invoice on behalf of the supplier based on outstanding good receipts against ERS-relevant POs. This process only works if this GR Bsd IV flag is selected on the PO Invoice Tab.

The challenge is:

If the same vendor account uses ERS for certain POs – but you have other non-ERS POs with GR IV flag set – it can be demanding to pick up only the correct lines/POs for the self-bill.

As always there is no right or wrong way and all depends on the requirements and needs of an organisation. ES2P has worked on a number of VIM projects, where we’ve implemented such solutions for GR IV Based/ non GR IV based PO invoices.  Why not drop us a line if you want to find out more.