SAP stablecoin payments are live: your customer's ERP can now pay invoices in USDC — and only the buyer's side reconciles itself

What SAP and Circle announced on October 6 and 7, 2026

On October 6, 2026, at its SAP Connect event, SAP said it was entering the payments market with SAP Pay, powered by Tereina, an SAP company (SAP News Center). The product is embedded in SAP Cloud ERP. In SAP's words, it "executes and reconciles payments within the same workflow when an invoice is due, reducing manual file handling and external processing dependencies."

Reuters filled in the commercial picture the same day. Tereina's service lets businesses pay suppliers, employees and affiliates directly from SAP, in traditional currencies or in stablecoins. It launches in the US and the UK. Until now, SAP had left payments to whichever providers its customers connected themselves. Tereina claims the service can cut payment costs by up to 25%. That's the company's own figure, not an independent one.

On October 7, Circle and Tereina announced the stablecoin piece (Circle press release). USDC "will serve as the preferred stablecoin" for eligible US-dollar payment workflows, and EURC is the option for euro activity. Circle CEO Jeremy Allaire called stablecoins "a core infrastructure layer for global commerce." Tereina CEO Cedric Bru said stablecoin payments "become a native feature of the applications they already trust."

Circle's SAP Pay page adds the gate: "To use USDC within SAP Pay, your organization will need an eligible Circle Mint account." Circle Mint is open to eligible businesses and institutions in specific regions, after background, KYC and sanctions checks that "can take a few weeks or more." The page lists the target workflows: intercompany liquidity across time zones, less prefunding, and cross-border supplier payments and AP/AR settlement.

Why SAP stablecoin payments matter more than another partnership

New stablecoin partnerships get announced every week. This one is different because of where the rail lands. In a large company, a supplier invoice is received, matched to a purchase order, approved and scheduled inside the ERP. Then, in most companies, someone exports a payment file to a bank. The bank's confirmation comes back later and gets matched by hand or by yet another tool.

SAP Pay removes that hop. The system that approves the invoice now sends the money and books the result. Adding USDC to that list means a treasury team can choose a stablecoin the way it chooses a wire: as a rail on an approved invoice, not as a separate crypto project. For cross-border payables, where wires can take days and pass through correspondent banks, that's the change that could shift behavior. It fits what the data already shows: stablecoin business payments look like invoices, not shopping carts.

Two cautions. First, the 84% figure describes SAP's customer base, not stablecoin usage, and nobody has said how many SAP customers will switch USDC on. Second, the payer has to hold USDC through Circle Mint, an institutional account. Our reading, and it's only a reading: the first live flows will probably be intercompany transfers between subsidiaries of the same group, which Circle lists first, and large cross-border payables. Small-ticket purchasing comes later, if at all.

Reconciliation follows whoever starts the payment

This is the part of SAP stablecoin payments that matters most if you're the one getting paid. SAP Pay can reconcile "in real time" on the buyer's side because the buyer's ERP started the payment. It knows the invoice, the amount and the transaction it just sent.

The supplier doesn't get that context for free. A wire can carry remittance information. An ACH payment can carry addenda. A standard USDC transfer on an EVM chain such as Ethereum, Base or Polygon carries a sending address, a receiving address, an amount and a transaction hash. It has no invoice-number field.

That's harmless with one customer. It breaks when three customers pay the same address in the same week, one pays two invoices in a single transfer, another comes up a few dollars short, and a fourth pays a quote that expired last month. Your accounts-receivable team is back to matching amounts and emailing customers for screenshots.

So the receiving side has to design the matching before the first payment arrives:

• One payment request per invoice, with the exact amount, the token and the network, so a payment can only belong to one invoice.
• An expiry, so an old quote isn't paid weeks later at an old amount.
• Partial-payment and overpayment detection, so "almost paid" never gets booked as paid.
• A machine-readable "paid" event that your ledger receives, instead of someone checking a block explorer.

If your customer is on SAP Pay and you are too, part of this may be handled for you, since Circle's page lists receiving customer payments as a use case. For the much larger group of suppliers who don't run SAP Cloud ERP, it isn't.

Four things that must be true before a supplier sees an SAP Pay USDC payment

