Blog

Your best accounts buy the same things every month. The buyer knows the order. Your rep knows the order. And it still arrives as an email that says "same as last time, but double the 500ml."

Someone on your team then opens the store, finds the account, checks the agreed price list, types the lines in, and replies to confirm.

So the team asks for a customer portal. That request is right about the pain and usually wrong about the fix.

The short answer: Most teams asking for a B2B customer portal want one thing from it: an existing account repeating a known order without emailing a rep. That job is usually solved by a per-account order form, a one-click repeat link, or the B2B features already in the platform you pay for. Build or buy a portal only when self-service, approvals and history require it.

A B2B customer portal is a logged-in area where a business account sees its own prices, places and repeats orders, and looks up its own order, invoice and shipment history.

What are you actually buying when you buy a portal?

Read that definition again and count the parts. A portal is a login and an identity for every buyer at every company. A catalog scoped to what that account is allowed to buy. Account-specific prices. An order flow. Often an approval chain, because the person choosing is rarely the person signing. Documents: invoices, statements, proof of delivery. History, which usually lives in your ERP, or enterprise resource planning system, and has to be exposed safely. Then roles and permissions across all of it.

That list is not a guess. BigCommerce's developer documentation describes its B2B Edition buyer portal as covering user roles, multiple company users, company hierarchy, a shared company address book, shopping lists, quotes, invoice management and quick ordering by SKU or previously purchased item. That is the real scope of the word "portal."

Each part is a surface that can break, and it breaks in front of your customer. A portal is not a project you finish. It is a system you now run, next to the store, the ERP and the warehouse. BigCommerce even splits the hosted portal from a self-hosted custom one, where the hosted version is updated for you and the custom version is yours to maintain. That single choice is the build versus buy question in miniature.

All of it is worth doing when the portal is the product. It is a poor trade when the actual request was "stop making Anna retype the Tuesday order."

What job is the request really asking for?

Ask your operations lead one question: of last month's orders, how many were an existing account buying things it has bought before?

In most wholesale businesses the answer is a large majority. Those orders need no browsing, no discovery and no persuasion. They need a fast, correct, low-friction repeat.

Now split the remainder. New accounts placing a first order, buyers asking for a product they have never taken, and negotiated deals are different jobs with different fixes. Do not let them justify a portal that mainly exists to serve repeat orders. Solve the repeat first. It is the cheapest job and the biggest one.

The reorder ladder: where should you stop?

Climb from the bottom. Stop the moment a rung solves the job you just measured. Each rung costs more to run than the one below it.

Rung 1: A per-account order form with their agreed prices

Solves: a named buyer opens one link, sees the items they actually buy at the price you agreed, enters quantities, submits. No login, no catalog to build, live in a day.

Runs out: it shows no stock, no history and no invoices. Prices now live in a second place, so someone has to keep them current. Past roughly 15 or 20 accounts, maintaining a form each becomes its own manual job.

Rung 2: A one-click repeat of the last order, sent by email

Solves: after each shipment, email the buyer their order back with a "reorder this" link. One click creates a draft order in your store with the same lines at their current agreed price, and your team confirms it. This covers the "same as last time" order, which is often most of them.

Runs out: quantity changes and substitutions. An editable quantity field on the link covers a lot more. It still cannot answer "what did we order in March."

Rung 3: A saved cart, draft order or shareable order link

Solves: a rep or the buyer builds a cart, sends the link, the other side opens it and pays with the account's terms attached. This is already a documented feature rather than a build. Shopify's help center describes B2B draft orders as the way to handle orders customers send by phone or email instead of through the online store, including setting a custom price, adding a purchase order number, and sharing the order with pricing locked by default.

Runs out: it is a per-order artifact, not a place. Nothing persists for the buyer between orders, so every cycle starts with a human again.

Rung 4: The B2B features in the platform you already pay for

Solves: company accounts, several buyers per company, customer-specific price lists, payment terms and a logged-in reorder view. That is a portal. You may already own it. Check your plan before anyone writes a scope.

This is the rung teams skip most often, so here is a documented example to check against. Shopify publishes a B2B features by plan page stating that companies, company locations, location-level permissions, quantity rules, quantity price breaks, net terms, payment reminders, draft orders, easy reorders, purchase order numbers, sales staff permissions and quick order lists are available across plans, while unlimited catalogs and catalogs assigned directly to a company or company location are Plus-only. Its catalogs page adds that Basic, Grow and Advanced plans allow up to 3 active catalogs across all B2B markets, and that when two catalogs price the same product, the lower price is shown. Its payment terms page 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 terms expire.

Read that as a checklist, not an endorsement. If most of the portal you are scoping is already on that list, you are scoping a subscription you own.

Runs out: pricing rules the platform's model cannot express, history that lives in the ERP, and approval chains on the buyer side. See customer-specific pricing for where those rules usually break.

Rung 5: A bought portal product

Solves: roles, approvals, documents and account history out of the box, with connectors to common platforms and ERPs. You pay a subscription plus setup, and someone else ships the bug fixes. Adobe Commerce, for example, documents requisition lists that a logged-in company buyer maintains for frequently ordered items, up to 999 lists per buyer account depending on configuration, and unlike a wish list the requisition list is not cleared when its items go to the cart. That behavior is exactly the reorder job, already built and documented.

Runs out: when your pricing or your ERP does not match the product's model. Then you pay for the product and for the workarounds around it, which is the worst of both columns below.

Rung 6: A custom build

Solves: exactly your rules, exactly your data, no compromise on pricing logic or ERP shape.

Runs out: never, and that is the problem. You own every future change, every dependency upgrade and every 7am outage. Take this rung only after the five below it have been tried and honestly ruled out.

When is a real portal the honest answer?

Four conditions. If two or more are true, a portal is a reasonable build. If none are, you are buying a login page.

• Many accounts self-serving. Enough buyers that per-account handholding does not scale, and enough order frequency that they will learn the tool.
• Approval chains on the buyer's side. The person who picks is not the person who signs. A portal can hold a basket in "awaiting approval" for three days. Email cannot.
• History that must be exposed from another system. Invoices, statements, proof of delivery and open balances that live in the ERP or accounting system, and that buyers currently get by asking your team.
• Roles and permissions. Site managers who order but cannot see pricing, head office that sees everything, a finance user who only wants documents. This is why platform documentation lists user roles and company hierarchy as core portal features rather than extras.

Build or buy: how do the options compare?

Three columns, because the first one is the option teams forget they have paid for.

Dimension	Platform B2B features you already pay for	Bought portal product	Custom build
Time to first real order	Days, if the plan includes it	Weeks, mostly data and mapping	Months
Ongoing cost shape	Inside your existing plan	Subscription plus per-change work	Your own maintenance, forever
Fit to unusual pricing rules	Only what the price list model allows	Good until your rules leave its model	Exact, at a price
Who fixes it at 7am	Your platform vendor	The vendor, at their pace	You, or the agency that built it
Exit cost	Low, it is a setting	Medium, data export and rebuild	High, nothing transfers

A worked example, illustrative

Use your own numbers. This arithmetic is here to be redone, not believed.

• 40 accounts that reorder regularly
• 3 reorders each per month, so 120 reorders
• 7 minutes of staff time per reorder to read, price and enter it

That is 840 minutes, 14 hours a month. At €35 an hour, about €490 a month, or €5,880 a year.

Now price rung 2 against rung 5. Say a repeat-order link handles 70 of those 120 orders with no human touch. That recovers 490 minutes, about 8 hours, or €286 a month, for a few days of work.

A bought portal at €300 a month plus €4,000 of setup would have to remove all 14 hours to leave €190 a month of margin, which pays back the setup in about 21 months. On time alone, the cheap rung wins clearly.

The real case for a portal is rarely the €490. It is the orders you never see because reordering was annoying, and the rep hours that go to service instead of selling. Those are worth more, and neither of us can put a number on yours. Estimate it yourself, and see what B2B automation actually costs for the cost side.

When should you not climb the ladder at all?

• Low order frequency. Ten accounts ordering twice a year will keep emailing. Let them.
• Every order is negotiated. If price, quantity and delivery are decided in a conversation, self-service has nothing to repeat.
• Your prices are not settled. A portal shows a price to a customer. If agreed prices still live in a spreadsheet nobody trusts, fix that first.
• Nobody owns it. A portal with no owner becomes a stale catalog with wrong stock, which is worse than no portal.
• You have not measured today. Without a baseline you cannot tell a win from a habit change.

How do you measure whether it worked?

Two numbers decide whether any rung worked. Write both down before you change anything.

Touchless reorders. Count the reorders placed in a month where no staff member opened, edited or typed the order. Divide by all reorders that month. If no report gives you this, tally it by hand for two weeks. A number you collected by hand beats a dashboard you do not trust.

Time from buyer intent to confirmed order. Start the clock at the buyer's email or click. Stop it at the order confirmation. Track the median and the worst case, because your accounts remember the worst case.

Two supporting numbers are worth keeping: orders that needed a price correction after entry, and reorder emails still landing in the shared inbox. If touchless reorders rise but the inbox does not empty, buyers are using both channels and you have added work instead of removing it. That pattern is the same one described in the B2B e-commerce automation guide.

Do this next week

1. Count last month's orders that were an existing account rebuying known items. That is your portal's real audience.
2. Time the manual reorder end to end, three times. Use the median.
3. Open your platform's own B2B feature and plan documentation and mark what you already pay for.
4. Ship rung 1 or rung 2 for your five busiest reorder accounts.
5. Measure touchless reorders and time to confirmed for four normal weeks, then decide about rungs 5 and 6 with evidence.

If the answer really is a portal, connect it in the right order. That sequence is in the B2B integration checklist, and the connection work itself is software integrations, not a new product.

FAQ

Do I need a B2B customer portal?

Only if buyers must serve themselves at a scale your team cannot cover by hand, or they need approvals, history and documents exposed from another system. If the real request is faster reordering by known accounts, a per-account order form, a repeat-order link or your platform's built-in B2B features usually solve it for far less.

