B2B Wholesale and Agent Procurement — Net-30, Quoted Pricing, and the Buyer-Agent Protocol.

Why generic shopping-agent assumptions break in wholesale commerce.

B2B commerce differs from retail not cosmetically but architecturally — all the way down into data schema, authentication, document format, and payment mechanics. Every assumption baked into a consumer shopping agent is wrong in the B2B context. Here is where each assumption breaks and what replaces it.

Price is quoted, not listed

A retail price is a single number visible to any visitor. A B2B price is the output of a negotiation: contract-specific pricing tied to a buyer's account, volume breaks triggered by order quantity, and spot pricing that shifts with commodity costs or freight rates. The same SKU may carry five different prices across five buyer relationships on the same day. An agent that retrieves a price from a public product page and submits a PO based on that number will, at best, receive a corrected invoice; at worst, the PO will be rejected entirely.

The correct data model at Layer 1 (Structured Data) therefore requires: quoted unit price (not MSRP), price-break tier arrays keyed to order quantity, minimum order quantity (MOQ), contract number or buyer account ID, unit of measure, lead time, and applicable regulatory flags.

Terms are net-30, net-60, or custom — not due at checkout

Consumer checkouts expect payment at the moment of purchase. B2B buyers expect an invoice payable 30, 60, or 90 days after the invoice date. The buyer carries open payables on their accounts payable ledger; the seller carries open receivables on their accounts receivable ledger. An AI agent that attempts to charge a stored card at order-submit will be rejected by the buyer's ERP. Payment terms also encode early-payment discounts: a term like 2/10 Net 30 means the buyer receives a 2% discount if payment arrives within 10 days; otherwise the full amount is due in 30 days. Agents operating on the CFO side must evaluate whether the early-payment savings exceed the cost of capital before scheduling payment timing.

Purchases require multi-level approval

Most enterprise procurement policies route purchase requests through a tiered approval chain: department head approves fit and budget, finance approves cash availability, and procurement (or legal) approves vendor qualification and contract terms. Spend thresholds trigger additional tiers — a $500 purchase may auto-approve, a $5,000 purchase may need a manager, a $50,000 purchase may require VP and CFO sign-off. The buyer-agent is never the final authority. It submits, recommends, and escalates — it does not unilaterally commit funds. Any UCP implementation for B2B must model this approval chain explicitly.

The buyer is a procurement agent acting under corporate policy

The most important reframe: the "buyer" in B2B is not a human with a credit card browsing for the best price. The buyer is an agent — human or AI — operating under a corporate spending policy that defines approved vendor lists, spend category budgets, payment term constraints, required compliance certifications (SOC 2, ISO 27001), and sometimes preferred procurement networks (Ariba, Coupa). The AI procurement agent's job is to enforce that policy mechanically, not to optimize for lowest sticker price alone.

The CFO-agent and procurement-agent: two distinct authority levels.

The AgentMall roadmap names the procurement agent as one of the highest-value agent personas in B2B commerce — higher-value than a consumer shopping agent because transaction sizes are larger, policy constraints are explicit, and the workflow is well-documented in existing procurement standards. There are two distinct personas, and they operate at different authority levels with different tool sets.

What the procurement agent does (7-step flow)

1. Receives a buying requirement from a human or a triggering system event — e.g., "We need 500 units of industrial solvent SKU #A-4412 for Q3 manufacturing, net-60 terms preferred, SOC 2-compliant supplier required."
2. Queries the approved vendor list via the buyer's ERP or procurement platform to find vendors approved for the relevant spend category.
3. Fans out RFQs (Requests for Quote) to N qualified suppliers via their MCP servers or procurement platform APIs — in parallel.
4. Aggregates and scores responses against policy: unit price, lead time, payment terms offered, compliance certifications on file, and supplier risk score.
5. Recommends one vendor (or a ranked short-list) to the human procurement manager, with a structured justification for each scoring dimension.
6. Executes the PO once approved, either via the procurement platform or direct EDI 850 transmission.
7. Tracks the order through EDI 855 acknowledgment, goods receipt, and EDI 810 invoice — reconciling against the PO before approving EDI 820 payment.

