How to handle SRM and ECC PO History mismatch problems?

The purpose of this blog post is to give you an overview about what you can do when there are mismatches between the Purchase Order history of your SAP ECC and SRM systems.

As an SRM Support engineer I often meet customer cases, where the booked values of SRM Confirmations (aka MM Goods receipts) and Invoices do not match. In the following Chapters, I collected the main steps of updating the follow-on document values – or as we call it, “actual values” – in order to synchronize your PO-documents.

Checking the SRM and ECC PO history

Checking SRM PO history

First of all, let us check what kind of history our Purchase Order has. In the SRM system, you can check that by opening the Purchase Order from your HTTP system in Display mode, and selecting the “Related documents” tab on item level. The fields “Confirmed quantity” and “Invoiced quantity” as well as the fields “Confirmed value” and “Invoiced value” show the total of the already booked follow-on document values.

A typical actual value problem: confirmation/invoice exist, their value is however zero in “Statistics”

Similarly, in the administration transaction code BBP_PD, you can check the same values by drilling down to the PO item level fields VAL_CF_E, VAL_CF, VAL_IV_E, VAL_IV, QUAN_CF_E, QUAN_CF, QUAN_IV_E, QUAN_IV :

Checking ECC PO history

In case there are Goods receipts or Invoices on your backend Purchase Order, the “PO history” tab will be automatically enabled in ME23N transaction on item level.

In case your SRM PO history shows different values than ECC, an update of the statistical values is necessary in order to synchronize the two systems.

How to trigger force-update of the Actual values?

You can trigger new update of statistical values by running the SRM report BBP_PO_INIT_NOTIFY_FOLLOWON in SE38 transaction. This report will write an actual value (“AV”) entry in the SRM BBP_DOCUMENT_TAB table.


Then you just need to run the cleaner job CLEAN_REQREQ_UP in SRM, t-code SE38. Usually that job is already scheduled in your SRM. If not you can schedule it or run it separately. Please run it carefully bearing in mind that interfering cleaner jobs might create inconsistencies in the system.


Ideally, the above steps will trigger a new update of GR / IR values on SRM side. In case you need deeper understanding of the process, you might wish to consult our following Wiki-page: PO Actual Value, Final Entry and Final Invoice Flag Update

Other resources

PO Actual Value, Final Entry and Final Invoice Flag Update