November 12, 2024

Shutting down the portals

A return to reality in the world of AI

Back to the Present

Portals have long been the core feature of business buying solutions known as Procure-to-Pay (P2P) systems. In the 1990s, when IBM launched its first procurement solution, REQCAT, it used Lotus Notes to build an internal solution that streamlined procurement processes. This was the first buying portal of its kind.

The concept was to create an electronic catalog—or, more precisely, a series of catalogs and forms—that offered various products and services negotiated centrally, allowing for employee self-service.

Centralizing purchase requests was crucial to IBM’s standardization efforts, ensuring compliance with negotiated deals. REQCAT and the procurement team were even recognized and awarded for saving IBM in the 90s.

Since then, procurement applications have largely followed the same model. They feature catalogs and custom forms accessible via a buying portal, which centralizes employee purchase requests. These catalogs are provided by suppliers through their own portals in a format compatible with the buying portal.

Despite minimal changes on the buying side since the 90s, companies of all sizes have since developed their own e-commerce platforms, aiming to enhance customer experience, reduce sales costs, and reach a digital audience. As search engines became the starting point for consumer research, digital transformation surged, growing at a remarkable rate.

Today, over 40% of global B2B transactions are conducted digitally. E-commerce websites and marketplaces account for 90% of this, with annual growth rates of around 20%, far outpacing the 4% growth of overall global commerce. In contrast, Procure-to-Pay solutions, which represent just 10% of digital commerce, experience a slower growth rate of around 10%, unable to keep up with the e-commerce boom.

An Attempt to Escape the Portals: Punch-Outs

As sales organizations invested in e-commerce, tensions grew between buyers and sellers. Suppliers questioned why they needed to provide static catalogs for customer portals when the same information was readily available on their websites with a simple login. The answer: purchase control.

Under pressure, a new standard emerged: cXML (commerce eXtensible Markup Language). Developed by Ariba in 1999, the then-leader in P2P, cXML was designed to facilitate business document exchanges between procurement applications, e-commerce hubs, and suppliers. This compromise allowed buyers to maintain control over purchases while enabling suppliers to use their own web applications.

This integration allowed buyer portals to “punch out” to supplier websites and bring carts back for approval before sending purchase orders. This was a groundbreaking development.

Punch-Out Limitations

While PunchOuts have improved communication, they’ve mostly been adopted by larger suppliers due to high implementation and maintenance costs. Beyond costs, portals have failed to offer two essential components of any commerce transaction: real-time product availability and streamlined payment.

Would you buy anything on a website that doesn’t show order status? It’s often a deciding factor. P2P solutions, with or without PunchOuts, can’t handle this.

In P2P, requests or carts must first be approved in the buyer portal before being sent as purchase orders, often through the supplier’s portal. Once received, suppliers confirm the availability of each line item—a process now dubbed Supply Chain Collaboration. By the time the purchase order is acknowledged and shipment confirmed, the requester might no longer need the product or have bought it elsewhere.

Unlike consumer e-commerce, P2P solutions also fail to provide seamless payment. Suppliers must log into portals to “flip” purchase orders into invoices, which they must also enter into their systems to keep sales and accounts receivable up to date. On the buy side, accounts payable must reflect these purchases—a cumbersome process.

Game Over

If we were to start from scratch, would we design procurement applications as they are now? Wouldn’t we instead start with consumer experiences and add the necessary business requirements? What would such an application look like? Let’s build it together.

We all make purchases daily—from paying in stores with our phones to buying online with cards. For a similar experience in business, we’d likely need three things:

  1. Access to negotiated prices and products
  2. Purchase approval
  3. Accounting for payments and purchases

Access to Negotiated Prices and Products

Supplier e-commerce websites can offer custom catalogs for their customers, displaying only the selected products at negotiated prices. Access is usually provided via login credentials, the same used for punchouts. For secure credential sharing across the organization, a simple Single Sign-On (SSO) solution would work.

Purchase Approval

With AI’s advancements, it’s hard to imagine we can tackle complex challenges but not the purchase approval process. Enter AI-powered approval.

After selecting items from a company catalog and filling the cart, BlueBean appears at checkout, launching an approval process as soon as a payment card is requested. The system checks whether the purchase is from a preferred supplier, within budget, and policy-compliant.

This happens in seconds, eliminating the need to bring the cart back into a portal for extended reviews. If the purchase aligns with company parameters, approval is instant. Otherwise, the request is sent to the appropriate approver for a decision. Upon approval, the requester is redirected to the cart to complete payment.

Accounting for Payments and Purchases

After approval, suppliers can offer two payment options: invoicing or card payment. Processing stacks of invoices isn’t ideal for a modern organization—so why not pay by card?

For those concerned about payment terms and widespread card issuance, there’s good news. Many issuers offer credit terms even with charge cards like RAMP, allowing suppliers immediate payment while giving buyers 45-60 days to pay.

To avoid issuing physical cards to everyone, virtual single-use cards can be employed. These close after each purchase or are set to zero for subscriptions. Virtual cards offer native digital transactions, eliminating invoice scanning errors and enabling detailed, AI-powered expense tracking.

Closing portals doesn’t require “Stranger Things” magic—it’s just AI in action.