What the CFO-agent does (4-tool set)

The CFO-agent operates at a higher level of abstraction, with delegated authority to set and enforce spending policy. It consumes the procurement agent's recommendations and acts as the policy enforcement layer:

Both personas require a CFO-side MCP server (Layer 3) with the tools above, distinct from the merchant-side MCP server. See MCP server construction patterns for tool schema definitions and hosting guidance.

SAP Ariba, Coupa, Oracle, JAGGAER, and Tradeshift — platform-by-platform.

The five major enterprise procurement networks and platforms a B2B wholesale supplier or distributor must understand are SAP Ariba Network (now SAP Business Network), Coupa, Oracle Procurement Cloud, JAGGAER, and Tradeshift. SAP Concur overlaps on travel and expense but shares API credentials with Ariba and is included here for completeness. All pricing figures below are volatile — re-verify before launch.

Ariba Network enrollment details for agent builders

Ariba's supplier fee model has a meaningful two-part trigger: at least 5 documents transacted and transaction volume exceeding $50,000 USD in at least one buyer relationship in a 12-month period. Suppliers below either threshold remain on the free Standard account. Suppliers using EDI or cXML integration are automatically assigned to Silver level ($750/yr) regardless of document count — plan accordingly before choosing your integration method. The 0.155% transaction fee is capped per buyer relationship at $20,000 USD/year in North America, which protects high-volume suppliers.

The Ariba OAuth flow uses client credentials:

curl -L -X POST 'https://api.ariba.com/v2/oauth/token?grant_type=openapi_2lo' \
  -H 'Authorization: Basic {Base64(client_id:client_secret)}' \
  -H 'Content-Type: application/x-www-form-urlencoded'

API groups available after registration at https://developer.ariba.com/api/: Core Procurement REST APIs, Strategic Sourcing REST API, Strategic Contracts REST API, Invoicing, Catalog Management REST API, Supplier Lifecycle & Performance, and SAP Business Network REST APIs (order/invoice exchange). Each API group has its own Swagger spec accessible after enrollment.

Key Coupa integration notes

Coupa supports three integration patterns for procurement agents: the Core REST API (JSON or XML, X-COUPA-API-KEY header), OAuth 2.0 (for agents needing per-user token delegation), and cXML OrderRequest (for EDI-style PO receipt). The REST API exposes: GET /api/purchase_orders, POST /api/purchase_orders, PUT /api/purchase_orders/{id}/issue, GET/POST /api/requisitions, GET/POST /api/invoices, GET /api/suppliers. The issue action on a PO is a distinct API call from creation — a common integration gap.

EDI is the execution rail — not the decision layer.

Electronic Data Interchange (EDI) is the standardized document format that fires once the procurement agent has made its decision. The agent decides; EDI transmits the paperwork. This boundary is architecturally critical: EDI segment logic must not leak into agent decision code, and agent ambiguity must not leak into what should be deterministic document generation. Keep the layers clean.

EDI document types in the agent procurement flow

Complete EDI 850 example — annotated

The following is a complete, non-truncated ANSI X12 EDI 850 Purchase Order. Delimiters: * (element separator), ~ (segment terminator), > (sub-element separator). This is the document the buyer-agent fires after PO approval — see the full 9-step worked example in §8 for context.

ISA*00*          *00*          *ZZ*BUYERCO        *ZZ*SUPPLIERCO     *240801*0900*>*00401*000000042*0*P*>~
GS*PO*BUYERCO*SUPPLIERCO*20240801*0900*42*X*004010~
ST*850*0042~
BEG*00*NE*PO-2024-00042**20240801~
CUR*BY*USD~
REF*IA*CONTRACT-2024-001~
PER*BD*Jane Procurement*TE*555-800-1212*EM*jane.procurement@buyerco.com~
TAX*0*VC*****22*ST~
ITD*01*3*2*10*30***NET 30~
DTM*002*20240831~
N1*BY*BuyerCo Inc.*ZZ*BCOINC~
N2*Accounts Payable Dept~
N3*100 Industrial Blvd~
N4*Chicago*IL*60601*US~
N1*ST*BuyerCo Warehouse 3*ZZ*BCOWH3~
N3*800 Dock Road~
N4*Gary*IN*46401*US~
PO1*1*500*EA*24.50*CP*VC*SKU-A4412*UP*012345678901~
PID*F****Industrial Solvent Grade A 1L~
SAC*A*I210****25000**50*50*5~
PO1*2*100*EA*89.00*CP*VC*SKU-B7710*UP*098765432109~
PID*F****Safety Neutralizer Kit~
CTT*2~
AMT*TT*21150.00~
SE*24*0042~
GE*1*42~
IEA*1*000000042~

