Embedded payments still need separate control states

One interface can hide several different truths

A purchase request says what someone wants. A purchase order says what the company committed to buy. A receipt says what arrived. An invoice says what a supplier claims. An expense says what an employee paid. An ERP posting says what Accounting recognized. A bank line says what cash actually left. Putting them in one queue helps only if the queue preserves those differences.

SAP's October 6 announcement is a useful signal of where spend software is moving. SAP Pay, powered by Tereina, is presented as embedded B2B payment execution and reconciliation inside SAP Cloud ERP. SAP says the service can support ACH or EFT, wire, check, and USDC across 89 corridors and more than 40 currencies. Those are vendor claims, not independently verified coverage guarantees. The important architectural change is that an approved invoice can move to a payment instruction without a separate bank portal or payment file.

SAP also says current SAP Pay keeps payment timing, currency, method, and approval under customer control, while Joule agents will later be able to trigger or execute payments. The tense is a control fact: embedded execution is current; autonomous agent execution is described as future capability. A control design should not grant an agent present authority because a roadmap statement makes autonomy sound inevitable.

ERP documentation shows why. Microsoft Dynamics distinguishes two-way, three-way, total, charge, and cumulative price matching, with tolerances and explicit choices about whether discrepancies block workflow or posting. SAP Concur supports different rule groups for POs with receipts, POs without receipts, and receipt confirmation. Those are not implementation details to collapse into a generic “AI confidence” score. They encode different obligations and evidence.

The practical thesis is that a unified interface should create one linked case, not one undifferentiated approval. Keep three release boundaries: commitment, accounting, and payment. Let AI normalize documents, search for links, and assemble exception evidence. Let deterministic rules prove arithmetic, duplicates, tolerances, authority, and segregation. Let named people own the decisions that create an obligation, recognize it, and release cash.

Embedded execution removes handoffs, not control objectives

Traditional payment operations often export an approved batch from ERP, upload it to a bank portal, obtain signatures, download confirmations, and import a reconciliation file. Embedding the payment provider can eliminate file handling and duplicate entry. It can also make state transitions happen inside one interface, where an invoice's green approval badge sits dangerously close to a payment button.

Design the integration as a chain of constrained services. The ERP owns the approved obligation and accounting state. The supplier master owns the controlled payee identity and destination version. A payment-orchestration layer proposes a rail, value date, currency, fee, and route. A policy service proves approval and segregation. Named signers authorize the exact instruction. The provider submits it to a rail. A bank, network, or wallet produces authoritative settlement evidence. Reconciliation links that consequence back to the open item.

approved invoice + current supplier master
  -> proposed payment instruction
  -> deterministic policy and sanctions gates
  -> named human authorization
  -> provider submission
  -> rail processing
  -> bank or wallet settlement evidence
  -> ERP open-item reconciliation
  -> exception or controlled closure

The provider's convenience claims should be treated as capability inputs, not outsourced assurance. “KYC/AML” or “OFAC screening” does not tell a controller which lists were checked, when screening occurred, how fuzzy matches are scored, who clears alerts, whether beneficiary banks and intermediaries are covered, or what happens when a party changes after authorization. Require the provider to expose evidence and events that your policy can test.

OFAC's framework emphasizes a risk-based sanctions compliance program built around management commitment, risk assessment, internal controls, testing or auditing, and training. Its guidance for instant payment systems also distinguishes systems with real-time settlement from deferred settlement. That distinction affects how long an organization has to stop or investigate a payment. Digital currency does not remove the underlying sanctions obligations.

Model payment as a state machine

SAP's own invoice-reconciliation documentation includes states such as Reconciling, Reconciled, Paying, Processing, Scheduled, Push Failed, Paying Failed, and Awaiting External Reconciliation. Product-specific labels vary, but the lesson is durable: “approved invoice,” “payment authorized,” “provider accepted,” and “cash settled” describe different facts.

Use an idempotency key derived from a stable payment-instruction ID, but never rely on it as the only duplicate control. A retry may use a different provider or rail, an operator may rebuild the batch, or a timeout may conceal a successful submission. Before retrying an unknown outcome, query the provider and authoritative account using the original reference. Then compare payee, amount, currency, and value date across every channel.

Destination changes reopen authorization. Do not display a full bank account or wallet in routine review; show a controlled fingerprint plus independently verified change evidence. A supplier email is not independent confirmation. Route changes, lookalike domains, urgent requests, and beneficiary-name inconsistencies to supplier-master or fraud specialists before rebuilding the instruction.

Rail rules should be explicit. Nacha requires account validation for a first-use or changed account number used for WEB debits; that rule should not be generalized to every credit payment. It is still a useful design prompt: define validation by entry class, direction, party, and rail rather than claiming one universal “bank verified” status. Wire, check, ACH, stablecoin, and other methods have different finality, cutoff, return, travel, fee, and evidence characteristics.

Keep commitment, accounting, and payment separate

