SAP Already Knows When Orders Can Ship. Why Are Customers Still Calling?

SAP ATP (Available to Promise) is SAP’s availability check. It tells what the business can actually commit to for a specific material, plant, quantity, and requested date by evaluating relevant stock, receipts, and issues within a configured scope of check—not just today’s on-hand inventory.

In B2B self-service portals and eCommerce, ATP is what makes availability credible online: buyers care about a shippable quantity and a believable date. As more buying journeys become rep-free in 2026, those answers need to be fast, consistent, and explainable.

What SAP ATP is

In SAP, ATP commonly refers to the availability check logic that determines whether requirements can be covered by stock or planned receipts, and when.

Conceptually, ATP is an order promising capability. It uses rule driven inclusion and exclusion of stock, receipts, and issues to compute what is actually promiseable for a requested date, then returns confirmed quantities and dates that can flow into order scheduling.

For a deeper breakdown on ATP in SAP, check out our blog here.

What is different about ATP in 2026

Customer expectations for instant answers

By 2026, buyer expectation in many B2B segments is that basic ordering questions are answered immediately during browsing and checkout.

That expectation does not stop at price and contract terms. It extends to:

• Can it ship
• When
• How much

More volatility (allocations, partial confirmations, constrained supply)

Volatility shows up as frequent reschedules, allocations, partial confirmations, substitutions, and backorders.

These are not corner cases anymore. They are the cases that drive customer frustration if the portal experience is built on a simplistic “inventory equals availability” assumption.

The concept that causes most online availability problems: scope of check

The key SAP concept is the scope of the availability check.

SAP defines scope via configuration and master data, particularly the pairing of:

• Checking group (typically maintained in the material master)
• Checking rule (typically maintained in configuration)

That pairing determines which stocks, receipts, and issues are considered. Two screens can both “show availability” and still answer different questions if they use different checking rules or include different MRP elements.

Manufacturing flavored example

A plant may have 500 units physically in unrestricted stock today. The same SKU may also have open sales orders, production orders, reservations, stock transfers, or planned receipts that SAP considers within the chosen scope of check.

SAP’s ATP check can be configured to consider these MRP elements, so the promiseable quantity for next week can be far less than 500 even though the warehouse count is unchanged.

Best practices for handling ATP in SAP

The goal is not more ATP complexity. It is disciplined ATP that is explainable, performant, and consistent across channels.

Best practices checklist

• Treat scope of check as a published contract. Document which stocks, receipts, and issues are included for each scenario, and align the portal’s ATP checks to the same checking group plus checking rule combination used for order confirmation.
• Standardize the checking rule used by external channels. If the portal and Customer Service use different checking rules, the same SKU can return different promise dates and quantities, creating reconciliation work and disputes.
• Make lead time governance non optional. Availability dates depend on maintained lead times (including replenishment lead time where used, and fallbacks like in house production time or planned delivery time). Assign owners, review cadence, and exception reporting.
• Use allocation intentionally when supply is constrained. If limited supply is distributed by customer, region, or channel, model it with governed allocation logic instead of manual overrides so the portal does not promise what the business will not honor.
• Separate browse signals from checkout confirmation. Show indicative availability during browsing, but run an authoritative ATP check at checkout and place the order immediately after so the promise the buyer sees matches what SAP will confirm.
• Design for partials and staged dates. ATP confirmations can split quantities and dates (schedule line behavior). Portal UX and integration should support partial confirmations instead of forcing a single number and single date.
• Make ATP results auditable. Log key inputs and outputs for external checks (material, plant, requested quantity and date, ship to context, rule intent, returned confirmation) so disputes are explainable and fixes are data driven.

How manufacturers expose ATP in B2B portals and ecommerce

There is no universally correct pattern. A few patterns recur because they map cleanly to user expectations and SAP realities.

Pattern A: Show “available now” only

When it fits: High volume MTS items with stable supply, low variability, and short lead times. Also useful when availability is mostly a warehouse question rather than a production question.

Risks: “Available now” can be misread as “guaranteed.” If the portal is reading a simplified stock number, it may diverge from the promiseable quantity computed by ATP scope rules.

UX guidance: Use language that states what is being shown, such as “Available to ship from stock,” and validate at checkout.

Pattern B: Show “available now” plus “next availability date”

When it fits: Mixed MTS and replenishment environments where backorders are normal but lead times are reasonably predictable.

Risks: The “next date” can be sensitive to lead time maintenance and replenishment lead time settings. If lead times are poorly governed, the portal will communicate incorrect expectations.

UX guidance: Display two numbers, available now and available by date, and add a short note for manufactured items indicating dates are subject to confirmation at order placement.

Pattern C: Show date ranges or tiered availability

When it fits: Constrained supply, long lead times, frequent rescheduling, or MTO products where exact dates are less credible until the order is created.

Risks: Too much nuance can confuse buyers and raise support load.

UX guidance: Provide a small set of tiers, such as “Ships in 1 to 3 days,” “Ships in 1 to 2 weeks,” “Ships in 3 to 5 weeks,” backed by an ATP rule set and refreshed periodically. Still run a true ATP check at checkout to generate exact confirmations.

Pattern D: Show availability by ship to, plant, or DC logic

When it fits: Multiple plants, regional DCs, dealer networks, ship to specific constraints. Common when freight policy or hazardous material constraints limit sourcing options.

Risks: The same SKU can have different availability by plant. Users will see contradictory answers if the UI does not make plant or DC context visible. Using the wrong plant in portal calls is a classic integration defect.

UX guidance: Make ship to location explicit (“Availability for Ship To X”) and provide a change ship to control. Silent defaulting is a support ticket generator.

Pattern E: Role based visibility (dealer vs customer vs internal)

When it fits: Tiered channels where internal users need deeper detail, dealers may have allocations, and end customers should see a simpler promise.

Risks: If role based logic is implemented only in the portal and not aligned to underlying promise rules, it becomes unauditable and inconsistent.

UX guidance: Use role based views to change display detail, not to invent separate promise math. Internal roles can see schedule line style breakdowns while external roles see summarized tiers.

Architectural tradeoffs worth stating plainly

Real time ATP is the gold standard for self service ordering because it keeps the portal’s promise aligned with what SAP will actually confirm at order creation.

The tradeoff is not that real time is too slow. The tradeoff is that naive implementations make too many calls in the wrong moments.

Real time becomes expensive when availability is calculated per SKU, per row, per scroll.
Real time becomes practical when checks are batched, triggered by intent, and scoped to the smallest meaningful set of products and ship to contexts.

Cached or staged availability is a compromise, not a shortcut. It can be acceptable for browse flows, but it must be governed with explicit freshness windows and a final authoritative check at checkout.

The portal should not simulate ATP with its own math. If the portal calculates availability independently, it will drift from SAP’s checking rules, product allocation behavior, and lead time settings, especially under volatility.

The hard part: setting expectations in the UI

The goal is not to expose everything SAP knows. The goal is to expose what a buyer needs to make a decision while keeping promises credible.

