Business Central and Shopify: Connecting Your Store to the ERP

Almost every business that sells online eventually hits the same wall. The store works, orders are coming in, and then someone has to take each order and type it into the accounting system so the business can invoice, pick, ship and account for it. For a handful of orders a day that is an annoyance. At a few hundred a day it is a full-time job with a built-in error rate, and the errors are the expensive kind: wrong stock, oversold items, mispriced orders, customers created three times over. Connecting the store to the ERP removes that wall. When it is done well, an order placed on the storefront becomes a sales document in the ERP within minutes, inventory stays honest across both systems, and finance stops reconciling by hand. This guide is about doing that well, using Business Central and Shopify as the concrete example, and then generalising to the other platforms you might be running.

The message up front: e-commerce integration is not really a technology problem, it is a data-ownership problem. Decide which system is the master for products, prices, stock and customers before you connect anything. Get that decision right and the sync is straightforward. Get it wrong and you spend the next year firefighting conflicts between two systems that both think they are in charge.

1. Why your store and your ERP must talk

Start with what actually happens when they do not talk. A customer places an order on the storefront. Someone reads that order, opens Business Central, creates a sales order, keys in the customer, keys in the lines, checks the price, and saves it. Then they go back to the store and mark it as being processed. Every one of those steps is a place a human introduces an error, and every order pays that tax. Multiply it by your daily order volume and you can see the real cost: not just the labour, but the mistakes that labour makes when it is tired at four in the afternoon on a busy day.

The disconnected model fails in four specific ways. First, re-keying orders is slow and error-prone, and it does not scale, so growth in sales turns directly into growth in back-office headcount. Second, inventory is a guess. The store shows whatever stock number was last typed in, which drifts out of line with the real figure in the ERP the moment anything ships or is received, so you either oversell and disappoint customers or you hoard safety stock and tie up cash. Third, pricing and product data diverge. A price changed in the ERP does not reach the store until someone remembers to change it there too, and the two descriptions of the same product slowly become two different products. Fourth, finance loses the thread. Revenue recognised on the store does not match revenue posted in the ERP, tax is calculated inconsistently, and month-end becomes an archaeology exercise.

A working integration fixes all four at once because it makes one system the source of truth for each kind of data and keeps the other in step automatically. Orders flow in without typing. Stock levels reflect reality on both sides. A price change in one place propagates. Finance sees a clean, posted trail. The whole point of connecting the store to Business Central is to let the ERP do what it is good at, which is inventory, costing, invoicing, tax and the financial record, while the store does what it is good at, which is selling. For the wider view of how Business Central manages the stock side of this equation, the Business Central inventory management pillar is the companion to this one, and the sales order management pillar covers what happens to an order once it lands in the ERP.

2. The native Business Central Shopify connector

The reason Shopify gets used as the worked example throughout this guide is that Microsoft ships a native connector between Business Central and Shopify as a standard part of the product. You do not have to buy a third-party bridge or build one yourself for the common case. The connector is installed and configured from within Business Central, you point it at your Shopify store, authorise the connection, and you get a supported, first-party integration that Microsoft and Shopify both maintain. That is a meaningful advantage: a first-party connector moves with the platform, gets updated alongside new releases, and does not become orphaned when a small vendor stops supporting their app.

At the capability level, the native connector synchronises the four things that matter most between a store and an ERP:

• Items (products): your Business Central items can be published to Shopify as products, so the catalogue the store sells from is derived from the ERP item master rather than maintained separately. Item details, pricing and stock information flow to the store.
• Inventory: available quantities are kept aligned so that what the store shows as in-stock reflects what the ERP actually holds, which is the single most important thing to get right if you want to stop overselling.
• Orders: orders placed on Shopify are brought into Business Central as sales documents, so an online sale becomes a real sales order or invoice in the ERP without anyone re-keying it.
• Customers: the shoppers who place those orders are synchronised into Business Central as customers, so the person who bought is a proper record in the ERP linked to their orders, not an anonymous line on a report.

