Connecting Ecommerce to an ERP: What Data Exchange Actually Involves

Summary: What it really takes to move data between an ecommerce store and an ERP, based on exchanges we have built with Salesforce, NetSuite, Epicor Prophet 21, and Microsoft Great Plains. Read this if someone has told you the two systems need to talk and you are trying to work out what you are agreeing to.

Somebody has decided your store and your ERP need to talk to each other. Usually it is the controller, who is tired of rekeying orders, or a customer who wants their pricing honored online the way it is honored on the phone.

The request sounds simple. It rarely is, and the difficulty is almost never in the code. It is in the decisions nobody has made yet.

We should say up front what we are and are not. We are not ERP specialists. We do not sell a prebuilt connector, and if you need someone to reimplement your Prophet 21 install, that is not us. What we have done, repeatedly, is build the exchange layer between a store and an ERP, including with Salesforce, NetSuite, Epicor Prophet 21, and Microsoft Great Plains. This post is about that layer.

Which direction is the data actually going?

Most ERP integrations are not one integration. They are four, and they are usually built at different times.

• Products, ERP to store. SKUs, descriptions, categories, units of measure.
• Inventory, ERP to store. Almost always the most time-sensitive of the four.
• Pricing, ERP to store. In B2B this is customer-specific, which is where it gets interesting.
• Orders, store to ERP. The one everybody thinks of first and the one with the least tolerance for error.

Scoping these separately is the single most useful thing you can do early. They have different refresh needs, different failure consequences, and different costs. Inventory that is an hour stale is a problem. A product description that is a day stale is not. Teams that treat “integrate the ERP” as one project tend to build the expensive version of all four at once.

Where do the mismatches actually show up?

In the places where the two systems disagree about what a thing is. Nearly every hard problem we have hit is a modeling mismatch, not a technical one.

The classic is units of measure. The ERP knows an item is sold in cases of twelve and stocked in eaches. The store has one number called “quantity”. Somebody has to decide what the shopper sees, what the ERP receives, and what happens when the two conventions meet mid-order.

Then there is the customer record. The ERP has an account, with terms, a credit limit, and possibly several ship-to addresses. The store has a user with an email address. These are not the same object, and deciding which system owns the truth for each field is a business decision that gets handed to developers by default when nobody makes it deliberately.

Product identity has the same problem. The store wants a variant model with size and color; the ERP has a flat list of distinct SKUs. Neither is wrong. They just have to be mapped, and the mapping has to survive somebody adding a new color next spring.

What has to be settled before anyone writes code?

Four questions. Getting written answers to these will do more for the budget than any technology choice.

1. Which system is the source of truth for each field? Not for the data as a whole. Field by field. Price, description, inventory, and customer terms often have different answers.
2. How fresh does each feed need to be? Real time is expensive and often unnecessary. A fifteen-minute inventory sync and a nightly product sync will serve most B2B catalogs perfectly well.
3. What happens when the ERP is unreachable? It will be, during upgrades and backups. Does the store queue orders and retry, refuse checkout, or accept the order and reconcile later? This is a business call with real consequences.
4. Who watches it? An integration nobody monitors fails silently, and you find out from a customer. Somebody has to own the alerts.

How does the data actually move?

Less excitingly than people expect, and that is usually the right answer.

If the ERP has a documented API, we use it. NetSuite and Salesforce do, and that is the straightforward case. Older on-premise systems frequently do not expose anything usable across the network, and then the practical answer is a scheduled file exchange, flat files on a secure endpoint, picked up on a timer. It is unglamorous and it is reliable, and it has the advantage that when something goes wrong you have a file you can open and read.

Middleware sits between those two. It is worth its cost when you have several systems to reconcile, and it is overhead when you have two.

What matters more than the mechanism is the queue and the retry. Any exchange that assumes both ends are up at the same time will eventually lose an order. Build it so a failed message waits and tries again rather than disappearing.

What does this have to do with punchout?

More than you would think, and if you are heading toward punchout it is worth knowing now.

A punchout catalog is a live conversation with a buyer’s procurement system, so the pricing and inventory it shows have to be right at that moment. If your catalog data is a stale nightly export, punchout will expose that immediately, in front of the customer who required punchout in the first place. In practice the ERP exchange is the foundation and punchout is the storefront on top of it. Suppliers who sequence it the other way usually end up doing the data work anyway, under more pressure.

We have delivered cXML and OCI punchout on nopCommerce and AbleCommerce, including Level 1 and Level 2 and cXML invoicing, connected to SAP Ariba, Coupa, and Oracle Supplier Network. The data layer underneath is the part nobody photographs. Our cXML PunchOut integrations guide covers that side in detail.

Working with us on this

If someone has told you your store and your ERP need to talk, the useful first conversation is not about technology. It is the four questions above. We are happy to run through them with you and tell you honestly whether the job needs us, needs your ERP partner, or needs both.

We have built these exchanges with Salesforce, NetSuite, Epicor Prophet 21, and Microsoft Great Plains, on nopCommerce, AbleCommerce, Shopify, and custom .NET applications. We do not have a prebuilt connector to sell you, which means we have no reason to tell you the answer is a connector.

See our ecommerce development services, or get in touch.