What to display: numbers, dates, or ranges

• Use a number when supply is stable and confirmations rarely split.
• Use dates when the business can reliably commit to a ship date.
• Use ranges when variability is high or the product is make to order.

SAP schedule lines can represent partial deliveries across dates and quantities. If the UI insists on one date, it will hide partial confirmation reality and push complexity into customer service.

Language that reduces support tickets

• “Available to ship” rather than “in stock” if the promise is based on ATP
• “Estimated ship date” when the business uses lead time based confirmations
• “Confirmed at checkout” when browse uses near real time data
• Avoid “guaranteed” unless inventory is intentionally reserved or a hard commit is enforced at quote time

When to show “call to confirm” vs when to commit

“Call to confirm” should be reserved for cases where the portal cannot credibly compute a promise, such as engineered to order products, highly configured assemblies, or constraints outside the modeled scope.

Overusing “call to confirm” defeats self service.

A more constructive compromise is request a quote for MTO and complex products, and commit at checkout for standard catalog items.

The framework that matters online: ATP accuracy vs ATP access

Most manufacturers invest in ATP accuracy and stop there.

Online ordering exposes the second half:

ATP accuracy is whether SAP can produce a credible promise result.
ATP access is whether the buyer can retrieve that promise result at the moment of ordering.

If ATP is not accessible in the channel where orders are placed, customers keep calling.

The next step: make SAP the only answer

Most ATP problems are not really ATP problems. They are channel problems: one set of rules in SAP, a different representation online, and a steady drip of exceptions when the two do not match.

The cleanest next step is to stop maintaining a parallel availability story and let SAP be the single source of promise in the customer experience.

That is the lane Corevist plays in: an SAP native self service portal that surfaces ATP, along with pricing and order status, directly from ECC or S 4HANA in real time. The point is not “more data.” The point is fewer mismatches, fewer reconciliations, and fewer touches for teams that currently have to explain why the website and SAP disagree.

First published Nov 16, 2023. Last updated Feb 5, 2026.

Definition: What is SAP ATP?

SAP ATP (Available to promise) is a real-time availability check in SAP SD and S/4HANA that determines whether a requested product quantity can be confirmed for delivery on a specific date. It evaluates current stock, planned receipts, and existing commitments to provide an accurate order confirmation.

In simple terms, ATP tells you: Can I fulfill this order, how much can I deliver, and when?

SAP ATP in 60 Seconds

• Definition: ATP (Available-to-Promise) is an availability check that confirms whether an order can be fulfilled based on current and future inventory.
• Where it’s used: Sales orders, delivery processing, and order fulfillment workflows in SAP SD and S/4HANA.
• Why it matters: It prevents over-promising, improves customer satisfaction, and ensures accurate delivery dates.

What an ATP check evaluates:

• Current stock
• Planned receipts (purchase orders / production orders)
• Existing commitments (sales orders / reservations)

Result: A confirmed quantity and delivery date, reflected in SAP as a schedule line confirmation.

SAP ATP Examples

Scenario 1: Order Quantity Exceeds Available Stock

• Customer order = 50 units
• Available stock (ATP) = 10 units
• Remaining quantity = 40 units

ATP Check Result:

• 10 units confirmed for immediate delivery
• 40 units confirmed for a future date based on planned receipts and lead times

Scenario 2: No Stock Available, Future Supply Exists

• Customer order = 200 units
• Current stock = 0
• Planned production = 200 units in 10 days

ATP Check Result:

• 0 units confirmed today
• 200 units confirmed for delivery in 10 days

In SAP, these confirmations are reflected in schedule lines, which define the confirmed quantities and delivery dates for each order.

SAP ATP Best Practices

• Use the correct ATP check configuration
  (check group and check rule) to align with your business processes
• Ensure inventory data accuracy
  across stock, receipts, and reservations
• Regularly review backorder processing
  to reallocate inventory efficiently
• Monitor schedule line confirmations
  to manage partial deliveries and customer expectations
• Avoid over-customization that breaks standard
  ATP logic and increases maintenance complexity
• Align ATP behavior with customer service goals
  (lead times, partial shipments, delivery commitments)
• Leverage S/4HANA ATP (aATP) for advanced capabilities like product allocation and supply protection

SAP ATP FAQs

SAP ATP is a powerful availability check and calculation, and its exact form will be unique to your ERP system.

SAP ATP requires you to model your entire supply chain and manufacturing process so the ATP check can accurately evaluate availability. Your SAP ERP system has to re-run the calculations of that model every time you get an order, in the context of all the orders that you have. It’s phenomenal to think about how SAP ATP calculation works.

The B2B industry is already struggling with the tradeoffs associated with “never say no.” That commitment means you have to have inventory, which costs money—and potentially, inventory can go obsolete.

SAP ATP allows a manufacturer to stay as lean as possible. It also forces the manufacturer to rethink any factors that aren’t supporting lean and just-in-time manufacturing.

How does SAP calculate available to promise?

Your ERP system uses a highly complex formula to perform an ATP availability check and calculate available-to-promise quantities. This formula takes many factors into account, including:

• All outstanding purchase orders to suppliers for parts and/or ingredients of the finished product.
• The manufacturing cycle time, how long it takes to convert inbound supplies to a product that’s available to promise to a customer.
• How you allocate product to competing customers.

Should all customers see the same SAP ATP calculation for a product?

This is a great question, and there’s no right answer. Every company (and every customer of that company) is different. This can become an issue in e-commerce if your SAP ATP calculation isn’t built to model smart management practices.

For example, it might seem like a good idea to show the same available-to-promise figure to every customer. But what if you sell out of the product before your biggest customer can put their quarterly order in? That’s not smart management. Better to make your smaller customer wait, rather than risk upsetting your biggest spender.

Luckily, there are strategies and technology available for manufacturers who need to hold back when there’s limited inventory. The key is to understand your customer landscape and use the tools at your disposal to allocate product to the highest-value customers first, often through ATP allocation logic and backorder processing.

How do different companies handle SAP ATP calculations?

Every company has different needs when it comes to SAP ATP. For example, in the B2C sector, Amazon has developed an interesting workaround for the available-to-promise problem. They show the inventory for all their products as, “Usually ships in X days,” instead of exposing a precise ATP confirmation. That could be 1 day, 3-5 days, or something similar. “Usually” is the key word here. It has all kinds of contingency baked into it. The whole phrase, “usually ships in X days,” is a euphemism for, “the product is in inventory (or we can get it quickly), we are going to promise it to you, but we reserve the right to send you a follow-up email saying that we couldn’t get it to you on time and it will be delayed.”

In the B2B sector, one of our clients takes a different approach. Their SAP B2B e-commerce website says, “Order by 5 today, and you’ll get it tomorrow.” The company carries everything in inventory. Of course, this model comes with its own challenges. The company can only fulfill their delivery promise about 85% of the time. But they’ve committed to this model for larger reasons that make sense in their industry, and they’re always trying to get that number to 90, 92, 93%.