Those four, items, inventory, orders and customers, are the backbone of any store-to-ERP integration regardless of platform. The value of the native connector is that it handles all four in a supported, configurable way, with settings that let you decide how aggressively to sync, which items to publish, how to map fields, and how to handle the edge cases. It is not a magic button, you still have to make the design decisions this guide is about, but it removes the entire build-and-maintain burden for the most common e-commerce platform. If you are choosing an e-commerce platform partly for how cleanly it will connect to your ERP, that native support is a real reason Shopify sits near the top of the Business Central list. The broader question of how well Business Central plugs into surrounding systems is covered in the Business Central APIs and integrations pillar.

3. How the sync works and what direction data flows

The most important thing to understand about any store-to-ERP integration is direction. Every field that lives in both systems needs a decision: which system is the master, and which is the follower. Get this explicit and written down before you switch anything on, because a sync that pushes data in the wrong direction, or in both directions for the same field, is how you corrupt data quietly across two systems at once.

The natural direction of flow for the four core objects follows from what each system is good at:

Read that table as a set of ownership decisions, not a technical diagram. The ERP owns what the product is, what it costs, and how much of it exists, so those flow outward to the store. The store owns the act of selling, who bought and what they ordered, so those flow inward to the ERP. Fulfilment status flows back out to the store once the ERP ships the order, so the customer can see their tracking. That is the clean default, and the native connector is built around exactly this shape of flow.

The second thing to understand is timing. Syncs run on a schedule or in response to events, not instantaneously in every case. An order might arrive in the ERP within a minute or within a scheduled cycle depending on how you configure it. This matters because your business processes have to tolerate the sync interval. If your warehouse expects to see orders the instant they are placed, and the sync runs every fifteen minutes, that gap needs to be understood and accepted, or the cycle tightened. Being honest about the sync interval up front avoids the recurring complaint that orders are appearing late, when in fact they are appearing exactly as configured.

The third thing is what happens when a record cannot sync. A well-run integration has a place where failed syncs surface, an order that could not be matched to a customer, an item that could not be published because it is missing a required field, a price update that could not apply. These need a monitored queue and a person who owns clearing it, because the failure mode of ignored sync errors is silent divergence: the two systems drift apart one skipped record at a time, and nobody notices until a customer or an auditor does.

4. Products, pricing and inventory alignment

Products are where most integrations either start clean or start crooked, and it is worth spending real design time here. The core decision is whether the ERP item master is the source of truth for the catalogue, or whether the store keeps its own product records and only exchanges enough with the ERP to process orders. The cleaner model, and the one the native connector supports, is ERP-as-master: you maintain items in Business Central and publish them to Shopify, so there is one authoritative definition of each product and the store is a presentation of it.

That said, an online store legitimately needs data the ERP does not care about: rich descriptions, lifestyle photography, SEO metadata, merchandising collections, marketing copy. The practical pattern is a split of responsibilities. The ERP owns the commercial and logistical facts, the item number, the price, the unit of measure, the tax setup, the stock. The store owns the presentation, the imagery, the storytelling, the on-page merchandising. The integration carries the commercial facts from ERP to store and leaves the presentation layer to the store. Trying to manage marketing content in the ERP, or trying to manage pricing and stock in the store, are both roads to frustration.

Pricing deserves particular care because it is where quiet errors cost real money. The ERP should be the master for the selling price so that a price change made once in Business Central reaches the store automatically, rather than being maintained in two places and slowly diverging. Two specifics catch people out. First, tax treatment: is the store price tax-inclusive or tax-exclusive, and does that match how the ERP holds and posts it? A mismatch here means every order posts with the wrong tax. Second, currency and price lists: if you sell in multiple currencies or run customer-specific pricing, you have to decide how much of that structure the store needs and how it maps, because a storefront rarely mirrors the full price-list complexity of an ERP.

Inventory is the field that customers notice fastest when it is wrong. The design principle is that the ERP holds the true available quantity and pushes it to the store, so the store never shows more than exists. The subtlety is defining what available means. Is it total on hand, or on hand minus what is already committed to open orders? Selling the same physical unit twice because two channels both saw it as available is the classic multi-channel failure, and it is prevented by the ERP calculating a genuine available-to-sell figure and syncing that, rather than a raw stock count. This is exactly where the ERP earns its place, because calculating true availability across reservations, open orders and incoming supply is what a proper inventory system does. If you are running a store alongside physical retail or other sales channels, the Business Central for retail pillar goes deeper on the multi-channel stock picture.

5. Orders, fulfilment and returns