What is the difference between a customer portal and a reorder link?

A reorder link does one job: it turns a past order into a new one in a click, with no login. A portal is a logged-in place that also holds identity, catalog access, prices, approvals, documents and history. The link solves the common case in days. The portal solves the whole surface, and you maintain that surface forever.

Should I build or buy a B2B portal?

Buy when your pricing, roles and documents fit a product's model, because you get approvals and fixes without owning code. Build only when your pricing rules or ERP shape cannot be expressed in any product you tried, and the value is large enough to justify owning the maintenance. Check your existing platform's B2B features before either.

Can I use my existing e-commerce platform for B2B self service?

Often yes. Platform documentation is the place to check. Shopify, for example, publishes a B2B features by plan page covering companies, company locations, net terms, draft orders, easy reorders and quick order lists, with unlimited catalogs and company-level catalogs reserved for Plus. Read your own plan's page before you scope anything new.

How much does a B2B customer portal cost to run?

Count three things, not one: the subscription or build cost, the setup and data mapping, and the ongoing work when prices, accounts or the connected ERP change. A bought product moves fixes to the vendor at their pace. A custom build keeps every fix, upgrade and outage with you.

What should stay manual even with a portal?

Negotiated pricing, credit limits, payment terms and refunds. Keep first orders from new accounts under human review too, because that is where wrong terms and wrong prices get set and then repeat quietly for a year.

Sources

• Shopify B2B features by plan: which features are on every plan, which are Plus-only.
• Shopify B2B catalogs and pricing: the 3 active catalog limit, quantity rules and volume pricing.
• Shopify B2B payment terms: net 7 to net 90, and payment not captured automatically at term end.
• Shopify B2B draft orders: phone and email orders, custom prices, PO numbers, shareable orders with locked pricing.
• Adobe Commerce requisition lists: documented reorder lists, up to 999 per buyer account, persisting after checkout.
• BigCommerce B2B Edition buyer portal introduction: the feature list that makes up a portal, from user roles to quick order by SKU.
• BigCommerce buyer portal overview: hosted versus self-hosted portal, and who maintains which.

A buyer at one of your largest accounts sends a short email. From the first quarter, all suppliers must trade documents by EDI. No discussion, and no alternative address for purchase orders.

The same week your developer says the whole thing is dated, and that a modern API would do it in a fortnight.

Both are partly right. The question is not which technology is better. It is which partner sets the rules for which flow, and who maintains it in two years.

The short answer: Most small distributors need both, split by partner. Use Electronic Data Interchange (EDI) for the trading partners who mandate it, because their format is a fixed input you cannot negotiate. Use an application programming interface (API) for the systems you control. For two or three partners, a shared order form and a person often beats both.

EDI is a standardized document format that trading partners exchange as structured messages, using agreed types such as a purchase order or an invoice. This article does not recommend a product. Most pages that rank on this question are published by vendors who sell one side of it.

What is EDI, and what is an API?

EDI is old, specified and stable. In North America the standards come from the Accredited Standards Committee X12, which defines and maintains the transaction sets used across the supply chain: 850 for a purchase order (PO), 855 for a PO acknowledgment, 856 for a ship notice or advance ship notice (ASN), 810 for an invoice, 846 for inventory and 820 for remittance advice. Elsewhere the equivalent is UN/EDIFACT, whose directories are published by UNECE with messages named ORDERS, ORDRSP, DESADV and INVOIC. Retail grocery largely runs on GS1 EANCOM, a subset of UN/EDIFACT that carries GS1 product and location identifiers.

Transport is specified too. AS2, defined in RFC 4130, packages business data as MIME over HTTP with signing and encryption, and returns a Message Disposition Notification (MDN) as an authenticated acknowledgment of receipt.

An API is the other model. Rather than exchanging documents, two systems call each other continuously: yours asks for orders, posts stock levels, pushes an invoice. The format is defined by whoever publishes the API, and it changes when they change it.

The difference that decides your case is not speed. It is who owns the format.

Which one does each trading partner actually let you choose?

Start here, because it removes most of the argument.

A large retail or grocery partner that mandates EDI is a fixed input. You will not talk them out of it. The documents they require, the identifiers they use and the timing windows are in their supplier pack. Treat that pack as a specification, not a preference.

Everyone else is a choice. A dealer ordering from your website, a partner with no requirement, your own warehouse or third-party logistics provider (3PL): those flows are yours, and an API or a portal is usually simpler.

So the first thing to produce is not an architecture diagram. It is a list, one row per trading partner: what they require, which documents, how many orders a month, and who owns it after launch.

How do EDI and an API compare on the dimensions that decide it?

	EDI	API
Who sets the format	The trading partner, inside a published standard	Whoever publishes the API
Latency	Batched, often in scheduled windows	Continuous, request by request
Setup cost shape	Mapping and testing per partner	Build once per integration
Ongoing cost shape	Subscription plus per-document or network fees	Engineering time, hosting, version upkeep
Error visibility	Acknowledgment messages built into the standard	HTTP status codes and alerting you build
Skills needed	Document mapping and partner compliance	Developers who own the code
Typically breaks when	A partner changes their spec or an identifier is wrong	The publisher versions, throttles or deprecates
Good fit	Partners who mandate it, high document volume	Your own systems, partners who publish an API

Two documented examples make the row about error visibility concrete.

On the EDI side, X12 publishes the supply chain transaction flow as an ordered exchange: the buyer sends an 850, the seller replies with an 855, then sends an 856 before delivery and an 810 to bill, and the buyer sends an 820. Each transaction is answered by a 997 functional acknowledgment confirming it was received and usable. Nothing moves silently. AS2 adds the signed MDN on top.

On the API side, you build that yourself. Shopify documents a calculated query cost model with a leaky bucket, where an app spends points per second according to plan and receives a throttle error when the bucket is full, so your code has to back off and retry. It also documents that it retries a failed webhook up to eight times in a four-hour period, then removes the subscription. Both are reasonable, and both are yours to handle. Neither tells your operations team anything unless you build failure alerts.

What is the third option nobody sells?

For two or three partners, a shared order form or a small portal plus a person beats both.

A buyer fills in a form that only offers stock keeping units (SKUs) and prices they are entitled to. The submission lands in your enterprise resource planning (ERP) system or store as a real order. Somebody checks the exceptions. No mapping fees, no certification, no engineering on call.

This is not a lesser answer. It removes the retyping, which is where the cost sits, for partners who never asked for a standard. If those partners reorder the same items regularly, the question becomes whether to build or buy the reorder portal, not whether to buy EDI.

The honest limit: it does not satisfy a partner who mandates EDI, and it stops scaling when one person cannot keep up with the exceptions.

What does each one really cost?

The costs sit in different places, which is what makes comparison hard.

EDI cost is mostly recurring and linked to volume. You typically pay a service provider a subscription, plus per-document or network charges, plus a one-off mapping and testing fee for each new partner. It grows as document count grows.

API cost is mostly up front and linked to people. You pay for a build, then for the time to keep it working through version changes, credential rotations and the partner's own releases.

Here is the shape, with illustrative numbers. Use your own rates.

Two partners mandate EDI. You trade four documents per order (850, 855, 856, 810) on 75 orders a month each, so 600 documents a month.

• Service subscription: €250 a month
• Documents: 600 × €0.10 = €60 a month
• Year one: (€250 + €60) × 12 = €3,720, plus a one-off mapping fee per partner

One further partner publishes an API and does not require EDI.

• Build: 50 hours × €80 = €4,000 once
• Upkeep: 2 hours a month × €80 = €160 a month, or €1,920 a year
• Year one: €5,920. Year two: €1,920

The API costs more in year one and less afterward, and it does not grow with document count. The EDI line is smaller now and rises with every new partner and every extra document. Neither is cheap, and both numbers are illustrative. Run yours the same way you would price any other automation decision.

Who owns it after launch?

This question kills more integrations than any technical one.

EDI ownership usually looks like a relationship with a service provider plus someone internal who reads partner compliance notices and handles rejected documents. It is an operations job.

API ownership is an engineering job. Someone reads deprecation notices, upgrades versions, rotates credentials and responds when a retry window closes. If that person is a contractor who finished six months ago, you do not have ownership. You have a countdown.

Write the owner's name next to each partner row before you sign anything. That line belongs in your B2B integration checklist alongside the technical ones.

When is neither worth doing?

• One partner, low volume. Twenty orders a month by email does not justify either.
• The partner has not actually mandated anything. Ask before you build. "It would be nice" is not a requirement.
• Your product data is not ready. EDI fails on identifiers. If your SKUs, barcodes and locations are inconsistent, fix that first or every document gets rejected.
• Nobody will own it. See above.
• The flow is a negotiation. Quotes, custom pricing and credit decisions stay with people.

What should you measure?

Before you commit, write down per partner:

• Orders per month, and documents per order
• Minutes of manual handling per order today
• Rejected or non-compliant documents per month, and how you found out
• Time from PO received to acknowledgment sent
• Chargebacks or penalties from partner compliance programs

After launch, the numbers that matter are rejections, manual touches per order and time to acknowledgment. If manual touches did not fall, the integration moved the work rather than removing it. Warehouse-side flows deserve the same treatment, since 3PL integration errors show up as missing ship notices long before anyone calls them an EDI problem.

How do you decide this week?

1. List every trading partner and what each one actually requires, in writing.
2. Mark the mandates. Those rows are EDI, and the decision is made for you.
3. For the rest, count orders per month and minutes of manual handling per order.
4. For any partner under a few orders a week, price the form-plus-a-person option first.
5. Name an owner for every remaining row before you ask a single vendor for a quote.

Partner requirements first, volume second, ownership third. Everything else follows, and it sits inside the wider B2B automation audit rather than replacing it.

FAQ

Is EDI obsolete?

No. EDI standards are actively maintained: X12 publishes and updates its transaction sets, UNECE publishes UN/EDIFACT directories, and GS1 maintains EANCOM for retail supply chains. Large retail, grocery and automotive partners still mandate it, so for those relationships it is a current requirement rather than legacy technology.