In other words, they’re using available to promise to drive their customer service excellence.

What SAP ATP configuration is right for my company?

As you can tell by now, available to promise configuration is totally dependent on your industry, your company, your products, and your customers. It’s helpful to think of SAP ATP configurations as falling on a spectrum.

For instance, brick-and-mortar retail provides us with one extreme on the spectrum. If you’re shopping for a pair of jeans in your size and the retailer doesn’t have that size in stock, you don’t buy them that day, and the store doesn’t get the sale. That’s lost revenue. You’re not going to sit at the register and say, those are the pants that I want. When they come in, call me and I’ll buy them. Available to promise is useless to you because you want your jeans now!

There is one exception to this rule in B2C—the product that is very unique. The further away the product is from a commodity, the more the consumer is willing to endure what is ultimately the far end of this spectrum: the dreaded black hole of “backordered.”

Somewhere between the two extremes, between “in inventory” and “backordered,” you have available to promise. SAP ATP helps you strike that balance between fulfilling customer expectations and working with the reality of your supply chain.

How does SAP ATP affect eCommerce sales?

Generally speaking, the more accurate your SAP ATP calculation is, the better that product will perform in ecommerce, since the web store tells customers exactly what to expect. This matters more than it used to: McKinsey’s latest B2B Pulse Survey notes that for B2B companies offering digital commerce, online channels now account for more than one-third of total revenue, which means inaccuracies in things like available-to-promise no longer just create operational headaches, they directly affect buying behavior at scale. That’s why it’s important to display accurate ATP confirmations in ecommerce. In Corevist Commerce Cloud, we provide functionality that performs a real-time ATP availability check to surface accurate availability and pricing without placing an order.

In some industries, this SAP ATP calculation is critical to closing the sale. If the customer doesn’t get a good answer, he or she will go somewhere else to buy it—especially if the product is highly commoditized. Here, lack of ATP in ecommerce can create friction for your customers. It could even cost you the sale.

Whenever we implement a new e-commerce website, we have many discussions with our client. We ask a thorough set of questions to help our client think through their policy for SAP ATP in ecommerce. The questions include:

• What are you going to do about inventory? Show it? Hide it? Give actual quantities that are in inventory? Give visual signals like green/yellow/red to give qualitative information about inventory?
• Can you run SAP ATP checks in SAP, and if so, do you want to display ATP confirmations in ecommerce? And if you want to display it, do you want to break up a line item into the various SAP ATP quantities and dates?
• If SAP can’t come up with a calculation for ATP and the product goes on backlog, do you want to take that order or not? And what message do you want to give your customer?

How do shifting tariff policies affect ATP?

Shifting tariff policies have made supply and replenishment less predictable for many manufacturers. In 2025, the effective U.S. tariff rate climbed into the high-teens, reaching levels not seen in decades after years of relatively low duties. Those changes affect where materials are sourced, how quickly they can be replenished, and how much inventory manufacturers are willing to hold. As a result, available-to-promise increasingly reflects more than what is physically on hand. In practice, manufacturers often cap the quantity that is promisable, prioritize certain customers or contracts directly within ATP, and avoid committing inventory tied to uncertain or higher-cost replenishment. When ATP logic doesn’t reflect those constraints, manufacturers are more likely to over-promise, expedite at a loss, or rely on manual intervention to protect key customer relationships.

What if I can’t provide an ATP date from SAP?

Different industries will handle the lack of an SAP ATP date in different ways. For example, one of our clients sells soda ash to farmers as a supplement for cows. If a factory goes down for a week, due to an explosion, it doesn’t produce any inventory. What happens if a farmer logs in to the website, in desperate need of soda ash, and sees no inventory available to promise? It’s a frustrating and stressful moment for the farmer. He needs a truckload this week. The product is backlogged, and the manufacturer doesn’t know when it will be available? What’s the farmer supposed to do?

If you can’t provide an available to promise date, the key is to communicate the situation with a friendly message. When your SAP-integrated ecommerce website senses that an ATP isn’t available in SAP, you can display a message that says, “Please call your Customer Service Representative for details about this product.”

Here’s another example of why SAP ATP matters in ecommerce. Some of our clients have multiple warehouses. They anticipate that at times, the customer’s “facing plant” may not have the required inventory. In that case, we serially check multiple plants and provide the customer with choices as to what he would like to do. This is a complex topic unto itself, and we covered it in this post–Multiple Line Items from Multiple Warehouses.

The factory explosion is a true story. In this case, our client chose to ship from another factory at their own expense. This helped our client maintain important customer relationships. The client showed dedication to the customer, showing that they understood the urgency of the need.

Team Members from Corevist Attend SAP BTP Partner Meetup: Insights and Implications for B2B E-Commerce

Recently, team members from Corevist attended the SAP BTP Partner Meetup, and the experience was a stark reminder of the transformative changes reshaping the SAP ecosystem. Having worked closely with SAP solutions for over a decade, our team has witnessed many shifts in strategy. However, the discussions at this meeting marked a true paradigm shift—one that manufacturers leveraging B2B e-commerce must embrace to stay competitive.

During the “Building and Certifying” session, a key takeaway was the importance of adopting a clean core approach during upgrades to S/4HANA. This approach is not just a guideline; it’s a critical mandate for businesses to transform their homegrown applications into clean core-compliant solutions. Here’s what this means for B2B e-commerce and how we can turn these challenges into opportunities.

The Clean Core Mandate: What It Means for B2B E-Commerce

The emphasis on clean core transformations, as part of the S/4HANA upgrade, is reshaping how businesses approach their IT ecosystems. Legacy e-commerce portals, custom IDOC integrations, and batch-loaded order systems are no longer viable without significant modifications. The upgrade to S/4HANA represents a fundamental overhaul of critical systems to ensure compliance.

Our team continually asked: How will manufacturers scale their e-commerce operations while adhering to this clean core mandate?

The Challenges and Opportunities

Challenge 1: The Resource-Intensive Upgrade Effort

For CIOs and upgrade sponsors, the complexity of revisiting homegrown systems is daunting. Yet, SAP’s Business Accelerator Hub offers a glimmer of hope—a repository of pre-certified, clean core extensions that minimize the heavy lifting. Solutions like Corevist (coming soon to the Accelerator Hub), with pre-built integration capabilities, enable manufacturers to bypass much of the reinvention process and focus on growth.

Challenge 2: Keeping Pace with SAP’s Roadmap

One striking insight from the event was realizing how many SAP customers have yet to transition to SAP S/4HANA. This highlights the scale of the opportunity for clean core transformation. The path forward is clear: while many companies delay the transition, most will ultimately comply. For B2B e-commerce, this delay offers a window of opportunity to adopt clean core-compliant platforms and lead in scalability and innovation.

Opportunity: Reframing Your E-Commerce Strategy

This transition is not just a challenge; it’s an opportunity to rethink your e-commerce strategy. By adopting clean core solutions like Corevist’s B2B e-commerce platform, businesses can:

