The 8 Systems to Connect First in B2B E-commerce

You run a store, an ERP or accounting system, a warehouse or a third-party logistics provider, a payments provider and a shared inbox. Every one of them works.

The question is never "should we integrate." It is "which two things do we connect first, and who owns it." Most teams answer by connecting whatever the loudest person complained about last week.

There is a better answer, and it is an order, not a list.

The short answer: Connect in the order of what failure costs you. Stock to the storefront first, then orders into fulfillment, then orders into accounting with the right payment terms, then customer and company records, then agreed price lists, then shipment tracking, then payments and receivables, and reporting last. Each connection removes one named failure.

An integration is an agreed, automatic exchange of one kind of record between two systems, with one system named as the source of truth and a defined behavior when it fails.

Why does the order matter more than the tooling?

Because the failures are not equal, and because connections build on each other.

An order sent into fulfillment before stock is trustworthy only ships a promise you cannot keep, faster. A price list pushed to a storefront before company records exist has nothing to attach itself to. A dashboard built over both gives you a very clear picture of a broken process.

The order below is ranked by what breaks without the connection, and by what it unlocks for the next one. Adjust it if your own failure costs differ, but change it deliberately, not because a connector was easy to install.

The eight connections, in order

1. Stock source of truth to the storefront

What it is: one system owns the stock number, and the storefront is told about every change to it.

The failure it prevents: selling stock you do not have to the account you least want to disappoint.

First thing to check: which system is allowed to change stock, and what the storefront already means by "available." Shopify, for example, documents distinct inventory states: on hand is everything at a location, available is what you can sell, and committed is "units that are set aside and can't be sold, such as units in an unfulfilled order, reserved in a draft order, or in a transfer marked as ready to ship." If your ERP pushes a raw count into the wrong state, you will oversell while the number still looks correct.

Likely answer: rules and an existing API, plus an alert when a sync fails. See failure alerts for e-commerce integrations, because a silent stock sync is worse than no stock sync.

2. Orders into the system that fulfills them

What it is: every accepted order reaches the warehouse or 3PL, once, with the right address, lines and delivery instructions.

The failure it prevents: orders that ship late, ship twice, or never ship at all.

First thing to check: what happens when the same order arrives twice. Shopify's guidance on duplicate webhooks is explicit: an app "might receive the same webhook more than once, for example after a network timeout or a retry," failed deliveries are retried 8 times over 4 hours, and the recommended fix is to process webhooks with idempotent operations or to store the X-Shopify-Webhook-Id and skip repeats. If nobody on your side implemented that, you have a duplicate order problem waiting for a bad network day. More on that in duplicate orders in e-commerce integrations.

Likely answer: engineering, because this is where retries, deduplication and order state actually live. Orders that arrive as emailed purchase orders need a separate step first, covered in AI order entry accuracy.

3. Orders into accounting, with the correct payment terms

What it is: a confirmed order becomes an invoice with the right customer, the right tax treatment and the right due date.

The failure it prevents: invoices that never get raised, and net terms that quietly become "whenever."

First thing to check: where the due date comes from. Terms belong to the account, not the order form. Shopify's B2B payment terms documentation lists net 7, 15, 30, 45, 60 and 90, all starting the day the order is placed, and notes that payments are not automatically captured when the term expires. That last sentence is a whole workflow hiding in one line. See wholesale net terms and accounting.

Likely answer: rules, if your accounting system already models customer-level terms. Engineering only when tax or multi-entity rules are unusual.

4. Customer and company records

What it is: one record per company, with its locations, its buyers, its terms and its price list, shared between store and back office.

The failure it prevents: the same buyer existing three times with three different prices, and terms that do not follow the account.

First thing to check: whether your platform already models a company separately from a person. Shopify's B2B features by plan page lists companies, company locations, location-level permissions, net terms, draft orders and quick order lists across plans, with catalogs assigned directly to a company or location reserved for Plus. If the model exists and you are not using it, stop and use it.

Likely answer: an existing feature far more often than teams expect. This is also the rung where a portal request usually appears, which is covered in build versus buy for a reorder portal.

5. Agreed price lists into the storefront

What it is: the price a given company sees online is the price you actually agreed with them.

The failure it prevents: a buyer paying the wrong price, which costs margin or costs the relationship, depending on the direction.

