Innovation planned with SAP Cloud ERP release 2608

by Luis Moreira & Roman Brückner

Why this matters for treasury teams

Treasury organizations are under increasing pressure to meet regulatory and audit requirements for payment controls, segregation of duties, approval traceability, and protection of sensitive Business Partner data. At the same time, many organizations are centralizing treasury operations and automating trading and transaction processing through integrated platforms.

Auditors increasingly expect clear evidence of who can create or change sensitive payment information, who approved the change, when the approval took place, and whether the approved data was used consistently in downstream payment and correspondence processes.

While authorization concepts help restrict access to sensitive master data, they do not fully address the need for workflow-based operational governance, approval traceability, and four-eyes control across the treasury lifecycle.

This is particularly relevant for Treasury Business Partners because changes to counterparty data, bank details, standing instructions, or other payment-relevant information can directly affect external confirmations, settlements, and payment initiation.

This creates a challenge: sensitive Business Partner changes must be controlled before they are used operationally, but treasury operations cannot simply stop every time a BP change is waiting for approval.

In customer and partner discussions, we repeatedly saw the same pattern. The first reaction was often: “This is an authorization issue.” But the deeper issue is operational governance.

Authorizations can restrict who is allowed to change master data. They do not, by themselves, create an end-to-end approval process, enforce a four-eyes principle, provide an auditable workflow trail, or prevent unreleased data from being used in critical treasury steps.

The new workflow addresses this gap by introducing a standard, workflow-driven approval process for Treasury-relevant Business Partner changes and by ensuring that Treasury operations react to the Business Partner release status before critical steps such as correspondence delivery and payment initiation continue.

Figure 1: Payment-relevant Business Partner data is a critical for Treasury Management processes.

Why this is more than a Business Partner workflow

A Business Partner approval workflow is only useful for Treasury if it also understands the treasury lifecycle.

In Treasury Management, Business Partner data is used across multiple steps:

• Creating treasury transactions
• Processing inbound transactions from trading platforms
• Creating mirror deals
• Sending confirmations and correspondence, such as MT300 or MT320
• Settling transactions
• Initiating payments and
• Postings

A simple “approve before use” concept sounds straightforward, but if the system blocks too much, treasury operations can grind to a halt. For example, blocking deal creation while a BP is under review can interrupt trading platform integration, require manual reprocessing, or cause avoidable operational effort.

The design therefore follows a lifecycle-aware governance model:

• Allow operational continuity where the risk is manageable
• Block critical external or payment-relevant steps until the BP is released
• Resume follow-on treasury activities after approval
• Keep the approval and change history traceable for audit purposes

 

Figure 2: The governance model protects critical payment and correspondence steps while keeping treasury operations moving.

What changes with the new workflow

With the planned innovation, a Treasury-relevant Business Partner change can trigger a release procedure and approval workflow. The workflow is based on SAP Flexible Workflow and is integrated with Treasury Business Partner roles.

At a high level, the process works as follows:

• A user creates or changes a Treasury-relevant Business Partner.
• The release procedure is triggered and the BP is marked as not released or pending approval.
• The approval request is routed through Flexible Workflow.
• The approver reviews the change in the standard workflow experience.
• After final approval, the BP is released.
• Treasury activities that were blocked because of the unreleased BP can continue.

The important part is what happens while the Business Partner is still under review.

During the approval phase, selected treasury operations can continue. For example, deal creation, TPI inbound processing, mirror deal creation, and selected accounting or posting steps can remain operational depending on configuration and process design.

At the same time, critical activities are protected. Payment initiation and correspondence delivery are blocked until the Business Partner has been released. This helps prevent unreleased payment or correspondence-relevant data from being used externally.

Figure 3: After a relevant Treasury Business Partner change is saved, the BP enters a pending approval state.

 

Example: Changing payment details for a treasury counterparty

Consider a central treasury team managing trading counterparties and payment instructions.

A master data specialist updates payment-relevant details for a counterparty, such as bank account information. Without workflow-driven governance, that change could become operational immediately. A treasury user might proceed with downstream activities, and the organization would rely on manual checks, spreadsheet approvals, or after-the-fact reviews.

With the new approval workflow, the same change triggers a release process. The approver receives the workflow task, reviews the change, and approves or rejects it.

While the BP is under review, Treasury Management treats the BP as not yet released for critical steps. The organization can continue with operational activities where appropriate, but correspondence and payment initiation are protected until approval is complete.

This distinction is essential. The objective is not to freeze the entire treasury lifecycle. The objective is to prevent sensitive, unreleased Business Partner changes from being used in the steps where they create the highest risk.

Figure 4: Approvers can review and approve Treasury Business Partner changes through the workflow inbox.

Impact on treasury processes

The planned workflow affects treasury processes in the following way.

Business Partner changes become governed

Relevant changes to Treasury Business Partners can trigger workflow approval. Customers can define which types of changes require approval and which non-sensitive changes may be suppressed through Cloud BAdI extensibility. This supports a real four-eyes principle and reduces reliance on manual approval processes outside the system.

Correspondence is protected

If a Business Partner is not yet released, treasury correspondence delivery is blocked. This helps prevent confirmations or other external communications from being sent based on unreleased or unapproved data. After the Business Partner is released, outstanding correspondence can be regenerated or processed through the correspondence monitor or the Job Scheduler.

 

