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

MYOB Acumatica — previously sold as MYOB Advanced Business — is the enterprise tier of MYOB's product range in New Zealand and Australia. Where MYOB Exo runs on your own server infrastructure and MYOB Business is aimed at smaller operations, Acumatica sits in the middle-to-upper tier: a cloud-native ERP built on the Acumatica platform, designed for multi-entity businesses with more complex inventory, purchasing, and financial reporting needs.

If your business runs MYOB Acumatica and you want to connect it to a B2B trade portal, this guide covers what needs to sync, where the complexity lives, and the technical realities that the product-marketing pages from connector tools tend not to mention.

A note on the MYOB Advanced → MYOB Acumatica rebrand

MYOB renamed MYOB Advanced Business to MYOB Acumatica to reflect the Acumatica ERP engine underneath the product. The technology, API structure, and data model are unchanged — only the marketing name shifted. If your organisation still calls it MYOB Advanced internally, or if you're searching for integration guidance under either name, the information below applies to both. Going forward this guide uses MYOB Acumatica, the current name.

The seven data flows a MYOB Acumatica integration needs

A functioning integration between MYOB Acumatica and a B2B ordering platform involves seven distinct data flows. Each one needs to work reliably before the platform is fit for production. Missing or half-implementing any of them produces a system that looks connected in a demo but generates reconciliation failures at scale.

1. Customer master

Customer accounts in MYOB Acumatica hold account code, trading name, billing and shipping addresses, payment terms, credit limit, and account status. This data drives who can log in to the trade portal, what delivery addresses they see at checkout, and whether their account is in good standing. Status changes — a customer placed on credit hold, a delivery address updated — need to propagate to the portal promptly. An account put on hold in Acumatica at 9 a.m. should not be able to place a portal order at 9:05 a.m.

2. Inventory item master

Stock codes, descriptions, units of measure, product categories, images, and base prices come from Acumatica's inventory module. New items added by your purchasing team, description corrections, discontinued lines — all of these need to propagate to the portal's product catalogue. The integration also needs to handle item-level flags: whether a product is active, whether it can be back-ordered, and any customer group restrictions on visibility.

3. Customer-specific pricing

This is the flow that determines whether the integration is actually useful in production. It is covered in detail in its own section below.

4. Stock on hand

Available quantity, per warehouse location in Acumatica. If your operation runs multiple warehouses or storage zones — a main store, a coolstore, a bulk holding area — the integration needs to determine which quantities are available to promise on the portal. That policy decision (expose all locations combined, the primary warehouse only, or a conservative buffer quantity) is a business decision, not one the integration can make. But the integration must implement whatever policy is agreed, and refresh the data frequently enough that stockouts are caught before customers try to order.

5. Orders from the portal into MYOB Acumatica

When a customer confirms an order on the trade portal, it must flow into Acumatica as a sales order — attributed to the correct customer account, with the right inventory codes, quantities, agreed prices, delivery address, and any order instructions. That sales order then drives the pick list for your warehouse team. A failure here — an order that reaches the portal confirmation screen but never appears in Acumatica — is the worst failure mode, and the one your monitoring must catch first. Customers assume their order is being picked; if it isn't in the system, it will not be.

6. Invoices and transaction history

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

7. Account status, AR balance, and credit limits

Outstanding AR balance, overdue status, and credit limit utilisation from Acumatica should be readable by the portal at checkout. A customer at or over their credit limit, or with an overdue invoice, should be flagged or blocked before they complete an order — not discovered later when your AR team reviews the aged debtors report. Some distributors also surface this information in the portal dashboard so trade customers can self-serve their account status without calling your team.

Why customer-specific pricing is the hard part

MYOB Acumatica supports multiple pricing mechanisms that can be in effect simultaneously across your customer base:

• Price classes — customer group tiers (Retail, Trade, Wholesale, or custom classes you define) applied to customer accounts as a default.
• Customer-specific price overrides — individual prices per customer per inventory item, for accounts that have negotiated a rate outside the standard class.
• Quantity break pricing — different prices at different order quantities for the same item.
• Date-effective promotional pricing — time-limited pricing that overrides standard rates within a defined window, typically configured as promotional price worksheets.
• Customer price lists — curated price lists attached to specific customer groups or individual accounts, independent of the global price class hierarchy.