Segment annotations

• ISA — Interchange Control Header. Sender ID (BUYERCO), receiver ID (SUPPLIERCO), date/time, interchange control number (000000042).
• GS — Functional Group Header. PO = Purchase Order functional group.
• ST*850*0042 — Transaction Set Header. 850 identifies this as a Purchase Order. Control number 0042.
• BEG*00*NE*PO-2024-00042 — Beginning segment. NE = New PO. PO number = PO-2024-00042.
• CUR*BY*USD — Currency: buyer pays in USD.
• REF*IA*CONTRACT-2024-001 — Reference: links to master contract CONTRACT-2024-001.
• PER*BD — Buyer contact (department buyer) with phone and email.
• ITD*01*3*2*10*30 — Terms of sale: type 01 (Basic), net days 30, early discount 2% if paid within 10 days. Human-readable: "2/10 Net 30".
• DTM*002*20240831 — Requested delivery date: August 31, 2024.
• N1*BY — Buyer name loop. ZZ = mutually defined qualifier.
• N1*ST — Ship-to name loop. Warehouse 3 in Gary, IN.
• PO1*1*500*EA*24.50 — Line item 1: 500 each at $24.50/EA. Buyer's vendor catalog ID SKU-A4412, UPC 012345678901.
• PID*F — Free-form product description: "Industrial Solvent Grade A 1L".
• SAC*A*I210 — Service, Promotion, Allowance, Charge. Volume discount applied.
• PO1*2*100*EA*89.00 — Line item 2: 100 each at $89.00/EA.
• CTT*2 — Transaction Totals: 2 line items.
• AMT*TT*21150.00 — Total monetary amount: $21,150.00 (500×$24.50 + 100×$89.00 = $12,250 + $8,900 = $21,150).
• SE*24*0042 — Transaction Set Trailer: 24 segments included.
• GE*1*42 — Functional Group Trailer.
• IEA*1*000000042 — Interchange Trailer.

How each layer changes when the buyer is a procurement agent.

The AgentMall 4-Layer Agent-Ready Model is universal. What B2B wholesale and procurement changes is the implementation of each layer, not the model itself. Here is precisely where and how each layer differs in the B2B context.

Layer 2 API reference — key endpoint paths

SAP S/4HANA Cloud (sourcing and procurement)

Oracle NetSuite purchase order REST

# Create PO
POST https://{account}.suitetalk.api.netsuite.com/services/rest/record/v1/purchaseOrder

# Read PO with sub-resources
GET  https://{account}.suitetalk.api.netsuite.com/services/rest/record/v1/purchaseOrder/{id}?expandSubResources=true

# Update PO
PATCH https://{account}.suitetalk.api.netsuite.com/services/rest/record/v1/purchaseOrder/{id}

# Auth: OAuth 2.0 token-based; requires Purchase Orders feature enabled in NetSuite account

Microsoft Dynamics 365 Business Central

# List purchase orders
GET https://{prefix}/api/v2.0/companies({id})/purchaseOrders

# Create purchase order
POST https://{prefix}/api/v2.0/companies({id})/purchaseOrders

# Auth: Bearer token (Azure AD OAuth 2.0)

Layer 3 MCP tool schemas

These are the merchant-side and buyer-side tool signatures your MCP server must implement. Each tool reads from live ERP data, not a cached snapshot.

/* MERCHANT-SIDE MCP TOOLS (seller exposes these) */