Do I have to use EDI if my customer asks for it?

If they mandate it, yes, or you stop trading with them. Ask for the supplier pack and read it before you agree to anything. It names the documents, identifiers, timing windows and testing steps, and those are the real scope of the work.

Can an API replace EDI with a large retail partner?

Usually not. The partner sets the format, and their systems are built around standardized documents exchanged with hundreds of suppliers. Some partners now offer an API alongside EDI, so it is worth asking, but treat the answer in their supplier pack as the constraint rather than something to negotiate.

Which EDI documents does a small distributor usually need?

Most start with the purchase order, the purchase order acknowledgment, the advance ship notice and the invoice, with inventory and remittance advice added later. The exact list comes from each partner. In X12 terms that is the 850, 855, 856 and 810, and in UN/EDIFACT terms ORDERS, ORDRSP, DESADV and INVOIC.

Is EDI or an API cheaper?

They are cheap in different ways. EDI cost is mostly recurring, through subscriptions and per-document or network fees that grow with volume. API cost is mostly up front, in engineering time, plus ongoing upkeep as versions change. Compare them over three years per partner, not as a single sticker price.

Do I need both EDI and an API?

Most distributors with a mix of partners end up with both, plus a portal or order form for the smallest accounts. Split the decision by partner rather than picking one technology for the whole business, and give each flow an owner.

Sources

• X12: Transaction Sets for the maintained X12 transaction sets.
• X12: Supply Chain Transaction Flow for the documented 850, 855, 856, 810, 820 and 997 sequence.
• UNECE: UN/EDIFACT Directories for the UN/EDIFACT message directories.
• GS1: EANCOM for EANCOM as a UN/EDIFACT subset with GS1 identifiers.
• RFC 4130: AS2 for AS2 transport, signing, encryption and MDN receipts.
• Shopify developer docs: Rate limits for calculated query cost, the leaky bucket and throttling.
• Shopify developer docs: Troubleshoot webhooks for the webhook retry window.

Someone quotes you a number to stop your team retyping purchase orders. The number is for building it.

A year later you are paying a connector subscription, a person is spending four hours a month clearing flagged orders, and an engineer spent two days in March because your store's API version was retired. None of that was in the quote. None of it was hidden either. Nobody asked.

The fix is not a better quote. It is a calculation with every line in it, done before you commit, using your own numbers.

The short answer: Add the one-off costs of discovery, build, testing and the change to your team, then the recurring costs of subscriptions, usage, exception review and maintenance. Value the benefit as hours recovered plus errors avoided. Months to payback is the one-off cost divided by monthly benefit minus monthly recurring cost.

The true cost of an automation is the one-off cost to design and build it plus everything it costs every month for as long as you run it. Every number below is illustrative. Replace all of them.

Why do automation estimates come in wrong?

Three reasons, and they compound.

First, the quote prices the build. The build is one line of about nine.

Second, the benefit is measured against zero rather than against today. Today's manual process has a cost and an error rate. You are not buying perfection, you are buying the difference.

Third, gross hours get counted as recovered hours. If 300 orders a month stop being typed but 60 of them get flagged for review, you did not recover all of that time. You recovered part of it and moved the rest.

There is a fourth, quieter one. The change costs something even when the software works. For a few weeks the new way is slower than the old way, because the person doing it is checking everything twice and still has the old habit. Someone has to learn what the exception queue means and what to do when it fills up. That is real time, it lands in the first month, and leaving it out makes the early weeks look like failure when they are just the change. Put a number on it, however rough, and it stops being a surprise.

What does the cost side actually contain?

Nine lines. The split between one-off and recurring matters more than any single figure, because the recurring lines are what decide whether this is still a good idea in year three.

Cost line	One-off or recurring	Typical shape (illustrative)
Discovery and specification	One-off	Days of your time and the builder's, scaling with how many buyers and formats exist
Build	One-off	The quoted number, usually the only one estimated
Testing against real edge cases	One-off	A meaningful percentage on top of build, and you supply the awkward documents
Change for the people doing the work	One-off, mostly	Training, a slower first few weeks, one person who now owns it
Connector or platform subscription	Recurring	Per seat, per operation or per execution
Per-document or per-call usage	Recurring	Per page or per API call, scales with order volume
Exception review	Recurring	Minutes per flagged item times volume
Maintenance when either end changes	Recurring, lumpy	Concentrated around platform version deadlines
Monitoring and alerting	Recurring	Small, and usually the first thing cut

The shapes are illustrative. The list is not. If a proposal is missing the bottom four rows, it is a build estimate, not a cost.

Subscription pricing is worth checking rather than guessing, because the pricing model changes how cost behaves as you grow. Make's published pricing lists paid plans from $9 a month for 10,000 credits, checked 16 September 2026. n8n's pricing page lists a Starter plan at 20 euros a month billed annually for 2,500 workflow executions, Pro at 50 euros for 10,000, and a self-hosted community edition available on GitHub, checked the same day. Both are usage-shaped, so doubling your order volume moves that line. Self-hosting trades the subscription for your own hosting and your own upgrades, which is a swap, not a saving.

Per-document costs are usually small. Amazon's Textract pricing lists the Analyze Expense API at $0.01 per page in US West (Oregon) for the first million pages, checked 16 September 2026. At 600 pages a month that is about six dollars. Worth putting in the table, not worth agonising over. Prices and currencies differ by vendor and region, so take each from the vendor's own page on the day you build your estimate.

What are the two costs everyone forgets?

Exception review. Every automation has a queue. Orders that fail a catalog check, a price check or an address check land there, and a person clears them. This cost never goes to zero, and it is the cost that decides whether the project works. Estimate it as minutes per exception times exceptions per month. If you do not know your exception rate, you do not have an estimate, you have a hope. Measuring it is the job of a proper accuracy test before you build.

Maintenance when a system at either end changes. This is not bad luck. It is published schedule. Shopify's API versioning policy documents a new API version every three months, each stable version supported for a minimum of 12 months with at least nine months of overlap between consecutive versions, and an app targeting an inaccessible version gets responses from the oldest accessible stable version instead. Read that as a calendar: at least one deliberate upgrade pass a year, on somebody's time, whether or not anything about your business changed. Your accounting system, your 3PL and your ERP each have a version policy too. Find them and add them up.

A third cost hides in the platform tier. Shopify documents that its B2B catalogs determine the products and prices a company can access, and that Basic, Grow and Advanced plans allow up to three active catalogs across all B2B markets, while Plus removes that ceiling. If you need distinct pricing for forty dealers, the honest options are a plan change or custom work. Both are a cost line. Neither belongs in a footnote.

How do you value the benefit without inventing numbers?

Three benefit lines, in descending order of how confident you can be.

Hours recovered. Minutes per task times tasks per month, valued at a rate you choose. Use a fully loaded cost, not a salary divided by hours. Count gross hours here and put the review time on the cost side, so it appears once.

Errors avoided. Not errors eliminated. Your manual process has an error rate and so will the automated one. The benefit is the difference, valued at what one error actually costs you: the credit note, the return freight, the repick, the admin, and the part you cannot invoice, which is the buyer's patience. Pick a number, write down how you got it, and use the same number everywhere.

Speed, only where it converts. Faster order confirmation is worth money when you can point at the mechanism: an order that was cancelled because confirmation took two days, a buyer who splits orders with a competitor on lead time. If you cannot name the mechanism, put zero in this line. A zero you can defend beats a guess that flatters the project.

What does a fully worked example look like?

Illustrative throughout. A wholesale brand receiving 300 emailed purchase orders a month, 6 minutes each to type, at a fully loaded €35 an hour.

One-off costs

• Discovery and specification: €1,200
• Build: €7,500
• Testing against real edge cases: €1,800
• Change for the team, roughly 20 hours at €35: €700
• Total one-off: €11,200

Recurring costs, per month

• Connector subscription: €60
• Document extraction usage, about 600 pages: €6
• Exception review, 20% of 300 orders flagged, 4 minutes each, so 4 hours at €35: €140
• Maintenance, averaged from about €2,400 a year: €200
• Total recurring: €406 a month

Benefits, per month

• Hours recovered: 300 × 6 minutes = 1,800 minutes, so 30 hours at €35 = €1,050
• Errors avoided: manual error rate 1% gives 3 bad orders a month, automated 0.5% gives 1.5, so 1.5 avoided at €120 each = €180
• Speed: €0, because this business cannot yet name a lost order
• Total benefit: €1,230 a month

Payback

Net monthly benefit is €1,230 minus €406, which is €824.

Months to payback = one-off cost divided by net monthly benefit = 11,200 ÷ 824 = about 13.6 months.

First year on the same figures: total cost of €11,200 plus twelve months of €406, which is €16,072, against a first year benefit of €14,760. So year one closes about €1,312 down, and the project turns positive early in year two.

That is a reasonable project, and it is nowhere near the "pays for itself in four months" version you get by dividing the build cost by gross hours saved. That shortcut would have said 7.1 months.

What if the estimate is wrong?

Two things move most: volume and maintenance. Test both before you sign anything.

Scenario (illustrative)	Net monthly benefit	Months to payback
Base case	€824	13.6
Volume halves to 150 orders a month	€282	39.7
Maintenance costs double	€624	17.9
Both at once	€82	over 130

Volume is the brutal one. Halving it halves the benefit while leaving the entire build cost where it was, and the answer flips from yes to no. So if your order volume is seasonal, run the calculation on a quiet quarter, not a busy one. If a single account supplies most of the volume, run it as though that account left.

Doubling maintenance hurts less than it feels like it should, which is a useful thing to know. It is a reason to insist the maintenance line exists, not a reason to walk away.

When does the maths say do not do it?

Say no when:

