Integrating MYOB Exo with a B2B ordering platform: what actually syncs

MYOB Exo Business is one of the most widely used ERP and accounting platforms in mid-market New Zealand and Australian distribution. Unlike MYOB's cloud products, Exo runs on your own server infrastructure — a Microsoft SQL Server database under the hood, installed on-premises in your building or a managed data centre. That architecture shapes everything about how integration works, and it's why connecting Exo to a B2B trade portal is more involved than the same exercise with Xero or MYOB Business.

This guide covers what actually needs to sync, where the complexity lives, and the technical approaches that hold up once real order volumes start flowing.

The seven data flows an Exo integration needs

A working integration between MYOB Exo and a B2B ordering platform involves data moving in both directions across seven distinct areas. Miss any one of them and you end up with a portal that looks connected but creates more reconciliation work than the manual process it replaced.

1. Debtor / customer master

Customer accounts in Exo are called debtors. Each debtor record holds the account code, trading name, delivery addresses, payment terms, and account status — active, on hold, or suspended. This data drives which customers can log in to the trade portal, what delivery options they see, and whether their account should be permitted to place an order at all. Account status changes made in Exo need to propagate to the portal before the next order is placed — not at the next day's batch sync.

2. Stock item master

Product codes, descriptions, units of measure, category structure and base prices come from Exo's stock item master. New codes added by your purchasing team, discontinued lines, description corrections — all of these need to propagate to the portal's product catalogue promptly. The integration also needs to handle Exo's stock item flags: whether an item is active, whether it can be back-ordered, and any customer-group restrictions on who can see or buy it.

3. Customer-specific pricing

This is the part that defeats most generic connector tools, and it is worth addressing in detail in its own section below.

4. Stock on hand

Available quantity, held per stock location in Exo. If your warehouse runs multiple locations — a main store, a coolstore, a bulk holding area — the integration needs to determine which quantities are available to promise on the portal. That's a stock policy decision your business makes, not one the integration can make for you: expose all locations combined, the primary warehouse only, or a conservative reserve quantity.

5. Orders from portal into Exo

When a customer confirms an order on the trade portal, it needs to flow into Exo as a sales order — correctly attributed to the debtor account, with the right stock codes, quantities, prices, delivery address and any order instructions. That Exo sales order then drives the pick list for your warehouse. A failure here — an order that reaches the portal confirmation screen but never appears in Exo — is the worst possible outcome and the one your monitoring must catch first.

6. Invoice and transaction history

Customers want to view their invoice history from within the portal account dashboard — download PDFs, reconcile against their own records, query outstanding items. Invoices completed from Exo sales orders need to flow back into the portal. For distributors running high invoice volumes, this also lets your accounts receivable team see payment status in one place without switching systems.

7. AR status and credit limits

Outstanding balances, aged debtors and credit limit utilisation from Exo should be readable by the portal when a customer is about to check out. An account that is over its limit or overdue should be blocked or flagged at the portal, not discovered later when your AR team reviews the Exo aged debtors report.

Why customer pricing is the hardest part

MYOB Exo's pricing model is among the most flexible of any NZ accounting system — and flexibility here means complexity for integrators. Exo supports multiple pricing mechanisms that can all be in effect at once:

• Price levels — global tiers (Retail, Trade, Wholesale, and custom levels you define) applied to debtor accounts as a default.
• Debtor special prices — individual overrides per debtor per stock item, set for customers who've negotiated a specific rate outside the standard levels.
• Date-effective promotions — time-limited pricing that overrides both levels and specials within a defined window.
• Quantity break pricing — different prices at different order quantities for the same item.

A customer logged into your trade portal expects to see their contracted price — the result of Exo applying all of these rules in the correct order of precedence. The typical failure mode in integrations that handle only part of this: the portal syncs the "Trade" price level and shows that to every customer, ignoring debtor-level specials. Customers with negotiated rates either see the wrong price immediately (they complain) or place an order at an incorrect price that only surfaces during invoice reconciliation (you absorb the margin difference or raise a credit note). Neither outcome is acceptable at volume.