get_quote(buyer_id, sku_list, quantities, requested_terms)
  Returns: {
    line_items: [{sku, unit_price, price_break_tiers, moq, lead_time_days}],
    payment_terms_offered, contract_number, quote_expiry
  }

check_credit_terms(buyer_id)
  Returns: {credit_limit, available_credit, payment_terms, outstanding_balance}

get_lead_time(sku, quantity, ship_to_zip)
  Returns: {estimated_ship_date, carrier, transit_days}

submit_po(quote_id, buyer_po_number, ship_to_address, requested_delivery_date)
  Returns: {seller_order_id, acknowledgment_expected_by, edi_855_pending}

check_po_status(seller_order_id)
  Returns: {status, ship_date, tracking_number, invoice_number}

submit_invoice(seller_order_id, invoice_number, line_items, due_date)
  Returns: {invoice_accepted, payment_due_date, early_payment_discount}

/* BUYER-SIDE / CFO-SIDE MCP TOOLS (buyer exposes these) */

approve_purchase(requisition_id, approver_id, notes)
  Returns: {approval_status, approved_amount, po_number_assigned}

set_spending_cap(category, department, amount, period)
  Returns: {cap_id, effective_date, current_utilization}

request_quote_comparison(requirement_spec, approved_vendor_list, scoring_weights)
  Returns: {rfq_id, vendors_invited, response_deadline}

get_policy_constraints(category, spend_amount)
  Returns: {approval_chain, required_certifications, preferred_terms, vendor_restrictions}

escalate_to_human(context, reason, urgency)
  Returns: {ticket_id, assigned_to, escalation_reason}

Establishing credit before the first agent-initiated transaction.

When two companies transact for the first time — including when an AI agent initiates the first transaction on behalf of a buyer entity — credit terms are not automatic. The seller must evaluate the buyer's creditworthiness before extending net-30 or net-60. In manual operations this takes days to weeks; in an agent-ready architecture it needs to be automated.

The three US business credit bureaus

Embedded B2B credit providers

For suppliers who cannot or do not want to manage credit underwriting in-house, embedded B2B credit providers take on the underwriting and credit risk in exchange for a fee:

Credit establishment in an agent flow

A procurement agent initiating a first purchase with a new seller must:

1. Request a credit application via the seller's MCP check_credit_terms tool.
2. Supply the buyer company's D-U-N-S Number, Employer Identification Number (EIN), and business references.
3. If the seller uses Resolve or Balance, the embedded provider runs the credit check automatically and returns a credit limit and available terms in real time.
4. Store the approved credit limit and terms as a persistent context artifact for future calls to the same seller's MCP — credit approval should not trigger a redundant check on every subsequent transaction.

Fan-out, score, recommend — the procurement agent's highest-value operation.

The Request for Quote (RFQ) workflow is one of the highest-value applications of the procurement agent. Manually, sourcing a new vendor for an item requires days of email back-and-forth. With an agent, it can execute in minutes — if the Layer 1 data and Layer 3 tools are in place.

RFQ agent flow (7 steps)

1. Receive requirement. Human procurement manager (or a triggering inventory event) submits: SKU or specification, desired quantity, required delivery date, budget ceiling, required certifications (SOC 2, ISO 27001), preferred payment terms.
2. Query approved vendor list. Agent calls buyer-side ERP or procurement platform to retrieve vendors approved for the relevant spend category. For SAP buyers: API_PURCHASING_SOURCE_SRV (Purchasing Source List). For Oracle buyers: /procurementApprovedSupplierListEntries.
3. Fan out RFQs in parallel. Agent calls get_quote on each approved vendor's MCP server simultaneously (or submits RFQ via procurement platform: Ariba Strategic Sourcing REST API POST to https://openapi.ariba.com/api/strategic-sourcing/v1/rfqs, or Oracle /supplierNegotiations POST). Each RFQ includes specification, quantity, requested delivery date, and payment terms requested.
4. Aggregate responses. Agent collects returned quotes: unit price, price-break tiers, MOQ, lead time, payment terms offered, compliance certifications claimed.
5. Score against policy using a weighted matrix.
6. Recommend. Agent surfaces a ranked recommendation with justification for each scoring dimension. If the top-ranked vendor falls within the procurement agent's delegated authority, it fires the PO directly. Otherwise, it escalates via escalate_to_human or routes to approve_purchase.
7. Execute PO. Once approved, buyer-agent calls submit_po on the winning vendor's MCP, or submits via Ariba Network or Coupa API, which generates and transmits the EDI 850.

