AI in the B2B customer portal: orders, invoices and reorders

A B2B customer portal is where a buyer goes after the purchase: to check order status and delivery dates, download invoices and credit notes, see what is left on a contract, and reorder what they bought last time. An AI agent in that portal answers those questions in plain language, but only from live account data fetched through tools, and only within what the signed-in user is allowed to see.

This article covers what the portal agent owns, why account data must come from tools and not from indexed text, per-user permissions inside a multi-user buyer account, the cache boundary for per-customer data, which questions deflect and which need a person, and the business case. Pre-sale help on the shop is a different problem, covered in AI support for B2B shops.

What does a portal agent own?

It owns the routine post-purchase questions: where is my order, when does it arrive, why is this invoice different from the order, is the credit note booked, what is left on the call-off, reorder the usual list, and is it in stock. A short list always goes to a person: disputes, contract changes, credit and goodwill decisions, and anything with legal weight.

Buyers ask for exactly this. In a Sana Commerce survey of 1,000 B2B buyers, 37% wanted order status, order history and outstanding invoices in the web store, and 40% wanted accurate stock, pricing and delivery dates (Digital Commerce 360, March 2024; vendor survey).

Reorders deserve special care because they are the action closest to revenue. The agent builds a cart from the order history, checks every line against current availability, replacements for discontinued items and the customer’s current price, and shows what changed since the last order. The user confirms the cart; the agent never places the order on its own. The same flow works for a recurring list, such as the monthly consumables order a site manager places every few weeks.

Where should the agent get account data from?

From the systems of record, through tools, at question time. The ERP or order management system owns orders, shipments, invoices and credit notes; the portal is a read layer with an API and a sync lag. Indexing account documents into a vector store and “answering from documents” fails here, because the answer that matters, today’s status, changes after indexing.

Invoice and credit-note questions show why. A credit note is the end of a chain, return order, RMA, disposition, credit note, inside the ERP, and between trading partners the same facts travel as EDI messages such as X12 810 invoices and 812 credit and debit adjustments. The agent explains an invoice by reading those records and linking the PDF, not by paraphrasing it. That matters more as invoices become structured data: in France, every VAT-registered business must be able to receive e-invoices through an approved platform from 1 September 2026, and large and mid-size companies must issue them from the same date (Service-Public.fr).

Be honest about freshness. Every answer that depends on a synced value should say when it was read and from which system, for example “status from the ERP, 10:42”. If the portal reads from a replica that lags the ERP by minutes, the agent should say so instead of presenting the value as live. Customers forgive a stated delay much more readily than a delivery date that turns out to be yesterday’s.

How do permissions work inside a buyer account?

A B2B account has many users with different scopes, and the agent must inherit exactly one user’s scope. Spryker’s company account model is a good worked example: business units, roles, and order visibility at three levels, own orders, business-unit orders or company orders (Spryker docs). Other platforms differ in detail, but the shape is common.

The vulnerable line is object access, not endpoint access. OWASP ranks Broken Object Level Authorization first in its 2023 API Top 10 and notes that comparing the session user to an id in the URL is not enough; every endpoint that receives an object id must check that this user may access that object (OWASP API1:2023). An agent makes this worse, because it will happily try ids it saw in a pasted email. Put the check inside each tool:

// Object-level check inside the tool (sketch): endpoint access is not object access
async function getInvoice(user: PortalUser, invoiceNo: string) {
  const invoice = await erp.invoices.get(invoiceNo, { onBehalfOf: user.id })
  if (!invoice) return { ok: false, error: 'NOT_FOUND' }

  const allowed =
    (user.scope === 'own' && invoice.orderedBy === user.id) ||
    (user.scope === 'business-unit' && invoice.businessUnit === user.businessUnit) ||
    (user.scope === 'company' && invoice.companyId === user.companyId)

  // same answer for "missing" and "not yours", so ids cannot be probed
  if (!allowed) return { ok: false, error: 'NOT_FOUND' }
  return { ok: true, invoice: pick(invoice, ['number', 'date', 'total', 'currency', 'status', 'pdfUrl']) }
}

The agent never runs as a service account with rights over every customer. If the tools are exposed over MCP, the current authorization specification, revision 2026-07-28, describes the pattern: OAuth 2.1, resource indicators so a token is bound to one server, minimal scopes with step-up on insufficient_scope, and explicit confused-deputy protections (MCP). The retrieval-side version of the same rule is in access control for RAG.

Buyer accounts also carry approval rules: order budgets per user, cost centers, and orders above a limit that need a second person in the buyer’s company. The agent must respect those rules exactly as the web store does, by calling the same checkout and approval services rather than reimplementing them. A reorder that skips the buyer’s own approval step is a failure even if every price and quantity is correct.

What may be cached in a B2B portal?