• Payback runs past about 18 months. You are integrating systems whose owners ship breaking changes on a published quarterly cadence. A payback horizon longer than the rate of change is a bet against the calendar.
• Volume is below the line. Under roughly 50 orders a month, at these illustrative rates, almost nothing in this article repays a custom build.
• The rules change every month. Specification churn is the most expensive thing in the table and it never appears in it. Stabilise the process first.
• Nobody owns it. An automation with no named owner has an exception queue nobody clears, which is worse than typing.
• The recovered hours go nowhere. If the 30 hours come back and land on nothing that grows the business, you bought a tidier week for €11,200.
• A cheaper move exists. Configuring quantity rules and volume pricing you already pay for costs an afternoon. Moving your top reorder accounts online removes the work instead of automating it, which is the build versus buy question. If most of your volume is with a few large buyers, a structured feed may beat a custom integration, which is the EDI versus API question, and X12 maintains the 850 purchase order transaction set for exactly that.

What should you measure after launch?

An estimate you never check is a story. Write the estimate down, then track the same lines for six months:

• Minutes per order, measured by watching, not asking
• Exception rate, and minutes spent per exception
• Errors that reached the buyer, and the real cost of each one
• Maintenance hours logged, with the cause written next to them
• Actual subscription and usage spend, from the invoice
• Time from order received to order confirmed

Then put actual next to estimated, line by line. The gaps teach you more about your next project than the project taught you. Exception review is usually higher than estimated and maintenance lumpier, which is why those two lines exist in the table at all.

How do you run your own numbers this week?

1. Count one task: minutes, times per day, working days. That is your hours line.
2. Write down what one error costs you, and how you arrived at the figure.
3. Get a quote, then add discovery, testing, change, subscription, usage, review, maintenance and monitoring underneath it.
4. Divide one-off cost by net monthly benefit. That is your payback in months.
5. Redo it with volume halved. If it still works, build it.

That sequence is the Find, Prioritize, Automate methodology with a calculator attached, and it decides which handoff from your B2B automation list goes first. If you want the arithmetic checked before you commit, that is what software integrations work should start with anyway.

FAQ

How much does B2B e-commerce automation cost?

There is no single price, because the cost is one-off build plus everything it takes to run. Price nine lines: discovery, build, testing, the change for your team, subscriptions, usage, exception review, maintenance and monitoring. A proposal that covers only the build is a build estimate, not a cost.

What is a reasonable payback period for an automation project?

Months to payback is your one-off cost divided by monthly benefit minus monthly recurring cost. Anything under about 12 months is comfortable, and anything past about 18 months is a bet against platform change, since the systems at either end publish breaking changes on a regular cadence.

Which automation costs are most often forgotten?

Ongoing review of exceptions and maintenance when a system at either end changes. Neither goes to zero. Exception review is minutes per flagged item times volume, and maintenance is scheduled work, because platforms publish version deprecation dates well in advance.

How do you value the hours an automation saves?

Multiply minutes per task by times per day by working days per month, and value the result at a fully loaded hourly cost rather than a salary. Count gross hours as benefit and put the remaining review time on the cost side, so the same time is never counted twice.

How do you put a price on an error?

Add what one wrong order actually costs: the credit note, the return freight, the repick, the admin time, and any lost margin. Use the same figure everywhere in your calculation, write down how you arrived at it, and value only the difference between your current error rate and the expected one.

When is automation not worth the money?

When volume is too low to repay the build, when the rules change every month, when nobody owns the result, when the recovered hours go nowhere useful, or when configuring a feature you already pay for would do the job. Halve your volume in the calculation. If it stops working, do not build it.

Sources

• Amazon Textract pricing for the per-page Analyze Expense rate used in the usage line, checked 16 September 2026.
• Make pricing for published plan prices and included credits, checked 16 September 2026.
• n8n pricing for cloud plan prices, included executions and the self-hosted community edition, checked 16 September 2026.
• Shopify API versioning for the quarterly release cadence, the minimum 12-month support window and the fall-forward behaviour, which is the maintenance line.
• Shopify: B2B catalogs for catalog-driven pricing and the per-plan limit on active catalogs.
• Shopify: quantity rules and volume pricing in B2B for the platform features worth configuring before building anything.
• X12 EDI examples for the 850 purchase order transaction set, the alternative integration path with its own cost shape.

A buyer places a wholesale order on net 30. The store takes it, the warehouse ships it, and the order appears in your accounting system a minute later. Everything looks connected.

Now open your accounts receivable report. The order is not on it.

It is sitting in the ledger as a paid sales receipt, for money nobody has sent you. Nobody will chase it, because the books say it is settled. Six weeks later a transfer arrives covering four orders, and somebody spends an afternoon working out what it was for.

The short answer: An order on payment terms should post to your accounting system as an open invoice with a due date, not as a paid sales receipt. Receipts record money you already hold. Terms orders are money you are owed, so they belong in accounts receivable until the transfer arrives and gets applied against that invoice.

Net 30 is a payment term where the buyer receives the goods now and pays the full invoice within 30 days of the invoice date. That one fact should change what your systems write down.

Why does your connector post every wholesale order as paid?

This is not a bug. It is a default built for a different customer.

Most store-to-accounting connectors were designed for consumer retail, where the card is charged before the order is confirmed. Order and payment happen in the same second, so the connector writes one document for both.

QuickBooks documents that an invoice "informs your customers of what they owe you", while a sales receipt "records goods or services paid for immediately at the time of purchase". A receipt states that you hold the cash. For a terms order, that is false.

The store usually knows better than the ledger. Shopify's B2B documentation shows the platform modelling terms properly: the available terms run from net 7 to net 90, and "all terms start from the day the order is placed". The same page adds that "payments aren't automatically captured when the payment terms expire", and that the order then shows as Overdue to the buyer.

So the due date exists. The unpaid status exists. They stop at the boundary, because the connector only knows how to write "paid". Same problem as an integration that fails without telling anyone: the damage comes from the silence.

What breaks when a net 30 order lands as a receipt?

Four things, in the order you notice them.

Nobody chases the money. Collections work off the aging report, and accounts receivable is money owed for goods already supplied. An order that never became an invoice is not on that report, so it is never overdue.

The cash forecast is wrong both ways. Today it overstates cash you hold. Next month it understates what is due in.

Reconciliation breaks when the transfer lands. A buyer pays three invoices with one transfer. If those invoices do not exist, the payment sits unapplied or gets coded straight to sales, and the revenue is in the books twice.

Your credit picture disappears. You cannot see that an account is at its limit if half its open orders were recorded as settled.

Both flows below are correct, for different order types.

	Prepaid order (card paid at checkout)	Terms order (net 30, 60 or 90)
When cash arrives	Before the goods ship	Weeks after the goods ship
Correct document	Sales receipt, or invoice marked paid	Open invoice with an issue date and a due date
Where it appears	Sales, plus a clearing account for the payout	Sales, plus accounts receivable
Reference the buyer needs	Order number	Purchase order (PO) number
What the bank line reconciles against	The platform payout batch	One or more specific open invoices

How do you check your own setup in ten minutes?

Do not read the settings page. Watch what your connector writes.

1. Create a test company account with net 30 terms, or use a quiet real one.
2. Place a small test order on those terms, for one cheap item.
3. After the sync, find the document it created in the accounting system.
4. Ask three questions of it. Does it have a due date? Is the outstanding balance greater than zero? Does it appear on the aging report?
5. Check which customer record it sits against, and whether the PO number made it across.

Any no means you have found it. Void the test document afterwards so it does not pollute the month.

What should a terms order map to in your ledger?

The fix is a mapping job, not a new system. This is ordinary software integration work between the store and the ledger you run.

• The company, not the buyer. Three people at the same dealer must post to one customer record, or the aging report fragments and credit limits mean nothing.
• The PO number. Most B2B buyers will not pay an invoice that does not quote it. Put it in the invoice reference field, not a note nobody prints.
• Issue date and due date. Shopify's developer documentation covers fixed, net and event-based terms plus percentage deposits, and net terms there run from the order date. Decide which date your ledger uses, then hold it.
• Tax treatment. Official EU guidance is that you do not charge VAT on goods sent to a business in another EU country if the customer has a valid EU VAT number, with services handled by the customer under the reverse charge. Map tax per line from the order.
• Line detail. Stock keeping units (SKUs), quantities, the price actually charged, shipping and discounts, each to the right ledger account. The invoice must carry that account's contract price, not the list price.
• Part payments and credit notes. A deposit reduces the balance on one invoice. A short shipment or return gets a credit note against the original, keeping the audit trail.
• Idempotency. Stripe documents the pattern worth copying: it saves the result of the first request for a given idempotency key and returns it for later requests with the same key. A retry must update the existing invoice, never raise a second. Duplicate invoices come from the same place as duplicate orders in an integration.

If your integration listens to webhooks, know how long the platform keeps trying. Shopify documents that it retries failed webhook calls up to eight times in a four-hour period, then removes the subscription. An order that arrives while your endpoint is down does not queue forever. It never becomes an invoice, and nothing tells you.

What does a missing invoice actually cost?

The numbers below are illustrative. Redo them with yours.

Say you ship 40 orders a month on terms, at an average order value (AOV) of €1,800. One in ten posts as a paid receipt, through a channel the mapping does not cover.

• 40 × 10% = 4 orders a month
• 4 × €1,800 = €7,200 a month that never enters accounts receivable
• Over six months, €43,200 of invoices that were never raised

Most of that money arrives eventually, because buyers pay against their own purchase orders. But it arrives late and unasked for. Say half get caught at reconciliation, at 45 minutes each: 24 × 45 minutes is 18 hours over six months, or about €630 of rework at €35 an hour.

The other half is the real problem. Those are invoices nobody raised, on accounts that have no idea they owe you. If one stops trading, that is not a late payment. It is a write-off you never provisioned for.

Fixing the mapping is not free either, and someone still handles the exceptions. Price that before you commit, the same way you would any other automation decision.

Where does a person have to stay in the loop?

Automating the document does not mean automating the judgment. Keep a human decision on:

• Credit limits. An order that takes an account past its limit should stop and wait.
• Terms changes. Moving an account from prepaid to net 30 is a commercial decision.
• Disputes. When a buyer short-pays for a damaged pallet, the credit note is a negotiation first.
• Write-offs and payment plans. Never automatic.