The first boundary is commitment. Before a supplier is instructed or a card purchase is made, the organization decides whether the need is legitimate, budgeted, competitively sourced when required, contractually acceptable, and approved by someone with current authority. An after-the-fact invoice approval cannot recreate this control. A familiar approver clicking “approve” does not prove that the purchase was allowed before the company committed.

The second boundary is accounting recognition. AP verifies that the right entity received a real obligation, the supplier and document are authentic, the goods or service evidence supports it, the amounts and taxes recalculate, the coding and period are correct, and no duplicate or credit relationship makes the liability wrong. The reviewer approves a specific bill or journal proposal, not an abstract vendor relationship.

The third boundary is payment. Treasury or AP prepares an exact batch from approved liabilities, current bank details, holds, credits, discounts, value dates, cash needs, currency, and signer rules. Authorized signers release the exact batch. The resulting bank and ERP records are reconciled. Supplier creation, bank change, invoice approval, payment preparation, and payment release should not silently converge on one person or one autonomous agent.

Build a linked case without erasing source identity

One spend case can connect a request, quote, contract, PO, receipt, invoice, card transaction, employee claim, credit, posting, payment, and bank line. Every node keeps its native system ID, timestamp, owner, version, and source hash. The case stores proposed edges such as “invoice bills PO,” “receipt fulfills line,” or “card charge duplicates claim.” A proposed link becomes accepted only after its control-specific test passes.

case_id: p2p-2026-0911-0042
legal_entity: example-services-uk
supplier_id: SUP-01892
artifacts:
  request: PR-4421@sha256:...
  purchase_order: PO-20291-v3@sha256:...
  receipt: SR-8841@sha256:...
  invoice: INV-88917@sha256:...
  card_candidate: CARD-55102@sha256:...
links:
  - from: INV-88917
    to: PO-20291-v3
    type: bills
    status: proposed
controls:
  supplier_identity: verified
  duplicate_cross_channel: exception
  three_way_match: blocked
  accounting_release: blocked
  payment_release: blocked

This record prevents two common mistakes. First, the AI cannot rewrite an invoice field and make the original disappear. It can propose that “Acme UK” maps to supplier SUP-01892, while the reviewer still sees the exact source. Second, a single green badge cannot hide a red control. An invoice may pass arithmetic and still fail receipt, supplier, approval, or duplicate checks.

Use explicit states. “Matched” should never mean “the model found something similar.” It means the declared policy, fields, tolerances, and evidence produced a reproducible result. Missing is different from mismatch. A service receipt that has not yet been confirmed is missing; a confirmed quantity of eight against an invoice for ten is a mismatch. The next owner and permitted resolution differ.

Search for duplicates across channels before matching the happy path

Unified spend increases duplicate risk before it reduces it. The same obligation can arrive as a supplier invoice, card charge, employee expense, recurring debit, forwarded PDF, OCR retry, consolidated statement, or credit-and-rebill. An exact invoice-number rule catches only a subset. Supplier systems reuse number formats, punctuation changes, and fraudsters alter small fields.

Build a deterministic candidate set using normalized legal supplier ID, amount, currency, invoice date, service period, PO, line fingerprints, bank destination, and prior payment. Add fuzzy signals for similar numbers, near amounts, duplicate documents with altered metadata, and line-level overlap. AI may explain why two records look related, but a person resolves ambiguous installments, consolidated invoices, deposits, credits, and recurring charges.

duplicate_key_exact = hash(
  legal_entity,
  supplier_master_id,
  normalize(invoice_number),
  currency,
  decimal(total)
)

candidate_if = (
  same_supplier and same_currency and
  (same_amount or overlapping_lines or same_po) and
  days_between(invoice_dates) <= policy_window_days
)

block_if = exact_key_exists or prior_payment_matches
review_if = candidate_if and not documented_credit_rebill

Only then apply the right commercial match. A two-way match compares invoice price and amount to the PO. A three-way match adds received quantity. Service work may use approved milestones or named service confirmation. Non-PO expenses need a different policy, not a fabricated PO. Cumulative checks matter when several invoices bill one PO line. Charges, tax, freight, discounts, and partial receipts need their own logic.

Tolerances are policy decisions. A 2% price variance may be acceptable for one category and prohibited for another. Quantity underbilling can be as important as overbilling because it may conceal a partial delivery or shift an accrual. Microsoft documents options that merely warn and still permit posting; a reviewer must know whether the system blocked the transaction or displayed an icon that someone ignored.

Worked example: the invoice is correct and the payment is still wrong

A marketing team receives an approved PO for £24,000 of services, billed in three £8,000 milestones. The supplier emails the first invoice. A project manager forwards it to AP and also pays it on a corporate card to keep work moving, then submits the card receipt as an expense. The supplier later sends the same PDF to the centralized invoice address.

Each individual item looks plausible. The invoice matches the PO and milestone. The card transaction has a receipt and business purpose. The second email has the same invoice number. A document-only process catches the repeated PDF but may miss that the card already settled the obligation. A card-only process sees an approved expense. A unified case searches every channel before release.