Figure 6: Correspondence can be held while the BP is pending approval and resumed after release.

Payment initiation is protected

Payment-relevant treasury flows are checked before payment initiation. If the relevant payer or payee Business Partner is not released, payment initiation is blocked.

Once the BP is approved and released, payment processing can continue.

Figure 7: Payment initiation is blocked until the relevant Business Partner is released.

Operational continuity is preserved

The design intentionally avoids blocking the complete treasury lifecycle. Treasury teams can continue with selected activities such as deal creation, transaction processing, and other operational steps where immediate blocking would create unnecessary rework. This is especially important for highly automated treasury processes, TPI integration, and mirror deal scenarios.

Auditability improves

Workflow history, approval status, user actions, timestamps, and change information can be made visible through standard workflow monitoring and inbox/outbox capabilities. This gives treasury and audit teams a clearer evidence trail than manual approvals or informal controls.

Figure 8:  “Workflow history provides transparency for audit and internal control reviews.”

 

Business value

The business value of this innovation comes from the combination of governance and process continuity. For treasury organizations, the new workflow helps to:

• Strengthen payment controls and segregation of duties
• Reduce the risk of unauthorized payment-relevant master data changes
• Replace manual approval processes with system-driven workflow
• Improve audit traceability for sensitive BP changes
• Reduce operational rework caused by incorrect correspondence or payment data
• Support centralized treasury operating models
• Preserve automation in TPI and treasury transaction processing
• Align master data governance with real treasury execution steps

The key point is that this is not only a compliance feature. It is an operational control that helps treasury teams run safely without creating unnecessary process friction.

 

How to enable the innovation

The exact setup may depend on customer scope, configuration, and release availability. The following sequence provides a practical orientation for implementation planning.

Prepare your governance model

Before starting configuration, define the governance policy:

• Which Treasury Business Partner roles are in scope?
• Which fields should trigger approval?
• Which changes are non-sensitive and can be excluded?
• Who is allowed to request changes?
• Who is allowed to approve changes?
• Are different approval patterns needed by company, country, role, or risk category?
• What escalation rules are required?

Typical in-scope Treasury BP roles may include counterparties, issuers, depository banks, and guarantors.

Activate the Treasury Business Partner workflow

Activate the Treasury Business Partner approval workflow using the relevant configuration activity available with the release. The release procedure marks the BP as not released or pending approval when a relevant change is made.

Figure 9: Activate Treasury Business Partner approval workflow in SSCUI 107391 – Maintain Roles for Release Workflow.

Define teams and responsibilities

Use the team and responsibility configuration to define the approval team for Treasury Business Partner changes. The responsible users should reflect the customer’s approval authority matrix and segregation-of-duties requirements.

Figure 10: Define the approval team and responsibility rules for Treasury Business Partner workflow processing.

 

Figure 11: Team members and their functions are assigned for Treasury Business Partner workflow processing.

 

Configure the Flexible Workflow

In the workflow configuration, create and activate the approval workflow for the Treasury Business Partner process.

Typical configuration elements include:

• Workflow start conditions
• Approval steps
• Treasury-relevant BP roles or team
• Approver determination
• Step conditions
• Deadlines (for notifications)
• Exception handling
• Activation of the workflow version

The configuration is performed in Fiori app: Manage Workflows for Treasury Business Partners  (F9582).

Configure field relevance and suppression logic

Use the available extensibility options, such as a Cloud BAdI FSBP_RELEASE_DEACTIVATE where applicable, to define which changes should trigger workflow and which non-sensitive changes can be suppressed.

For example, changes to payment-relevant fields such as bank account, IBAN, BIC, or account holder information should generally require approval, while non-sensitive administrative changes may not.

Test the end-to-end process

A recommended test sequence is:

1. Change a payment-relevant field for a Treasury Business Partner.
2. Confirm that the workflow is triggered.
3. Confirm that the BP status indicates pending approval or unreleased.
4. Attempt correspondence delivery and verify that it is blocked.
5. Attempt payment initiation and verify that it is blocked.
6. Approve the workflow task.
7. Confirm that the BP is released.
8. Regenerate or resume correspondence where needed.
9. Continue payment processing.
10. Review the approval history in My Inbox or My Outbox.

This end-to-end validation is important because the innovation spans master data governance, workflow, correspondence, payment processing, and auditability.

Next steps

Looking ahead, we are also evaluating additional process control options, such as an optional posting block controlled via switchable messages. This would give customers more flexibility to decide how strictly unreleased Business Partners should be handled in Treasury posting processes, depending on their governance model.

Key takeaway

The new Business Partner Approval Workflow for Treasury Management is designed to close an important governance gap in SAP Cloud ERP.

It introduces a workflow-driven four-eyes principle for sensitive Treasury Business Partner changes, but it does so in a treasury-aware way. Instead of blocking the entire lifecycle, it protects the critical steps where unreleased Business Partner data creates the highest risk: correspondence and payment initiation.

For treasury teams, this means stronger governance, better auditability, lower operational risk, and fewer manual controls while keeping treasury operations moving.

With the planned availability in SAP Cloud ERP release 2608, customers can start preparing now by reviewing their Treasury BP roles, approval policies, sensitive field definitions, and end-to-end treasury process controls.

This is not just a Business Partner workflow. It is lifecycle-aware Treasury governance.