1. Your customer runs SAP Cloud ERP with SAP Pay, in a launch market (the US or the UK).
2. Your customer has an eligible Circle Mint account. Circle says onboarding includes identity, KYC and sanctions checks and can take a few weeks or more.
3. You've agreed on a token and a network. Neither the release nor Circle's SAP page names a chain. Several outlets report Arc, Circle's own blockchain (on mainnet since September 16, 2026), as the preferred network for the first workflows. If your customer sends on a network you don't receive on, the payment becomes a problem instead of a convenience. Networks also get retired: Circle is winding down USDC on Noble this month (our analysis).
4. You actually want USDC. Some suppliers will: no correspondent banks, settlement in seconds, a dollar balance outside a local banking system. Others will still want a local-currency wire. That's a commercial decision to make customer by customer.

None of this is a reason to wait. Buyers ask suppliers for payment details long before the first payment run. The supplier who already has a stablecoin invoice flow is the one who can say yes on that call.

How to get ready to receive stablecoin invoice payments, step by step

Payzum is a non-custodial, crypto-only payment processor. It doesn't plug into SAP Pay and isn't part of the Circle and Tereina partnership. What it gives a supplier is the receiving half described above: invoices that match themselves, settled to a wallet you control.

1. Connect a wallet you control. Self-custody, hardware or multisig. Payments settle there directly. Payzum never holds, pools or controls the funds, so there's no processor balance to freeze.
2. Choose your token and networks. Accept USDC or USDT on Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche or Solana, plus Bitcoin. Confirmation typically takes about 2 seconds on Base and Polygon and about 0.4 seconds on Solana. If a customer pays in another crypto, optional auto-conversion settles it in USDC or USDT. Print the token and network on the invoice.
3. Issue each invoice as its own payment request. Payzum invoices carry an expiry and detect partial payments and overpayments. The status moves through waiting, partially_paid, finished, expired or failed, so "almost paid" never reads as paid. For repeat billing, use payment links or subscriptions.
4. Let the ledger update itself. Signed webhooks push each confirmed payment to your systems, with your invoice reference and the on-chain transaction hash. Official open-source integrations cover ERPNext/Frappe and Akaunting, and SDKs exist for Node.js/TypeScript, PHP, Python and Rust.
5. Pay your own suppliers from the same wallet. Mass payouts in EVM stablecoins on Polygon, Arbitrum, Optimism, Base, BNB Chain and Avalanche let USDC from one customer pay your contractors without a round trip through a bank.

The limits, stated plainly: Payzum doesn't support Arc or EURC today, and it settles in crypto only, never to a bank account. If a buyer can only pay on Arc or in EURC, raise it before the first invoice, not after the first payment.

Who should care first: three scenarios

• A contract manufacturer in Mexico selling to a US group. The buyer pays suppliers from SAP and wants to test stablecoin settlement on cross-border payables. The manufacturer issues each invoice as a USDC payment request on the network both sides agreed. It gets a finished status when the payment confirms, and pays its own sub-suppliers from the same wallet.
• An IT services firm in Colombia billing a monthly retainer to a UK client. Wires take days and lose money to intermediary fees. A USDC invoice with an expiry, plus a signed webhook into the firm's ERPNext, replaces the "did it arrive?" emails at the end of each month.
• A mid-size distributor that isn't on SAP at all. It wants the same "invoice approved, paid, booked" loop for its own customers. Payzum invoices with the Akaunting or ERPNext integration give it that loop without an enterprise ERP.

Receiving a B2B payment: wire vs raw USDC transfer vs Payzum invoice

Fair objections

"None of our customers run SAP Cloud ERP."

Then SAP Pay won't reach you soon. The shift underneath it still matters. The platforms that hold invoices on the payer side, such as ERPs, spend platforms and banks, are adding stablecoin rails one after another. We covered Ramp's version earlier this year. Your receiving process shouldn't depend on which one your customer picks.

"Shouldn't we just open a Circle Mint account?"

Maybe, if you need to mint and redeem USDC for dollars directly with the issuer, at volume. But Mint is an institutional account with weeks of onboarding, and you don't need one to receive USDC. Circle's own FAQ points businesses that don't qualify to exchanges, apps and other providers. What you do need is a receiving process: an address you control, invoices that match, and a ledger that updates.

"Is it safe to hold the USDC we're paid?"

USDC is redeemable 1:1 for US dollars through Circle, but every issuer can freeze addresses, and holding any token is a treasury decision. Decide how much you keep and for how long, and pay suppliers or convert on your own schedule. Settling to your own wallet at least removes the processor as another party that could hold your money.