SAP Concur - Creating Invoice Purchase Requests vi...

michael_cliff · ‎2025 Mar 05

This is the second part of a series on utilizing SAP Concur Invoice APIs. Part one deals with vendor management and can be found here. This post will focus on creating purchase requests.

Prerequisites

You must be contracted for Invoice Processing, Purchase Requests for Invoice, and Client Web Services.

This post will not discuss authentication. Please see this post for an introduction to authentication and web service application building within Concur. Please use this link to download a Postman collection for the Invoice APIs. The complete documentation for the Purchase Request v4 API can be found on the SAP Concur Developer Center. Note that this collection assumes you’re using the environment from the authentication blog linked above. You will need an application with the following scopes:

purchaserequest.read
purchaserequest.write
INVPMT (needed to get the expense type codes sent in the purchase request payload)

Works with these SAP Concur solutions:

Invoice – Standard
Invoice – Professional

Background

Before we get into the nuts and bolts of the APIs, here’s a quick primer on the lifecycle of the requisition to payment process:

An employee needs to buy a good or service. Before ordering / signing a contract, the employee must first seek approval to ensure the purchase is appropriate and is within budget. A purchase request is created, which contains a list of requested items, the quantity for each, and the unit price.
The purchase request is submitted and will go through an approval workflow as designed by the customer. This could be a simple 1-up approval to the manager, or a more complex approval that goes to a cost approver depending on a cost center, project, or other cost object that was coded on the request.
Once the purchase request is approved, a new purchase order is created based on the request details and is submitted to the vendor.
The vendor receives the purchase order and ships goods / delivers services as needed.
The vendor generates an invoice that’s sent to the customer. Note that you may also see invoices referred to as Payment Requests in some Concur documentation.
The goods / services are received by the customer, and a goods receipt may be created indicating the quantity and date of receipt of the goods received.
Accounts payable receives the invoice and matches it against the PO that was sent as well as the receipt—this is known as 3-way matching. Any discrepancies are noted and adjustments to the invoice and/or the PO are made as needed.
The invoice itself goes through an approval process. If the invoice matches the PO it can be configured to skip approval steps. If there were discrepancies between the invoice and the PO, then additional approvals can be required.
Once the invoice is fully approved, it is released for financial posting and payment. Payment can be made directly from Concur via Invoice Pay or can be handled in an external system.
Once payment has been confirmed, the payment status within Concur can be updated as appropriate.

SAP Concur Invoice has functionality to handle all these steps, but there are some scenarios where it may make sense to handle part of the process outside of Concur and use APIs to push the data to Concur instead.

Let’s say you already have an ordering system with a robust punch-out catalog, but maybe the approval functionality is limited and inconvenient for end users to use. In this case it makes sense to continue handling the order request creation process in your external system, but send the purchase request to Concur so you can take advantage of the flexible and easy-to-use approval process offered by Concur. In this scenario, step 1 from above will be completed by the purchase request API, and steps 2-10 will be handled through the normal Concur process.

Create a Purchase Request

Creating a purchase request is quite straightforward. The payload is separated into two parts: the header information that applies to the request as a whole, and one or more line items that details exactly what is being requested. Within the Postman collection, expand the Purchase Request folder and click on the Create Purchase Request row:

Line items do not all need to share the same vendor code or vendor address. If multiple vendors are used, note that a separate PO will be created for each distinct vendor code and vendor address combination.

The exact details that are required to be populated will vary based on your site’s configuration, but the payload in the sample Postman collection is typical of what’s needed. The complete schema details are here. Some of the values needed are also dependent on your configuration – here’s a list of those fields and where in the configuration you can find the configured values (you may need to work with one of your Concur admins and/or your Concur implementation team if you don’t have admin rights):

policyExternalId: Administration -> Invoice -> Policies – open the desired policy and scroll to the bottom:
shipToAddressCode and billToAddressCode: Administration -> Invoice -> Company Locations – use the value in the Address Code column:
vendorCode and vendorAddressCode: see my previous blog on vendor management.
expenseType: use the “Get Codes for Localized Strings” request in the Postman collection:
uomCode: Administration -> Invoice -> Units of Measure – Use the value in the Code column:

Once you have your payload built, you can send the POST request to create the purchase request. The response for a successfully created purchase request looks like this:

You can then make a GET request to the returned URI to see some basic details about the request:

Note that the approval status is “Pending Approval”. Purchase requests created via API are automatically submitted unless there’s a blocking exception or there’s no default approver assigned. In that case, the user will need to manually submit the request after clearing the exceptions or working with HR to have an approver assigned as needed.

At this stage, no further interaction with the request via API is possible. The Purchase Request endpoint does not support the PATCH / PUT / DELETE methods so you cannot make changes to a purchase request once it’s been created. When the purchase request workflow is completed, a new purchase order is created based on the details of the request and is transmitted to the appropriate vendor(s).

At this point, you can retrieve the IDs of the created purchase order(s) by making a GET request to the purchase request endpoint again:

You would then be able to use the PO numbers to call the purchase order endpoint in order to retrieve the PO details. I will cover those APIs in part three of this series, so stay tuned!

Share and Connect

What do you think? Do you have anything to add? Leave a comment below.
Did you find it useful? Give us a like and share on social media.
Want to know more about SAP Concur? Please follow here.
Want to ask questions about SAP Concur and its offerings? Ask here.

Thank you!