A customer logged into your trade portal expects to see their contracted price — the result of Acumatica applying all of these rules in the correct order of precedence. The typical failure mode: the portal syncs the "Trade" price class and shows that to every customer, ignoring customer-level overrides. Customers with negotiated rates see the wrong price and either complain immediately (best case) or place orders at incorrect prices that only surface during reconciliation, where you absorb the margin difference or raise a credit note.

A correct implementation resolves each customer's effective price per inventory item at the point the product list is displayed — not just once in a nightly batch. For large catalogues across many customer accounts, this is a performance design problem as much as a data problem: pricing data that is stale by hours is not acceptable for an active trade portal.

The cloud API advantage — and what it does not solve

The biggest technical difference between MYOB Acumatica integration and MYOB Exo integration is connectivity. Exo runs on-premises — its API service is hosted on your server, inside your network, requiring you to bridge from your premises to any cloud platform. Acumatica is cloud-native. The API is hosted by MYOB and accessible via standard OAuth 2.0 authentication from anywhere with an internet connection. No firewall rules, no relay agents, no on-premises hosting decisions.

MYOB Acumatica exposes both a REST API and an OData endpoint. The REST API handles standard create/read/update/delete operations for customers, inventory items, sales orders, and financial records. OData is useful for complex queries — filtering, sorting and joining data across entities — that would otherwise require multiple API calls. For a B2B portal integration, the REST API handles the transactional flows (orders, customer sync) and OData handles bulk reads (pricing lookups, catalogue refresh).

What cloud hosting does not solve is the data complexity. Pricing rules, multi-entity configurations, and inventory policies in Acumatica can be just as complex as in any on-premises system — the API is simply easier to reach. The work of correctly mapping each customer's effective price, handling multi-warehouse stock, and ensuring order writes succeed reliably is the same regardless of where the system is hosted.

Multi-entity and multi-branch configurations

MYOB Acumatica is more commonly used in multi-entity businesses — companies that operate multiple legal entities, trading brands, or branch operations within a single Acumatica instance. If your business is structured this way, the integration design needs to account for it: which entity does an inbound portal order belong to, how are inter-entity stock movements handled, and which financial ledger does an invoice post to? These are not edge cases in Acumatica — they are common configurations, and a portal integration that ignores them will generate posting errors from day one.

What a production-grade integration needs beyond the data flows

The gap between an integration that passes a demonstration and one that runs reliably for years is almost entirely operational. The data flows are the necessary foundation; the following are what make them stay working.

• Webhook or event-driven updates where possible. MYOB Acumatica supports push notifications for certain events. For account status changes and order confirmations, event-driven updates are more reliable than polling on a fixed interval. For catalogue data, scheduled polling is still the practical approach.
• An error log your operations team can act on. When a stock item fails to sync, an order write fails, or a pricing discrepancy is detected, someone in your business needs to know — not from a customer complaint two days later.
• Retry logic with dead-letter queuing. API rate limits, transient network failures, Acumatica maintenance windows — order writes should queue and retry within a defined window rather than silently failing. Orders that exhaust retries should route to a dead-letter queue for manual review, not disappear.
• Pricing freshness monitoring. If customer-specific pricing data has not been refreshed within a defined period, flag it before a customer session starts — not after they see the wrong price at checkout.
• Periodic reconciliation. Compare portal order records against Acumatica sales orders and invoices weekly to catch any orders that fell through the gap. Especially important in the first months after go-live, when edge cases in the data model surface in production for the first time.

When integration is the right move — and when it is not

Connecting a B2B trade portal to MYOB Acumatica makes sense when your current process is manual — order emails or phone calls that your team re-keys into Acumatica, pricing errors discovered at invoicing, AR queries handled by phoning your accounts team. A well-built integration eliminates that re-keying, puts correct pricing in front of customers before they order, and gives your sales reps visibility into account status without logging into Acumatica.

Integration is not always the answer, though. If your product range is highly customised, your pricing rules change frequently, or your warehouse and fulfilment workflows have outgrown what a general ERP handles well, the right move might be a consolidated platform rather than adding another system to the stack. See the replace vs integrate decision framework for a structured way to work through that.

For a comparison of how all MYOB editions approach integration, the MYOB integration overview covers the full product range — Business, Exo, and Acumatica — and where each one sits on the complexity and capability spectrum. If you want to understand what a MYOB Acumatica integration would look like for your specific operation, talk to the Zeabyte team — we work across 25+ accounting and ERP systems and build the B2B trade portals they connect to.