SAP Pay Puts Your ERP in the Money Path

SAP Pay runs supplier payments inside Cloud ERP through Tereina. What is confirmed, what SAP and Reuters describe differently, and what finance should ask.

For as long as most of us have worked with SAP, the story ended the same way. The invoice was approved in SAP, and then the money moved somewhere else.

A bank portal. A payment file. A middleware box. A reconciliation job the next morning, and a person squinting at the exceptions.

On 6 October, SAP announced it wants to remove "somewhere else". It is called SAP Pay, and it matters more than most of the AI headlines from SAP Connect.

The short version: SAP is now in the payments business. When an invoice is approved in SAP Cloud ERP, SAP Pay can execute the payment and reconcile it, using traditional rails or stablecoins. That is convenient. It also puts SAP in a different place in your risk map.

What is confirmed

What it is: an out-of-the-box B2B payments solution embedded in SAP Cloud ERP. When an invoice is approved, it executes the payment and auto-reconciles it to the originating invoice or purchase order.
Who runs it: Tereina, which SAP describes as a regulated payment-service provider founded in April 2026 and a wholly owned SAP subsidiary.
Rails: ACH, EFT, wire, check and real-time payments, plus stablecoin payments in USDC through a native integration with Circle. SAP says intelligent routing picks the rail across 40+ currencies, and describes 89 global corridors without per-country bank setup.
Bank connection: secure bank communication runs through SAP Multi-Bank Connectivity. SAP says SAP Pay does not replace it.
Compliance: SAP says OFAC and KYC/AML screening is applied to every transaction.
Control: SAP says "nothing moves without your approval" and that payments run through your existing SAP workflow.
Pricing: a subscription based on number of transactions, in blocks of 1,200 transactions a year, with 1 to 3 year contracts and auto-renewal. Price on request. Data center choices listed: US East and Frankfurt.
Availability: SAP's news says it is generally available now in the United States and the United Kingdom.

Before and after. The 'before' row is typical, not SAP's wording. Diagram by ayraix.com.

Why it is a bigger move than it looks

SAP had long stopped short of payments. Reuters quotes Tereina's CEO saying SAP "had stopped short of payments and let customers connect their own providers", and compares SAP Pay to Apple Pay: a payment service native to the system it runs in.

SAP's own page lists what the old way needed: "separate banking platforms, file transfers, third-party middleware and postpayment reconciliation". Those are layers other vendors sell. SAP is offering to fold them into the ERP.

The next step is already on SAP's page. The AI agents that support finance teams through Joule "will soon trigger and execute payments, too, closing decision to execution in one flow". That is the part to think about. An agent deciding and paying, in one flow.

Three things SAP and Reuters describe differently

Good reporting starts with what does not line up. I found three gaps in the public material.

Ownership. SAP calls Tereina a wholly owned subsidiary. Reuters describes it as a payments company in which SAP "owns a stake", and says the CEO declined to disclose the size of that stake. Ask for the legal structure in writing.
Geography. SAP's news says generally available in the US and UK. The price page says the service may only be used for transactions by customers or affiliates domiciled in the United States or the European Union, unless the documentation provides otherwise. Ask where you can actually use it.
The savings claim. Reuters reports Tereina claims a 25% cut in payment costs. That is a claim, not a result. Ask for the model, and for references with similar payment mixes.

SAP Pay in numbers, and three things to verify. Diagram by ayraix.com.

What finance, treasury and audit should ask

1. "Approve" now means "pay"

When approval triggers execution, the approval step is the control. Who can approve? Can one person create a vendor, change its bank details and approve its invoice? Those are classic separation-of-duties questions. They matter more when nothing sits between approval and money leaving.

2. Vendor bank changes get more dangerous

Payment fraud often starts with a changed bank account. If payments flow straight from approval to execution, a bad bank-detail change travels faster. Check your call-back and dual-approval rules for master data, not just for payments.

3. Whose licence covers what?

A regulated payment provider holds specific licences in specific places. Ask which entity, which licence, which country. Today the public material points to the US and UK, and the price page to the US and EU.

4. Where does the money sit, and for how long?

Get the funds flow in writing: the accounts, the timing, who holds the funds between instruction and settlement, and what happens if the provider fails.

5. Stablecoin settlement

SAP describes USDC payments with Circle for cross-border settlement, and says settlement takes minutes instead of days. That is an interesting option. It also raises accounting, treasury policy and audit questions that are separate from the technology. Your auditors will want your policy before your first payment.

6. Agents and payments

SAP says agents will soon trigger and execute payments. Apply the autonomy ladder from our post on agent access: an agent may draft and recommend payments long before it should release them. Decide your rule now.

7. How do you leave?

If you stop using SAP Pay, how do you get back to your own banks without a new project? SAP says it complements SAP Multi-Bank Connectivity, which suggests a route back. Ask for it to be in the contract.

A control matrix for the new flow

Vendor created or bank details changed. Owner: master data team. Controls: dual approval and a call-back to a known contact. Evidence: change log.
Invoice approved. Owner: AP approver. Controls: approval limits, matching, no self-approval. Evidence: workflow log.
Payment executed. Owner: SAP Pay and your payment settings. Controls: sanctions screening, routing rules, release limits. Evidence: execution log from the provider.
Payment reconciled. Owner: AP and treasury. Controls: exceptions queue, timing checks. Evidence: reconciliation report.

If any row has no owner today, fix that before you switch automation on.

How it compares with the options you have

Direct bank connections. You handle formats, bank onboarding and testing yourself. Maximum control, maximum effort.
SAP Multi-Bank Connectivity. A secure corporate-to-bank network. SAP says SAP Pay uses it, and does not replace it.
A third-party payment provider or treasury platform. A separate contract, separate screening and reconciliation interfaces.
SAP Pay. Embedded in the ERP, priced by transaction blocks, with execution, screening and reconciliation in one flow, run by a provider SAP owns or partly owns.

The honest differences are not features. They are who holds the contract, who screens, where reconciliation happens, and how you leave.

A 30-day pilot idea

Pick one legal entity in a supported country and one low-risk group of suppliers.
Start with domestic payments only. Test cross-border and stablecoin separately, later.
Measure: time from approval to settlement, exceptions, reconciliation effort, and cost per payment against your baseline.
Check each control in the matrix above with real evidence.
Decide what the pilot must prove before you widen it.

The take

Fewer hops is good. Fewer hops also means fewer places where a person, a file or a delay can stop a mistake.

And look at the bigger picture: the ERP, the agents, and now the payments, all from one vendor. That is convenient. It is also concentration. Take the convenience. Plan for the concentration.