• Ensure seamless integration with SAP S/4HANA.
• Reduce operational friction.
• Deliver superior customer experiences that drive loyalty and growth.

The Role of SAP BTP in Scaling B2B E-Commerce

SAP Business Technology Platform (BTP) emerged as a critical enabler of agility and scalability during the Partner Meetup. The platform provides the tools manufacturers need to integrate their e-commerce operations with real-time data analytics, AI-driven efficiencies, and extensibility.

Untapped Potential in BTP Credits

In discussions with SAP leaders, it became clear that many customers can significantly leverage their BTP credits as part of their Grow packages. These credits are vital in enabling manufacturers to expand and innovate their e-commerce capabilities without incurring additional costs.

Maximizing ROI Beyond Upgrades

A clean core e-commerce extension not only simplifies the upgrade process but also delivers ongoing value. By integrating with S/4HANA, businesses can unlock efficiencies, reduce time-to-market, and foster innovation cycles that drive long-term ROI.

Real-World Application: A Use Case for Manufacturers

Consider a manufacturer in the chemical industry transitioning from a legacy portal to a clean core-compliant e-commerce platform. By adopting Corevist’s solution, they achieve:

• Streamlined migration: A certified extension minimizes effort and risk.
• Enhanced customer experience: Real-time integration with SAP ensures accurate order data and personalized service.
• Global scalability: Support for multilingual, multi-currency environments aligns with global operations.

This case highlights how clean core strategies can turn challenges into opportunities for innovation and growth.

Embracing the Future of B2B E-Commerce

Reflecting on the insights from the Partner Meetup, it’s clear that scaling B2B e-commerce in today’s SAP-driven landscape requires a proactive approach. Clean core compliance is more than a technical requirement; it’s a strategic advantage that ensures scalability, agility, and innovation.

At Corevist, we’re committed to helping manufacturers navigate this transformation. By leveraging SAP BTP and adopting certified clean core solutions, businesses can future-proof their e-commerce operations and deliver unparalleled value to their customers.

Are you ready to scale your B2B e-commerce strategy for the future? Let’s start the conversation.

For manufacturers embarking on their journey to SAP S/4HANA Public Cloud, the need for robust e-commerce integrations has never been more critical. As the backbone of your digital transformation, SAP S/4HANA enables real-time insights and operational efficiency—but how do you connect your e-commerce platform to unlock these benefits?

Historically, manufacturers relied on SAP Process Integration (PI) and Process Orchestration (PO) to bridge systems. However, with SAP announcing the end of mainstream maintenance for PI/PO in 2027 (with extended support only until 2030), manufacturers moving to S/4HANA Public Cloud must shift their focus to SAP Integration Suite, a cloud-native platform designed for modern, scalable integration.

In this post, we’ll compare PI/PO and SAP Integration Suite, exploring why the latter is the future-proof choice for manufacturers adopting S/4HANA Public Cloud and scaling their e-commerce operations.

Why Manufacturers Need to Rethink PI/PO

SAP PI/PO has served manufacturers well for decades, offering centralized integration for on-premises systems. While reliable, its architecture was designed for legacy environments.

Key Limitations of PI/PO in Today’s Context:

• On-Premises Focus: Difficult to support hybrid cloud or fully cloud-based ecosystems like SAP S/4HANA Public Cloud.
• Batch Processing: Limited capabilities for real-time, event-driven e-commerce scenarios.
• End-of-Maintenance Risks: Mainstream support ends in 2027, making PI/PO costly and risky to maintain.

For manufacturers moving to S/4HANA Public Cloud, the need for agile, scalable integrations far exceeds what PI/PO can deliver.

The Rise of SAP Integration Suite for E-Commerce

SAP Integration Suite, part of SAP Business Technology Platform (BTP), is designed for modern integration needs. It enables seamless connectivity between cloud, on-premises, and hybrid environments, making it the ideal solution for manufacturers moving to S/4HANA Public Cloud and looking to scale their e-commerce platforms.

Core Benefits of SAP Integration Suite:

• Cloud-Native Design: Fully aligned with S/4HANA Public Cloud’s architecture.
• Real-Time Integration: Supports event-driven architecture for instantaneous data updates between e-commerce and ERP.
• Prebuilt Content: Includes integration packages for SAP S/4HANA and leading e-commerce platforms, accelerating time-to-value.
• API Management: Offers comprehensive tools for designing, monitoring, and securing APIs—essential for modern e-commerce operations.

Key Differences: PI/PO vs. SAP Integration Suite

Feature	SAP PI/PO	SAP Integration Suite
Deployment	On-premises only	Cloud-native, hybrid-ready
Integration Speed	Batch processing	Real-time, event-driven
API Management	Limited	Advanced API design and monitoring
Prebuilt Integrations	Few, often custom-built	Extensive library tailored for SAP systems
Scalability	Hardware-limited	Dynamic cloud scalability
Future-Readiness	End-of-life by 2030	Continuous innovation, SAP-supported

Why Integration Suite is Critical for Manufacturers Moving to S/4HANA Public Cloud

As manufacturers adopt S/4HANA Public Cloud, integration challenges become more complex. E-commerce platforms must not only exchange real-time data with ERP systems but also scale with evolving customer demands. Here’s why Integration Suite stands out:

1. Real-Time Data for Seamless Customer Experience

E-commerce success depends on real-time inventory updates, pricing accuracy, and order confirmations. Integration Suite’s event-driven architecture ensures instant communication between your e-commerce platform and SAP S/4HANA, keeping customers informed and satisfied.

2. Cloud-Native Alignment with S/4HANA Public Cloud

Unlike PI/PO, Integration Suite is purpose-built for the cloud. It supports SAP BTP’s vision of connected, scalable systems, ensuring a smooth transition for manufacturers adopting S/4HANA Public Cloud.

3. Accelerated Deployment with Prebuilt Integrations

SAP Integration Suite includes prebuilt content for common e-commerce use cases. This reduces the time and effort required to integrate S/4HANA with your platform, allowing you to achieve ROI faster.

4. Scalable for Growth

With cloud scalability, Integration Suite can handle increasing transaction volumes and new system integrations, giving manufacturers the flexibility to grow their e-commerce operations without rearchitecting integrations.

5. Unified API Management for E-Commerce Ecosystems

Manufacturers often use multiple systems—e-commerce platforms, customer portals, and third-party tools. Integration Suite’s API management capabilities simplify connecting these systems, ensuring consistent performance and security.

The Cost of Delaying Migration

Relying on PI/PO while moving to S/4HANA Public Cloud carries significant risks:

• Operational Delays: Incompatible systems can disrupt order processing and customer experience.
• Increased Costs: Extended PI/PO maintenance is costly, and resolving integration issues often outweighs migration costs.
• Missed Opportunities: Delayed adoption of Integration Suite may prevent manufacturers from leveraging the full potential of S/4HANA and e-commerce.

