On a diagram, an eCommerce integration can look deceptively simple.
You have an eCommerce platform. You have an ERP. Maybe you connect the two, move product and inventory data one direction, send orders back the other way, and call it a day.
Anyone who has actually worked on one of these projects knows that’s rarely how it goes.
I recently sat down with Robert Rand, Chief Partnership Officer at iPaaS.com, for an episode of the Human Element Podcast, “Beyond the Cart,” to talk about the hidden complexities of B2B eCommerce integrations. Robert and I have both been working in this space for a long time, and one thing we agreed on almost immediately is that the technology itself is only part of the challenge.
The real complexity comes from the business processes, systems, people, exceptions, and years of accumulated decisions sitting behind that technology.
That’s especially true in B2B.
There’s Almost No Such Thing as a “Standard” B2B Integration
One of the first questions I asked Robert was which B2B requirements companies tend to underestimate.
His answer, jokingly, was: “All of them.”
He’s not far off.
Two companies might use the exact same ERP and eCommerce platform and still require very different integrations. That’s because the ERP that exists today may have been customized over ten, twenty, or even more years around the way that particular organization operates.
And B2B commerce introduces questions that don’t normally exist—or at least aren’t nearly as complicated—in a typical B2C transaction.
Does a customer need to be approved before ordering? Where does that approval happen? Does the buyer have a tax exemption certificate? Do they get net payment terms? Are prices based on customer groups, individual contracts, volume, or specific SKUs? Can multiple buyers belong to the same company account? Does one person need to approve another person’s order? Which addresses can each person ship to? What happens when a customer wants to use their own freight account?
Those aren’t edge cases in B2B. They’re the business.
As Robert pointed out during our conversation, once you start accounting for customer hierarchies, negotiated pricing, quote workflows, CPQ systems, shipping rules, fulfillment processes, and payment terms, the simple idea of “send an order from eCommerce to the ERP” can get off the rails pretty quickly.
Start by Mapping What Actually Exists
At Human Element, one of the first things we ask for when we’re starting a major eCommerce or integration project is a system map. Most companies don’t have one so we help build it.
And nearly every time we go through that process, we discover something the original project team didn’t know about. There might be a separate system being used by one department. There might be two tools doing essentially the same job for different teams. There may be spreadsheets or manual processes sitting between major platforms that nobody thought of as part of the “tech stack.”
This is why discovery is so important.
Before you design the future state, you need to understand the current state. And that means getting very specific about where data originates, where it goes, who uses it, and which system should ultimately be considered the source of truth.
Inventory may come from a warehouse management system. Pricing may come from the ERP. Product descriptions and attributes may live in a PIM. Orders may need to go to the ERP for accounting, another system for fulfillment, and the CRM so the sales team has visibility.
Your organization doesn’t necessarily need everyone working inside one giant system. What you need is a tech stack in which those systems can work together intelligently.
Robert described a useful way to approach this during discovery: work through the business one data flow at a time.
What happens when a product is created? Where does it start? What information has to be added before it can appear online? Is there an approval step? Should products with a zero-dollar price be excluded? What happens when an order arrives? Where does it go next?
Instead of beginning with APIs, begin with what a human being expects to happen when everything works correctly.
Then determine how technology can make that happen.
Don’t Modernize Everything at Once Just Because You Can
Another common situation we see is an organization deciding it’s time to modernize—and then attempting to replace everything simultaneously.
The client wants a new ERP, new eCommerce platform, new CRM, new integrations, new processes, and they want them all to launch at the same time.
We almost always recommend against that.
Change management is difficult enough when you’re replacing one major business system. Trying to coordinate multiple implementations at the same time creates dependencies everywhere, and the chances of every project being ready on exactly the same day aren’t great.
A better question is: Where can we create the most value first?
In many cases, eCommerce is a good candidate because improvements there can directly affect the customer experience and begin producing a return relatively quickly. A business may be able to continue using an older ERP while dramatically improving how easily customers can find products, see availability, place orders, and manage their accounts online.
Then additional capabilities can be layered in.
Maybe CRM synchronization comes next. Maybe it’s PIM. Maybe accounts receivable automation. Maybe tax exemption certificate management.
The important thing is that they don’t necessarily have to happen on launch day.
Robert described this as finding the minimum viable product that generates meaningful value, launching it, and then continuing to improve the ecosystem incrementally.
That’s a much healthier way to think about digital transformation than trying to eat the entire elephant at once.
You Need the Right People in the Room
Technical discovery also can’t happen entirely within the eCommerce team.
Finance matters. Sales matters. Account management matters. Warehouse and fulfillment teams matter. Customer service matters. And if an outside ERP VAR or another service provider has spent years customizing one of your systems, they probably need a seat at the table too.
Those people know where the bodies are buried.
We’ve seen plenty of projects where a requirement emerges late because a stakeholder wasn’t involved early enough. Suddenly you discover that a group of customers ships using its own freight accounts, or an obscure ERP customization controls a critical workflow, or product information lives in custom database tables that aren’t exposed through the standard API.
Those discoveries are much less expensive during planning than they are a week before launch.
As Robert put it, it’s the old “measure twice, cut once” principle. Bringing stakeholders together during discovery costs time, but the opportunity cost of not doing it can be much higher: scope changes, missed launches, rework, and frustration.
Plan for the Project to Change
Even with a great discovery phase, something unexpected is going to happen. That’s just the reality of complicated technical projects.
An ERP needs an upgrade. A security patch becomes mandatory. A vendor changes an API. A requirement turns out to work differently in production than everyone believed during planning.
I’ve used the Mike Tyson line before: everybody has a plan until they get punched in the face.
The point isn’t that planning doesn’t matter. It’s the opposite. Good planning includes the assumption that something will change.
That’s why we talk about risk at the beginning of projects. What could affect this implementation? Where are the unknowns? Which integrations have we never built before? Where should we have budget or timeline flexibility?
For particularly complex work, we want some buffer rather than pretending our original estimate can account perfectly for every unknown.
Projects go much better when everyone enters them understanding that adaptation is part of the process rather than interpreting every change as a failure of the plan.
Building an Integration Is Only Half the Job
One topic I think doesn’t get enough attention is what happens after the integration works.
Years ago, custom integrations were often the default. You built exactly what you needed and connected System A to System B. But now you own it.
APIs change. Systems go offline. Data arrives in formats you weren’t expecting. Someone puts a question mark in a field that’s supposed to contain a number. An eCommerce platform releases a new API version.
If you don’t have the right monitoring in place, the first person who discovers your integration stopped working might be a customer asking why an order they placed two weeks ago never arrived. That’s a bad monitoring system.
Robert walked through several capabilities that platforms like iPaaS.com have built specifically around these realities: queued transactions, automatic retries, proactive error reporting, version control, security, role-based access, scalability, and standardized integration patterns.
Those aren’t glamorous features. They’re the things you become extremely grateful for when something inevitably goes wrong.
We’ve experienced this firsthand. We’ve had custom Shopify integrations where an API change affected important processes. Without sufficient logging, you may not know there’s a problem until someone notices the downstream impact. An integration platform that has already solved queuing, retry logic, versioning, logging, and monitoring gives you a much stronger starting point than building every one of those capabilities from scratch.
This is really a technical-debt question. You can custom build almost anything.
The more important question is whether you want to own, support, maintain, troubleshoot, secure, and upgrade that custom solution indefinitely.
eCommerce Doesn’t Replace the Sales Rep
Toward the end of our conversation, we talked about industries that have been slower to adopt eCommerce. One pattern I’ve noticed is that many of them are heavily dependent on sales representatives.
There’s sometimes an assumption that introducing eCommerce means replacing the salesperson. I don’t think that’s the right way to look at it. The goal should be to give the customer more options while making the salesperson more valuable.
A buyer who knows exactly what they need shouldn’t necessarily have to call someone simply to place a routine reorder. They might want to order at 10:00 at night, check inventory, view invoices, or see an expected turnaround time without talking to anybody.
That doesn’t mean relationships stop mattering. It means the sales rep can spend less time acting as what Robert called a “glorified order taker” and more time doing the things humans are actually good at: maintaining the relationship, identifying new opportunities, solving problems, checking in after an order, and helping the customer when expertise is valuable.
That’s particularly important as a new generation of buyers and employees enters industries that historically relied heavily on phone calls, emailed spreadsheets, trade shows, and even faxed orders.
You don’t have to eliminate every legacy process overnight. But you do need to be building toward where your customers are going.
And Yes, We Had to Talk About AI
It would be difficult to have a technology conversation in 2026 without eventually getting to AI.
One example I brought up during the podcast came from demonstrations I’ve seen around agentic commerce. Some eCommerce search providers can now take something like a PDF purchase order, identify the products on it, add available items to a cart, flag unavailable products, and potentially suggest alternatives. It’s a fascinating example because it’s using new technology to bridge a very old business process.
We’re also seeing AI become useful in the integration process itself. At Human Element, we’ve used it to help organize API documentation, compare systems, identify potential data mappings, surface possible risk factors, and give experienced developers and strategists a better starting point.
That’s the key phrase: a better starting point.
AI is most useful when it augments someone who already understands the problem.
Robert described similar uses at iPaaS.com. AI can help users create transformation logic without manually writing formulas, accelerate development of new integrations, and make documentation much easier to create and maintain.
But neither of us believes that means you can remove knowledgeable humans from the process.
Financial data isn’t something where “probably correct” is acceptable. Orders, taxes, inventory, and customer records need deterministic, reliable systems underneath them. And prompting matters.
As I mentioned during the episode, asking AI, “How much does a Shopify site cost?” is very different from asking, “What will it cost to reproduce the feature set of a heavily customized, ten-year-old Adobe Commerce site on Shopify?”
The second question reflects the real problem.
AI can accelerate the work tremendously, but somebody still needs to know which question to ask and whether the answer makes sense.
Integration Strategy Is Really Business Strategy
The biggest takeaway from my conversation with Robert is that integration work isn’t just about moving data between APIs. It’s about understanding how a business operates today, deciding how it should operate tomorrow, and creating the infrastructure to support that change.
That means mapping your current systems. Identifying your sources of truth. Bringing stakeholders into the process early. Prioritizing the capabilities that create the most value. Planning for change. Building in monitoring and reliability. Reducing manual work where automation makes sense. And leaving room for the technology stack to continue evolving.
You don’t need to solve every problem on day one. But you do need to understand the problems you’re choosing to solve—and the ones you’re intentionally leaving for later.
That’s the difference between simply connecting systems and building an eCommerce ecosystem that can actually support the business for the long term.
If you’re planning a B2B eCommerce implementation, replacing a platform, or trying to untangle an existing collection of integrations, I hope you’ll listen to the full episode of “Beyond the Cart” with Robert Rand of iPaaS.com. We get much deeper into the realities of these projects, the mistakes we’ve both seen companies make, and the practical steps that can make the process a whole lot less painful.