First thing to check: how many price lists you need versus how many your plan allows, and what happens when two apply at once. Shopify's B2B catalogs documentation states that Basic, Grow and Advanced plans allow up to 3 active catalogs across all B2B markets, and that when multiple catalogs price the same product, the lowest price is shown. A rule like that decides your entire pricing design.

Likely answer: an existing feature, then rules for the exceptions, then engineering for genuinely unusual logic. Customer-specific pricing goes into where the platform model runs out.

6. Shipment and tracking back to the buyer

What it is: when the warehouse ships, the buyer learns about it without asking.

The failure it prevents: the "where is my order" email, which costs your team more time than the shipment did.

First thing to check: who owns the tracking number and whether it reaches the customer automatically. Shopify's tracking number documentation describes adding tracking during or after fulfillment and notes it appears in shipping confirmation and shipping update emails, with a "send a notification to the customer" option that requires an email address on file. If your 3PL ships and nothing flows back, that notification never fires. Shopify also documents that creating a fulfillment service automatically creates a dedicated location for it, which is the detail that usually explains strange stock numbers after a 3PL goes live.

Likely answer: an existing feature plus a connector, with an alert when tracking is missing. See 3PL integration errors.

7. Payments and receivables reconciliation

What it is: payments, deposits and settlements matched back to invoices without a person reading a bank statement.

The failure it prevents: cash that is collected but not recognized, and chasing accounts that already paid.

First thing to check: whether retried payment calls can charge twice. Stripe's idempotent requests documentation describes the standard mechanism: send an idempotency key, and "if a connection error occurs, you can safely repeat the request without risk of creating a second object or performing the update twice." It also notes keys can be pruned after 24 hours, so a retry a week later is a new request. That is the shape of every safe money integration.

Likely answer: rules and existing features for matching, engineering for anything touching payment creation.

8. Reporting, last

What it is: order, margin and service numbers pulled together in one place.

The failure it prevents: honestly, none. Reporting prevents nothing. It reveals.

First thing to check: whether the flows feeding the report are trustworthy yet. If stock, orders and invoices still move by hand, the report will faithfully show numbers assembled by hand.

Likely answer: an existing feature. Almost nobody needs reporting engineering before connections 1 to 7 are stable. Built last, it is cheap, because the data finally means something.

The eight at a glance

#	Connection	The failure it prevents	Likely answer
1	Stock source of truth to storefront	Overselling your best accounts	Rules plus an alert
2	Orders to warehouse or 3PL	Late, doubled or missing shipments	Engineering
3	Orders to accounting with terms	Missing invoices, drifting net terms	Rules
4	Customer and company records	Duplicate accounts, wrong terms	Existing feature
5	Agreed price lists to storefront	Buyers charged the wrong price	Existing feature, then rules
6	Shipment and tracking to buyer	"Where is my order" emails	Existing feature plus connector
7	Payments and receivables	Unmatched cash, wrong chasing	Rules, engineering for charges
8	Reporting	Nothing. It only reveals	Existing feature, built last

What does getting the order wrong actually cost?

An illustrative example, so redo it with your own numbers.

A line sells 40 units on a normal day. Your ERP pushes stock to the storefront once a night, and you hold a buffer of 8 units to absorb the gap. That buffer covers about a fifth of a day, so by mid-morning the storefront number is guesswork.

Say that produces 6 oversold orders a month, each costing 25 minutes across sales and the warehouse to unpick. That is 2.5 hours, about €88 at €35 an hour, which is nothing.

The labor is not the point. Six times a month a buyer who chose you is told the thing they bought is not coming. That is what connection 1 protects, and it is why it goes before the dashboard that would have shown you the problem.

How should you sequence the work?

Four rules, and they matter more than the order itself.

1. One connection at a time. Two half-finished integrations sharing a data model is how teams end up unable to tell which one broke.
2. Each one has a named owner. Not a team. A person who knows what it does, where its logs are, and who to call.
3. Each one has a rollback. Before it goes live, write down how to turn it off and what happens to in-flight records if you do.
4. Never start with reporting. If a stakeholder wants a dashboard first, the honest answer is that it will work perfectly and change nothing.