The issuing, numbering, due dates, payment application and the reminder at day 25 are mechanical. They belong to the machine.

When is this not worth automating?

• You ship a handful of terms orders a month. Four invoices by hand is not a project.
• Your enterprise resource planning (ERP) system already owns the order. Fix the ERP flow instead.
• Billing is bespoke per order. Milestone billing and consignment need a person, not a rule.
• Nobody reads the aging report. Raising more invoices changes nothing.

What should you measure before and after?

Write these down before you touch anything:

• Terms orders shipped per month, and how many appear on the aging report within 24 hours
• Days sales outstanding (DSO), or your simplest version of it
• Unapplied payments sitting in the ledger at month end
• Hours spent on month-end reconciliation
• Credit notes raised only to correct a wrongly posted document

Check again after two billing cycles. The first number matters most: the share of terms orders that become open invoices untouched.

How do you fix this in one week?

1. Place one test order on terms and find the document it created.
2. Check it for a due date, an outstanding balance and a place on the aging report.
3. List the missing fields: company, PO number, due date, tax.
4. Map them between store and ledger, with the order number as the unique key.
5. Re-run the test, then reconcile one real buyer payment end to end.

That is the Find, Prioritize, Automate approach on one document. Then take the next handoff from the wider B2B automation audit.

FAQ

Why does my store-to-accounting connector mark wholesale orders as paid?

Because most connectors were built for consumer retail, where the card is charged at checkout and the order and the payment are the same event. They write one document that records both. Wholesale orders on payment terms separate those events by weeks, so the default records money you have not received.

Should a net 30 order create an invoice or a sales receipt?

An invoice. A sales receipt says the money is already in hand, which is only true for a prepaid order. A net 30 order should create an open invoice with an issue date, a due date and an outstanding balance, so it stays on the accounts receivable aging report until the payment is applied.

Which customer record should a wholesale invoice sit against?

The company, not the individual who placed the order. Several buyers at the same dealer need to roll up into one customer record. Otherwise the aging report splits across duplicates, credit limits cannot be enforced, and one payment covering several orders has no clean place to land.

How should part payments on a wholesale invoice be handled?

Apply the payment against the existing invoice so the outstanding balance drops. Do not create a second document for the remainder. The invoice keeps its original due date and stays on the aging report until it is fully settled.

What happens when a buyer returns part of a terms order?

Raise a credit note against the original invoice rather than editing or deleting it. The credit note reduces the open balance, keeps the audit trail intact, and gives the buyer a document they can match to their own purchase order.

Can I fix orders that already posted as receipts?

Yes, but do it deliberately. Pull the list of terms orders that posted as paid, agree the correction with whoever owns the books, and void or reverse each one before raising the correct invoice with its original date. Fix the mapping first, or you will repeat the cleanup next month.

Sources

• Shopify Help Center: Setting up payment terms in B2B for net terms, the order-date start, deposits and manual capture.
• Shopify developer docs: Set payment terms for fixed, net and event-based terms.
• QuickBooks: Invoices, sales receipts, bills and statements for both document definitions.
• Xero: What is accounts receivable? for the accounts receivable definition.
• Stripe API reference: Idempotent requests for documented idempotency-key behaviour.
• Your Europe: Cross-border VAT rates in Europe for EU B2B VAT and the reverse charge.
• Shopify developer docs: Troubleshoot webhooks for the webhook retry window.

A buyer calls to say the price on their portal is wrong. You ask three people what the price should be and get three answers. Each one is right, according to a different document.

Sales has the email where the discount was agreed in March. Finance has the invoice history. The store has whatever was typed into it last. Somewhere there is a spreadsheet called price list FINAL v4 that everyone quietly treats as the truth.

Pricing gets named as the hard part of business to business e-commerce constantly, and then left at that. It is not hard because the arithmetic is difficult. It is hard because several correct rules apply to the same line at the same time, and nothing anywhere says which one wins.

The short answer: B2B customer specific pricing works when one system owns the price, the order of precedence between rules is written down, every negotiated price has a start and end date, and a small set of representative accounts is tested after every change. Automation should carry the agreed number reliably. It should never decide the number.

Customer specific pricing is the practice of showing each business buyer the price agreed with them, instead of one public list price, by layering rules on top of a base price list.

What actually decides the price on a B2B order?

Seven layers show up in almost every wholesale business. They stack, and each one can override the one below it.

1. Base price list. The default trade price for a product.
2. Customer or group override. A percentage or fixed price for a tier such as distributors, or for one named account.
3. Volume or quantity break. A lower price above a certain quantity.
4. Contract price. A negotiated number for one account, usually with a start and end date.
5. Temporary promotion. A seasonal or clearance price, meant to expire.
6. Currency. The same product sold in euros, pounds and dollars, where converting on the fly is not the same as a deliberate local price.
7. Cost-plus. A price derived from your cost, so it moves when your supplier moves.

Each layer has an owner, and each one fails in a specific way when nobody owns it.

Rule type	Who usually owns it	The failure when unmanaged
Base price list	Commercial or finance	Price rises never reach the store, so margin quietly shrinks
Customer or group override	Sales leadership	Every rep invents a tier, and tiers stop meaning anything
Volume or quantity break	Commercial, with finance sign-off	Buyers split or combine orders to game the break
Contract price	The account owner who negotiated it	Runs forever because nobody set an end date
Temporary promotion	Marketing	Becomes the permanent price nobody dares raise
Currency price	Finance	Auto-conversion drifts from the local market price
Cost-plus	Finance or purchasing	Supplier cost changes, sell price does not, margin goes negative

Print that table and write a name in the middle column. If a cell is empty, that is the rule that will break first.

What do the platforms actually document about precedence?

Here is the part that surprises teams. Your platform already has a precedence rule. You just did not choose it.

Shopify B2B resolves ties by lowest price. In Shopify, a catalog combines product availability with a price list, and catalogs are assigned to companies and company locations. The Help Center states plainly that "if there are multiple catalogs and prices for a specific product, then the lowest price displays to the customer". Assign an account two catalogs and the cheaper number wins, whether or not that was the agreed one.

Volume pricing then behaves differently again. Shopify documents up to ten price breaks per product, applied per variant, and adds that "after you apply volume pricing to a product the price becomes fixed. Any overall adjustment discount set on the catalog won't apply". So a later catalog-wide adjustment silently skips exactly the products you discounted most.

Adobe Commerce resolves ties by an explicit priority number. Its catalog price rules carry a Priority field, and the documentation says "the rule with the highest priority (lowest number, for example, 0, 1, 2, 3…) takes effect". The same page notes that Magento Open Source uses From and To dates on the rule, while Adobe Commerce removed those fields and requires a scheduled update instead.

BigCommerce falls back to the catalogue price. A price record there is "a price override for a particular variant" containing a variant, a price and a currency, and price lists are assigned to customer groups or channels. Crucially, "if an active price list doesn't contain prices for a variant, then the catalog pricing will be used". A missing row does not raise an error. It shows your wholesale buyer the retail price.

Three platforms, three different answers: lowest wins, lowest priority number wins, and fall back to list. None of them is wrong. All of them will happily produce a price your sales director never agreed to.

Five ways customer-specific pricing breaks

1. A spreadsheet is the real source of truth

The store holds a copy that was current the last time someone remembered to upload it. Nothing is wrong with a spreadsheet as a working tool. The problem is two systems both believing they are authoritative, with no direction of travel between them.

2. Contract prices with no expiry

A three-month introductory price agreed in March is still running in November, because the field for an end date was blank. This is the most expensive item on this list, and the easiest to fix.

3. No written precedence

Two rules match, one wins, nobody predicted which. If your team cannot answer "a distributor with a contract price orders 600 units, which price applies" without opening the admin, the rule is not written down.

4. Rounding, tax and currency applied in the wrong order

Discount then round, or round then discount, gives different totals at scale. Tax is worse, because it depends on settings most people never open. Adobe Commerce, for example, lets you calculate tax based on unit price, row total or order total, and hold catalogue prices either including or excluding tax. Those choices change the invoice. Currency has the same trap: BigCommerce requires a price record per currency, and without one it converts automatically, which is a display decision standing in for a commercial one.

5. No record of who changed a price

When a buyer disputes a price, the useful question is not what the price is. It is what it was on the day they ordered, and who set it. Some platforms log this for you. Adobe Commerce keeps an admin action log with a configurable retention period, archived to file. Many setups keep nothing at all, which turns every dispute into an argument about memory.

A worked example: when two rules collide

The numbers below are illustrative. Use your own products and your own margins.

An account is set up like this:

• Base trade price: €10.00 per unit
• Distributor group override: 20% off, so €8.00
• Volume break at 500 units and above: €7.60
• Contract price agreed in March for this one account: €7.90, no end date recorded

The buyer orders 600 units. Two rules match. The contract says €7.90. The volume break says €7.60.

On a platform that resolves ties by choosing the lowest price, the buyer pays €7.60. That is €0.30 below the negotiated number, or €180 on this order. If the account reorders 600 units every month, that is €2,160 a year, on one product, for one customer, from a rule collision nobody decided.

Now the second half, which is worse. The €7.90 contract price was meant to run for three months. It is still active. So the business is simultaneously losing €0.30 a unit to the volume break and carrying a contract price that expired in June. Two errors, pointing in opposite directions, on the same line.

Neither is a bug. Both systems did exactly what they were configured to do. The missing piece is a written rule saying a contract price outranks a volume break, and a date field that would have retired the contract on time.

The design that holds

Five commitments, none of which require new software.

• One system owns price. Everything else holds a copy that can be deleted and rebuilt from the owner. If you cannot rebuild your store's prices from one source in an afternoon, you do not have an owner, you have two masters.
• Precedence is written down, as an ordered list. For example: contract price, then promotion, then volume break, then group override, then base list. Whatever order fits your business, it must exist on paper before it exists in code, and the platform's own default must be checked against it.
• Every negotiated price has a start and an end date. No exceptions. An indefinite price is a decision to never revisit it. Where the platform supports scheduled updates, use them.
• A price change is a release, not an edit. Draft it, test it, publish it, and be able to roll it back.
• Everything is logged. Who, what, when, and the previous value. If the platform will not do it, a simple append-only record of price changes is a few hours of work and settles disputes permanently.

