Yes AI. AI consulting for Australian businesses.
Forms and calculators require JavaScript. You can still read this page and contact us by phone or email.
Call (03) 9003 0111 | hello@yesai.au
Interactive controls are loading. Phone and email links are available.
WooCommerce is not a hosted platform with one predictable shape. It is a plugin on a WordPress site you control, sitting on hosting you chose, extended by anywhere between five and fifty other plugins. That flexibility is exactly why people pick it, and it is also why integrating it is a different job to integrating a closed platform.
This page covers what actually matters when you connect WooCommerce to accounting, inventory, ERP or point of sale: where order data really lives after the storage change, which parts of the REST API are trustworthy, why the scheduler is the single most common cause of a stalled sync, how tax gets recorded, and what has to be designed differently because anyone with admin access can install a plugin that changes the rules.
None of these are reasons to avoid WooCommerce. They are the four assumptions that get carried over from hosted platforms and quietly cause trouble.
WooCommerce historically stored orders as WordPress posts with the detail in a meta table. High Performance Order Storage puts them in dedicated order tables instead, with an optional compatibility mode that writes to both. An integration built against the old assumption can read stale data on a store that has switched, and a database level query that worked last year can return nothing at all. The first question on any WooCommerce integration is which storage mode the store is running and whether synchronisation between the two is switched on.
Subscription plugins, bundle plugins, booking plugins, wholesale pricing plugins and multi-currency plugins all store their data in their own fields. An order total that looks simple in the admin screen can be the product of three extensions interacting. Any integration that maps only the core fields will get the headline number right and the detail wrong, which is worse than being obviously broken because it reconciles until it does not.
WordPress runs its scheduled jobs when someone loads a page, unless the site has been reconfigured to use a real system timer. On a quiet Australian store overnight, that means queued actions can sit untouched for hours and then all fire at once when the first customer of the day arrives. Sync jobs, stock updates and webhook retries all ride on that scheduler. Fixing it is usually a ten minute hosting change, and skipping it produces symptoms that look like an integration fault for months.
On a hosted platform the vendor absorbs traffic spikes. On WooCommerce the PHP memory limit, the execution timeout, the database size and the number of workers are yours. Bulk operations such as a full catalogue push or a historical order backfill will find those limits first. Integrations have to be written to work in small batches with resumable progress rather than one long run, and the hosting has to be sized for the sync as well as the shoppers.
Very few businesses need all six on day one. Ordering them by the manual hours they remove is usually the right way to sequence the work.
Every paid order becomes either an individual invoice or part of a daily sales summary in Xero, MYOB, Reckon or the ERP. The choice between the two matters more than most people expect: individual invoices give you customer level debtor history and are the right call for wholesale, while a daily summary keeps a high volume retail ledger readable and reconciles far more easily against the payment gateway payout. Refunds, partial refunds, shipping and any surcharge each need their own account and tax treatment agreed before the first record moves.
The inventory system or ERP owns the number and WooCommerce displays it. Pushing on a change rather than on a timer keeps the store current without hammering the site, and a safety buffer per product line absorbs the gap between a warehouse pick and the update landing. Variable products need care because the stock can be managed at parent or variation level, and mixing the two is a common source of phantom availability.
Product data is maintained once in the ERP or a product information system and published to the store, rather than typed into WordPress and then re-typed everywhere else. Attributes, variations, images, categories and tax class all have to map cleanly, and the store keeps a small set of fields it genuinely owns, usually the marketing copy and the merchandising order. Getting the ownership line right here prevents the slow drift that ends with the website advertising last season prices.
Guest checkout means the same person can appear a dozen times with different capitalisation and three delivery addresses. Matching on email alone is not enough for business customers who order under several addresses, and matching on name is worse. A workable rule usually combines email, phone in a normalised format, and for wholesale the ABN, with anything ambiguous going to a review queue instead of being merged automatically.
Orders flow to the warehouse, third party logistics provider or point of sale for picking, and the consignment number and carrier come back to update the order and trigger the shipping notification. Order status is the contract between the systems here, so custom statuses added by a plugin need to be mapped explicitly rather than assumed. This is the flow customers notice first, because it is the one that stops the enquiries about where a parcel is.
Purchase history, product interest and lifetime value feed the email platform so segments reflect what people actually bought rather than what they browsed. Marketing consent captured at checkout has to travel with the record and unsubscribes have to travel back, because a suppression that only exists in one system is a compliance problem rather than a data quality one.
If a store is running High Performance Order Storage and an integration reads the legacy tables, or the other way around, you get an integration that appears to work on old orders and silently misses new ones. Confirm the mode, confirm whether compatibility synchronisation is enabled, and build against the supported interfaces rather than the database. A direct database write is the fastest way to end up with orders that exist in one place and not the other.
WooCommerce webhooks are queued through the same scheduler that everything else uses, and they can be delayed, duplicated or dropped when the queue backs up or a request times out. Use them as a prompt to go and fetch the current state rather than as the source of truth, keep a reconciliation sweep that catches anything missed, and make every write safe to repeat so a duplicate delivery updates rather than creates.
WooCommerce tax classes, whether prices are entered inclusive or exclusive of GST, how shipping is taxed, and how rounding is applied at line or order level all have to match what the accounting system expects. Australian stores selling a mix of GST free food or medical items alongside standard rated goods need the class mapped per product, not per store. Getting this wrong produces small differences that pass unnoticed until a BAS reconciliation.
On a self hosted platform, updates to WordPress, WooCommerce, PHP and every extension are your decision and your risk. An unattended auto update can change a field name or a hook and break a sync at two in the morning. Agree an update window, run updates on a staging copy that has the integration connected, and keep the ability to roll back. This single piece of governance prevents most of the emergencies.
REST API keys generated under a staff member account stop working the day that person leaves and their account is deleted, and they inherit whatever permissions that person had. Create a dedicated service account with the narrowest role that works, generate keys against it, store them properly, rotate them on a schedule, and keep API access over encrypted connections only. Under the Privacy Act 1988 and the Australian Privacy Principles you also need to be able to say who and what can reach customer records.
Backfilling three years of orders or pushing a twenty thousand line catalogue in a single request will hit a timeout, a memory limit or a rate cap, usually about eighty percent of the way through, leaving a half finished state that is hard to reason about. Design every bulk operation as small resumable batches with a cursor, a record of what has been done, and the ability to restart from the last good point rather than the beginning.
We list every extension that touches orders, products, pricing, tax or customers, and work out which fields are core and which belong to a plugin. That audit is what tells us whether the integration is a fortnight of work or a month, and it is yours to keep whether or not we build anything.
We use the official REST endpoints and documented hooks rather than writing into the database, and the integration runs on a managed cloud automation layer we operate. You are not maintaining a plugin, keeping a script alive on your web host, or discovering that the sync died when the server was rebuilt.
Every change is tested against a copy of your store with the integration attached and real order data, including the awkward historical records. That is also where WordPress and plugin updates get tested before they go anywhere near the live site, which is how you avoid finding out about a breaking change from a customer.
Heartbeat checks so a stalled scheduler is noticed within the hour rather than at month end, record level logging of what moved, and a short daily queue for the orders that genuinely need a person. Failures alert a named human the same day, and anything that failed can be replayed once the cause is fixed.
Five steps. The first flow is normally live in three to five weeks, and we start with whichever one is eating the most hours.
Storage mode, plugin inventory, tax configuration, hosting limits, current API usage, and a timed list of the tasks people repeat by hand. We put hours and a dollar figure against each one so the sequencing is an evidence based decision rather than a preference.
Which system owns products, prices, stock, customers and orders, written down and signed off. At the same time we map every tax class to the accounting system, and decide invoice per order or daily summary. These two decisions shape everything that follows.
Trigger, direction, fields, matching rules, duplicate handling, what happens to an order that will not map, and what a person should see when it does not. Written so your bookkeeper can check it, not just a developer, and approved by you before any build starts.
Built in resumable batches against the official interfaces, tested on your real data including the messy historical orders, then a live cutover on the highest value flow with someone watching the first day of traffic and a rollback path ready.
Same day alerting, buffer and matching rules tuned against real traffic rather than guesses, staging tests before every WordPress or plugin update, and new flows added to the same layer as the business grows. Documentation updated each time so it never lives in one head.
The six patterns, what each costs and how to choose.
Connecting the back office to any online store.
The same job on a very different platform.
Getting tax right across every connected system.
One stock pool across store, shop and marketplace.
When the connector you need does not exist yet.
Yes, and for a straightforward retail store an off the shelf connector for Xero or MYOB is often the right answer. We will tell you when that is the case rather than quoting a build. The point where a custom integration starts earning its cost is when you need something the connector does not do: wholesale price tiers driven by the ERP, a mix of GST free and standard rated products mapped per line, multi-warehouse stock, an order flow that has to reach a point of sale as well as the ledger, or a daily summary posting that has to reconcile exactly against a gateway payout including fees and chargebacks.
It is the newer way WooCommerce stores orders, in dedicated database tables rather than as WordPress posts with the detail spread across a meta table. It makes large stores noticeably faster. It matters to integration because anything reading orders directly from the database on the old assumption will either miss data or read stale data, depending on whether compatibility synchronisation is switched on. An integration built against the official REST interface works either way, which is one of several reasons we build that way rather than querying tables.
Almost always the scheduler. WordPress triggers its queued jobs when a page is loaded, so on a store with no overnight traffic the queue simply waits until the first visitor arrives, then processes a backlog all at once. The fix is to disable the traffic dependent scheduler and drive it from a real system timer on the hosting, which most Australian hosts support and which takes minutes to configure. It is worth checking before you spend money diagnosing an integration that is working exactly as configured.
They can, which is why the update process is part of the integration design rather than a separate concern. We test WordPress, WooCommerce and extension updates on a staging copy with the integration connected before they reach the live site, keep monitoring in place so an unexpected change is detected the same day rather than at month end, and build against documented interfaces which change far less often than internal ones. What we cannot do is make an unattended automatic update safe, so agreeing an update window is part of the handover.
The pattern that holds up is to let the ERP or accounting system own the customer tier and the price list, and have WooCommerce read it rather than maintain a second copy. A wholesale plugin then becomes a display layer rather than a source of truth. This matters because the alternative, maintaining tiers in both places, drifts within months and the arguments that follow are always about which number was right. If your wholesale volume is significant, it is also worth checking whether a dedicated B2B ordering flow serves you better than bolting tiers onto a retail store.
A single well defined flow, such as orders into accounting, is usually two to four weeks from scoping to live. A full connected stack covering orders, stock, products, customers and fulfilment is normally staged over two to three months so the manual work drops early rather than all at the end. Cost depends on the number of flows, how many plugins are involved in the data model and how clean the historical data is. We quote a fixed build price plus a flat monthly managed fee, and we are wary of per order pricing because it turns a good trading month into a larger bill.
Usually no, and we would rather say so than sell a replatform. WooCommerce integrates perfectly well when the storage mode is understood, the scheduler is driven properly and the plugin footprint is known. The honest cases for moving are a store where the extension stack has become genuinely unmaintainable, one where hosting costs to keep the site fast now exceed a hosted platform, or a business whose requirements have moved to something the platform does not do well. Replatforming while trading is a serious project in its own right and should be judged on its own merits, not treated as an integration fix.
Book a call. We audit the store, the plugins and the manual hours, then tell you plainly which flows to automate first and where an off the shelf connector will do the job for less. The audit is yours either way.
All discussions held in confidence. Australian-based consultants.