One more decision sits across all eight: how the data moves. Large trading partners may require electronic data interchange, the long-standing standard set maintained under UN/EDIFACT and its regional equivalents, while most modern systems expose APIs. That choice is usually made for you by whoever is bigger. EDI versus API for B2B integration covers how to decide when it is not.

When does this order not apply?

• A single dominant trading partner. If one account is most of your revenue and mandates EDI, their requirement outranks this list.
• You are pre-launch. With no order volume, connect nothing. Run it by hand, learn the exceptions, then automate what repeats.
• The process itself is unstable. If your fulfillment model changes next quarter, connecting to it now buys you rework.
• A regulatory or audit deadline. Sometimes reporting genuinely goes first. Say out loud that it is for the auditor, not for operations.
• Nobody can own it. An integration without an owner is a future outage with no phone number attached.

Cost is the other check. Run each connection through the arithmetic in what B2B automation costs first.

How do you know a connection worked?

Write these down before the first connection goes live, then again after four normal weeks.

• Touchless order rate. Orders that reached fulfillment with nobody opening, retyping or correcting them, as a share of all orders.
• Stock accuracy. How often a buyer was told after ordering that stock was not available.
• Days from ship to invoice. Connection 3 should collapse this. If it does not, the invoice is not triggered by the event you think it is.
• Failed and retried syncs per week. Zero is suspicious. It usually means nobody is looking.
• Time your team spends fixing integrations. Subtract it from the hours you claim to have saved.

Two of these matter more than the rest: touchless order rate and time spent fixing things. If touchless orders rise and repair time rises with them, you did not remove work. You moved it.

Your first month

1. List which of the eight connections exist today, and which run through a person.
2. For each missing one, write the failure it would prevent and roughly what that failure costs you now.
3. Pick the highest one on the list that is still manual. Not the easiest one.
4. Give it an owner, a rollback plan and an alert before it goes live.
5. Measure for four normal weeks, then start the next one.

That is the Find, Prioritize, Automate methodology applied to integrations, and it is the same argument made at the process level in the B2B e-commerce automation guide. The work itself is software integrations, done one connection at a time.

FAQ

What should a B2B e-commerce business integrate first?

Connect your stock source of truth to the storefront first. Overselling costs you the accounts you least want to lose, and every later connection assumes the stock number can be trusted. Orders into fulfillment come second, then orders into accounting with the correct payment terms.

Why is reporting the last integration, not the first?

Because reporting prevents no failure. It only shows you failures faster. If stock, orders and invoices still move by hand, a dashboard will accurately report numbers that were assembled by hand. Connect the flows first, then reporting becomes cheap and the data finally means something.

How do I choose the source of truth for stock?

Pick the system where physical reality is recorded first, usually the ERP or the warehouse system, and make every other system a follower. Then check what your storefront means by available stock, since platforms separate on hand, committed and available, and pushing a raw count into the wrong state causes overselling while the number looks right.

Do I need EDI, or is an API enough?

It depends on your trading partners, not on your preference. Large buyers often mandate electronic data interchange using standards such as UN/EDIFACT, and that requirement outranks anything else. Where no partner mandates it, a modern API integration is usually simpler to build, monitor and change.

How many integrations should I run at once?

One. Two half-finished integrations touching the same orders or stock make it impossible to tell which one broke when something goes wrong. Finish, measure for a few normal weeks, then start the next.

What is the first thing to check before connecting orders to fulfillment?

What happens when the same order arrives twice. Platforms retry failed webhook deliveries, so your side must either process them idempotently or record the delivery ID and skip repeats. Without that, one bad network day turns into duplicate shipments to your customers.

Sources

• Shopify inventory states: the documented difference between on hand, available, committed and unavailable.
• Shopify guidance on duplicate webhooks: repeat deliveries, the 8 retries over 4 hours, and deduplication by webhook ID.
• Shopify fulfillment services: how a 3PL receives fulfillment requests, and the dedicated location created for it.
• Shopify tracking numbers: tracking added during or after fulfillment, and the customer notification option.
• Shopify B2B payment terms: the net term options and the note that payment is not captured automatically.
• Shopify B2B features by plan and catalogs: the 3 active catalog limit and the lowest-price rule when catalogs overlap.
• Stripe idempotent requests: the standard mechanism for retrying a payment call without charging twice.
• UN/EDIFACT at UNECE: the standards body behind the EDI formats large trading partners ask for.