This is ordinary business process automation applied to the one area where a small error repeats on every line of every order.

The test matrix you run after every price change

The cheapest safety net in pricing is a short list of real accounts with known correct answers. Ten rows, checked after every change, by hand at first.

Account	Product	Quantity	Expected price	Rule that should win
Distributor with a contract	Core SKU	600	€7.90	Contract price
Same distributor	Core SKU	100	€7.90	Contract price, below volume threshold
Distributor without a contract	Core SKU	600	€7.60	Volume break
New account, no overrides	Core SKU	10	€10.00	Base list
Export account, other currency	Core SKU	100	Local list price	Currency-specific record

Illustrative figures again. Fill the expected column from the commercial agreement, not from what the system currently shows, otherwise you are testing that the bug is still there. Once the list is stable, the same rows make an obvious automated check that runs after every price import.

When should pricing stay human?

Automation carries the agreed number. It does not agree it. Keep a person in charge of:

• The negotiation itself. Volume commitments, annual terms and the price at the end of them.
• Exceptions. A one-off price to win back an account is a commercial decision, not a rule.
• Cost-plus renegotiation. When a supplier raises cost, a person decides what to pass on.
• Credit and terms. Price and payment terms get negotiated together. Terms belong with net terms and accounting, and they need approval, not a trigger.
• Very small catalogs. Twenty products and six accounts do not need a rules engine. A checked list and a calendar reminder are enough.

The same boundary applies to machine learning. Extraction tools can read a purchase order and propose lines, but the price must come from your own price rules, which is the core argument in AI order entry accuracy. Never let a model decide a number a customer will be invoiced for.

What to measure before and after

Write these down before you change anything.

• Price disputes raised by buyers, per month
• Credit notes issued because of a pricing error, per month
• Negotiated prices currently live with no end date
• Days from a price decision to that price being live for buyers
• Number of places a price can be changed

The last one is the real health metric. It should be trending towards one. If you are weighing a portal or a platform change at the same time, price this work separately, because pricing rules follow you into any new system. That is part of the calculation in build versus buy for a reorder portal.

Fix one pricing rule this week

1. Export every live negotiated price and sort by start date. Find the ones with no end date.
2. Give each one an end date, even if that date is twelve months out.
3. Write your precedence list in one sentence per layer, and check it against what your platform documents.
4. Build the ten-row test matrix and run it once, by hand.
5. Name one owner per rule type from the first table.

That is one week, no new software, and it removes the two failures that cost the most. Then the next layer. It is the same Find, Prioritize, Automate methodology we apply to every handoff in B2B ecommerce automation.

FAQ

How do B2B customer-specific prices actually work?

A base price list sets the default, and rules layered on top change it for particular buyers: group overrides, volume breaks, contract prices, promotions and currency-specific prices. When more than one rule matches an order line, the platform applies its own precedence rule to pick a winner, so the agreed price only reaches the buyer if your configuration matches your commercial agreement.

Which price wins when two pricing rules apply to the same order?

It depends on the platform, and the defaults differ. Shopify's B2B documentation says the lowest price displays when multiple catalogs apply, Adobe Commerce uses an explicit priority number where the lowest number takes effect, and BigCommerce falls back to catalog pricing when a price list has no record for a variant. Write your intended order of precedence down, then check it against what your platform documents.

Should contract prices have an expiry date?

Yes, every one of them. A negotiated price with no end date runs until someone notices, which is usually a margin review months later. Record a start and an end date on every contract price, and put the renewal in the account owner's calendar before the price goes live.

Can I keep my price list in a spreadsheet?

As a working document, yes. As the source of truth for a live store, it causes trouble, because the store holds a copy that ages the moment it is uploaded. Pick one system that owns price, treat the spreadsheet as an input to it, and make sure the store's prices can be rebuilt from the owner at any time.

How do I stop rounding and tax errors on wholesale prices?

Decide the order of operations and document it: discount, then rounding, then tax, or whichever sequence your accountant requires. Check your platform's tax settings, since options such as calculating tax on unit price versus row total, or holding catalog prices with tax included, change the final invoice. Then verify with a test order per country and currency.

Should AI set prices for B2B customers?

No. Use automation and AI to carry an agreed price accurately and to extract order lines from documents, but keep the number itself coming from your own price rules. Negotiated pricing is a commercial decision with contractual weight, and a model that guesses a price creates an invoice you have to defend.

Sources

• Catalogs and pricing in B2B, Shopify Help Center documents that a catalog pairs product availability with a price list, and that the lowest price is displayed when several catalogs apply.
• Quantity rules and volume pricing in B2B, Shopify Help Center documents price breaks per variant and that volume pricing fixes the price so catalog adjustments no longer apply.
• Manage B2B catalogs, Shopify developer docs covers creating price lists and percentage adjustments through the API.
• Create a catalog price rule, Adobe Commerce documents the Priority field and how From and To dates differ between Magento Open Source and Adobe Commerce.
• Scheduled changes for catalog price rules, Adobe Commerce covers scheduling a price rule to start and stop.
• Tax configuration settings, Adobe Commerce documents calculating tax on unit price, row total or order total, and catalogue prices including or excluding tax.
• Price Lists, BigCommerce developer docs documents price records per variant and currency, assignment to customer groups and channels, and the fallback to catalogue pricing.
• Action Logs report, Adobe Commerce documents logging of administrator actions, which is the basis of a price audit trail.

A buyer places a wholesale order on Tuesday. Your store marks it paid. Your accounting system has the invoice. Every screen you own says the order is on its way.

On Friday the buyer emails to ask where it is. You open the warehouse portal and the order is not there. It never was. Your third party logistics provider, the 3PL, refused it on Tuesday afternoon, and the refusal went into a log nobody reads.

This is the most expensive kind of integration failure, because nothing looks broken. A crashed sync gets noticed within an hour. A politely rejected order sits there looking perfect until your best account phones.

The short answer: most 3PL integration errors are rejections, not crashes. The warehouse refuses an order because a product code, a unit of measure or an address does not match what it holds, and that refusal never reaches a person. Fix it with a pre-flight check, a rejection queue someone reviews daily, and a weekly report comparing orders sent against orders acknowledged.

A 3PL integration error is any failure in the link between your store or enterprise resource planning system, the ERP, and your outsourced warehouse that stops an order being picked, packed or reported back correctly.

Why does a rejected order still look complete on your side?

Most store to warehouse integrations are one directional in practice, even when the documentation says otherwise. Your system sends the order, gets a response meaning the message was received, and marks the order as sent. Received is not accepted. The warehouse validates the order afterwards, in its own queue, and that second step is where orders die.

The acknowledgement that comes back is the part teams skip. It needs somewhere to land. If nothing on your side reads it, a rejection has exactly the same effect as silence.

What the platform already sends back

This is not a theoretical gap, and the vocabulary for it is usually already there. On Shopify, a 3PL that runs as a fulfilment service app does not fail quietly at the protocol level. It answers a fulfilment request by calling either an accept or a reject mutation, and the reject mutation takes a reason and an optional message, plus the specific line items it cannot ship.

The reasons are a fixed list. Shopify's documented rejection reasons include INVALID_SKU, INCORRECT_ADDRESS, UNDELIVERABLE_DESTINATION, INVENTORY_OUT_OF_STOCK, MISSING_CUSTOMS_INFO and INTERNATIONAL_SHIPPING_UNAVAILABLE. Read that list again. It is more or less the complete catalogue of ways a warehouse says no, published by the platform.

Shopify's own guidance for fulfilment service developers says the outcome shows on the fulfilment order card in the admin, with the rejection message attached. So the information exists. What does not exist by default is a person whose job is to look at that card today. That is the whole failure.

What EDI has done for decades

Electronic data interchange, EDI, solved the acknowledgement problem long before anyone built a REST integration. In the X12 standard, a supplier answers a purchase order with an 855 Purchase Order Acknowledgment, and the ACK segment carries a status code for every single line. X12's worked example shows IA for a line accepted, IQ for a quantity change, DR for a rescheduled date and IR for a line rejected.

Per-line acceptance, per-line rejection, as a normal part of the conversation. If your custom integration has no equivalent of IR, it is not simpler than EDI. It is missing a feature.

Put an illustrative number on the gap. Say you ship 400 wholesale orders a month and 1.5% get rejected without anyone noticing. That is six orders. Each one takes roughly 40 minutes to spot, diagnose, correct and resend, so 4 hours a month at, say, €35 an hour, about €140. The time is the cheap part. Six late deliveries to trade accounts, each found by the buyer rather than by you, cost far more than €140 in credibility. Redo that arithmetic with your own volume and your own rejection rate.

Eight reasons a warehouse rejects an order

The causes repeat across every warehouse and every platform. The wording of the error changes. The underlying mismatch does not.

Rejection cause	What the buyer sees	The check that prevents it
Stock keeping unit, the SKU, exists in the store but was never created at the warehouse	Order confirmed, then nothing ships	Block the product from going live until the warehouse has acknowledged the code
Codes differ by case, spacing or a supplier prefix	Partial shipment, one line missing	Normalize codes on send, and compare the full catalog against the warehouse list weekly
Bundle or kit sold as a set, warehouse holds only components	Order accepted, warehouse cannot find the item	Decide whether the bundle is built at the warehouse or split into components before sending
Case pack ordered, units sent, or the reverse	Buyer gets 12 units instead of 12 cases	Send the unit of measure explicitly, and reconcile pack quantities at setup
Address validation fails on a flat, unit or building number in the wrong field	Order stuck, no tracking, no explanation	Validate the address at checkout, not at the warehouse
Missing country code or a postal format the warehouse cannot parse	Export order never leaves	Require country on every address and test one order per destination country
Order held for a stock allocation that never clears	Order sits in the portal, nobody chases it	Age the held orders and alert after a fixed number of hours
Duplicate order reference from a retry	Buyer receives two shipments, or none	Send a stable, unique order reference so a retry updates rather than duplicates