A correct implementation resolves each debtor's effective price per stock item at the point the portal product list is displayed — not just once in a nightly batch. For large catalogues across many debtors, this is a performance design problem as much as a data problem.

Technical approaches for connecting to Exo

Because Exo runs on-premises with SQL Server, there are three realistic integration paths — and most production integrations use more than one.

The Exo REST API

MYOB provides a REST API for Exo Business that covers debtors, stock items, pricing, sales orders and invoices. This is the officially supported integration method and the safest choice for writes — orders, customer updates — because it uses Exo's own business logic and is less likely to break when Exo is upgraded. The API runs as a Windows service on the Exo server (or any server with SQL access), which means you are responsible for hosting, securing and monitoring it. Your portal communicates with it over HTTPS.

Direct SQL access

Because Exo's data lives in SQL Server, it is technically possible to query the database directly. Some integrations use direct SQL for scenarios the API does not cover well — complex pricing lookups across large catalogues, bulk stock refresh jobs. The risk is coupling to Exo's internal schema, which can shift between Exo versions. If you use direct SQL, read only where possible, confine writes to the API, and document your queries against the specific Exo version they were tested on.

File-based exchange

Scheduled exports from Exo (CSV or XML), imported by the portal at defined intervals. The most robust to network complexity — no open ports, no real-time requirements — but the most limiting for user experience. If your portal promises live stock availability or per-session pricing, file-based sync introduces a gap that customers will notice. This approach suits simpler integrations or specific data flows (overnight product catalogue refresh) alongside real-time API calls for orders and pricing.

The on-premises challenge

This is the point most integration guides skip, because it applies to Exo but not to the cloud-native systems most guides are written about.

MYOB Business and Xero are cloud SaaS — their APIs live on MYOB's and Xero's own infrastructure and are accessible from anywhere with an authorised token. MYOB Exo is different: the API service runs on your server, inside your network. For a cloud-hosted trade portal to reach it, you need to decide how to bridge the gap:

• Expose the Exo API service to the internet — requires firewall rules, a static IP or DNS name, TLS termination, and ongoing security management. Simple to set up; the attack surface is real and needs active attention.
• Use an API gateway or reverse proxy — places a hardened endpoint in front of the Exo service, adds rate limiting, authentication, and logging before a request reaches your internal network.
• Run a lightweight relay agent on-premises — a small service that polls Exo locally and pushes data to a cloud-hosted message queue. The portal reads from the queue; no inbound internet access to your network is required. Higher complexity to build; better security posture for environments with strict network policies.

Whichever approach you take, the integration must account for Exo server downtime — maintenance windows, backups, reboots — and define what the portal does when Exo is temporarily unreachable. Orders placed during an outage should queue and process once Exo returns, not be lost or silently discarded.

What a production-grade integration needs beyond the data flows

Once the data flows are working, the gap between a demo integration and one that runs reliably for years is mostly operational:

• An error log your operations team can see. When a stock item fails to sync, an order write fails, or a pricing discrepancy is detected, someone needs to know without waiting for a customer complaint.
• Retry logic for transient failures. Exo server briefly unreachable, network blip — order writes should queue and retry within a defined window rather than silently failing.
• Pricing freshness alerts. If debtor special prices haven't been re-synced in more than a defined period, flag it before a customer places an order at the wrong rate.
• A periodic reconciliation process. Compare portal order records against Exo invoices weekly to catch any orders that fell through the gap — especially important in the first months after go-live.

MYOB Exo is one of the more demanding integrations in a B2B distribution stack — partly because of the on-premises architecture, partly because of the pricing model. But the businesses that run on it tend to be exactly the kind of established mid-market operations where a proper trade portal pays for itself quickly: high order volumes, complex customer pricing, a need to reduce manual re-keying and AR follow-up. Getting the integration right is the prerequisite.

For a broader overview of how MYOB editions compare for integration, see our MYOB integration guide. If you're weighing whether to extend your current Exo setup or migrate to a consolidated platform, the replace vs integrate decision framework covers how to work through that. And if you want to talk through what an Exo integration would look like for your specific operation, reach out to the Zeabyte team — we work across 25+ accounting and ERP systems including MYOB Exo, Accredo, Attaché, SAP and Xero.