The order is the payload the whole integration exists to move. When a customer completes checkout on Shopify, that order needs to become a document in Business Central that the business can act on: pick it, ship it, invoice it, account for it. The native connector brings orders in as sales documents, and the design questions are about how much processing you want to happen automatically versus with a human in the loop.

A well-formed incoming order carries everything the ERP needs to process it without anyone re-typing: the customer, the shipping and billing addresses, the line items mapped to the correct ERP item numbers, the quantities, the prices as charged, the shipping cost, the tax as calculated at checkout, and the payment status. The mapping of store products to ERP item numbers is the joint that has to be tight, because an order line that cannot be matched to an item is an order that cannot be processed automatically and lands in the exception queue. Keeping the item mapping clean is most of what keeps order sync reliable.

Fulfilment is the return leg. Once the ERP ships the order, the fulfilment status and tracking information should flow back to the store so the customer sees their order marked as shipped with a tracking number, without anyone updating the store by hand. This closes the loop: order in from the store, fulfilment out to the store, and the customer experience stays coherent across both systems. Skipping this leg is a common half-measure, orders come in automatically but shipping updates are still typed into the store manually, which reintroduces exactly the re-keying the integration was supposed to remove.

Returns and refunds are the part everyone underestimates. A store order is not final at the point of sale; some fraction comes back, and the integration has to handle a return as more than a note. A refund on the store has a financial counterpart in the ERP, a credit memo or return order, and the returned stock has an inventory counterpart, the goods coming back into available quantity. If returns are not part of the integration design, they become a manual reconciliation that grows with your return rate. Decide early how a Shopify refund maps to a Business Central credit and how returned goods re-enter stock, because retrofitting returns handling onto a live integration is harder than designing it in.

The honest limitation: no connector, native or otherwise, will fix a messy item catalogue or an inconsistent product mapping. If the same physical product exists under three item numbers in the ERP and two SKUs on the store, the integration will faithfully carry that mess in both directions and multiply it. The unglamorous work of cleaning up your item master and agreeing one SKU per sellable thing is the foundation the whole integration stands on, and there is no software shortcut around it.

6. Customers, tax and financial posting

Customers are the object most likely to make a mess quietly. Every online order is placed by someone, and that someone needs to exist as a customer in the ERP so the order can be posted against them and so you have a real record of who buys what. The native connector synchronises Shopify customers into Business Central, and the design challenge is matching: recognising that the person placing today's order is the same person who ordered last month, rather than creating a fresh customer record every time.

Duplicate customers are the classic symptom of weak matching. A shopper who uses a slightly different email, or checks out as a guest, or whose name is spelled differently, becomes a second customer record, and now their history is split across two accounts and your customer count is inflated with phantoms. The defence is a clear matching rule, usually on email as the primary key, and a decision about how to handle guest checkouts, whether they map to individual customers or to a single generic web-sales customer. High-volume consumer stores sometimes deliberately post all web sales against one summary customer to avoid a flood of one-order records, while lower-volume or B2B stores want each customer as a proper record. There is no universally right answer, but there is a right answer for your business, and you have to choose it deliberately rather than let the default decide.

Tax is where e-commerce integrations most often post wrong without anyone noticing until a filing. The store calculates tax at checkout using its own tax engine and rules. The ERP has its own tax setup for posting. These two have to agree, or every order carries a small discrepancy that compounds. The specific things to reconcile: whether prices are tax-inclusive or exclusive on each side, whether the tax rates and jurisdictions match, and critically, whether the tax amount the store actually charged the customer is the amount that posts in the ERP. The safest principle is that the tax charged to the customer at checkout is the tax of record, and the ERP posts that figure, rather than recalculating tax independently and producing a number that differs from what the customer paid. A recalculation mismatch is small per order and enormous in aggregate.

Financial posting is the endpoint that makes the whole thing worth doing. When an order flows cleanly from store to ERP with the right customer, the right lines, the right prices and the right tax, it posts to the general ledger correctly and finance can trust the numbers without a manual reconciliation. That is the payoff: revenue on the store matches revenue in the ledger, tax is consistent, and the customer sub-ledger reflects reality. The whole integration effort is ultimately in service of this, a financial record that is right by construction rather than right after a month-end scramble. Business Central sitting at the centre of the Microsoft stack also means this financial data is available to the reporting and analytics tools around it, which the Business Central and the Microsoft ecosystem pillar covers.

