ERP integration for B2B ecommerce: the 2026 guide for Australia and New Zealand

Most wholesalers don’t struggle to build a B2B store. They struggle to keep it in step with the ERP: the right price for each customer, stock that’s really on the shelf, and orders that land in the ERP without anyone keying them in again.

This guide covers how to get that right, for Australian and New Zealand wholesalers and distributors running MYOB, Xero, NetSuite, Pronto Xi, Options, Business Central, Cin7, Unleashed and similar systems. It’s written from integrations our team has built and run in production since 2017, including one that syncs around ten million ERP records every night, and it uses their real numbers where we have them.

If you’re short on time, read the key takeaways above, then jump to which data to sync and what goes wrong.

What ERP integration means for a B2B store

ERP integration connects your online trade store to the system that runs your business, so data moves between them without anyone re-keying it. Products, stock, customers and their prices come from the ERP into the store. Orders, payments and new customer details go from the store back into the ERP.

That sounds like any ecommerce integration, and retail stores connect to ERPs too. B2B is harder in a few specific ways:

• Every customer can have a different price. Contract prices, customer price levels, group discounts and quantity breaks all live in the ERP, and the store has to show the exact price the ERP will invoice.
• Customers buy on account. Credit limits, payment terms, overdue balances and stop-credit flags matter at checkout, and they change every time an invoice is raised or paid.
• An account is many people. One customer can have buyers at several branches, approvers, and an accounts-payable contact who only pays invoices.
• Orders carry more. A trade order brings a purchase order number, a required-by date, a branch and delivery address, and sometimes custom line items such as installation.
• The ERP is the business. Your team quotes, picks, invoices and chases debt in the ERP. The store has to fit around it, not the other way round.

Get these right and the store becomes the easiest way for customers to order. Get them wrong and your team ends up checking every online order before it goes into the ERP, which is the work the store was meant to remove.

Why it matters more every year

Trade buyers increasingly want to order without talking to anyone. In a Gartner survey of 632 B2B buyers, 61% said they prefer a rep-free buying experience.^[1] When Gartner asked again the following year, that rose to 67%.^[2] McKinsey’s B2B Pulse research found buyers now use an average of ten channels when they buy, up from five in 2016.^[3]

Australian businesses are moving the same way. According to the Australian Bureau of Statistics, 32% of Australian businesses received orders online in 2024-25, up from 30% in 2021-22.^[4]

The catch is that buyers notice when the data behind a store is wrong. In Sana Commerce’s survey of 750 B2B buyers, 73% said they prefer to buy online, but 85% had run into problems caused by outdated systems or inaccurate data.^[5] That’s a vendor survey, but it matches what we see: a B2B store is only as good as its connection to the ERP. A trade customer who sees the wrong price or orders stock that isn’t there goes back to emailing your team.

What nine years of production syncs taught us

Most ERP integration guides are written from first principles. This section is written from integrations that have been running in production for years, so you can see what the patterns in the rest of this guide look like at real volumes.

Impact’s website replaced a Magento store with an unreliable sync to Options, and it had to launch without interrupting ordering. Since the 2018 launch, Impact reports website sales up 200%, with over 60% of its business orders now placed online and a 33.5% conversion rate for logged-in business customers.^[6] Its staff don’t re-key online orders.

Across these and other integrations, including three separate wholesalers on Options ERP and integrations with NetSuite, MYOB and Xero, a few lessons have held every time:

1. The website is the easy half. The storefront takes weeks. The integration is what decides whether the project works, and it’s where most of the effort and risk sit.
2. Mix sync methods. No single method fits everything. Impact uses a nightly full sync as a safety net, webhooks for changes during the day, and a five-minute push for orders and payments.
3. Log every sync where the business can see it. At Impact, every sync is logged in the control panel, so the team can see what came through and re-run anything that failed, without calling a developer.^[6]
4. Keep shared data shared. Impact’s search index holds product data only, and each customer’s pricing is added as results load, so one index serves every customer instead of one per price list.
5. Integrations are long relationships. Most of our integration client relationships run for five to seven years, through ERP upgrades, new warehouses and new customer types. Design for the business in five years, not just for go-live.

Which data to sync, which way and how often

Start by listing every type of data the store needs and deciding three things for each: which system owns it, which way it flows, and how fresh it has to be. This table is the starting point we use with most wholesalers.

Use the explorer to see how each one syncs, why it matters and what usually goes wrong with it.

Customer pricing: the hardest part

