SAP ECC and Wise integration

What moves between them

Vendor payment records flow from SAP ECC into Wise. SAP ECC vendors marked for Wise payout are polled on a fixed schedule, matched to their Wise recipient profile, and executed as transfers with a Wise quote. The payment direction is SAP into Wise (outbound from SAP). Cost center codes from SAP are stored in the transfer's external metadata so reconciliation back to SAP is complete. Transfer state changes from Wise flow back as events (transfersstate-change, transferspayout-failure) and are recorded in the audit log. The integration never writes vendor changes back into SAP from Wise.

How ml-connector handles it

ml-connector stores the RFC agent credentials encrypted and uses RFC Basic Auth via SAP .NET Connector or Java Connector to poll SAP ECC on a schedule you define. For each vendor due for Wise payout, it retrieves the SAP vendor code, bank country, and cost center, then builds the recipient profile in Wise if it does not exist. It requests a Wise quote for the payout amount and currency, creates the transfer with the quote ID, and uses the customerTransactionId field to prevent duplicate transfers if the call fails and is retried. On the Wise side it uses OAuth 2.0 client credentials with a 12-hour token refresh, and tracks quote expiry so a fresh quote is always requested before funding. Wise webhooks (transfersstate-change, transferspayout-failure) are registered once and verify their signature with RSA-SHA256; ml-connector records the webhook event and can audit or replay the payout if a failure is observed. RFC_READ_TABLE polling has a 512-character row width limit for classic SAP systems, so wide vendor records are read via BBP_RFC_READ_TABLE if available. BAPIs require an explicit BAPI_TRANSACTION_COMMIT call or payments remain locked in SAP.

A real-world example

A mid-sized manufacturing company buys components from vendors across Europe and Asia. The procurement team approves vendor invoices in SAP ECC and enters payment orders by hand into both SAP and Wise, then manually reconciles the two systems at month-end to catch mismatches. The AP team spends hours chasing missing or duplicate payments. With SAP ECC and Wise connected, each approved invoice in SAP is paid automatically through Wise, the payout is recorded with the SAP cost center and vendor code for traceability, and the webhook updates SAP when the transfer completes or fails. The AP team now focuses on exception handling instead of data entry, and month-end reconciliation is instant because every SAP payment is tied to a specific Wise transfer ID.

What you can do

• •Execute vendor payments from SAP ECC through Wise without manual entry, with idempotency via customerTransactionId to prevent duplicate transfers.
• •Map SAP vendors and cost centers to Wise recipients and metadata so payouts are traceable back to SAP GL accounts.
• •Poll SAP ECC on a schedule you control using RFC Basic Auth through an on-premises agent, with retries and full audit history on every record.
• •Receive Wise webhook events (transfersstate-change, transferspayout-failure) with RSA-SHA256 signature verification and record the outcome in the audit log.
• •Handle OAuth 2.0 token refresh, quote expiry, and recipient immutability on the Wise side so payments flow reliably across currency boundaries.

Questions

How does the integration handle the RFC agent requirement and authentication?

ml-connector stores the RFC agent credentials encrypted and uses RFC Basic Auth via SAP .NET Connector or Java Connector running on the customer network. The on-premises agent is required because RFC calls cannot originate directly from the cloud; the agent sits on the customer network and executes RFC_READ_TABLE polling on a schedule you define. On the Wise side, ml-connector uses OAuth 2.0 client credentials with automatic token refresh every 12 hours.

What happens if a Wise transfer quote expires or a recipient needs to be changed?

Wise quotes expire, so ml-connector requests a fresh quote immediately before each payout to ensure the rate is current. Recipients are immutable in Wise, so if a vendor's bank account or details change, ml-connector deletes the old recipient and recreates it with the updated information before the next payout. Transfers are idempotent via customerTransactionId, so a retry after a network failure does not create a duplicate payment.

How are Wise webhook events recorded and can a failed payment be replayed?

Wise publishes transfer state changes and failures as webhooks (transfersstate-change, transferspayout-failure) with RSA-SHA256 signature verification. ml-connector registers these webhooks once and records every event in the audit log with the timestamp, transfer ID, and SAP cost center. If a transfer fails in Wise, the failure is logged and can be replayed by re-executing the payment or by manual intervention if the reason requires SAP approval.