Preparing Your Business for the Transition

1. Evaluate Current Integrations: Assess which PI/PO integrations are critical for e-commerce and prioritize them for migration.
2. Adopt a Phased Approach: Implement Integration Suite for new projects (e.g., S/4HANA and e-commerce) while gradually migrating existing integrations.
3. Leverage SAP BTP Partners: Work with experienced SAP systems integrators like Mouri Tech to streamline the transition and optimize for your specific needs.

Build Your E-Commerce Strategy on a Future-Ready Platform

For manufacturers adopting S/4HANA Public Cloud, the transition to SAP Integration Suite is more than a technical upgrade—it’s a strategic investment in scalability, agility, and customer experience. By enabling seamless e-commerce integrations, Integration Suite ensures your digital transformation aligns with modern business demands.

SAP recently announced that SAP Commerce, their on-premises commerce platform, is now end-of-life. The final release of SAP Commerce, version 2205, will reach End of Mainstream Maintenance (EoMM) July 31, 2026.

This isn’t too surprising, given SAP’s emphasis on the cloud. Between S/4HANA and SAP Commerce Cloud, the company has set a clear direction for their offerings.

Yet for organizations using SAP Commerce, it’s time to evaluate commerce strategy—both short-term and long-term. Here are the main things to consider.

The opportunity for SAP Commerce customers

No one likes getting that EoMM notification. But for many organizations, there’s actually a silver lining in this cloud.  Now that you have to make a decision, you can take the opportunity to reevaluate your needs and what the market offers in terms of commerce platforms. Commerce has evolved significantly since the days when the on-premises approach was the only way. You may find that there are numerous options that will serve your business better.

In fact, the sunsetting of SAP Commerce offers an opportunity to modernize your commerce program in two main areas:

• Infrastructure
• Customer experience

Let’s talk about those.

Infrastructure: Is it time to move to the cloud?

No doubt about it, an on-premises commerce solution offers total control. But with that control comes great responsibility—and cost. SAP Commerce customers are well aware that the solution requires full-time resources to maintain the entire stack.

For many organizations, a cloud-based approach actually serves the business better. You relinquish control over things that aren’t worth controlling, which reduces cost, risk, and technical debt.

So what do you gain when you move to the cloud?

Quite a bit, actually.

A SaaS (software as a service) solution ensures you’re always on the latest version, always secure, and always receiving new features and functionality. You can say goodbye to the days of backward-compatibility checks, broken customizations, and everything that made the on-premises approach so challenging. 

Customer experience: Getting more bang for less buck

Simply put, out-of-the-box cloud solutions are often cheaper than on-premises alternatives—not to mention more feature-rich. You don’t have to build custom features to serve your customers. Instead, a robust cloud platform will include built-in functionality that can be configured to meet your customers’ needs.

Configuring is always cheaper than building. Ultimately, that helps you create a better customer experience faster and at a lower cost.

The platform provider makes this possible by monitoring emerging industry trends and buyer preferences. The provider works constantly to build and launch new features and capabilities in the platform—specifically to stay ahead of the evolving needs of buyers.

By definition, a cloud platform is far more future-proof in terms of customer experience. It comes with a dedicated product team who constantly takes the pulse of the market and innovates to stay ahead.

Options for migrating off SAP Commerce

Organizations that want to move to the cloud have several options. If they need deep integration to ECC or S/4HANA for B2B use cases, Corevist Commerce Cloud is a great option. Our platform offers a clear path to seamless, integrated commerce that leverages your investment in ERP data and logic. Since Corevist supports even the most complex B2B use cases in a cloud-hosted, out-of-the-box platform, there’s no need to build custom functionality or the dreaded third-party integration to SAP.

For organizations that need even more control (and can justify the expense), SAP offers a well-defined migration path from SAP Commerce to SAP Commerce Cloud. Check out the Thrive with SAP Commerce Cloud program to learn more.

The bottom line

At the end of the day, you just need continuity. Your customers are buying online now, and you don’t want to let them down. Whichever path you choose, you have options as you replace SAP Commerce. The key is to know what matters to your organization—and which path will offer you the best outcome as your commerce program matures.

If you’re looking for low cost of ownership, prebuilt integration, and a dedicated support team, Corevist Commerce Cloud could be a great fit. Check out our demo to learn more.

If your business depends on SAP ERP, then your B2B ecommerce solution must share data with SAP, whether that’s ECC or S/4HANA. Otherwise, you’ll end up with duplicate records for customers, products, orders, and more—and you’ll have to implement manual processes to synchronize the two systems.

Hence the need to integrate B2B ecommerce and SAP.

But not all integrations are created equal. Conventional architecture involves a connector or middleware solution sitting between SAP and B2B ecommerce, yet this can create a permanent burden of upgrades and configuration changes to keep everything working smoothly.

The alternative is a solution like Corevist Commerce—which includes direct, prebuilt, real-time integration to SAP ERP. In fact, Corevist includes 49 integration points to SAP to cover the entire customer journey.

Here are 7 that are truly essential, regardless of your industry or business model.

1. Order status and tracking

Tracking ecommerce orders is a normal feature in B2B ecommerce solutions. But what about orders from all channels—phone, fax, email, and EDI?

Every order your customer has placed lives in your SAP ERP system. So it’s a great bonus to give them access to all orders within B2B ecommerce.

But customers don’t only need order status. They also need line item status, shipment status, and real-time integration to carrier tracking numbers.

To offer all this, you’ll need a robust, real-time integration to SAP ERP that pulls all orders (and relevant data) associated with the customer’s account. Corevist includes all this functionality out of the box.

2. Real-time credit status

Whether they order by phone, email, EDI, or B2B ecommerce, customers need visibility into their credit status. After all, if a crucial order is going to go on credit block, customers need to know so they can deal with the situation and ensure they get their products on time.

This is why credit status is an essential B2B ecommerce feature. It needs to come from your SAP ERP system in real time, which requires a robust integration.

Naturally, Corevist includes this feature out of the box. Every customer sees their credit status in real time, straight from your SAP ERP system.

3. Self-service invoice payments

Not every organization is ready to accept B2B ecommerce orders paid by credit card. Some may prefer to take orders with a payment method of “invoice.”

Outside of B2B ecommerce, customers may continue to place orders by alternate methods that generate invoices.

Whatever the scenario, SAP companies become more customer-friendly when they offer self-service digital payments within their B2B ecommerce experiences. (They also cut costs and reduce days sales outstanding.)

Offering this functionality requires integration to SAP and a payment provider. Corevist supports this with an add-on.

4. Personalized pricing

If customers are going to place orders via B2B ecommerce, then they’ll need to get their personalized pricing in B2B ecommerce. If customers see generic pricing, that will cause confusion and frustration. If the order posts to SAP with the wrong pricing, that will incur extra costs for the merchant, as the order needs adjustment and customer needs manual follow-up to explain the situation.