7. Beyond Shopify: other platforms via APIs and middleware

Shopify gets the native connector, but plenty of businesses run something else: WooCommerce, Magento, BigCommerce, a marketplace like Amazon, or a bespoke storefront built in-house. The good news is that the design principles are identical regardless of platform. The same four objects, items, inventory, orders and customers, still need to flow, the same ownership decisions still apply, and the same failure modes, stock mismatches, duplicate customers and tax errors, still lurk. What changes is the mechanism connecting the two systems, because there is no first-party connector to lean on.

There are three broad ways to connect a non-Shopify store to Business Central:

• Direct API integration: Business Central exposes APIs, and so does every serious e-commerce platform. You can build an integration that reads orders from the store's API and writes them into Business Central through its API, and pushes items and stock the other way. This gives you full control and no per-transaction middleware cost, but you own the build and the maintenance, including handling authentication, retries, error queues and every platform version change.
• Integration platform (iPaaS) or middleware: a dedicated integration service sits between the store and the ERP, with pre-built connectors for both, and you configure the mapping rather than code it. This is the most common choice for non-native platforms because it handles the plumbing, the scheduling, the error handling and the retries for you, and it insulates you from API changes on either side. The trade-off is a subscription cost and a dependency on the middleware vendor.
• Pre-built connector app: for popular platforms, third parties publish connector apps, sometimes on Microsoft's marketplace, that do for WooCommerce or Magento roughly what the native connector does for Shopify. Quality varies, so evaluate the vendor's longevity and support before you depend on their app, but a good one gets you most of the native-connector benefit for a platform Microsoft does not cover directly.

The choice between these comes down to volume, complexity and appetite for ownership. A high-volume store with complex rules and the engineering capacity to maintain it might build a direct API integration for control and cost. A business that wants it to just work and does not want to own the plumbing chooses middleware. A business on a popular platform with a straightforward model buys a proven connector app. What none of them should do is re-key orders by hand while pretending the volume is still small enough to manage. The API surface that makes all three approaches possible is the subject of the Business Central APIs and integrations pillar, which is worth reading alongside this one if you are on a non-Shopify platform.

8. Multi-channel and multi-store scenarios

Life gets more interesting when there is more than one selling channel. Many businesses run a Shopify store, a physical shop, and a marketplace presence all at once, or several stores for different regions or brands. The integration principles hold, but a new discipline becomes essential: the ERP has to be the single point that reconciles stock and orders across every channel, because no channel can safely be its own source of truth once there is more than one of them.

The central risk in multi-channel is overselling the same physical stock across channels. If the Shopify store and the Amazon listing both independently believe they have ten units, they can each sell ten, and now you owe twenty units you do not have. The only reliable defence is a single available-to-sell figure calculated in the ERP and pushed out to every channel, so that a sale on any channel reduces the available quantity that all the others see. This is precisely the job an ERP is built for, and it is the strongest argument for making Business Central the hub rather than letting each channel manage its own stock. The moment you have two channels, channel-owned inventory is a liability.

Multi-store adds a mapping dimension. Two stores might sell overlapping catalogues at different prices in different currencies for different regions, and the integration has to route each store's orders to the right entity, apply the right price list, and post to the right dimension so reporting can tell the channels apart. Business Central's dimensions are the natural tool here: tag every web order with its source channel and store, and financial reporting can slice revenue and margin by channel without a separate spreadsheet. Designing that dimensional tagging into the integration from the start is far easier than adding it after a year of untagged orders. For businesses weighing whether Business Central is the right hub for this kind of multi-channel operation in the first place, the is Business Central right for your organization pillar frames that decision.

9. Common integration pitfalls

Across e-commerce integrations, the same handful of problems recur regardless of platform, and every one of them is preventable with the right up-front design. Knowing them in advance is most of the battle:

