Skip to main content

Celonis Product Documentation

FAQ - Parked and Blocked Invoices

Please reach out to ( in case you have any questions.

  1. Why do we need a _CEL_AP_CASES table combining parked and posted invoices?

    In the best case scenario, every incoming invoice can be matched against the purchase order and the goods receipt (Three-Way Match) without any variance and is automatically posted in the ERP. However, matching or even identifying the respective matchable invoice and purchase order lines can become very difficult.

    Depending on the SAP settings and the process design (e.g. GR required for posting an invoice), SAP doesn’t allow the posting of the incoming invoice. In those scenarios, the incoming invoice can be parked in SAP’s MM module. This has the advantage that the available invoice data can already be entered and the invoice is digitized in the ERP. The parked invoice represents the incoming invoices and are with regards to the header - line item structure similar to the well-known PDF invoices.

    Incoming invoices are handled on header level as its lines do not always exist from the beginning or have bad data quality, for instance due to poor OCR quality. Parking an invoice also has the advantage that almost all values/fields can still be changed.

    After the problem has been clarified and resolved (e.g. via communication or via workflows), the invoice is posted and available in the SAP FI module. When posting an invoice, multiple lines from the incoming invoice are usually consolidated to one accounting line. After the posting, many changes are prohibited by the system. In order to update values such as price, quantity, company code, the invoices need to be reversed and posted again with the updated values. For the processing of an invoice, invoices from both stages (SAP MM & FI) should be included to ensure that all invoices are processed and paid at the right time.

    Instead of parking the incoming invoice in the SAP MM module, it’s common that third-party vendors such as OpenText and ReadSoft are used for the pre-processing of an invoice. Oftentimes, those solutions are offering workflow solutions, too, that are used for the communication with other stakeholders (e.g. procurement, logistics). The section SAP FI - only blocked invoices describes how the data pool and data model can be adjusted for those system combinations. There are also companies that don’t use any parking solutions.

    Parked vs. Blocked summary

    • Parked Invoice: In the organization there are hundreds of invoices received daily. There is a separate data entry team for entering the invoice data in the system. The Park invoice is used for this purpose. The invoice can be parked in the system in case the data entry person is not clear about the data to be entered in the MIRO screen. There is no financial entry generated at the time of parking the invoice.

    • Blocked Invoice: The invoice is entered and then it is blocked for the payment. In the finance department once the invoice is created in the system the payment has to happen to the vendor. In case the invoice is blocked for the payment it is blocked at the header level for all the items in the invoice. The GR IR account is cleared at the invoice level but the payment for the vendor is blocked for the particular invoice.

    The SAP ECC - Operational (MM + FI open) data model creates a unified invoice table (_CEL_AP_CASES) taking invoices from both process stages, parked MM Header and posted FI Lines.

  2. What is the difference to the former “AP Execution App / Invoice Orchestration” App?

    There’s certainly an overlap between the two apps. We took the learnings from the Orchestration App and built a new App which is much more focused, leaner and easier to implement (e.g. no Steering View, no Invoice Management)

    The focus lies less on the pure amount of execution gaps but rather on providing relevant contextual information for parked & blocked invoices that help with the resolution and faster processing to realize cash discount and pay on-time.

  3. Do we replace preprocessing systems such as VIM OpenText or ReadSoft Process Director?

    No, we don’t replace any preprocessing systems but the app can be used on top of it to prioritize and orchestrate invoices. By using ActionFlows, potentially selected actions can be executed in the downstream system.