Weighted scoring matrix

Agent-initiated RFQ to PO via Ariba Network — 9 steps with real API calls.

Scenario: BuyerCo's procurement agent receives a reorder trigger for Industrial Solvent Grade A (SKU-A4412), 500 units, required by August 31, net-30 preferred. Three approved vendors (SupplierA, SupplierB, SupplierC) are on file. BuyerCo uses SAP S/4HANA and is connected to Ariba Network.

Step 1 — Agent retrieves approved vendor list

GET https://hostname/fscmRestApi/resources/11.13.18.05/procurementApprovedSupplierListEntries
  ?q=itemDescription=SKU-A4412
Authorization: Bearer {token}

Returns: SupplierA (AN01234567890), SupplierB (AN09876543210), SupplierC (AN05555555555) — all with active Ariba Network IDs.

Step 2 — Agent fans out RFQs via Ariba Strategic Sourcing API

POST https://openapi.ariba.com/api/strategic-sourcing/v1/rfqs
Authorization: Bearer {oauth_token_from_api.ariba.com}
Content-Type: application/json

{
  "title": "RFQ-2024-0412 Industrial Solvent SKU-A4412",
  "items": [{"partNumber": "SKU-A4412", "quantity": 500, "uom": "EA"}],
  "suppliers": ["AN01234567890", "AN09876543210", "AN05555555555"],
  "responseDeadline": "2024-08-05T17:00:00Z",
  "requestedDeliveryDate": "2024-08-31",
  "paymentTermsRequested": "NET30"
}

Step 3 — Suppliers respond via Ariba Supplier Portal or API

Step 4 — Agent scores using the weighted matrix

SupplierA wins on composite score: competitive price, lead time meets the August 31 window, preferred terms, SOC 2 on file. SupplierB's 14-day lead time misses the required delivery window — a 0 on that dimension drops its composite score below SupplierA despite the lower unit price.

Step 5 — PO within delegated authority

500 × $24.50 = $12,250 — within the procurement agent's $25,000 authority ceiling for this category. No escalation required. Agent calls submit_po on SupplierA's MCP server:

{
  "tool": "submit_po",
  "arguments": {
    "quote_id": "QT-SUPP-A-0412",
    "buyer_po_number": "PO-2024-00042",
    "ship_to_address": {
      "line1": "800 Dock Road",
      "city": "Gary",
      "state": "IN",
      "zip": "46401"
    },
    "requested_delivery_date": "2024-08-31",
    "payment_terms": "NET30"
  }
}

Step 6 — Ariba Network transmits EDI 850

The Ariba Network receives the PO via API and transmits the EDI 850 Purchase Order to SupplierA's ERP. The complete EDI 850 document appears in §4 above — that is the exact document generated for this transaction.

Step 7 — SupplierA returns EDI 855 acknowledgment

Within 24 hours, SupplierA's system returns an EDI 855. Agent parses the ACK segment: IA (Item Accepted) for both line items. Order confirmed. The agent updates the PO record from "pending acknowledgment" to "confirmed."

Step 8 — Goods ship; 3-way match executes

SupplierA ships August 10. Buyer's warehouse logs goods receipt. SupplierA submits EDI 810 invoice via Ariba Network on August 11. Buyer's ERP runs the 3-way match: PO PO-2024-00042 + goods receipt timestamp + EDI 810 invoice. All three match within tolerance. Invoice cleared for payment.

Step 9 — CFO-agent evaluates early-payment discount

Net-30 payment due September 10. The 2/10 term offers 2% discount if paid by August 20. With cost of capital at 5% annually, 2% for 20 days ≈ 36.5% annualized return — well above cost of capital. CFO-agent approves early payment, fires EDI 820 with ACH transfer. Accounts receivable cycle closes on SupplierA's side; accounts payable cycle closes on BuyerCo's side.