• Stock mismatches from ambiguous availability: the store shows a stock number that does not reflect what is truly available to sell, because the sync pushes raw on-hand instead of on-hand minus commitments. The result is overselling and disappointed customers. Fix: sync a genuine available-to-sell figure calculated in the ERP, not a raw count.
• Duplicate customers: weak matching creates a new customer record for what is really a returning shopper, inflating the customer count and splitting order history. Fix: a clear matching key, usually email, and a deliberate policy for guest checkouts.
• Tax discrepancies: the store charges one tax figure at checkout and the ERP posts a different one because it recalculates independently. The gap is tiny per order and large in aggregate, and it surfaces at filing time. Fix: post the tax actually charged as the tax of record, and reconcile inclusive-versus-exclusive treatment on both sides.
• Item mapping breaks: an order line references a product that cannot be matched to an ERP item, so the order cannot process automatically. Fix: one clean SKU per sellable thing, mapped once and maintained.
• Ignored sync error queues: failed syncs pile up unwatched and the two systems drift apart silently. Fix: a monitored exception queue with a named owner who clears it.
• Bidirectional conflicts: the same field is set to sync in both directions, so the two systems fight over which value wins and data flickers. Fix: one master per field, direction decided and documented before go-live.
• Forgetting returns and refunds: orders flow in but refunds and returned stock are handled manually, growing with the return rate. Fix: design credit memos and stock returns into the integration from the start.

Notice that none of these is a limitation of the connector or the platform. They are all design decisions that were skipped or made by default. The connector will do exactly what you configure it to do, which is why the configuration decisions, not the software, determine whether the integration is clean or a constant source of small fires.

10. A practical path to a clean integration

If you are about to connect a store to Business Central, the sequence matters more than the specific tooling. The path I would advise any business to follow:

• Step 1: clean the item master first. Before connecting anything, get to one SKU per sellable product, with correct pricing, units and tax setup in the ERP. The integration amplifies whatever state your catalogue is in, so start it clean.
• Step 2: decide ownership per field. Write down which system masters products, prices, stock, customers, orders and fulfilment status, and in which direction each flows. This document is the specification the whole integration is built against.
• Step 3: pick the mechanism. On Shopify, use the native connector. On another platform, choose between direct API, middleware, or a proven connector app based on your volume, complexity and appetite for ownership.
• Step 4: nail tax and availability before go-live. Confirm that the tax charged matches the tax posted, and that the stock figure synced is true available-to-sell. These two are the errors that cost real money, so verify them explicitly rather than assuming.
• Step 5: pilot with a subset. Sync a limited catalogue and a low order volume first, watch the exception queue, and confirm orders, stock, customers and tax all behave before opening the floodgates. Prove the loop closes on a small scale.
• Step 6: design returns and fulfilment feedback in. Do not stop at orders flowing in. Make sure fulfilment status flows back to the store and refunds map to credits and stock returns, so the loop is complete in both directions.
• Step 7: assign an owner for the exception queue. A named person watches failed syncs and clears them. This is the difference between an integration that stays healthy and one that silently rots.

Steps one and two, the catalogue cleanup and the ownership decisions, are the ones businesses most want to skip and most regret skipping. They cost nothing but discipline, they happen before any software is switched on, and they determine whether the rest of the project is smooth or a series of conflicts. The technology, whether it is the native connector or middleware, is the easy part. The design decisions this guide keeps returning to are the part that actually earns the clean result.

Final thoughts

Connecting a store to the ERP is one of the highest-return integrations a growing business can do, because it removes a cost that scales linearly with sales, the re-keying and reconciliation tax, and replaces it with a system that gets cheaper per order as volume grows. Business Central makes the common case genuinely straightforward with a native Shopify connector that syncs items, inventory, orders and customers as a supported first-party feature, and the same principles extend cleanly to other platforms through APIs, middleware or connector apps when Shopify is not the store.

The thing to hold onto is that the connector is not the project. The project is the set of decisions about who owns what data, which direction each field flows, how availability is calculated, how customers are matched, and how tax and returns are handled. Make those decisions deliberately, clean the item master before you start, and assign someone to watch the exceptions, and the integration is a quiet workhorse that just runs. Skip them and no connector, native or otherwise, will save you from the stock mismatches, duplicate customers and tax discrepancies that make store-to-ERP integrations a byword for pain. The difference between the two outcomes is not the software. It is the practitioner's judgement about the boring decisions, made before anything is switched on.

Related reading: Business Central APIs and integrations, Business Central inventory management, Business Central sales order management, Business Central for retail, Business Central and the Microsoft ecosystem, Is Business Central right for your organization?.