# How agentic commerce works in enterprise relationships

How procurement, contracts, identity, billing, support and finance systems are absorbing agents into existing commercial relationships.

Source: https://aecon.ai/guides/ai-agent-enterprise-commercial-relationships
Author: Agentic Economy
Published: 2026-09-13
Updated: 2026-09-14

**Chapter 14 of The Hitchhiker's Guide to the Agentic Economy**

[Report hub](/guides/hitchhikers-guide-agentic-economy-2026) · Previous: [payment credentials and settlement](/guides/ai-agent-payments-credentials-rails-settlement) · In this chapter: [the lifecycle](#section-the-enterprise-relationship-lifecycle) · [market map](#section-the-enterprise-commercial-backplane) · [AE-JOB-001](#section-ae-job-001-from-onboarding-to-exit) · [relationship record](#section-the-enterprise-relationship-record) · Next: [packaging and pricing AI agent services](/guides/ai-agent-services-business-models-pricing)

## Our view

Enterprise commerce is a continuing control and evidence relationship. Five successful checkouts can move money five times while leaving the supplier's legal identity, contract, budget authority, acceptance test, liability, support route and exit plan unresolved.

An agent can be configured to assist with discovery, quote requests, purchase orders, service calls and invoice handling. It cannot make those responsibilities disappear. A governable supplier relationship joins the buyer's objective to an accountable counterparty, a bounded delegation, a versioned offer or contract, delivered work, acceptance, invoice and reconciliation, remedy, renewal and orderly exit.


> **Key Takeaways**
>
> - Attended purchases, bounded delegated purchases and contracted relationships carry different authority, support and remedy structures.
> - A commercial account owns durable state that a transaction-scoped credential should not own: counterparties, terms, data boundaries, budgets, obligations, acceptance and exit.
> - Procurement, finance, operations, security and the supplier need joined records. Independent “success” messages do not reconcile a job.
> - Delivery is not acceptance, settlement is not delivery, and an availability credit is not a remedy for an incorrect business result.
> - Australia changes the route where PayTo agreements, Peppol eInvoicing or cross-border privacy controls add a material record or decision. They do not turn payment or an invoice into authority or acceptance.

This chapter uses primary enterprise procurement, contract, billing, support, payment-mandate and Australian infrastructure sources checked on 13 September 2026. They establish documented supply, specified terms or scheme behaviour—not current demand, accepted work, repeat use, market price or profitability. No account, onboarding, invoice or payment was initiated.

### Sources and scope

Agentic Economy compared the research pack's primary supplier-lifecycle sources ([SAP](https://help.sap.com/docs/strategic-sourcing/supplier-management-setup-and-administration/supplier-management-setup-and-administration-guide?source=redirect), [Oracle](https://docs.oracle.com/en/cloud/saas/procurement/26a/oaprc/supplier-registration-process.html) and [ServiceNow](https://www.servicenow.com/docs/r/source-to-pay-operations/supplier-lifecycle-operations/supplier-performance-management-overview.html)), procurement/matching workflows ([Coupa](https://docs.coupa.com/en/supplier-documentation/coupa-for-suppliers/the-coupa-supplier-portal-or-csp), [SAP Ariba](https://help.sap.com/docs/buying-invoicing/invoicing-and-payment-process-guide/invoicing-and-payment-workflow-in-sap-ariba-solutions) and [Oracle](https://docs.oracle.com/en/cloud/saas/procurement/26b/oapro/match-approval-level-options.html)), and provider terms cited below. A capability is documented supply, not observed deployment.

The `AE-JOB-001` walkthrough is a synthetic proposed record. It contains no quote or market price. Corrections can be submitted through the [contact page](/contact). [About Agentic Economy](/about) explains the publication and its Australian focus.

## Enterprise software is absorbing the agentic transaction

The enterprise market is not building a parallel commercial system for agents. Procurement platforms, identity providers, marketplaces, billing systems, ERP products and payment networks are extending their existing records and controls to software actors.

This favours incumbents at the institutional layer. Microsoft, AWS, OpenAI, Stripe and enterprise software providers already sit inside accounts, contracts, identity domains and finance workflows. Agent interfaces can change how work is requested or executed without displacing those systems of record.

Our view is that agentic enterprise commerce will develop as an integration market. New protocols will carry intent, tasks and transaction data, while established systems continue to own supplier qualification, contracts, invoices, tax, settlement, support and exit.

## Why repeated checkout is not a commercial relationship

Checkout is a transaction boundary. It can capture a cart, a payment credential and an order acknowledgement. An enterprise relationship is the durable boundary around many transactions and the obligations between them.

For this guide, **commercial relationship** is the continuing set of parties, obligations, decision rights and remedies around repeated work. Treat a **qualified supplier** as a supplier record approved for a defined scope and period under the buyer's process, with separate confirmation of the executed legal counterparty and terms where the relationship requires them. **Service acceptance** is the buyer's recorded decision that a delivered result met the agreed test. **Order event** means one acknowledged purchase or instruction; it does not mean the wider relationship is healthy.

For example, five checkouts may prove five order events. They do not, by themselves, prove that the same legal supplier remained qualified, that the same data terms applied, that the buyer's cumulative spend stayed within policy, that delivery met an acceptance test, that invoices matched receipts, or that a failed result has an owner and a remedy. A seller can also change its plan, subcontractor, price, region or support tier between checkouts while the buyer's agent continues to replay an old route.

This is why supplier systems distinguish prospective from spend-authorised suppliers. [Oracle's registration process](https://docs.oracle.com/en/cloud/saas/procurement/26a/oaprc/supplier-registration-process.html) describes checks for legal name, DUNS and tax identifiers, while [SAP's supplier lifecycle documentation](https://help.sap.com/docs/strategic-sourcing/managing-suppliers-and-supplier-lifecycles/topics-about-searching-for-suppliers-and-supplier-management-projects) separates registration, qualification, commodity, region and approval states. These are product capabilities, not a universal buyer policy, but they expose the state that a stateless checkout omits.

The distinction also protects the provider. A recurring service needs a stable definition of work, a support identity, a change process and a way to end access without abandoning open jobs, unpaid invoices or customer data. An agent can initiate each job; the relationship tells everyone what counts as an authorised job and what happens when the job goes wrong.

## The enterprise relationship lifecycle

The answer in one lifecycle is: qualify the counterparty, onboard it into the buyer's controls, agree the contract or private offer, authorise bounded jobs, deliver and inspect the result, invoice and reconcile, remedy exceptions, then renew, amend or exit with the records closed.

For instance, a supplier can remain active in the payment system after its data approval expires. The lifecycle needs a qualification gate that can stop the next job even when checkout still works.

![The enterprise relationship lifecycle runs from qualification and onboarding through contract, job authority, delivery and acceptance, invoice and reconciliation, remedy, and renewal or exit. Each stage has a different owner and an explicit exception path.](/media/reports/agentic-economy-part-iii/enterprise-relationship-lifecycle.svg)

The figure is a control model, not a conversion funnel or a claim that any provider completes every stage. The accessible table carries the stage, authoritative owner, minimum evidence and exception path in text.

| Lifecycle stage | Authoritative owner | Evidence to retain | Exception or next state |
| --- | --- | --- | --- |
| **Need and intake** | Business owner | Named principal, objective, context, deadline, acceptance test and prohibited actions | Missing or ambiguous scope returns to the requester; it is not unlimited agent authority |
| **Qualification** | Procurement, security and privacy | Legal supplier identity, registration, service/category scope, risk tier, data region and expiry | Mismatch or expired approval leaves a candidate unqualified |
| **Onboarding** | Supplier-management owner | Approved profile, contacts, payment/tax details, security review, support route and escalation | Missing due diligence or failed risk gate pauses activation |
| **Contract or private offer** | Contract owner and supplier | Parties, version, scope, price, term, data terms, service levels, liability, dispute, renewal and exit | Unnegotiated change or unclear obligation requires human review |
| **Job authority** | Business sponsor and finance/resource owner | Job ID, order/PO or entitlement, delegate, allowed tools/data/actions, budget, hard cap, expiry and revocation | Out-of-scope action is denied; in-flight effect moves to reconciliation |
| **Delivery and acceptance** | Supplier delivers; buyer or named reviewer accepts | Output/version, source or receipt, timestamp, acceptance criterion, decision, correction deadline | Partial, late or wrong work becomes rework, rejection or dispute; it is not auto-accepted |
| **Invoice and reconciliation** | Supplier finance and buyer AP/tax | Invoice, contract/PO, receipt, accepted quantity, tax, credits/refunds, settlement and ledger references | Mismatch opens an exception; “paid” does not close acceptance |
| **Support and remedy** | Service owner, contract owner and risk | Incident, severity, response/restore, correction/reperform, refund/credit, indemnity, notice and dispute owner | Unresolved liability or harmful output remains open across suppliers |
| **Renewal, amendment or exit** | Contract and data owners | Value review, notice, changed terms, final invoice, export/deletion proof, handover, revocation and open claims | No accepted value or incomplete data/authority closure stops renewal or requires escalation |

Payment, delivery, acceptance, invoice, reconciliation and renewal are parallel business states. Here, **financially reconciled** means the authority/order, invoice or adjustment, settlement and buyer ledger references agree under the organisation's policy. A remedy or warranty claim can remain open after financial reconciliation and must be tracked separately. A provider's `completed`, `paid`, `active` or `renewed` flag can be retained in its native record, but the buyer needs a business state joined to the job and the relationship.

## The enterprise commercial backplane

The relationship is not a new protocol at the top of an “agent stack”. It joins control planes that enterprises already operate. The reviewed sources document parts of this backplane, not one deployed end-to-end system.


| Control plane and owner | Documented examples | What remains buyer-specific |
| --- | --- | --- |
| **Supplier qualification — procurement/risk** | [Oracle registration](https://docs.oracle.com/en/cloud/saas/procurement/26a/oaprc/supplier-registration-process.html), [SAP lifecycle](https://help.sap.com/docs/strategic-sourcing/managing-suppliers-and-supplier-lifecycles/topics-about-searching-for-suppliers-and-supplier-management-projects), [ServiceNow performance](https://www.servicenow.com/docs/r/source-to-pay-operations/supplier-lifecycle-operations/supplier-performance-management-overview.html) | Policy, scope, risk decision, expiry and enforcement |
| **Contract, obligations and renewal — legal/contract owner** | [Ironclad product descriptions](https://legal.ironcladapp.com/fy2026-product-descriptions), [AWS private offers](https://aws.amazon.com/marketplace/partners/private-offers), [Microsoft SaaS offers](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/plan-saas-offer) | Negotiated allocation, service result, liability, change and exit |
| **Billing and entitlement — supplier/finance** | [Stripe usage billing](https://docs.stripe.com/billing/subscriptions/usage-based/how-it-works), [Metronome invoicing](https://docs.metronome.com/guides/implement-metronome/core-concepts/how-invoicing-works) | Whether the meter represents the sold and accepted result |
| **Invoice, receipt and settlement — AP/tax/payment owner** | [Oracle matching](https://docs.oracle.com/en/cloud/saas/procurement/26b/oapro/match-approval-level-options.html), [SAP Ariba invoicing](https://help.sap.com/docs/buying-invoicing/invoicing-and-payment-process-guide/invoicing-and-payment-workflow-in-sap-ariba-solutions), payment records from Chapter 13 | Matching, tax treatment, exceptions, close and adjustment policy |
| **Support and remedy — service/contract/risk owner** | [AWS support](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html), [Google Cloud Customer Care](https://docs.cloud.google.com/support/docs), [Atlassian SLA](https://www.atlassian.com/legal/sla) | Customer-result acceptance, correction, harm and continuity; only the cited Atlassian SLA documents service credits here |
| **Marketplace configuration — platform and seller** | [Stripe Connect marketplace](https://docs.stripe.com/connect/marketplace?locale=en-GB) and [tax](https://docs.stripe.com/tax/connect) documentation | Seller, MoR, tax, support, refund, dispute and negative-balance roles under the executed setup |

One person or company may hold several roles, but each decision right still needs a name. Product capability does not prove that a buyer implemented the control or that systems share stable identifiers.

[Chapter 15 maps the service and business models](/guides/ai-agent-services-business-models-pricing) that price these responsibilities, including SaaS, usage, transaction, marketplace, managed-service, consulting and outcome-linked structures.

## `AE-JOB-001`: from onboarding to exit

`AE-JOB-001` is a synthetic Perth advisory-firm scenario: a client wants a sourced competitor and market briefing by a deadline. The firm supplies it; an agent gathers approved sources and an analyst reviews the result. It is illustrative, not a reported job.

### 1. Qualify and onboard the supplier

The buyer records its principal and the supplier's legal identity, service category, jurisdictions, contact and data boundary. It checks registration, qualification scope/expiry, security or privacy review, and a named support route.

The agent is a delegated actor, not the supplier; the analyst owns acceptance. Browsing, data and model providers remain upstream dependencies with their own terms. Keeping identities distinct prevents a later incident collapsing into “the agent did it”.

### 2. Agree the offer, contract and authority

The illustrative offer is one briefing covering five named competitors and up to ten approved public sources, delivered within one business day after a complete brief, with analyst review, required sections and sourced claims. External research has a hard cap recorded in the live quote; publication is prohibited. A valid rejection triggers correction within two business days or the agreed refund. Client material is retained only for delivery and correction.

A real buyer binds the quoted amount and offer to a contract, SOW, private offer or PO and records its tax and data terms. The principal approves the purpose; the authority record limits tools, sources, spend, time and publication. A payment credential cannot enlarge those limits.

### 3. Authorise and run the first job

The brief creates `job_id=AE-JOB-001`. A versioned offer, order or PO reference is attached before execution. The job records approved source classes, geography, confidentiality, deadline and acceptance test. Each external call gets an attempt or receipt reference; retries point to the same logical effect until known.

The operational cost ledger records model, data, browsing, infrastructure, retry and analyst time. The invoice ledger records the accepted briefing, charge, tax, credits and settlement. They link by job ID; a call, token or retry is not automatically a billable result.

### 4. Deliver, inspect and accept

The supplier delivers a versioned briefing with source links, retrieval dates, required sections and a change log. The analyst checks coverage, source permissions, claims and confidentiality against the acceptance test. The business state becomes `accepted`, `rework` or `rejected`; a provider response cannot write `accepted`.

If a competitor is omitted, a prohibited source appears or client material leaks, payment settlement does not complete the job. The analyst records reason, deadline and accountable supplier. A support ticket may run in parallel, but it is not acceptance.

### 5. Invoice, reconcile and repeat

The supplier invoice references the contract/PO, job, accepted unit, tax, credits and due date. Finance matches it to order, delivery and analyst decision. [Oracle's matching levels](https://docs.oracle.com/en/cloud/saas/procurement/26b/oapro/match-approval-level-options.html) distinguish PO/invoice, receipt and inspection or accepted quantity; [SAP Ariba](https://help.sap.com/docs/buying-invoicing/invoicing-and-payment-process-guide/invoicing-and-payment-workflow-in-sap-ariba-solutions) routes discrepancies before payment scheduling. Invoice and acceptance remain separate.

The second briefing follows acceptance, remedy closure and reconciliation. It proves repetition, not contribution or retention. Renewal evidence includes accepted jobs, corrections, support incidents, total cost and unresolved risk.

### 6. Handle an exception and preserve continuity

Suppose an upstream data service returns a stale source and the briefing makes a harmful recommendation. In this synthetic scenario, the executed offer makes the advisory firm the customer's first service counterparty; a real marketplace, pass-through or subcontracting arrangement can allocate that role differently. The operator pauses jobs, preserves source/run records, identifies affected outputs, informs the owner and opens correction, reperform, refund or dispute. Security or privacy owners assess further action against the actual executed terms.

An upstream `200 OK` cannot close the incident, and deleting the failed trace cannot close it either. Retain investigator, evidence hold where required, impact assessment, correction and continuity decision. Liability caps or service credits are contract facts, not proof that the customer is whole.

### 7. Renew or exit cleanly

At renewal, compare accepted work with price and operating cost, review amendments and qualification, and confirm the data/service scope still fits. Continued access is not renewal evidence.

At exit, close or dispute the final invoice, export needed job/acceptance/financial records, revoke credentials, complete or hand over open work, and obtain deletion or retention evidence. [OpenAI's services agreement and DPA](https://openai.com/policies/services-agreement/) ([DPA](https://openai.com/policies/data-processing-addendum/)) and [Microsoft's DPA](https://www.microsoft.com/licensing/docs/view/Microsoft-Products-and-Services-Data-Protection-Addendum-DPA?lang=1) show that return, access and deletion are term-bound. Public terms do not prove a downstream copy was deleted, so the exit record carries proof, owner and any retention hold—not merely “cancelled”.

## The Enterprise Relationship Record

The **Enterprise Relationship Record is an Agentic Economy editorial proposal**, not a standard, contract template, accounting ledger or legal, tax, privacy or assurance substitute. It is a linked view of one Commercial Job Record. Jobs, orders, payments and accepted outcomes remain authoritative in their own systems; the relationship record preserves the joins and decision rights.

| Group | Fields to retain | Invariant |
| --- | --- | --- |
| **Identity** | Relationship and version; buyer and supplier legal entities; agent/operator/reviewer IDs; jurisdictions; tax IDs or ABN where relevant | Display name, workspace or API account is not legal identity |
| **Supplier lifecycle** | Discovery source; registration; qualification scope and expiry; risk; security/privacy approval; preferred or denied status | Approval has an approver, scope and timestamp |
| **Contract and offer** | Contract/SOW/PO/private-offer IDs; version; scope; price; term; amendments; governing terms; renewal notice | Every job links to the terms/version in force |
| **Authority** | Principal; delegate; tools, data and actions; spend/time/publication caps; approvals; revocation | Payment capability cannot widen authority |
| **Budget and entitlement** | Alert versus hard cap; commitment/credit balance; overage; subscription, PO or entitlement | Funding, warning, hard stop and settlement are distinct |
| **Job and delivery** | Job ID; objective/context; calls/retries; output/version; timestamps; dependencies; receipts | Calls are evidence inside a job, not the sold unit by default |
| **Acceptance** | Criteria/version; reviewer or rule; accept/reject/waive; correction deadline and reason | Delivered or settled cannot auto-accept |
| **Invoice and tax** | Invoice, credit/refund; line basis; PO/receipt/contract links; tax fields; due date | Operational cost and invoice units need references, not silent substitution |
| **Settlement and reconciliation** | Mandate/charge; settled date; fees/payout; chargeback/refund; ledger and exception IDs | Settled cannot close delivery, acceptance or dispute |
| **Data and security** | Data classes; region; retention; subprocessors; access; export/deletion proof; revocation | Exit requires evidence, including downstream handling where applicable |
| **SLA and support** | Plan; SLO/severity; response/restore; monitoring source; tickets; credits; escalation | SLA measurement is not acceptance |
| **Liability and remedy** | Warranty; indemnity; cap/exclusions; insurance; incident notice; correction/refund/dispute owner | Each failure class has an accountable counterparty and next action |
| **Renewal and exit** | Owner/date/notice; value review; price amendment; migration; termination reason; final reconciliation | Renewal needs accepted-work evidence; exit closes work, money, data and authority |

The record preserves immutable IDs, versions and effective timestamps. At minimum, it joins `relationship_id`, `job_id`, `order_id` or `po_id`, `authority_id`, `attempt_id`, `effect_id`, `delivery_id`, `acceptance_id`, `invoice_id`, `settlement_id`, `incident_id` and `exit_id`. When two systems disagree, the stricter current boundary governs until the authoritative state is resolved; only then can a retry, renewal or deletion proceed.

### One canonical join, several authoritative systems

The Commercial Job Record is not a replacement ERP or global mutable database. It is the canonical join for the job: an append-only map of identifiers, versions, decisions and evidence owned by the systems that created them.

No cross-system join described here was observed in production. The map is a target architecture and test contract; SAP, Oracle, ServiceNow, billing, payment and provider documentation establishes component capability, not stable IDs or precedence across an actual buyer and supplier.

| Decision or state | Authoritative system or owner | What the joined record stores | Who may change it |
| --- | --- | --- | --- |
| Supplier qualification | Vendor/procurement system and named approver | Supplier ID, scope, status, expiry, evidence and decision timestamp | Procurement or risk role under buyer policy |
| Contract and offer | Contract repository, supplier and contract owner | Executed document/offer ID, version, effective dates and job reference | Authorised parties through amendment; prior versions remain |
| Delegated authority | Buyer policy/IAM system and principal | Principal, delegate, permitted actions/data, caps, expiry, revocation and policy digest | Principal or delegated policy owner; credential cannot widen it |
| Order and fulfilment | Merchant/service system | Checkout/order/fulfilment IDs, state, event version and retrieval link | Merchant under its native contract; buyer records disputes separately |
| Payment and settlement | Processor, bank, wallet or network plus finance owner | Logical payment ID, attempts, provider states, finality meaning and ledger references | Native provider records remain immutable; finance appends reconciliation/adjustment |
| Delivery and acceptance | Supplier delivers; named buyer reviewer decides | Artefact/version, criteria, decision, reason and correction deadline | Supplier may replace delivery; only named reviewer/rule writes acceptance |
| Invoice and tax | Supplier billing and buyer ERP/AP | Invoice/credit/tax IDs and PO, receipt, acceptance and settlement links | Authorised finance roles; corrections append rather than erase |
| Incident, remedy and exit | Service, contract, risk and data owners | Case IDs, owners, deadlines, remedy, export/deletion evidence and closure | Named case owners; retention holds override routine deletion |

If two systems disagree, the native owner resolves its own state and the joined record appends the resolution. `outcome_unknown` belongs to the service or reconciliation owner named for that boundary, with an escalation deadline. No shared record may manufacture `ordered`, `settled`, `accepted` or `deleted` merely to make the systems agree.

### Finance close and reconciliation gate

This is a management-control template, not accounting, revenue-recognition or tax advice. Before delegation, the organisation must set its own materiality threshold, close deadline, segregation of duties and posting policy. Unknown states above that threshold block release, renewal or deletion; permitted low-value exceptions go to a named suspense or investigation queue rather than being guessed closed.

| Job state | What finance may conclude | Minimum evidence bundle | Owner and enforcement |
| --- | --- | --- | --- |
| **Quoted** | Exposure can be compared; no order, payable, cash movement or accepted revenue is implied | Current offer/version, supplier/payee, amount or cap, currency, fees/tax basis, expiry and approver | Business/procurement; blocks order when material fields are unknown |
| **Ordered or entitled** | A commitment may exist under the executed terms; payment and delivery remain open | Contract/PO/order/entitlement, authority digest, job ID and cancellation terms | Procurement/contract owner; duplicate order check before retry |
| **Payment initiated or pending** | Value may be reserved, in transit or unresolved; it is not automatically settled or accepted | Logical payment ID, attempt, method, provider state, amount and next retrieval time | Finance/payment owner; blocks a new attempt until resolved or explicitly escalated |
| **Delivered, not accepted** | Work exists; invoice/payment treatment follows the contract and local policy, not the delivery flag alone | Delivery/version, acceptance criteria, reviewer, deadline and any rejection/rework case | Service and acceptance owner; cannot auto-write acceptance |
| **Accepted, invoice unmatched** | The service decision is complete; financial close remains open | Acceptance, invoice/credit, PO/contract, tax basis and settlement reference | AP/controller; mismatch is aged and assigned, not silently netted |
| **Reconciled** | The job can close for this management record, subject to the organisation's accounting policy and later remedies | Authority, order, delivery, acceptance, invoice/credit, settlement, ledger and unresolved-claim check | Controller or delegated reviewer; sign-off is segregated from execution |
| **Disputed, refunded or unknown** | The original event remains; adjustment, reserve or suspense treatment follows policy | Original evidence, case ID, amount, owner, next action, deadline and final adjustment | Named exception owner; breaches of the policy deadline escalate before close or renewal |

The close pack is finite: one relationship/job ID, current authority and terms, native order and payment references, delivery and acceptance, invoice/credit/tax references, settlement and ledger match, plus open remedy. It does not require finance to reconstruct an agent conversation. The organisation records its amount threshold and time-to-resolve target in the policy; this report does not invent a universal number.

## The delegated-chain failure

The hardest enterprise seam is not whether one agent can call one supplier. It is what happens when a delegated chain produces wrong or harmful work. A buyer may instruct its agent; the agent may call a managed service; that service may call a model, data provider or subcontractor. Every hop can report technical success while the customer's result fails.

| Question | Accountable first action | Evidence that must survive |
| --- | --- | --- |
| Who stops further effects? | Named stop authority revokes or narrows the buyer's delegation and supplier access | Policy version, revocation, queued work and residual effects |
| Who investigates? | The contracted service owner leads the customer-facing investigation and coordinates upstream providers | Job, source, model/tool, version, trace, data and incident links |
| Who corrects the result? | Supplier performs the agreed correction or rework; buyer accepts or rejects the replacement | Original and replacement artefacts, criteria, decision and deadline |
| Who pays or refunds? | Contract/finance owner applies the invoice credit, refund, reperform or dispute route | Original invoice/settlement, adjustment and reason |
| Who notifies? | Accountable organisation assesses customer, privacy, security and contractual notices | Decision, affected scope, notice owner and timing |
| Who preserves continuity? | Business and service owners choose a fallback supplier or pause work without widening authority | Handover, fallback approval, open jobs and data-access record |

[AWS customer terms](https://aws.amazon.com/agreement/) and the [OpenAI services agreement](https://openai.com/policies/services-agreement/) illustrate how customer responsibility, output review, suspension, indemnity, liability limits and termination can be allocated in provider terms. Those allocations vary by service, plan, region and negotiated order. The platform, model provider, marketplace and payment provider do not automatically own the downstream business result.

## Australia where the route changes

Australia matters here only where local infrastructure adds a material state or responsibility. It is not a decorative national subsection.

**PayTo changes the debit record.** [Australian Payments Plus describes PayTo agreements](https://www.auspayplus.com.au/solutions/payto-faqs) that state amount, purpose and frequency for one-off, ad hoc or recurring debits and can be viewed or managed by the customer. That can make a repeat collection route more legible for an Australian buyer. The agreement authorises a debit; it does not authorise the agent's underlying job, prove delivery or accept the result. The relationship record therefore stores the PayTo agreement alongside authority, order, acceptance and settlement rather than replacing them.

**Peppol changes invoice exchange.** The [ATO's eInvoicing material](https://softwaredevelopers.ato.gov.au/eInvoicing) describes software-to-software exchange over the Peppol network, with access points validating and routing documents. This can reduce manual invoice entry where both parties participate. It does not prove that the invoice is correct, that the buyer accepted the work or that payment settled. The [ATO's tax-invoice guidance](https://www.ato.gov.au/api/public/content/0-53cc7a8e-0668-4c9d-95d7-eb841eb09c04) describes information requirements for electronic invoices; it is not a universal conclusion about a particular supply's tax treatment.

**Cross-border data can change the exit and supplier review.** [OAIC's APP 8 guidance](https://www.oaic.gov.au/privacy/australian-privacy-principles/australian-privacy-principles-guidelines/chapter-8-app-8-cross-border-disclosure-of-personal-information) addresses reasonable steps and continuing accountability in applicable cross-border disclosures. Contractual controls, retrieval and deletion evidence remain buyer diligence questions rather than guarantees supplied by that guidance. For an APP entity considering a disclosure within APP 8's scope, the route record includes data class, destination, subprocessors and exit evidence before a job sends personal information offshore. This is a route and governance consideration, not legal advice; applicability depends on the facts and the governing obligations.

Another organisation's procurement rulebook, or a provider's claim of Australian availability, does not define a private buyer's control design. The operative boundary is the buyer's policy, governing obligations and executed contract, together with current supplier terms, data region and support coverage.

## What the market has not resolved

Enterprise platforms expose many of the necessary records, but no common agentic commercial layer joins them. Procurement owns the supplier, identity systems own the actor, runtimes own execution, service platforms own delivery, and finance systems own invoices and settlement. The integration burden remains with the enterprise and its vendors.

We expect agentic commerce to reinforce existing systems of record rather than replace them. The near-term opportunity lies in connecting those systems around a job, while the longer-term market may develop new commercial records that travel with delegated work across organisations.

## What the sources establish

| Market event | What it records | What remains separate |
| --- | --- | --- |
| **Specified** | A standard, scheme, contract or product defines a state or interface | Implementation, buyer enablement, safe configuration or demand |
| **Available** | A provider publicly describes a current capability, plan or support route | Access for this buyer, region, plan or workflow |
| **Discoverable or quoted** | A listing or published price/offer can be found | Supplier qualification, accepted work, negotiated price or market rate |
| **Ordered or authorised** | An order, PO, subscription, mandate or bounded delegation exists | Payment settlement, delivery, acceptance or repeat value |
| **Settled or invoiced** | A payment, balance, invoice or tax-document event exists under that system's semantics | Correct authority, conforming work, acceptance or profitability |
| **Delivered** | An artefact or service was made available | Completeness, correctness, acceptance or remedy closure |
| **Accepted and reconciled** | A named buyer/reviewer accepted the stated result and work, money, tax and exceptions were matched | Renewal, contribution, retention or safe downstream use |
| **Repeated** | A later job or order links to the relationship | Positive unit economics, durable demand or customer satisfaction |

The research pack contains no independent enterprise record that follows an agent from onboarding through contract, accepted delivery, invoice, dispute and repeat purchase across providers. There is no cross-system interoperability test connecting procurement, contract lifecycle management, runtime, supplier, ERP/AP and payment. Private amendments, security schedules and support escalations are usually not public. The chapter therefore reports documented supply and proposes a record; it does not claim that the market has already solved the relationship.

## Unresolved market questions

Our view would change if a transactional protocol demonstrably owned the complete continuing relationship: negotiated obligations, supplier qualification, acceptance, support, liability, invoice and reconciliation, and orderly exit across buyers and providers. A neutral, widely implemented identifier joining authority, order, payment, delivery, acceptance and remedy would also move this category materially.

Questions that remain open:

- Can procurement, contract, runtime, supplier, finance and payment systems share an export-stable job and relationship identifier without weakening their own authority boundaries?
- Which conformance tests catch repricing, duplicate requests, partial delivery, failed acceptance, invoice mismatch, refund and exit before a buyer expands delegation?
- Which contractual allocation is workable when an agent's supplier chain produces harmful work and each upstream provider limits its own liability or remedy?
- Can a repeated service prove accepted value and contribution when retries, human review, support, data and integration maintenance are counted?
- Which Australian production routes join agent authority, PayTo or bank collection, Peppol invoice exchange, privacy controls and accepted delivery in one auditable job?

Three observed patterns would weaken the relationship thesis: enterprises routinely permitting unknown suppliers to incur obligations without an accountable counterparty; repeat accepted work without a durable contract, acceptance or remedy record; and exits that prove complete export, downstream deletion and replacement continuity without assistance. None is visible at meaningful scale in the reviewed sources.

## Conclusion

Agentic commerce becomes enterprise commerce when a transaction sits inside a relationship that can be governed, inspected and repaired. The relationship joins the buyer's objective and accepted result to a qualified supplier, current contract or purchase order, bounded authority, separate delivery and finance states, named exception ownership and an orderly exit.

Payment protocols and billing meters remain useful components. They do not make a supplier qualified, a result correct or a liability allocation clear. The durable capability is the joined Enterprise Relationship Record around many Commercial Job Records—and the discipline to leave unknown and disputed states open until someone with the right authority resolves them.

## About the author and editorial record

Agentic Economy is the accountable publisher of this report. Joel Chan founded the publication in Perth to research the infrastructure, companies and operating choices shaping the agentic economy. This chapter is source-led market analysis, not a sponsored ranking, legal or tax advice, or evidence that any listed provider has been independently tested or adopted by an AE customer.