SOC 2, ISO 27001, GDPR, HIPAA, and PCI DSS — the B2B compliance stack.

B2B procurement introduces a compliance surface area that consumer agent commerce largely avoids. Enterprise buyers have vendor risk management programs; a procurement agent that cannot produce compliance documentation will not clear vendor onboarding, regardless of how good its pricing is.

Eight architecture errors that kill B2B agent deployments before launch.

Mistake 1 — Using retail price data in B2B POs

A procurement agent that reads a public product page price and fires an EDI 850 at that number will receive either a corrected invoice or a PO rejection. The seller's ERP holds the contract-specific price and will override or reject any PO that does not match it. Fix: Always call get_quote with the buyer's account ID before constructing a PO. Never use MSRP or public catalog price for B2B PO pricing.

Mistake 2 — Ignoring MOQ (Minimum Order Quantity)

Ordering below MOQ results in automatic order rejection or a repriced invoice at a higher per-unit rate. Fix: Retrieve MOQ from the Purchasing Info Record (API_INFORECORD_PROCESS_SRV in SAP, or equivalent) at Layer 1. Include MOQ validation in the agent's pre-PO checklist. If the required quantity is below MOQ, the agent should either aggregate with other requisitions or escalate to a human buyer.

Mistake 3 — Firing a PO without credit terms established

The first PO with a new vendor will be held until credit terms are approved. If the agent fires the PO and then waits for credit approval, it introduces unexpected delays that can miss delivery windows. Fix: Call check_credit_terms before submit_po for any new vendor relationship. If no credit line exists, initiate a credit application first via Resolve, Balance, or Apruve.

Mistake 4 — Treating the buyer-agent as the payment authority

An agent that attempts to pay at order-submit (consumer UCP behavior) will either be blocked by the buyer's ERP or create a compliance violation if it bypasses the approval chain. Fix: Build the multi-step approval workflow explicitly into the UCP layer. The buyer-agent submits and tracks; the CFO-agent (or human) approves and pays. No payment fires without an approved PO on record.

Mistake 5 — Not checking EDI/cXML capability before Ariba Network enrollment

Suppliers that use EDI or cXML integration are automatically placed at Silver level ($750/yr) on Ariba Network, regardless of document count. A supplier expecting Bronze pricing ($50/yr) but integrating via EDI will face a $700/yr cost surprise on day one. Fix: Before choosing an integration method (EDI, cXML, API, or portal), calculate the Ariba fee schedule based on projected volume and integration method. Use Ariba's published fee calculator (re-verify before launch).

Mistake 6 — Skipping 3-way match before scheduling payment

Paying an invoice before confirming goods receipt and PO match creates risk of overpayment, duplicate payment, and audit findings. Fix: Build a 3-way match gate in the CFO-agent's approve_purchase logic: PO exists + goods receipt logged + invoice matches PO line items within tolerance. Only then schedule EDI 820 payment.

Mistake 7 — No SOC 2 attestation on the MCP server

Enterprise buyers will not route procurement traffic through an MCP server that cannot produce a SOC 2 Type II report or, at minimum, a completed vendor security questionnaire. Fix: Begin SOC 2 observation period before your first enterprise buyer conversation. Have a completed Vendor Security Assessment Questionnaire (VSAQ) ready for prospects who ask before Type II is complete.

Mistake 8 — Storing personal data in agent context beyond the transaction

Procurement records contain personal data — buyer names, email addresses, approval chain members. Retaining this data in agent context or logs beyond the necessary retention period creates GDPR/CCPA exposure. Fix: Define retention policies for agent logs and conversation history before go-live. Apply data minimization: store the minimum necessary fields. Implement a process for responding to data subject access and deletion requests.

Eight questions from operators building B2B agent procurement.

Making your B2B wholesale operation agent-ready — five steps.

Where to go next in the AgentMall stack.

B2B procurement is one of five vertical deep-dives in this batch. Cross-link to the hub for the full vertical survey, or drill into the protocol and capability layers that underpin this spoke.

Also in this series