Only what is identical for every customer. RFC 9111 says a shared cache must not reuse a response to a request with an Authorization header unless a response directive explicitly allows it, and defines private for responses meant for one user (RFC 9111). In a portal, prices, customer stock, orders, invoices and call-off balances are per customer by definition.

Headers are not enough on their own. Web cache deception tricks caches into storing private dynamic responses by exploiting differences in how the cache and the origin parse paths; PortSwigger’s prevention advice is to mark dynamic responses no-store or private and make sure CDN rules do not override Cache-Control (PortSwigger). In a Nuxt front end, route rules make the split explicit:

// nuxt.config.ts (sketch): shareable catalog vs never-shared account data
export default defineNuxtConfig({
  routeRules: {
    '/catalog/**': { swr: 600 },                                         // same for every customer
    '/account/**': { headers: { 'cache-control': 'private, no-store' } },  // orders, invoices, prices
    '/api/account/**': { headers: { 'cache-control': 'private, no-store' } },
  },
})

Which questions can the agent close, and which need a person?

Decide per question class, not for the portal as a whole. Gartner’s survey of 5,728 customers found that only 14% of service issues are fully resolved in self-service, and only 36% even for very simple issues; 43% of failures came from not finding relevant content (Gartner, Aug 2024). An agent with live tools can fix the “could not find it” part; the rest stays with people.

When a question goes to a person, the handoff should carry the work already done: the user, the account, the objects the agent looked up and what it found, so the customer does not repeat the story. ContactBabel reports that 52% of businesses say customers call because they could not find the self-service function at all (ContactBabel); a visible, well-prepared handoff is part of the self-service design, not an admission of failure.

What is a portal agent worth?

It is worth lower cost per contact on frequent, simple questions and faster, error-free reorders. No audited uplift for B2B portal agents has been published, so the case uses cost-per-contact data, buyer preferences and per-account instrumentation.

• Cost per contact: ContactBabel’s self-service guide, updated December 2025, puts a typical web self-service session under 10p or 15 cents against £6.25 or $7.16 per phone interaction (ContactBabel). These are UK and US contact-center averages, not B2B-specific.
• Reorders: 79% of B2B buyers in Sana Commerce’s survey prefer to place repeat orders online, yet they report errors on 33% of online orders, 68% are discouraged by such mistakes and 74% would switch suppliers for a better web store (vendor survey, March 2024).
• Digital share: McKinsey’s 2026 B2B Pulse reports that 71% of B2B companies now sell online and roughly one-third of revenue flows through digital channels (McKinsey, May 2026).

For a head of e-commerce or customer service, the four numbers to instrument per account are deflection by question class, reorder rate from history, portal adoption and contacts per order. I build this layer, permissions, caching and the Nuxt front end, on B2B commerce stacks such as Spryker and Pimcore, and I run LLM features on my own Nuxt site; the same boundaries apply at both scales.

When should you not build a portal agent?

Do not build one when ERP data is unreliable, when invoices exist only as scans without a structured source, when nobody owns a permission matrix that can be enforced and tested, or when there is no audit log. With low order volume, good search and a visible phone number beat an agent. And avoid deflection theater: if the headline metric counts assumed resolution, it will look better than reality.

Multi-entity and multi-language portals add one more condition: every locale and legal entity needs an owner who checks what the agent says about invoices, taxes and delivery terms in that market. Without owners per locale, wait.

A checklist for a portal agent

1. Write the permission matrix as code and test it with own, business-unit and company users.
2. Check object-level access inside every tool and return the same error for missing and forbidden objects.
3. Test cache headers on every authenticated route, including CDN rules; I drive these checks with Playwright MCP.
4. Return identifiers such as order and invoice numbers verbatim from tools, never from the model.
5. Link the real invoice or credit-note PDF in every document answer.
6. Map escalation per question class and keep the human option visible on every screen.
7. Write metric definitions before launch, with confirmed and assumed resolution separate.
8. Keep an audit trail of every tool call with user, object and result.

A pilot on one question class, order status or invoices, with a defined exit criterion is the honest way to start. If you want help with the permission model, the cache boundary or the tool layer, see my B2B e-commerce work.

Sources

1. Gartner: only 14% of customer service issues are fully resolved in self-service (19 Aug 2024)
2. ContactBabel: The Inner Circle Guide to Self-Service (updated Dec 2025)
3. McKinsey: The surprising economics of B2B growth (B2B Pulse 2026)
4. Digital Commerce 360: Sana Commerce survey on B2B online ordering errors (11 Mar 2024)
5. OWASP API Security Top 10 2023: API1 Broken Object Level Authorization
6. RFC 9111: HTTP Caching
7. PortSwigger Web Security Academy: Web cache deception
8. Model Context Protocol: Authorization (revision 2026-07-28)
9. Spryker: company user roles and permissions
10. Fortune: Klarna brings humans back to customer service (9 May 2025)
11. Fin by Intercom: reporting metrics and resolution definitions
12. Service-Public.fr: electronic invoicing reform, 1 September 2026