Ten questions that save months of rework, and the answers I'd want to hear before signing anything.
A WooCommerce ERP integration with Dynamics 365 Business Central moves orders, customers, products, and stock between your online store and Microsoft's ERP, so finance and warehouse teams work from one set of numbers. The projects that go well share one trait. The team answered the hard questions before the build started, not during the second month of testing.
The first question most people ask about a WooCommerce dynamics 365 integration is how long it will take. It's the wrong first question. The better one is which decisions will be painful to undo later. Those decisions cluster around data ownership, tax, customers, and failure handling. What follows is the list I'd want answered before any money changes hands, along with what a useful answer sounds like.
Who owns the product record?
Splitting the product master is the first real decision in any WooCommerce ERP integration with Business Central. Business Central holds item numbers, costs, base prices, units of measure, and inventory posting groups. WooCommerce holds descriptions, photos, categories, and marketing copy. Most of the trouble starts when the same field, like price or weight, lives in both places with no rule for which one wins.
A good answer sounds like this: "Business Central owns item number, cost, and base price. WooCommerce owns the title, description, images, and any store-only pricing for promotions. Weight and dimensions come from Business Central and are read-only in the store." When someone can't give you a sentence like that, the project isn't ready.
The item number deserves special attention. If the SKU in WooCommerce doesn't match the item number in Business Central exactly, including leading zeros and case, the sync will either create duplicates or update the wrong item. Compare both lists before the first sync, and look for near-duplicates that differ only by a dash or a trailing space.
How do order statuses map?
Business Central has its own states for sales orders, shipments, and invoices. WooCommerce has its own status names, and plugins often add more. The mapping between them decides when an order is "real" in your books. Get it wrong and you'll see invoices created for orders that are still waiting on payment, or shipments posted before the warehouse has packed anything.
Write the map as a table with one row per WooCommerce status and one column for what happens in Business Central at that point. Pending payment should probably create nothing. Processing might create a sales order. Completed might trigger a shipment. Refunded should produce a credit memo, not a deleted order. Argue about each row now, because the sync will follow whatever you agree to.
How will customers be matched?
Customer matching is where a WooCommerce ERP integration either earns trust or loses it. A shopper may check out as a guest, create an account later, and then call in a phone order. Without a matching rule, Business Central ends up with three customer records for one buyer, and the sales history looks fragmented.
Email address is the usual starting point, but it isn't enough on its own. Business customers often place orders under a company name with several buyers using different email addresses. Decide how B2B accounts map to Business Central customer cards, contacts, and ship-to addresses before launch. Changing this later means merging records by hand, which nobody enjoys and which often introduces new errors.
What about tax and currency?
Tax setup in Business Central is tied to tax areas, tax groups, and posting setup. WooCommerce calculates tax using its own rules and rates. If those two systems don't agree on which rate applies, the invoice total in Business Central won't match the amount the customer paid, and your accountant will find the gap at month-end.
Multi-currency adds another layer. If your store charges in one currency but Business Central books in another, you need to define the exchange rule, the timing of conversion, and how rounding differences get posted. Small rounding gaps seem trivial until they add up across thousands of orders. Ask any provider to show you a reconciliation report for tax and currency before go-live, not just a successful test order.
How are returns and refunds handled?
Refunds in WooCommerce are easy to trigger. In Business Central, a refund usually means a credit memo or a return order, and each one affects inventory, revenue, and customer balances differently. A good integration decides, in advance, whether a refund creates a credit memo, whether the returned goods come back into stock, and whether damaged returns get written off.
Return handling is often the last item on the project plan, which is exactly backwards. Returns touch inventory and accounting at the same time, so they belong in the first round of design. Ask the provider to walk through three scenarios: a full refund on an unshipped order, a partial return after shipment, and a damaged item that should never go back on the shelf.
What happens when a sync fails?
Every integration fails sometimes. A network timeout, a missing item, a customer record with a typo in the postcode, or a Business Central validation error can all stop a single order from crossing over. The question is what happens next. Does the record retry automatically? Does anyone get an alert? Can an operator fix the problem and resubmit without a developer?
Ask for a demonstration of a failed sync, not just a description of one. You want to see the error log, the retry behavior, and the screen an operator would use to fix a record. Pay attention to duplicates. An order that gets retried should never produce two sales documents in Business Central. A provider who can't explain how they prevent that has not thought hard enough about failure.
Failure handling is what separates a demo from a dependable WooCommerce ERP integration. The demo always works. The Sunday morning when a batch of orders fails is the real test.
Who maintains it after go-live?
Integrations need an owner. Someone must watch the logs, respond to alerts, review the mapping when a new product line launches, and handle upgrades in both WooCommerce and Business Central. If nobody has that job, the integration slowly decays until a finance person notices that revenue in the ERP looks wrong.
Name the owner before launch. It can be an internal administrator, an external support contract, or a mix of both. Agree on response times for different severities, and make sure the provider can explain what they will do when Microsoft ships a Business Central update. The long life of your WooCommerce ERP integration depends on this conversation more than on the initial build.
How should we test?
Testing needs a sandbox that resembles production. Business Central offers sandbox environments, and your WooCommerce test store should use the same tax settings, shipping methods, and payment gateways as the live site. Testing against a store with three products and no tax rules proves very little.
Build a test script that covers normal orders, multi-item orders, partial shipments, refunds, backorders, failed payments, B2B accounts, and whatever odd transactions your business handles every month. Run the script, compare the results in both systems line by line, and sign off in writing. Many projects skip the final step, which is a parallel run where the new integration and the old process both operate for a short period so the team can compare results before switching over.
Packaged connector or custom build?
A packaged connector is faster to launch when your processes are standard and your catalog is moderate. A custom build makes sense when your pricing, approval steps, or warehouse logic don't match a common model. The mistake is choosing based on the sales deck instead of your hardest scenario.
Take your most unusual order from last year and ask each option to process it in a test environment. If the packaged connector needs three workarounds and a spreadsheet, that's information. If a custom build needs two months of development for one edge case, that's information too. Make the decision on what the business actually needs, and be honest about the maintenance you're signing up for.
Plenty of teams start with a packaged option and move to something custom later, once they understand their own processes better. That path is fine as long as the data model stays clean enough to migrate. Ask how exports and exits work before you start.
What does success look like?
Success should be measurable before the project begins. Pick a small set of numbers: the percentage of orders that create Business Central documents without manual intervention, the average time from order placement to ERP record, the count of failed records per week, and the number of month-end reconciliation differences. Track them from the first day of live operation.
Agree on targets with the provider. A realistic first target might be that most orders sync automatically and that every exception has a named owner. Perfection in week one is unlikely, but a clear trend toward fewer exceptions is a good sign. If the numbers stall, the mapping or the process probably needs attention, not more code.
Frequently asked questions
How long does a WooCommerce ERP integration with Business Central take?
Timelines vary with complexity. A standard setup covering orders, customers, and inventory often takes several weeks from kickoff to go-live, including testing. Custom pricing, multi-company setups, or unusual approval steps can add significant time. The most reliable estimates come from a provider who has reviewed your product data and order types first.
Can a WooCommerce ERP integration handle B2B pricing?
Many can, but the details matter. B2B pricing in Business Central often relies on price lists, customer-specific discounts, and contract prices. The integration needs to send the right customer and price context with each order, and the store needs to show the correct price to logged-in business buyers. Ask the provider to demonstrate a contract price flowing from Business Central into a live WooCommerce order.
Does the integration need Business Central to be in the cloud?
Business Central is offered as a cloud service and as an on-premises product. The integration approach depends on which one you run and how it's exposed to the internet. Confirm the deployment model early, because it affects connectivity, authentication, and how updates are applied. Your IT partner should be part of that conversation from the beginning.
Will the integration handle multiple companies in Business Central?
It can, if the setup is designed for it. Each Business Central company needs its own mapping for items, customers, tax, and posting groups. Orders from the store need a rule for which company they belong to, which may depend on the product line, the country, or the sales channel. Decide that rule before configuring anything, because moving orders between companies later is painful.
How do I know the tax setup is right?
Ask your accountant to review a sample of test invoices from both systems, side by side, for each tax scenario you sell into. Confirm that the tax rate, the taxable base, and the rounding match what you are required to report. A correct tax setup is one your accountant has signed off on in writing, not one that looks right on a screen.
What if we change our product catalog often?
Frequent catalog changes need a clear process for creating, updating, and retiring items. New items should be created in Business Central first, then pushed to the store, so the item number is always the anchor. Retired items should be disabled in the store rather than deleted, because existing orders still reference them. Test the workflow with a few new products before a big launch.
Can I sync customers both ways?
You can, but two-way customer sync needs strict rules. Most teams use the store as the entry point for online customers and Business Central as the owner of the customer master for accounting. Changes made in one place should update the other only where a clear rule says they should. Unrestricted two-way editing usually creates conflicts that nobody knows how to resolve.
How should payment gateways be handled?
Payment status should flow from the gateway through WooCommerce into Business Central, so the ERP knows whether to expect cash. Decide which gateway events create a sales document, which ones post a payment, and what happens when a payment is disputed. Gateways differ in timing, so test each one you use with real transactions in a sandbox.
What's the most common reason projects stall?
In my view, it's unresolved decisions about data ownership and mapping. The technical build is usually the easiest part. Projects stall when no one can agree on which system owns the item price, or what happens when a customer orders from two countries on one account. Settle those questions in a workshop before the build begins, and most of the friction disappears.
Should I hire a developer or rely on the provider?
Most businesses need both, at different times. A provider or partner handles the initial build, mapping, and testing. Your internal team handles daily operations and approvals. A developer may be needed later for custom reports, new workflows, or unusual integrations. Make sure you have a named person on your side who can speak for the business during the project and after it.
If you run Business Central and want orders, stock, and customers to move between it and your store without manual copying, the woocommerce erp integration page lays out how the BCWC Connector handles each piece. You can also book a 30-minute demo and walk through your own order scenarios with someone who knows the setup.
Top comments (0)