Two rows deserve extra attention. Address problems are not carelessness. The Universal Postal Union, which maintains the S42 international addressing standard, describes more than 200 address formats in use worldwide, along with country specific templates for rendering them. A field that is optional in one country is mandatory in another, which is why export orders fail first.

And the last row causes its own damage. Retries that lack a unique reference are the usual source of duplicate orders in ecommerce integrations, and teams often create them while fixing the very rejections listed above.

Case packs, inner packs and bundles: why wholesale breaks first

Retail orders rarely hit this. Wholesale hits it constantly, because the buyer orders in cartons and the store sells in units.

A case pack is the outer carton the warehouse actually picks. An inner pack is the smaller sealed unit inside it. Your store may list all three as separate products, or as one product with a quantity multiplier, or as a single unit with a minimum order quantity of 12. The warehouse holds one physical thing with one code.

Supply chain standards are unambiguous about this. Under the GS1 GTIN Management Standard, a unique Global Trade Item Number is assigned at every level of the packaging hierarchy that can be ordered, priced or invoiced, so the each, the inner pack and the case are different trade items with different identifiers. A change to the number of items in a case means a new number, not an edited one. If your store treats the case as the same product as the unit, you have already left the standard, and the warehouse will eventually make you pay for it.

Platforms give you tools for the store side. Shopify's B2B features document increment quantity rules, where products boxed in multiples of ten can only be bought in tens, and note that these rules apply per variant. That keeps the buyer ordering whole cartons. It does not, by itself, tell the warehouse which physical thing to pick. Both halves have to agree.

Bundles behave the same way. If the store sells a starter set and the warehouse holds four separate components, someone must decide where the set is assembled. Either the warehouse builds it and holds a real code for it, or your integration explodes the set into component lines before sending. Both work. Neither works if the decision was never made and each side assumed the other handles it.

Why treat the product code as a contract between two systems?

Here is the principle that removes most of these errors permanently.

The product code is not a label. It is the only thing the two systems must agree on exactly. Everything else, the name, the description, the images, can differ safely. The code cannot.

That means four commitments:

• One owner. Name the system that creates product codes, usually the ERP or, in smaller setups, the store. Every other system copies. Nobody invents a code locally to solve a Friday problem.
• One format. Fix the character set, the length, the case and whether prefixes are allowed. Write it down. A code that differs only by a trailing space is a different code to a machine and the same code to a human, which is why these bugs survive so long.
• No silent renaming. Changing a code is a migration, not an edit. Old code retired, new code created, mapping kept. This is exactly the discipline GS1 applies to trade item numbers.
• No code goes live before the warehouse confirms it. The launch checklist below is that rule, written out.

This is what makes any software integration survive its second year, and it is worth agreeing before you connect anything.

Three controls that stop silent rejections

You do not need a new platform. You need three small things wired to a person.

A pre-flight check before the order is sent

Before an order leaves your system, check that every code on it exists in the warehouse catalog, that the unit of measure is one the warehouse recognises, and that the address has a country and a postal code in a valid format. Hold anything that fails and tell a person. Catching it here costs a minute. Catching it after rejection costs 40.

A rejection queue with a named owner

Every rejected order goes into one list, with the reason, the order reference and the buyer. One named person reviews it daily, before lunch. Not a shared inbox. Not a channel. A list with an owner and a time. Automation without an owner is just a faster way to lose things, and this is where failure alerts that people actually act on earn their keep.

A weekly orphan report

Count orders sent to the warehouse this week. Count orders acknowledged this week. Subtract. Anything unmatched for more than 24 hours is an orphan, and the list should be short enough to read over coffee. This one report catches what the first two controls miss, including failures caused by your own retry logic.

A launch checklist for adding a product without breaking fulfillment

Most unknown SKU errors arrive in the week after a product launch. Marketing set the product live, and the warehouse learned about it from an error log. Run this before any product becomes orderable.

1. Create the code in the owning system, in the agreed format.
2. Send it to the warehouse and wait for confirmation that it exists there.
3. Confirm the unit of measure and pack quantities match on both sides: units per inner, inners per case.
4. If it is a bundle, confirm where it is assembled and which code the order should carry.
5. Confirm stock exists, or is expected, and that the store is not selling from a zero allocation.
6. Send one test order end to end and watch it appear in the warehouse portal.
7. Only then make the product orderable.

Seven steps, ten minutes, and it removes the single most common rejection cause. The wider version lives in the B2B ecommerce integration checklist.

When should you not build this?

The advice stops applying in a few real situations.

• Very low volume. Under roughly 20 orders a month, a person checking the warehouse portal each morning is cheaper and more reliable than any build.
• You are about to change warehouse. Do not harden an integration you plan to replace within a quarter.
• The warehouse gives you no acknowledgement at all. Some arrangements only expose a portal. Then the fix is commercial, not technical: ask for a status feed or a daily exception file before you write code against a wall.
• The real problem is master data. If your catalog itself is inconsistent, a pre-flight check will reject everything. Clean the codes first.

What to measure before and after

Write these down before you change anything, otherwise you will not know whether the work paid.

• Orders sent versus orders acknowledged, per week
• Rejected orders per week, and the top three reasons
• Median hours from rejection to correction
• Orders where the buyer told you first, per month
• Late shipments traced to an integration fault, per month

Check again after four normal weeks. The fourth number matters most. Buyer-reported failures going to zero is the point, and your account managers will feel it before any dashboard shows it.

Fix one gap this week

1. Pull last month's orders sent and orders acknowledged, and find the orphans.
2. Sort the rejections by cause and take the top one.
3. Add the pre-flight check for that cause only.
4. Name the person who owns the rejection queue, and the time they check it.
5. Schedule the weekly orphan report, even if you build it by hand at first.

Then the next cause. That is the Find, Prioritize, Automate methodology applied to one link in the chain, and the same sequence we use for every handoff in B2B ecommerce automation.

FAQ

What causes an unknown SKU error at a 3PL?

The order carries a product code the warehouse has never been given. Usually the product went live in the store before it was created in the warehouse system, or the code differs by case, spacing or a supplier prefix. Bundles and case packs cause it too, when the store sells a set or a carton and the warehouse only holds components or single units.

Why does my store show an order as fulfilled when nothing shipped?

Because your system recorded that the order was sent, not that it was accepted. Most integrations mark an order as handed over when the warehouse receives the message, and validation happens afterwards. Without reading the acknowledgement back, a rejection looks identical to success on your side.

How do I find orders my 3PL rejected?

Compare orders sent to the warehouse against orders acknowledged by the warehouse for the same period, and list anything unmatched for more than 24 hours. Run it weekly. Pair it with a rejection queue that a named person reviews daily, so new failures surface within hours rather than at the weekly check.

Should I validate addresses before sending an order to the warehouse?

Yes, and earlier if you can. Validate at checkout or at order entry, where the buyer can still correct it. Flat, unit and building numbers in the wrong field are a common rejection cause, and export orders also need a country code and a postal format the warehouse can parse.

Who should own product codes when a 3PL is involved?

One system owns them, usually the ERP, and everything else copies. Fix the format, forbid locally invented codes, and treat a code change as a migration with the old code retired and the mapping kept. GS1 applies the same rule to trade item numbers, including a separate number for each packaging level.

Is it worth automating 3PL rejection handling at low volume?

Often not. Under roughly 20 orders a month, a daily look at the warehouse portal is cheaper and more reliable. It becomes worth building when rejections happen weekly, when buyers report failures before you do, or when a single late wholesale shipment costs more than the build.

Sources

• fulfillmentOrderRejectFulfillmentRequest, Shopify GraphQL Admin API documents how a fulfilment service rejects a request, with a reason, an optional message and specific line items.
• FulfillmentOrderRejectionReason enum, Shopify is the published list of rejection reasons, including invalid SKU, incorrect address, undeliverable destination and missing customs information.
• Build for fulfillment services, Shopify shows the accept and reject flow and where the outcome appears to the merchant.
• X12 855 Purchase Order Acknowledgment example, X12 shows per-line acknowledgment status codes, including the code for a rejected line.
• GTIN Management Standard, GS1 is the rule set for assigning a unique identifier to each level of a packaging hierarchy and for changes to case quantities.
• Addressing solutions and the S42 standard, Universal Postal Union explains why address formats and required fields differ by country.
• Quantity rules and volume pricing in B2B, Shopify Help Center documents increment rules for products boxed in fixed multiples, applied per variant.

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.

Your wholesale buyers can order online. You run a store, an ERP or accounting system, a warehouse or 3PL, and an inbox full of purchase orders.

And someone on your team still spends the morning retyping those purchase orders into the store.

That's not a software problem. Every tool you bought works. The problem lives between them, in the handoffs. And in B2B, handoffs don't just cost time. They cost wrong prices, oversold stock and late orders to your best accounts.

The short answer: B2B e-commerce teams should automate their handoffs first. A handoff is any point where order, price, stock or customer information moves between systems or people by hand: a PDF purchase order retyped into the store, stock counts copied from the ERP, a new wholesale account set up manually. Find them, put a price on them, delete the ones nobody needs, then automate the most valuable one that follows stable rules.

This guide shows you how to do that in about 30 minutes, using one real order from last week. No new tools required.

Why another B2B app won't fix it

When orders feel slow, the instinct is to buy something. A B2B portal. An order management system. An AI order-entry tool.

Here's the math nobody runs first.

A typical B2B e-commerce stack already has more tools than people count: the store, the ERP or accounting system, the warehouse or 3PL, the CRM, the shipping tool, a price list spreadsheet, the payment provider, and the inbox where buyers still send orders. That's eight.

Every tool might need to exchange data with every other one. The number of possible connections grows much faster than the number of tools:

Tools in your stack	Possible tool-to-tool handoffs
5	10
8	28
12	66

Not every pair needs connecting. But every pair that needs a connection and doesn't have one turns into a person with a copy button.