It’s better to ensure that every customer sees 100% accurate pricing in B2B ecommerce. A robust SAP integration can provide this for every logged-in user, and Corevist includes this functionality out of the box.

5. Real-time inventory

If customers are going to place an order, they need to know whether the product is available. Some merchants may have business reasons for not providing this information, but in our experience, most organizations want to provide it—because customers need to see it.

If SAP ERP is the system of record for inventory availability, then you’ll need an SAP integration that shows real-time inventory. (Bonus points if this integration supports personalized ATP quantities for different logged-in customers, as Corevist does.)

6. Instant, error-free order posting to SAP

An SAP “integration” isn’t much good if it allows orders to post to SAP with errors. Ideally, the solution should only allow orders that conform perfectly to your SAP business rules—and it should provide intelligent error messaging to customers to help them solve issues before placing the order.

If you can achieve all this, then every order that posts to SAP from B2B ecommerce will be error-free. This eliminates the need for callbacks, adjustments, and additional work from customer service.

Corevist includes this integration out of the box. Our application simulates an order against the relevant SAP business rules and returns any error messages. Once the customer fixes the order and it passes the simulation check, the customer can place the order—which posts it to SAP instantly.

7. Change order capabilities

Not every organization allows customers to change orders after they’ve been placed. But for those that do, it’s essential to give customers this power within the B2B ecommerce experience.

Naturally, providing this functionality requires a robust integration to SAP. You want to capture those changes in SAP immediately, and you want to ensure that customers don’t make changes that aren’t allowed by your SAP business rules.

To do all this, you’ll need a powerful SAP integration—which Corevist includes out of the box.

The takeaway

If your business lives in SAP ERP, then your B2B ecommerce experience needs to reflect all the data and logic that exists in SAP. That’s why a comprehensive SAP integration is essential to success in B2B ecommerce. It’s also why Corevist includes this integration out of the box. You get a managed, cloud-hosted solution that always reflects the state of your SAP system—plus you get our team of SAP experts upgrading, managing, and supporting your solution.

As the SAP market increasingly migrates from ECC to S/4HANA, many organizations are evaluating their options for integrating SAP hybris (now called Commerce Cloud) to S/4HANA. For companies that haven’t implemented either solution yet, the possibilities are wide open. If you’re already wedded to either solution, then you need to get strategic and balance the complexity of your architecture against the availability of specialized resources.

The question gets more complicated for companies that are still using older, on-premises versions of hybris (as opposed to Commerce Cloud, which is hosted in the cloud only). With many versions of hybris becoming end-of-life in 2020 and 2021, these organizations need to define a path forward for their eCommerce channels.

So what does it take to integrate S/4HANA and hybris/Commerce Cloud? Is this architecture a good fit for your organization?

In this post, we’ll explain your options. We’ll also look at good-fit use cases and alternatives for scenarios in which you can’t justify the cost and complexity of this architecture.

The basics of S/4HANA integration with hybris (SAP Commerce Cloud)

First off, we need to define a few terms. S/4HANA is easily confused with SAP HANA — but they’re not the same.

HANA is SAP’s new in-memory, relational database management system.

S/4HANA is the latest incarnation of SAP’s business suite ERP software, and it runs on the HANA database.

To make matters more complicated, SAP’s original hybris platform was on-premises only. SAP has evolved the original hybris application and now offers it only on Microsoft Azure public cloud. As we mentioned above, older on-premises versions of hybris are reaching the end of support in 2020 and 2021.

In this post, we’re talking about integrating SAP Commerce Cloud with S/4HANA ERP.

Your best option for integrating these systems is to use SCPI (SAP Cloud Platform Integration). The out-of-the-box package for S/4HANA and Commerce Cloud offers a combination of real-time and batch services for different functions.

However, it’s worth noting that integration on SCPI is not direct. SCPI is a third system that sits between HANA and Commerce Cloud. This means that in both batch and real-time scenarios, data must be replicated across all three systems. In B2C scenarios, replication and synchronization typically doesn’t cause problems since transactions are generic. However, in B2B, the complexity of customer-specific business rules can make this architecture unwieldy.

Resources required to integrate Commerce Cloud with S/4HANA

While SCPI does offer out-of-the-box integration points, most organizations will need some degree of customization to fit their business processes — especially in a B2B scenario. This means you’ll need to engage a consultancy and a systems integrator to scope and build the solution for you. Alternatively, if you have SAP experts in your IT department with plenty of bandwidth, you can build the integration in-house (although that’s not a fit for every organization — see below).

Because this is a complex architecture with duplicate data and business logic, and because customization is usually required, your staffing requirements won’t end at GoLive. You’ll need a vendor to own and support your custom integration indefinitely. Alternatively, if you have the SAP resources on staff, you can support this complex integration in-house. Whichever route you choose, your integration experts will need to work hand-in-glove with your S/4HANA team and your Commerce Cloud team.

What types of companies should integrate Commerce Cloud and S/4HANA?

Integrating SAP Commerce Cloud and S/HANA makes sense for organizations that have the resources to support this complex architecture. However, in some scenarios, this integration may be difficult to justify.

As a general rule of thumb, here are the types of organizations that succeed with this architecture.

• B2C retailers that only need basic, batch-synchronized integration.
• B2B organizations that prioritize a unique, B2C-style user experience over comprehensive ERP integration and customer-personalized business rules. (Hint: Check out our blog on headless commerce for B2B to determine if a unique user experience is a competitive differentiator for your organization.)

There’s a specific scenario in which this integration may be too expensive and complex to justify.

B2B manufacturers who don’t need to differentiate with a unique user experience, but rather require deep ERP integration for customer-specific business rules. For organizations like this that don’t have lots of IT staff (or outsourcing budget) to dedicate to the integration, running Commerce Cloud integrated to S/4HANA may be too difficult to maintain.  

In these scenarios, Corevist offers an SAP-approved alternative to Commerce Cloud that integrates with S/4HANA out of the box. (See below — Alternatives.)

What if you’re migrating from ECC to S/4HANA and don’t have Commerce Cloud implemented yet?

If you’re a manufacturer with customer-specific business rules, you don’t differentiate based on a unique eCommerce user experience, and you have limited IT resources, you should think carefully about implementing Commerce Cloud and integrating it to S/4HANA. As we outlined above, that architecture may be too difficult to maintain.

It’s worth noting that Corevist easily follows you from ECC to S/4HANA. Due to how we’ve architected our built-in SAP integration, the transition from ECC to S/4HANA doesn’t require much heavy lifting. With both integrations certified by SAP, you’re in good hands as you start your next chapter on S/4HANA. Read more here: Should We Wait For Our S/4HANA Migration To Launch Corevist Commerce?

Alternatives to integrating Commerce Cloud and S/4HANA

For manufacturers who may struggle to support an S/4HANA integration with Commerce Cloud, Corevist offers an SAP-approved alternative. Corevist Commerce includes comprehensive, prebuilt integration to SAP ERP for S/4HANA, ECC, R/3 and All-in-One. Our integration works in real time and doesn’t add a third system between the ERP and the eCommerce platform. And because our solutions are fully managed, you don’t have to sweat about supporting your architecture. We’ve got you covered.

