Expense v4 API user-context model creates a major blocker for central ERP integrations

[sbisht]

We are currently working on an SAP Concur Expense integration with Microsoft Dynamics 365 Business Central.

Our requirement is very simple from an enterprise integration point of view:

Retrieve approved expense report data centrally, transform it, post it into Business Central, and track posting success/failure.

However, the Expense v4 API design appears to create a major architectural problem for this use case.

Many Expense v4 endpoints require values such as userID, contextType, and reportId. For example, report retrieval is done in the form of fetching a report for a specific user/context.

Even when the OAuth application has the required scopes, the API still appears to depend on whether that specific user/context has permission to access the report and its related child data, such as expenses, allocations, itemisations, and receipts.

This creates a serious problem for a central ERP integration.

If permissions are kept strict, the integration fails for reports where the selected user/context cannot access the data.

If broader permissions are granted to make the integration work, this creates a security concern because access is being widened only to support an integration.

This does not feel suitable for a central finance/ERP posting process. A Business Central integration should not need to fetch expense reports “on behalf of” individual users. It should work as an authorised company-level/system integration and retrieve only the approved financial documents that are ready for ERP posting.

From my current understanding, Expense v4 may be enforcing Concur’s user-context security model, but that model does not align well with central reporting, finance extraction, or ERP posting requirements.

We are now exploring the Financial Integration Service (FIS) API because it appears closer to the correct architecture for ERP posting. However, our FIS endpoint currently returns an empty transaction list even though the token includes the FISVC scope.

Example endpoint being tested:

GET /financialintegration/fi/v4/companies/transactiontypes/expense/transactions

Example response:

{
  "links": [
    {
      "rel": "self",
      "href": "/fi/v4/companies/transactiontypes/expense/transactions"
    }
  ],
  "content": [],
  "page": {
    "size": 25,
    "totalElements": 0,
    "totalPages": 0,
    "number": 0
  }
}

We also tested with ignoreDocumentStatus, but understand that this flag may only be considered when docId is also supplied.

Questions for SAP / community:

1. Is Expense v4 officially recommended for central ERP posting integrations?
2. If yes, how is SAP expecting customers to avoid user-level permission dependency and over-permissioning?
3. Is there a supported company-level access model for Expense v4 that allows central retrieval of approved reports without acting on behalf of individual users?
4. For ERP posting use cases, is FIS the recommended approach instead of Expense v4?
5. If FIS is the recommended approach, what exact SAP Concur configuration is required to make approved expense reports appear in the FIS transaction queue?
6. Does FIS need to be enabled at company/group/policy level before the transaction endpoint returns data?
7. What exact report/payment/accounting status is required before an expense report appears in the FIS READY queue?

At the moment, the Expense v4 model appears misaligned with enterprise ERP integration requirements. It may work for narrow user-context lookups, but it creates a security and scalability bottleneck for central finance integrations.

I would appreciate any guidance from SAP or anyone who has successfully implemented a central SAP Concur Expense to ERP posting integration without granting broad user/report permissions.

[KevinD]

@sbisht I'm trying to reach out to some colleagues who know way more about APIs than I do. Stay tuned.

[KevinD]

@sbisht hello again. My colleague @michael_cliff provided the following answers below in red.

1. Is Expense v4 officially recommended for central ERP posting integrations? No, Expense v4 is not recommended / intended to be used for ERP postings due to the issues you've outlined.
2. If yes, how is SAP expecting customers to avoid user-level permission dependency and over-permissioning?
3. Is there a supported company-level access model for Expense v4 that allows central retrieval of approved reports without acting on behalf of individual users? To be clear, you can use the Expense v4 endpoints with a company-level access token, but you need to include the correct context type and user UUID of the report owner. Example: GET 
    https://us2.api.concursolutions.com/expensereports/v4/users/50e6f152-4a41-414d-a6fb-214823dd70fd/con...
   where 50e6f152-4a41-414d-a6fb-214823dd70fd is the user UUID of the user that created the report, and B3EF7B045339432AA6A6 is the report ID. Note that these values are dummy values for illustrative purposes only, and will not work in your site. You can use the identity endpoint to lookup the user UUID if you know the user's login ID or employee ID.
   However, this is still not a good fit for posting as you need to already know that the report exists and is in a status that's ready to be posted.