Pricing is where most B2B integrations go wrong, because ERPs model it in very different ways. MYOB AccountRight has price levels A to F. Cin7 Core and Unleashed allow up to ten price tiers per product, and Unleashed applies customer prices, then quantity prices, then tiers and discounts, then the default sell price. Options and Pronto hold contracts per customer with their own rules and dates. Xero holds one sales price per item, so trade price lists have to live in the B2B platform.

Whatever your ERP does, the rule is the same: the store must show the price the ERP will invoice. There are two ways to get there.

• Sync the price rules into the store and calculate prices there. This is fast and keeps working when the ERP is offline, but the store has to reproduce the ERP’s logic exactly, including the order rules are applied in.
• Ask the ERP for each customer’s price when it’s needed. This is always right, but it’s only as fast and reliable as the ERP’s API, and it can use up API limits quickly.

Most integrations we build sync the rules and keep a live check for the final price at checkout where the ERP allows it. Whichever you choose, test it against real invoices: take a hundred recent invoice lines across different customers and confirm the store would have charged the same.

Read more about customer pricing and tiers in TierCommerce.

Stock: per warehouse, not one number

Sync stock per warehouse or location, not as a single total, so you can show buyers what their nearest branch holds and route orders properly. For businesses selling apparel or anything with variants, sync stock per size and colour, not per style. And decide early what you show when stock is low: an exact number, “in stock”, or a next-shipment date from incoming purchase orders.

Orders: minutes, and exactly once

Orders don’t need to reach the ERP instantly, but they must arrive once and only once, with everything your team needs to process them: account code, purchase order number, required-by date, branch, delivery address and any notes. Decide how each field maps before you build. In Business Central, for example, the buyer’s PO number belongs in the external document number. In Xero, which has no sales orders, an online order becomes a draft or approved invoice.

Invoices, statements and payments

Bringing invoices and statements into the store lets buyers download and pay them online, which is often worth as much to a wholesaler as online ordering. Payments then flow back to the ERP against the right invoice. Get this right and your accounts team stops chasing copies of invoices. See accounts payable online for how that works for buyers.

Real-time or scheduled?

“Real-time” is the most over-specified requirement in ERP integration. Very little needs to be instant, and trying to make everything instant is the fastest way to hit your ERP’s API limits. It helps to think in three speeds.

Where your ERP can send webhooks or events, use them: Options, Pronto Xi (through Tasks and Alerts), Business Central, Cin7 Core (with its Automation module), MYOB Acumatica and Katana can all tell the store when something changes. Where it can’t, as with MYOB AccountRight, poll for changes on a short schedule and only fetch what changed.

Either way, keep a scheduled full sync running as well. Webhooks get missed, and a nightly run that compares everything catches what slipped through. At Impact, that nightly run is scheduled around Options’ routine maintenance window and finishes before the business day starts.

A worked example: how fast can you hit a Xero limit?

Xero allows 60 API calls a minute and 5,000 a day for each connected organisation, with no more than five at once.^[8] That sounds like plenty. Here’s how a modest trade store can use it up. The figures are illustrative; your own will differ.

• Orders: 150 orders a day, each needing about four calls (find or create the contact, create the invoice, apply the payment, read back the result), is 600 calls.
• Stock: checking for stock changes every five minutes is 288 calls a day, even on days when nothing changes.
• Live lookups: checking a customer’s balance or a live price on 2,000 page views a day is another 2,000 calls.

That’s 2,888 calls before a single retry, a month-end rush or a catalogue refresh. And the per-minute limit bites first: if 30 orders arrive in the same minute after a sales rep’s email goes out, that’s about 120 calls in a minute, double what Xero allows. A good integration queues them and sends them at a steady rate; a naive one starts failing.

Try it with your own numbers. The calculator opens on this example, and you can switch to Cin7, Katana or Business Central to compare their limits. It also has its own page you can bookmark or share.

ERP API limits for Australian and New Zealand systems

Every ERP limits how hard you can use its API, and the limits are often the real constraint on an integration’s design. These are the published limits for the systems we see most in Australia and New Zealand, as of October 2026. Where a vendor doesn’t publish numbers, we say so.

Two things change these numbers in practice. First, other apps connected to the same ERP may share the same limits, so check what else is already connected. Second, on-premises systems such as Pronto Xi, Options and SAP Business One are limited by your own server rather than a published cap, which means a heavy integration can slow the ERP down for your own staff. Agree the load with whoever runs your ERP before you go live.

Native connector, middleware or ERP-embedded store?

There are three ways to connect a B2B store to an ERP, plus a fully custom build. Each suits a different business, and the choice matters more than which ecommerce platform you pick. Switch between them to compare.

1. Native integration in the B2B platform