When we log into a website or portal, we want to have accurate, cleansed data — our own data that’s personalized to us. This is especially true for B2B buyers dealing with manufacturers. In this context, personalization is critical and often a complex requirement to solve. It requires deep integration to SAP to ensure every B2B user gets an experience that’s driven by their unique SAP data and business rules.

In the world of SAP eCommerce, this gets tricky when the manufacturer has a customer with multiple sold-to’s that roll up to a single payer in SAP. How do you make sure the user with one sold-to sees only their own account information — not all the data for the high-level payer?  

One of our clients encountered this situation recently. Many SAP-integrated solutions would struggle to support this complexity, but Corevist’s architecture was flexible enough to solve this.

The problem: Multiple purchasing entities reporting to a single payer

Our client is a global manufacturer of industrial equipment. One of their larger customers has four purchasing locations around the US — east coast, west coast, north and south. All four regions roll up to a single paying group because their accounts payable department is centralized at the corporate level.

By default, when each of the four buyers logged on to our client’s portal, they each saw all open items for their payer number. For example, when the east coast buyer logged in and accessed open items (i.e. the invoices they need to pay off), they saw all open items from all regions governed by their payer number in SAP.

At the very least, this would lead to confusion, as the account balance is much larger than the buyer would expect. Things could get really messy if the buyer posted a payment against an open item associated with a different sold-to.

This is not the traditional setup, but it does happen. Typically, our clients’ customers have separate payer numbers for those unique geographical regions. Because of how Corevist is architected, each user would automatically see the right accounting information if their region had its own payer number.

Our client asked us if we could restrict financial visibility by sold-to. Luckily, we could!

Our solution: Filtered view driven by sold-to

We created a filter in Corevist Commerce Cloud to restrict the visibility of financial information by sold-to. Instead of showing all open items for the payer associated with the sold-to (which is our standard functionality), the filter looks at ship-to and sold-to on an item-by-item basis. It returns only the data associated with the buyer’s location for views like open items, search for invoices and pay invoices.

This wasn’t too difficult on our end, and our client was thrilled with the result. Now any customer of theirs with a single payer and multiple sold-tos can receive a filtered, personalized view of financial information straight from SAP ERP.  

Caveat: Transactions should post through SD, not FI

For this filtering to work, SAP has to be configured correctly.

In a nutshell, transactions need to post through the SD (sales and distribution) module, rather than direct FI (financial accounting) postings. When any transaction is posted in the FI module, you always post it against the payer number. If there’s a rebate, debit or credit posted against the payer directly in FI, it’s impossible to use that as a filter criterion (unless the clerk indicates who the sold-to is). You have no idea which sold-to that transaction applies to.

If those FI transactions run through SD, the filter works. The ship-to and sold-to information is preserved, which allows the filter to function.

Nine times out of ten, these transactions run through SD anyway. It’s standard procedure in the SAP world. But we do encounter outlying cases, and running it through SD isn’t the only way to pay off an open item. An SAP user with the correct permissions can go into the FI module and directly post a credit or debit against the payer.

In this scenario with multiple sold-tos, that creates a black box financial item. You can’t tell what sold-to it was associated with.

The takeaway: Follow SAP best practices and Corevist follows suit

Because Corevist is so deeply integrated into SAP ERP, the finer points of UX (user experience) in the portal often depend on SAP configuration. While it’s challenging to make SAP “customer-ready” in this way, it’s a great exercise because it forces you to bring your configuration closer to your actual business processes.

When you do that, you not only gain a better B2B portal experience — you also get a more harmonious data landscape with less technical debt accruing over time.

SAP WCEM (Web Channel Experience Management) offered a great solution for organizations doing B2B eCommerce. It was a great step up from SAP Internet Sales, with excellent B2B functionality and a reduced dependence on IT resources for configuration and UI changes.  

While WCEM was sunsetted in 2013 after SAP’s acquisition of hybris, many organizations still depend on it for their B2B channel. As these companies plan their migrations to S/4HANA, the challenge of replacing WCEM comes to the foreground. How do you define a B2B solution that at least replicates what you had before?

And while you’re at it, how do you surpass the functionality and value that you got from WCEM?

Whether you’re migrating to S/4HANA or not, here are three keys to finding a great replacement for SAP WCEM.

1. Determine the depth of SAP integration you need in your WCEM replacement

If you were using WCEM in a B2B scenario, you’ll need some degree of SAP ERP integration in your replacement platform. But what SAP-integrated features are essential to the future of your B2B eCommerce program?

Ask yourself if your B2B customers need any of these capabilities.

• Personalized catalogs and picklists driven by SAP ERP data
• Real-time product availability (including customer-personalized ATP, or available-to-promise, if you use these calculations)
• Dynamic pricing based on contract rules in SAP ERP, cart quantities and bundled products
• Intelligent error messaging so customers can fix orders that don’t conform to SAP ERP business rules
• Error-free order posting to SAP ERP (so you can reduce the burden of callbacks for your customer service team)
• Self-service order tracking, status checks and order history (again, to reduce customer service workload)
• Self-service invoice tracking, real-time credit status and online invoice payments
• Dynamic SAP reports in the B2B eCommerce portal

Each of these features is heavily dependent on SAP data, logic or both. To deliver them in your WCEM replacement, you’ll need comprehensive SAP ERP integration. In many cases, that integration will need to work in real time (rather than depending on batch synchronization).

Keep this in mind as you’re evaluating your options for integration architecture. If you can avoid batch-based architecture, you should. This is the thinking behind the Corevist Platform.

2. Don’t create more work for IT when you replace SAP WCEM

Unlike SAP Internet Sales, WCEM allowed non-technical admins to make some changes to the configuration and UI of the web store experience. This was a great asset — particularly for manufacturers who couldn’t justify adding FTEs in the IT department just to support B2B eCommerce.

Here’s where things get tough in replacing WCEM. Today’s B2B eCommerce platforms weren’t built to put SAP ERP at the center of your universe. These platforms want to own your business data and logic. To get them to work hand-in-glove with SAP ERP, you’ll need an integration platform sitting between the two systems — which requires duplication and synchronization of all relevant data and logic.

For many organizations, that’s a significant burden, both in the project phase and in ongoing support. You’ll have to maintain business rules in three places (SAP, integration platform, B2B eCommerce) rather than just one place (SAP). Outsourcing this workload can reduce your hiring burden, but it doesn’t deal with the real problem, which is unnecessary complexity.

In the worst cases, this complexity can actually lead to a broken SAP integration. When that happens, your B2B portal is dead in the water.

So how do you replace WCEM without creating more work for IT?

