What B2B E-commerce Automation Costs, With the Maths

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.