The ecommerce platform connects directly to your ERP with an integration it builds and maintains itself. There’s no third system in the middle, and the platform’s B2B features (pricing, credit, approvals, invoices) are designed around what the ERP holds.

• Best for: wholesalers whose ERP the platform supports natively, who want to be live quickly without an integration project.
• Watch for: what “native” actually means. Ask whether the vendor built the integration or resells someone else’s connector, and whether it’s two-way and logged.

2. Ecommerce platform plus middleware or a connector

A general ecommerce platform connects to the ERP through a third-party connector app or an integration platform (iPaaS) that maps data between them. This is how most global platforms reach ERPs they don’t support themselves.

• Best for: businesses already committed to a platform, or with several systems to join up, where an integration team will own the middleware.
• Watch for: a third subscription, often billed in US dollars, and a third place for things to break. When a sync fails, it can be hard to tell whether the store, the connector or the ERP is at fault.

3. Store built into the ERP

Some ERPs sell their own web store module, such as NetSuite SuiteCommerce, and some platforms read live data straight from specific ERPs, such as Sana Commerce with SAP and Microsoft Dynamics. There’s no sync to fail because the store uses the ERP’s data directly.

• Best for: businesses committed to that ERP for the long term, with the budget for its licensing and implementation partners.
• Watch for: lock-in. Change ERP and you rebuild the store. The buying experience is also limited by what the ERP can do, and ERP licences are usually priced well above ecommerce platforms.

A fourth option, a fully custom portal with a custom integration, is still right for some businesses with unusual requirements. It gives you complete control, at the cost of owning every line of code for as long as the portal runs.

What goes wrong, and how to design for it

Every integration fails sometimes. ERPs go down for maintenance, networks drop, and vendors change their APIs. The difference between a good integration and a bad one is what happens next. These are the failures we see most, and the defences that work.

Duplicate orders and invoices

The most damaging failure is a duplicate: an order sent twice, or an invoice and payment created twice. It usually happens when the ERP accepts an order but the confirmation is lost, so the integration tries again.

The defence is called idempotency: every write carries a unique reference, and before creating anything the integration checks whether it already exists. Ask any vendor how they prevent duplicate orders when the ERP times out. If the answer is vague, expect duplicates.

A nightly sync that fails halfway

A full sync of millions of rows that dies at row 4 million leaves the store half updated. Process large syncs in batches that can be resumed, compare against what’s already there so unchanged rows aren’t rewritten, and make each batch safe to run twice.

Webhooks that arrive twice, late or out of order

Webhooks are not guaranteed to arrive once or in order. Treat each one as a prompt to fetch the latest record, not as the record itself, and the order they arrive in stops mattering.

Rate limits that silently drop updates

An integration that ignores rate-limit errors doesn’t crash; it just stops updating some records, and nobody notices until a customer orders stock that isn’t there. We see this most with Cin7 integrations built without throttling. Respect the limit, back off when told to, and alert someone when a sync falls behind.

Rounding and reconciliation drift

A cent of rounding difference per order adds up across thousands of orders. With Xero especially, most of the reconciliation drift we’re called in to fix traces back to refunds, partial refunds, surcharges and multi-currency orders. Agree with your accountant how GST is rounded (per line or per invoice) and make the store and ERP do the same.

The ERP changes underneath you

ERP vendors retire products and change their APIs. MYOB, for example, has moved its API to OAuth connections with granular scopes, and is retiring MYOB Exo Payroll, with MYOB Acumatica as the suggested replacement.^[18] An integration built in its own layer, separate from the storefront, can be updated or swapped without rebuilding the store.

Get your data ready before go-live

An integration copies your ERP’s data onto a website your customers will read. Problems that your team works around every day become visible to every customer. Before go-live, check:

• Product codes and units. No duplicate codes, consistent units of measure, and pack sizes that make sense to a buyer.
• Product names. ERP descriptions like “BOLT HEX M10X50 ZP” work internally. Decide where the web-friendly names and descriptions will live.
• Customer records. Merge duplicate accounts, set the right price level or contract on each, and collect buyer email addresses.
• Contracts and prices. Remove expired contracts and check overlapping ones, because the store will apply them exactly as the ERP does.
• Stock locations. Decide which warehouses the store sells from and how stock in transit is shown.
• Inactive items. Flag discontinued and internal-only items so they don’t appear online.
• Tax codes. Check GST codes on every item, including GST-free lines.

This work usually takes longer than the integration itself, so start it first.

What’s different in Australia and New Zealand

Most ERP integration guides are written for the US or Europe. A few things matter more here:

• GST display per customer. Trade customers usually see prices excluding GST, while sole traders and retail buyers may expect them inclusive. The store should switch per customer and match how the ERP calculates GST.
• Local systems. MYOB, Pronto Xi, Options, Xero, Cin7 and Unleashed are common here and rare in the US, so many global platforms reach them only through third-party apps or custom work. Check this first.
• Payment terms. 30 days end of month and similar terms are standard, and buyers expect to pay invoices online by card or bank transfer. See payment terms.
• Separate AU and NZ entities. Many businesses trade through an Australian and a New Zealand company, with different currencies, tax and price lists. NetSuite OneWorld subsidiaries, for example, can map to separate stores or price lists.
• Procurement for universities and government. Larger buyers often order through eProcurement systems such as Unimarket, which means PunchOut catalogues. Impact Office Supplies runs three Unimarket catalogues for university and government customers.^[6] See PunchOut.
• Data location. Many businesses prefer, or their customers require, that data is hosted in Australia.

Cost and timeline

ERP integration costs vary more by approach than by ERP. These ranges are a starting point for planning. They exclude GST, and your own quotes will depend on how customised your ERP already is.

In the same planning model, a custom NetSuite portal came to about A$183,000 over five years, against A$400,000 or more for SuiteCommerce Advanced.^[19] The lesson holds for any approach: compare five-year costs, not build costs, because licensing and maintenance usually cost more than the build.

On timelines, a focused one-way sync can be built in a few weeks. A full two-way integration with contract pricing, several warehouses and invoice payment usually takes months, and depends more on how customised your ERP is than on which ERP it is.

For TierCommerce, see pricing. To estimate what order automation alone could save, try our order automation ROI calculator.

B2B ecommerce platforms compared for AU and NZ ERPs

We make TierCommerce, so we’re not neutral. Instead of ranking platforms, this table compares them on the facts that matter for ERP integration in Australia and New Zealand: how each connects to your ERP, which local systems it covers, and whether its pricing is published. Each row is based on the vendor’s own public pages as of October 2026; check them for changes before you decide.

To see every platform against a single ERP, including NetSuite and Business Central, pick yours below.

How to use the comparison: start with your ERP. If a platform reaches it only through a third-party app or custom work, add that app, its subscription and its support to your comparison. Then compare the B2B features themselves: customer pricing, credit and terms, buyer roles and approvals, quotes, invoice payment and PunchOut. Our side-by-side comparisons go into each one:

• TierCommerce vs Shopify B2B
• TierCommerce vs BigCommerce B2B
• TierCommerce vs Adobe Commerce
• TierCommerce vs NetSuite SuiteCommerce
• TierCommerce vs Commerce Vision
• TierCommerce vs Cloudfy

A staged rollout plan

The safest integrations go live in stages, so each part is proven before customers depend on it. This is the order we use.

1. Discovery and mapping. List every data type, its owner, direction and freshness, using the table above. Agree how each order field maps into the ERP.
2. Read-only sync. Bring products, customers, prices and stock into the store without sending anything back. Compare store prices against a hundred real invoice lines until they match.
3. Test orders. Send test orders into a test copy of the ERP. Try the failure cases on purpose: the ERP offline, a timeout after the order was accepted, a customer on stop credit, an item with no stock.
4. Pilot customers. Invite five to ten friendly customers to order online while your team watches every order arrive in the ERP.
5. All customers. Open the store to everyone, with the sync log watched daily for the first few weeks.
6. Invoices and payments. Add online invoices, statements and payments once ordering is stable.
7. Automation. Then automate what’s left, such as the orders customers still email as PDFs. Our Order Entry co-worker turns emailed purchase orders into ERP sales orders.

Questions to ask any platform or integrator

Whoever you choose, these questions separate integrations that last from ones that don’t:

1. Did you build the integration with our ERP yourselves, or is it a third-party connector?
2. Is it two-way? Which data goes each way, and how often?
3. How do you stop an order being created twice if our ERP times out?
4. What happens to orders while our ERP is down for maintenance?
5. Where can our team see what synced, what failed and why, and can we re-run a failed sync ourselves?
6. How do you show each customer the exact price our ERP will invoice? Can we test it against real invoices?
7. How do you stay within our ERP’s API limits as our order volume grows?
8. What happens to the store if we change ERP?
9. Who supports the integration when it breaks, in which time zone, and how fast?
10. Can we speak to a customer running the same ERP?

If you’d like to see how TierCommerce answers them on your own products and ERP, book a demo. Bring a price list and a recent purchase order, and we’ll show you both working.