• Look for a solution that includes prebuilt, configurable SAP ERP integration. This prevents you from reinventing the wheel with a complex, custom architecture. It allows your IT team to focus on their core responsibility — maintaining SAP ERP.
• Look for a managed solution provider. When coupled with prebuilt integration, this allows your IT team to maintain SAP ERP as the “one true truth” for business data and logic while a dedicated partner supports and upgrades the B2B eCommerce solution. It allows you to replace WCEM without creating additional workload for IT.

3. Define your timeline for replacing WCEM

This is especially critical if you’re migrating off ECC onto S/4HANA. That migration is a huge project. Once you make the cutover, you’ll lose any integration between ECC and WCEM.

Clearly, you need to launch a separate project to replace WCEM while you work out the S/4HANA migration. (Again, constrained IT resources really make this difficult.)

Unfortunately, many organizations come to an impasse here. How can they possibly scope a new B2B eCommerce solution, integrated to S/4HANA, while also getting their ducks in a row for the S/4HANA migration itself?

The key is to replace WCEM early — before you complete the S/4HANA migration.

In fact, with a solution like the Corevist Platform, you can launch now on ECC, then transition your Corevist investment to S/4HANA when you’re ready. The best part? Corevist’s deep SAP integration follows you from ECC to S/4HANA with minimal heavy lifting. Check out this post for more: Should We Wait For Our S/4HANA Migration To Launch The Corevist Platform?

Editor’s note: A version of this article first appeared Aug 31, 2017.

What’s the best B2B eCommerce registration process for your business? The answer depends on many factors, but there’s one thing to understand right away: B2B registration is unlike B2C. In retail eCommerce, adding a new user is simple — you just let them sign up. Since you won’t accept an order without a viable credit card, you’re not too concerned about vetting at the signup point.

For manufacturers doing SAP B2B eCommerce, new user requirements are far more complicated. You don’t want consumers mistakenly signing up for your secure-access portal. Even legitimate companies might not be a good fit depending on your target customer profile.

In this article, we’ll give you the two steps you need to perform in vetting a new customer. Then we’ll give you three different processes you can use to get a new user fully registered.

Vetting step 1: Check for duplicate accounts

When a B2B user registers for your eCommerce site, you want to make sure they don’t already have an account with you. Duplicate accounts can get out of hand fast — and they’re not just an IT problem. If a customer doesn’t realize they have two accounts, they’ll get confused and frustrated when they can’t find orders or invoices.

Clearly, you need a process that flags duplicate accounts and deals with them.

The easiest way to prevent duplicate B2B registrations is to check any new signup against existing records. This feature is built into Corevist Commerce Cloud, and it runs automatically. If a new user tries to sign up with an email address that already exists, Corevist asks them to reset their password. If the email is not yet on file, then the user can continue with the registration.

Vetting step 2: Make sure they’re a good fit

It’s a slippery slope to allow anyone with an internet connection to sign up as a B2B eCommerce user. Most manufacturers have at least two reasons to vet potential customers—and companies in highly regulated industries often have more than just these two.

Creditworthiness

Good thing Amazon doesn’t ask for your personal credit score, right?

Things are totally different for manufacturers doing B2B eCommerce. Validating a street address isn’t enough to make an order legitimate. Before you allow a company to buy from you, you may need to investigate their credit history. In fact, most manufacturers will already have these rules defined. Clearly, your B2B user registration process needs to abide by those rules.

Of course, some organizations may want to mimic the B2C registration process as much as possible in B2B eCommerce. In these scenarios, it may make sense to process the user’s first order via credit card, then move the customer into the vetting process. If they pass, you can feed them into one of the three onboarding methods below so they get set up as a permanent sold-to before they place their next order.

Legality check

Some manufacturers need to vet new customer applications for legality before committing to do business with them. Manufacturers in pharma and chemicals typically have stringent regulations on who they can sell to. For example, a chemical manufacturer that sells flammable products must run a compliance check to ensure that the new customer isn’t on a watchlist.

Once a customer has been vetted and accepted, you can move them into a registration process. There are three workflows that we recommend. We’ll list them now in order of least efficient to most efficient.

Process 1: Signup generates an email to customer service

This process requires a human touch to get the new customer’s data into SAP. After the new customer has been approved, an email with the customer’s information is generated and sent to customer service. A CSR (customer service rep) has to rekey that data manually into SAP to complete the customer’s registration.

This isn’t the most efficient method, but it works in specific use cases. For example, if you have a very unique product with little competition and long lead times, your customers may not mind a protracted registration process.

However, companies at the other end of this spectrum usually can’t afford to insert that delay into the process. If you sell products that are closer to true commodities, and if your customers need the product as fast as possible, this manual process could harm your customer experience. At scale, it can have a direct impact on revenue and customer retention.

Process 2: Signup generates a workflow in SAP

This process is a little more efficient than the last one. Instead of the signup form generating an email to customer service, it generates a workflow process in SAP to kick off the customer master creation process. You could think of this as “data staging.” This process takes the web form data and drops it into a database in SAP.

There are several ways to move this data into SAP. For example, you can have the data update the accounts in the order and put a temporary block on the order. Then the customer service team can monitor these blocked orders and initiate the master data creation process.

Another way to execute Process 2 is to use a custom transaction to create customers. This kicks off an email to the master data team to use the custom transactions to create the customer master record.

Either way, a CSR can easily click a few buttons within SAP to onboard the customer instead of having to rekey the data manually.

Process 3 (Hands-free): Signup generates a quote and related workflow in SAP

If an automated solution will work, you should always choose that over a manual workflow. You’ll reduce errors and free up resources for more important tasks.

That’s how this B2B registration method works, and it’s great for high-volume onboarding.

The customer fills out a web form that automatically creates a quote in SAP. That quote, in turn, kicks off the customer master workflow process, using a 1-time sold-to. This 1-time sold-to is only used for the initial quote. A CSR still needs to go in and convert that 1-time sold-to into a permanent sold-to. Then all future orders are placed against that permanent sold-to.

This method allows you to onboard a new B2B customer quickly. It’s also the most competitive method because you’re showing the new user pricing and availability online. That real-time business data gives the new customer an incentive to do business with you.

Now, this method isn’t a great fit for every use case. For example, if you get one new customer a month, it’s cheaper to onboard them using a manual process. But if you get one new customer a minute, this process is the most efficient solution.

The Takeaway

To figure out which method is best for you, start by setting two benchmarks for your new user registration process:

• Time required to register
• Effort required to register

Then look at each benchmark from two perspectives:

• Your customer’s needs (how easy is it to register with your competition?)
• Your business requirements (how much is it costing you to onboard new B2B users?)

Research your customer’s needs. How long do they expect to wait to get registered and fulfill that first order? If your competition promises 24 hours, you need to do it that fast or faster.

As you’re considering the cost of your onboarding process, look at these factors:

• The average number of orders you get from new customers
• How much time you want to spend per order to meet your SLA
• Your capacity to fulfill those net-new orders

Now it’s time to allocate resources. You can choose Process 1, 2, or 3, depending on how many resources you can devote to new user registration. Ultimately, you need to ask yourself: Which method is right for my business?