4. For ERP posting use cases, is FIS the recommended approach instead of Expense v4? Yes, FIS is the recommended approach for the ERP posting use case. See the Financial Posting via Financial Integration Service guide on the Concur developer portal and the Financial Integration Service Use Case document for more information.
5. If FIS is the recommended approach, what exact SAP Concur configuration is required to make approved expense reports appear in the FIS transaction queue? The "Enable Financial Integration" box needs to be checked in the Expense Group configuration in order for reports to be made available to FIS. This setting needs to be enabled for each Expense Group you wish to use with FIS. Note that reports that are FIS enabled will not be included on the Standard Accounting Extract (SAE) - a report can either be posted via FIS or extracted on the SAE, but not both. This is by design. The FIS Setup Guide has additional details and considerations.
6. Does FIS need to be enabled at company/group/policy level before the transaction endpoint returns data? Yes, only reports created after the above configuration change has been made will be returned in the FIS queue. 
7. What exact report/payment/accounting status is required before an expense report appears in the FIS READY queue? The report needs to be fully approved by all approver steps and be in the "Processing Payment" status. 

I hope this helps.

[sbisht]

Thanks for confirming that FIS is the recommended route for ERP posting.

I have one follow-up architecture question about how the FIS queue should be consumed.

In our scenario, the same approved expense report data may be needed by more than one internal process. For example, one process may be responsible for ERP posting, while other processes may need the same report/document data for separate downstream activities.

As per our current understanding, FIS behaves like a financial posting queue rather than a normal reporting API. Once a document is retrieved and later marked as posting success, it moves forward in Concur and may no longer be available from the same FIS queue response.

Can SAP please confirm the recommended design pattern for this kind of scenario?

Specifically:

1. Should FIS normally be consumed by only one main integration process?

2. If multiple internal processes need the same financial document data, what is SAP’s recommended approach?

3. Is it correct that once posting success is sent back to FIS, the document will no longer be returned by the standard GET transactions call?

4. Is there any supported way for multiple processes to independently retrieve the same FIS document from Concur, or is that not the intended usage?

5. At what point should posting success be sent back to FIS — immediately after ERP posting succeeds, or only after all required downstream processing is complete?

6. What is the recommended approach if ERP posting succeeds but another downstream process fails afterwards?

We want to make sure we follow the intended FIS architecture and do not design multiple automations in a way that conflicts with how the FIS queue/status lifecycle is expected to work.

[Mass]

Hi @sbisht 

I'll begin by stating that I'm the systems accountant and not the Integration developer.

We use Azure Integrations to push and pull data between multiple end points (Concur, MS D365 CRM and F&O, plus many other applications/systems).

We integrate Concur Expense with D365 F&O using a hybrid of FIS and Expense v4 for expenses, as we found at the time of development that not all required data was available in either Expense v4 or FIS. This was developed about 4 years ago so the missing expense data might now be solely available within FIS.

We also send HR and Project data from F&O to Concur to maintain User records and List data.

We have opted to extract expense claims that are Approved into our central Azure integration and from here it is pushed to a D365 F&O staging table, before using a custom posting service batch job to create and post the journals. We do not send posting successes back to Concur, so all claims remain with a status of "sent for payment" and can be repulled if required. If there is an issue with the expense data then we repair it within the F&O staging table rather than send back to Concur, as more often that not it cannot be repaired in Concur.

I hope some of this is relevant and can assist you.

Mass

[sbisht]

Thank you @Mass , this is really helpful and gives good insight into how other teams are handling this scenario in a real implementation.

This also confirms that the concern is legitimate: in real-world integrations, the same approved expense data may be needed by more than one downstream process, and the standard FIS lifecycle may not always fit neatly without some careful design decisions.

I will share this with our solution team for internal discussion.

In the meantime, I will wait for @KevinD  to provide an official SAP response on the recommended design pattern for this scenario, especially around whether multiple downstream processes should rely on FIS directly, when posting success should be sent back, and what SAP recommends if the data needs to be reused after ERP posting.