The engine creates three candidate records under one obligation. Exact document hashing links the two PDFs. Supplier, amount, date, PO, and line description link the card charge. AP verifies the supplier and invoice, the receiving owner confirms milestone one, and the budget owner confirms the original commitment. Accounting records the service expense and clears the card liability; it does not create a second trade payable. The emailed invoice is marked already settled, and payment is blocked.

The case retains every source, reason, reviewer, and status. If the supplier claims non-payment, AP can show the payment path without deleting the invoice. If the card charge is later reversed, the case reopens and the payable can be reassessed. Closure represents a reconciled consequence, not an AI label.

Exceptions need owners, clocks, and permitted resolutions

An exception queue is useful only when each class has a control objective and owner. A missing receipt belongs first to the receiving or service owner. A price variance belongs to procurement or the contract owner. A tax-code question belongs to qualified tax or Accounting staff. A bank change belongs to supplier-master and fraud controls. A stale approval returns to the current delegated approver. AP should not become the universal owner merely because the invoice arrived there.

Set service clocks by consequence. A routine missing receipt may wait. A potential account takeover or urgent bank change requires immediate security and bank contact. A discount deadline can justify priority but cannot weaken identity or authority checks. Escalation changes who reviews; it does not turn missing evidence into approval.

Approve exact artifacts, then reconcile the real consequence

Accounting approval should identify the invoice or journal hash, legal entity, supplier, period, amount, currency, coding, tax, match result, exceptions, and reviewer authority. If any material field changes, approval expires. The same rule applies to payment. Signers review an exact batch and bank destination, not yesterday's spreadsheet or a summary card that can drift from the executable file.

ICAEW's current invoice-fraud guidance emphasizes independent supplier verification, segregation between vendor setup, invoice approval, and payment, plus duplicate and anomaly review. That separation is especially important when AI can move information across systems quickly. Credentials and payment execution should remain outside the model's reach; the agent submits a proposal to a deterministic service that checks policy and named approval.

After release, match the bank statement and payment confirmation to the approved batch and ERP open item. Confirm amount, currency, fees, FX, date, payee, settlement, and residual balance. Failed payments, partial settlements, discounts, credits, and bank fees create new exceptions. “Payment sent” is not closure. Closure means the approved liability was settled once and the books and bank agree.

Common failure modes

A 30-day pilot should start with exceptions

Choose one legal entity, one ordinary spend category, and a historical population containing known duplicates, partial receipts, non-PO invoices, credits, card overlap, price variances, bank changes, rejected payments, and late approvals. Freeze the population and reviewer decisions. Do not begin with live payment authority.

During week one, map authoritative systems, control states, delegation, tolerances, owners, and evidence. During week two, run AI extraction and link proposals in shadow mode; compare them with deterministic matches and human conclusions. During week three, let the system prepare exception packets while people continue existing approvals. During week four, permit a narrow, low-risk posting path only if identity, duplicate, matching, authority, and audit evidence meet threshold. Keep payment read-only until the separate release and reconciliation controls pass drills.

Measure population completeness, field accuracy, exact and fuzzy duplicate precision/recall, match accuracy by spend type, false auto-clear rate, exception aging, reviewer correction, first-pass resolution, time to posting, payment rejects, reconciliation breaks, and incidents. The most important metric is not touchless percentage. It is the rate at which a transaction that should have been blocked reached posting or cash.

• Freeze originals and system IDs before AI processing.
• Test cross-channel duplicates, not invoice-number duplicates alone.
• Reperform arithmetic and match logic deterministically.
• Prove current delegation and segregation on the exact artifact.
• Route every exception to a named fact owner.
• Keep supplier-bank change and payment release outside autonomous authority.
• Reconcile bank and ERP before closing the case.
• Stop the pilot if population completeness or block effectiveness is unknown.

FAQ

Does SAP Pay currently let Joule agents execute payments?

SAP describes embedded SAP Pay execution as available and says Joule agents will soon be able to trigger and execute payments. Treat agent execution as a roadmap statement until your contracted product, region, configuration, and authorization model prove otherwise.

What is an AI procure-to-pay exception workflow?

It is a linked evidence process across request, PO, receipt, invoice or expense, approval, posting, payment, and reconciliation. AI prepares evidence and proposed links; deterministic controls and authorized people decide release.

Can a perfectly matched invoice be paid automatically?

Only if policy allows and the system separately proves supplier identity, duplicate status, authority, bank details, payment holds, batch integrity, and segregation. A commercial match is necessary for some invoices but is never the whole payment control.

Does one platform become the source of truth?

It can become the control case, but source authority remains distributed. The PO system owns the commitment record, receiving owns delivery evidence, the supplier master owns controlled identity, the ERP owns the posting, and the bank owns cash settlement.

Where should AI have the most autonomy?

In reversible preparation: intake, classification, candidate linking, arithmetic, explanation, and exception packet assembly. Autonomy should narrow as the workflow approaches supplier changes, accounting posting, external communication, and payment.