Skip to main content



Coupa Success Portal


Use Cases

Coupa has released a pre-payments functionality on purchase orders a couple of releases back.

Currently this is not mirrored into the invoice system, therefore for P2P customers, we recommend to turn this off and follow the following best practices to manage pre-payment/down payment invoices against purchase orders.

When the full functionality is available, we will amend this article.


The provided best practice relates a lot on integration and ERP functionality to handle the needs.

In Coupa we only provide workflows and custom fields to steer the process.

Scoping Questions

  • Do you indicate pre-payments on purchase orders?
  • Do you receive individual invoice documents on pre-payments?
  • Do you receive final invoices that state the full amount including the pre-payment?

Regional/Country Specific Considerations

We do not see any country or region limitations for this functionality

Do's & Don'ts

Currently we do not see any major things to avoid while following the process. With the new pre-payment functions in Invoicing we will give options 

Design Element Recommended Design Alternative Design Risky Design Rationale

Heat Map Assessment

Screen Shot 2021-06-02 at 4.14.06 PM.png

Pre-Payments will not be used for any scenarios No Risks are incorporated into the current design and the design is fully defined (all design elements determined).  Customer is still determining use cases for Pre-Payments One or more Risks are incorporated into the current design Pre-Payments are happening offline or via a third party application

Related Success Metrics and Value Drivers



How to configure

Step 1: Custom Fields

As custom fields cannot be loaded, please use the screenshots provided here to create the required custom fields. Please follow the sequence given below as some fields have dependencies.

  • Requisition
    • Pre/recurring-Payment agreed – Drop Down
      Yes/Ja (1)
  • Purchase Order
    • Pre/recurring-Payment agreed – Drop Down
      Yes/Ja (1)
  • Invoice
    • Pre/recurring-Payment agreed – Drop Down from PO
      Yes/Ja (1)
      Pre-Payment/Anzahlung (2)
      Final Invoice/Finale Rechnung (3)
      Recurring Payment/Zahlungsplan (5)
      No/Nein (4)

Step 2: Approvals

A number of approval chains will control the pre-payments process.

The approval chain designs below use concepts from the default invoice process, which identifies approval chains by regions. The region is marked as “XX” and can be replaced by country codes, e.g. “DE” of not used please remove the “dynamic account custom field” condition against the “Region”.

Workflows are assigned to accounts payable team, here represented by a group called “xx Accounts Payable”. For your instance, please replace “xx Accounts Payable” with the Group Name of your AP Team. The accounts payable team needs “edit as approver” for invoices as part of their role definition

  • XX Pre-payment agreed Approval Block INV

    Replace “xx Accounts Payable” with the Group Name of your AP Team.

    Message says “Please select if invoice is a pre-payment or a final invoice. Bitte für Anzahlungen spezifizieren, ob Anzahlungs oder Finale Rechnung.”
  • XX Pre-payment agreed Submission Block INV
    Message says “Please select if invoice is a pre-payment or a final invoice. Bitte für Anzahlungen spezifizieren, ob Anzahlungs oder Finale Rechnung.”
  • XX Pre-Payments Approval AP INV
    Replace “xx Accounts Payble” with the Group Name of your AP Team.

Step 3: Integration Requirements on Objects Exported:


  • Pre-payments
    in the pre-payments dropdown specific invoice handlings can be defined by the AP team that need to be mirrored in a different posting behavior when the invoice is created in the ERP via the OK2PAY file.
    • The value (1) will never be exported, the system forces the AP to select a different value than that.
    • The value (2) indicated a pre-payment, so posting an invoice against a interim ledger and not directly into actuals as for pre-payments there is no service or good provided yet
    • The value (3) indicates a final invoice. This posts against the accounting stated in the billing information but recommendation is to post this with a specific payment block to ensure that the money is not paid twice. AP can then in the ERP filter on this payment block and clear the final invoice against the pre-payments already paid. When done so, the payment block in ERP can be removed and outstanding liability will be paid.
    • The value (4) just triggers a normal invoice posting

Additional References

 Provide links to other articles/content for configuration, technical information, or other details. 


  • Was this article helpful?