How to Integrate WooCommerce with MYOB Acumatica

Choose the integration architecture first

There are two common ways to connect WooCommerce with MYOB Acumatica: use an integration platform between the systems, or connect WooCommerce directly to the Acumatica contract-based REST API. Both approaches can work, but they solve different problems.

Middleware is useful when a business needs to coordinate several systems, transform complex workflows, or manage many integrations from one platform. A direct connector is often simpler when the main requirement is a focused WooCommerce-to-Acumatica workflow and the business does not need an additional hosted integration layer.

• Direct integration keeps the connector and synchronization logic inside WordPress.
• Middleware can be useful when several ERP, CRM, PIM, marketplace, or warehouse systems need to share data.
• The architecture should be chosen before field mapping because it affects authentication, monitoring, retries, and ongoing operating costs.
• Whichever approach is used, catalogue, customer, and order data should have a clearly defined source of truth.

Confirm MYOB Acumatica API access before development

A direct implementation requires a working Acumatica REST endpoint, an integration user, the correct company or tenant context, and permissions for every entity the connector needs to read or write. These details should be tested before any production synchronization is enabled.

Authentication success alone is not enough. The onboarding process should also confirm the Acumatica endpoint version, required entities, custom fields, branch or warehouse rules, and whether the standard API contract exposes the data the WooCommerce store actually needs.

• Use a dedicated integration account rather than a personal administrator account.
• Test authentication and a small read request before building the complete sync.
• Confirm which Acumatica company, branch, warehouse, and price data should be used.
• Document custom fields and custom endpoints before mapping them into WooCommerce.

Match WooCommerce products to Acumatica inventory items

The cleanest standard mapping is usually WooCommerce SKU to Acumatica InventoryID or the agreed item identifier. A product or variation should have one stable ERP identifier so price and stock updates are deterministic.

Product creation can be added, but it is a different problem from synchronization. A first implementation is usually safer when the WooCommerce catalogue already exists and the connector updates known products rather than automatically creating categories, images, attributes, and variations from ERP data.

• Require unique SKUs for products and variations included in synchronization.
• Log missing and duplicate mappings instead of silently guessing which product to update.
• Decide whether inactive or discontinued ERP items should be hidden, marked out of stock, or ignored.
• Treat automatic catalogue creation as separate scope when complex product structures are involved.

Decide what stock value WooCommerce should display

Stock synchronization becomes complicated when Acumatica contains several warehouses, allocations, committed quantities, branches, or business-specific availability calculations. The correct WooCommerce quantity is not always the first inventory number returned by the ERP.

A standard implementation should define one warehouse or one agreed availability rule during onboarding. The connector can then import that value on a schedule and update WooCommerce only when the ERP value has changed.

• Choose the source warehouse or availability formula explicitly.
• Agree how backorders and negative availability should be treated.
• Use scheduled synchronization at an interval appropriate for order volume and operational risk.
• Keep a manual sync option for testing and recovery.

Separate standard pricing from customer-specific pricing

A simple store may need only one Acumatica price value imported into WooCommerce. B2B stores are often different: the visible price can depend on the logged-in customer, price class, contract, quantity, currency, or other ERP rules.

The integration should therefore distinguish between standard catalogue pricing and customer-specific pricing. Standard prices can be synchronized to WooCommerce product data, while account pricing needs a reliable mapping between the WooCommerce customer and the appropriate Acumatica customer or price class.

• Define the standard price source used for guests and unmapped customers.
• Map logged-in WooCommerce customers to their Acumatica customer account when account pricing is required.
• Store imported pricing locally so normal storefront page views do not require a live ERP request.
• Document how sale prices, taxes, currencies, and quantity breaks interact with ERP pricing.

Map WooCommerce customers before relying on ERP pricing or order export

Customer mapping affects more than account pricing. The same mapping may determine which business account receives a sales order, which price class applies, and which billing or shipping data is considered authoritative.

For existing customers, use a stable Acumatica customer identifier stored against the WordPress user rather than trying to match by company name on every request. New-customer creation can be supported, but the required fields and duplicate rules should be agreed first.

• Prefer stable ERP customer IDs over repeated email or company-name matching.
• Define what happens when a WooCommerce customer has no Acumatica mapping.
• Decide whether guest orders create ERP customers, use a shared guest account, or require manual review.
• Keep customer creation rules separate from product and order synchronization rules.

Export WooCommerce orders to Acumatica at the right status

Order export should occur only after WooCommerce has reached the business-defined point at which the order is ready for the ERP. For many stores that is the Processing status after payment, but stores using manual review, bank transfer, subscriptions, or custom fulfilment may require a different trigger.

The exported SalesOrder should include deterministic product mappings, quantities, customer information, addresses, freight or shipping data, tax treatment, and a reference back to the WooCommerce order. The connector should also record the Acumatica order reference so the same WooCommerce order is not accidentally created twice.

• Define the exact WooCommerce status that triggers export.
• Make exports idempotent so retries do not create duplicate ERP orders.
• Store the Acumatica SalesOrder reference on the WooCommerce order.
• Keep failed exports visible for manual review and retry.

Build retries and diagnostic logging into the integration

ERP integrations fail for ordinary operational reasons: credentials expire, a custom field changes, a product mapping is missing, the API times out, or a sales order contains data the ERP refuses. A production connector needs to make those failures recoverable.

Logs should identify the operation, WooCommerce record, Acumatica entity, response status, and a useful error message without exposing passwords, session tokens, or unnecessary customer data. Automatic retries are appropriate for temporary failures, while validation and mapping errors normally require correction before retrying.

• Separate temporary transport failures from permanent validation failures.
• Use bounded retries instead of retrying indefinitely.
• Redact credentials and sensitive data from logs.
• Provide a manual retry path after the underlying issue has been fixed.

Test with real business scenarios before enabling automation

The first successful API request is not the end of integration testing. Test representative products, customers, prices, orders, taxes, shipping methods, and failure scenarios against the actual Acumatica configuration.

A controlled onboarding process should begin with connection testing and manual synchronization, then verify the resulting WooCommerce and Acumatica records, and only then enable scheduled catalogue sync and automatic order export.

• Test simple products and variations that represent the real catalogue.
• Test standard and customer-specific pricing where applicable.
• Create test orders covering the main shipping and tax scenarios.
• Confirm duplicate prevention by intentionally retrying an exported order.
• Review logs and recovery steps before production go-live.

Define the standard scope before starting the integration

A focused first implementation is easier to test and maintain than an attempt to synchronize every possible ERP entity immediately. A practical standard scope can cover existing WooCommerce products, one agreed stock rule, standard pricing, customer mapping where required, and WooCommerce-to-Acumatica SalesOrder export.

Additional workflows such as product creation, multiple warehouses, complex price rules, invoices, deliveries, refunds, credit notes, tracking updates, multiple companies, or custom Acumatica entities should be reviewed separately because each can materially change the implementation.