So a new app rarely removes that work. It becomes tool number nine, and the handoff moves somewhere else.

The better move is almost always cheaper: start with the systems you already run, and close the gaps between them.

The real cost of retyping one purchase order

Nobody complains about a six-minute task. That's exactly why it survives.

Run the numbers on emailed purchase orders:

• 6 minutes to retype one purchase order
• 15 orders per working day
• 20 working days per month

That's 1,800 minutes. 30 hours every month, spent retyping.

At €35 an hour, that's about €1,050 a month, or roughly €12,600 a year.

But in B2B, time is the smaller cost. Say one in every 100 retyped orders has a wrong quantity, SKU or price. At 300 orders a month, that's three wrong wholesale orders every month. Each one means a credit note, a return, a reshipment, or a buyer who quietly orders from someone else next time.

These numbers are illustrative. Use your own.

Be honest about the other side too. Automation isn't free. Someone still reviews purchase orders that don't match the catalog, handles the occasional failure and maintains the setup. If 20% of that time stays manual, you recover about 24 hours a month, not 30.

Still worth it? Usually. But now you're deciding with numbers instead of a feeling.

8 handoffs hiding in most B2B e-commerce businesses

These are the handoffs we look for first. The products change. The gaps don't.

Handoff	What it looks like today	What it costs when it slips
Emailed PO → store or ERP	Someone retypes PDF or Excel purchase orders line by line	Wrong SKUs, quantities and prices
Sales rep order → system	Orders taken by phone, WhatsApp or at trade shows get entered later	Orders that ship late, or never
Wholesale application → account	New buyer details copied in, price list and terms set by hand	Slow first orders from new accounts
ERP stock → store	Stock counts updated once a day, or by hand	Overselling to key accounts
Price list → store	Customer-specific prices copied from a spreadsheet	Buyers seeing, and paying, the wrong price
Order → accounting	Orders and payment terms re-entered as invoices	Missed invoices, books that don't match
Shipment → buyer update	Tracking numbers copied from the 3PL into emails	"Where's my order?" emails to your team
Overdue invoice → reminder	Someone checks due dates and chases payment by hand	Late cash on net 30 and net 60 terms

If you recognized three of these, you already have the start of your list.

How to find your handoffs in 30 minutes

Don't start with your tools. Start with one real order and follow it.

Step 1: Pick your most common order type

An online reorder, an emailed purchase order, or an order a sales rep took. Pick the one your team handles most often.

Step 2: Follow one real order from start to finish

Take an actual order from last week, not the process as it's supposed to work. Write down every step from the moment the order arrived to the moment it was paid. For each step, note:

• The tool it happened in
• The person who did it
• The waiting time before the next step started

Step 3: Circle the handoffs

Go back through your list and circle every step where:

• Order, price or stock data was typed again even though it already existed somewhere
• Work waited for someone to notice it
• Something happened only because someone remembered to do it
• Someone had to check or decide something, like a price, a credit limit or a stock level

Those circles are your handoffs. Pay extra attention to the memory steps. They work perfectly until your operations manager goes on holiday.

Step 4: Put a price on each one

For every handoff, multiply minutes per occurrence by times per day by working days per month. Then write down what a single mistake costs. In B2B, one wrong price or missed order can cost more than a month of the time.

Step	From → to	Minutes	Times per day	Hours per month	Cost of one mistake

That's your handoff audit. It tells you what's worth fixing before you spend a cent on software.

Stuck on the mapping? Book a 30-minute call and we'll map one order flow with you.

Delete before you automate

Here's the step most teams skip, and it's the one that saves the most money.

Automation makes a process faster. It doesn't make it right. Automate a bad process and you get the same waste, just quicker and harder to see.

Before automating anything on your list, run it through this order:

1. Remove it. Does anyone use the output? A daily stock spreadsheet nobody checks should be deleted, not automated.
2. Simplify it. Fewer price lists, fewer order channels, fewer approvals that don't protect anything.
3. Move repeat buyers online. Every order a buyer places in your store is one nobody retypes. Getting your top reorder accounts to order online can beat any automation.
4. Use B2B features you already pay for. Most e-commerce platforms now include B2B tools such as company accounts, customer price lists and payment terms, sometimes only on higher plans. Check what yours includes before connecting anything.
5. Connect your systems. APIs and integrations move orders, stock and invoices between systems automatically.
6. Add AI or custom software only for the gap that's left.

The cheapest automation is the task you stop doing. That's the core of how we approach business process automation.

Rules, AI or custom software: which one fixes which handoff

Once a handoff is worth fixing, use the simplest thing that fixes it reliably. There are three kinds of solutions, and each one has a job.

Traditional automation: rules, APIs and triggers

Best for: stock sync, orders into accounting, shipment updates and payment reminders. Anything with structured data and a clear trigger.

Check first: Which system is the source of truth for stock and prices? What happens when a sync fails, or runs twice?

AI

Best for: reading purchase orders that arrive as PDFs, Excel files or plain email text in whatever format each buyer uses. Also sorting incoming buyer emails.

Check first: Does every extracted line get checked against your catalog and the buyer's price list? Keep a person reviewing anything that doesn't match. Never let AI decide a price.

Custom software

Best for: customer-specific pricing rules, ERPs without a ready-made connector, and reorder flows your platform can't handle.

Check first: Is the problem valuable enough that you want to own and maintain code for it?

One rule saves most businesses real money: if a normal API call solves the problem reliably, adding an AI agent only adds cost and new ways to fail. Keeping stock in sync between your ERP and your store is a job for an API, not an AI agent.

Tools like Zapier, Make or n8n handle simple B2B flows well. They start to strain with customer-specific pricing, large catalogs, high order volumes or ERP data that needs validation. That's where automation engineering becomes part of the solution, and where proper software integrations beat a chain of fragile zaps.

What to automate first: a four-question priority test

You now have a list of priced handoffs. Don't start with the most annoying one. Start with the one that scores best on these four questions:

1. How many hours does it cost per month?
2. What does a mistake cost? A wrong price to a key account matters more than a late report.
3. Are the rules stable? If the process changes every month, fix the process first.
4. What will it cost to build, review and maintain?

Here's how that plays out with four typical candidates. The numbers are illustrative, so replace them with yours:

Handoff	Hours per month	Cost of a mistake	Rules	Best first move
Emailed PO → store	30 (6 min × 15 a day)	High: wrong orders	Messy formats, stable fields	AI reads the PO, rules check SKUs and prices, a person approves mismatches
Wholesale application → account	13.3 (20 min × 2 a day)	Medium: slow first orders	Mostly stable	An approval step, then the account, price list and terms get created automatically
ERP stock → store	10 (30 min once a day)	High: oversold orders	Stable	API sync, with an alert when it fails
Weekly sales report	8 (2 hours × 4 a month)	Low	Stable	Ask who reads it. Maybe delete it

Notice that the stock sync costs less time than the purchase orders, yet it might go first. It's stable, cheap to build, and one oversold order to your biggest account can cost more than a month of retyping.

Then ask one more question before you build anything: what will you do with the time you get back? Recovered hours only matter if they go to the thing that actually limits your business, whether that's opening more accounts, shipping faster or looking after key buyers. If faster admin doesn't move that, a different fix deserves the slot. We wrote more about this in why we automate.

When not to automate

Good automation advice includes the word no. Skip automating a handoff when:

• The volume is low. A handful of orders a month from one key account doesn't need a system.
• The deal is negotiated. Custom quotes and pricing conversations need a person.
• It's a credit decision. Keep human approval on credit limits, payment terms and refunds.
• Nobody owns it. Every automation needs a person who knows how it works and what happens when it breaks.
• You haven't measured today's baseline. If you don't know how long it takes now, you won't know whether the fix worked.

Measure it, or it didn't happen

Before you build, write down today's numbers:

• Manual minutes per order
• Order error rate: wrong SKUs, quantities or prices
• Time from order received to order confirmed
• Oversold orders per month
• Time spent fixing things when they go wrong

Check again after a few normal weeks. Count the focused hours you actually got back after review and maintenance, plus the errors that stopped happening. A dashboard full of "tasks completed" means nothing if your team isn't any less busy.

Fix one handoff this week

Not ten. One.

1. Pick your most common order type.
2. Follow one real order from arrival to payment.
3. Circle the handoffs and price them, including the cost of mistakes.
4. Delete what nobody needs.
5. Automate the most valuable, most stable one that's left.

Measure it. Then do the next one. That's the whole Find, Prioritize, Automate methodology in five lines.

FAQ

What should a B2B e-commerce business automate first?

Start with handoffs: the manual steps where order, price or stock data moves between systems or people. Pick one that happens often, follows stable rules and costs real money when it slips, such as retyping emailed purchase orders or updating stock by hand. Delete tasks nobody needs before you automate anything.

Do I need to replace my e-commerce platform or ERP to automate?

Usually not. Most platforms and ERPs already offer APIs, built-in B2B features and integrations. The manual work tends to sit between those systems, so connecting what you already run is often cheaper and less risky than migrating.

Can AI read purchase orders from emails and PDFs?

Yes, AI can extract SKUs, quantities and delivery details from purchase orders in most formats. The output still needs checks: validate every line against your catalog and the buyer's price list, and have a person review anything that doesn't match before the order is confirmed.

How do I keep stock in sync between my ERP and online store?

Pick one system as the source of truth for stock, usually the ERP. Send changes to the store through the platform's API, either when stock changes or on a short schedule, and set up alerts so a failed sync gets noticed before a buyer orders stock you don't have.

How do I know if a B2B automation is worth it?

Multiply minutes per task by times per day and working days per month to get gross hours. Subtract the time still needed for review, exceptions and maintenance. Then add the cost of the errors you avoid, such as wrong prices or oversold orders, and compare the total against the cost to build and run it.

What should not be automated in B2B e-commerce?

Keep people in charge of negotiated pricing, credit limits, payment terms, refunds and disputes. Avoid automating low-volume tasks or processes whose rules change often, and don't automate anything without an owner who knows what happens when it fails.