What sync actually covers
"Shopify sync" sounds like one feature, but it's really six overlapping ones, and most integrations don't handle all six with the same seriousness.
Orders are the obvious one — a new order in Shopify needs to exist in the ERP within seconds, not at the next scheduled batch. Customers need to be created or matched, so repeat buyers don't become duplicate records every time they order. Products and variants need to sync on both creation and update, so a title, price, or option change in Shopify doesn't require re-entry elsewhere. Inventory is the one item that has to run in both directions — more on that below — because both systems need to agree on how many units actually exist. Fulfillments need to flow back from Shopify as shipping and delivery events happen, so order status reflects reality. And payment status — captures, voids, refunds — needs to update whatever ledger tracks what a customer has actually paid.
This matters as a list because integrations tend to get built in the order above, and stop partway through. Order sync is genuinely the easiest piece to build — which is exactly why so many integrations look complete after step one and quietly leave the rest as future work.
Webhooks vs. CSV exports
Two fundamentally different mechanisms get sold as "Shopify integration," and the difference between them determines almost everything else about how the integration behaves.
A webhook-based integration means Shopify calls the receiving system the moment something happens — an order is created, a fulfillment is updated, a refund is issued. The receiving system doesn't ask for data; Shopify pushes it, typically within seconds. This is what makes real-time inventory and same-day order visibility possible at all.
A CSV-export or polling-based integration means the receiving system periodically asks Shopify what's changed, or a person manually exports a file and imports it elsewhere. That's not a lazy approach in every context — for a one-time historical backfill, an export is often the right tool. But as an ongoing sync mechanism, it reintroduces the exact latency problem an integration is supposed to solve: the gap between an order happening and it being visible elsewhere stretches from seconds to however long the poll interval or export cadence is.
Freshness is the headline difference, but webhooks also raise two problems polling doesn't face in the same way. Deduplication: Shopify's own delivery guarantee is "at least once," not "exactly once" — a network hiccup can cause the same event to be delivered twice, and an integration that doesn't dedupe on a stable key like (store, order ID) will occasionally create the same order twice. Failure handling: a webhook delivery can fail if the receiving server is briefly down or unreachable. Shopify retries automatically, but a serious integration still needs its own reconciliation pass — a periodic check that catches anything a genuine outage might have missed, rather than assuming every webhook that was supposed to arrive, did.
Neither problem is a reason to avoid webhooks — they're the price of real-time sync, and a trustworthy integration pays that price explicitly rather than pretending the failure modes don't exist.
The hard 20%: where accounting actually breaks
Getting an order's line items and total into another system is, relatively speaking, the easy part. The remaining work — call it the hard 20% — is almost entirely about the situations where "the order" and "the money" stop being the same thing.
Refunds are the first crack. A refund isn't just a negative order — it needs to reverse the specific revenue, tax, and cost-of-goods-sold entries the original sale created, and any restocked units need inventory to reflect that too. An integration that treats a refund as "subtract from the total" instead of "post a proper reversing entry" produces books that don't actually balance, even if the top-line numbers look approximately right.
Payment gateways and their fees are the second. The amount a customer paid and the amount that lands in a bank account are rarely the same number — a processor takes a fee, and that fee is a real expense needing its own line, matched to the order it came from. An integration that only records "order paid" without capturing the fee quietly overstates margin on every transaction.
Partial fulfillments complicate the tidy assumption that one order equals one shipment equals one moment of revenue recognition. When an order ships in two boxes on two different days — common for backorders or multi-warehouse fulfillment — the accounting needs to track that state without double-counting the shipment or losing track of what's still owed.
Cash on delivery (COD) is its own category, and it matters most in markets where COD is a dominant payment method. A COD order is "paid" only once the courier collects cash and that collection is reconciled back — so the order can be shipped, delivered, returned, or fail delivery, and each outcome needs its own accounting treatment rather than one generic "order complete" state.
These are where a superficial integration and a real one diverge — exactly the surface the commerce and Shopify layer has to get right for the books to be trustworthy rather than merely plausible.
Inventory truth across store, warehouse, and POS
Inventory is the one data type here that has to move both directions, which makes it the hardest to get right.
Every other sync direction is one-way by nature: an order or fulfillment happens in Shopify and flows to the ERP. But inventory gets touched from multiple places at once — a storefront sale, a point-of-sale sale, a stock adjustment or transfer inside the ERP, a work order completing in a warehouse. Whichever of those happens most recently is the one that's actually true, and every other system needs to catch up to it — not just the ERP catching up to Shopify.
This is where "one number per SKU" stops being a slogan and becomes an engineering requirement: a correction made inside the ERP — a recount, a transfer, a production run finishing — has to push back out to the storefront, or the storefront keeps selling a unit that's no longer there. A system that only pulls Shopify's stock count and never pushes back is solving half the problem, and the half that lets overselling happen quietly is the more expensive half to get wrong.
Checklist for evaluating any Shopify-ERP integration
Whether the integration under consideration is Kayan's or anyone else's, these are the questions worth asking before trusting it with real order volume:
- Webhooks or polling? Ask for the actual typical delivery latency, not just the word "real-time."
- Deduplication on a stable order identifier? A retried webhook delivery should never create a second order.
- A reconciliation pass independent of webhooks? Something has to catch orders missed during a genuine outage.
- Do refunds post as reversing entries, not negative totals? Ask whether a refund reverses revenue, tax, and COGS, and whether restocked units update inventory.
- Are gateway fees captured as their own line item? If fees aren't visible, margin is overstated on every order.
- Does inventory sync both directions, or only from Shopify outward? A one-way pull can't prevent overselling caused by an ERP-side correction.
- How are partial fulfillments and multi-shipment orders handled? Ask for a concrete walkthrough, not a yes/no.
- Is cash-on-delivery its own accounting path? This matters most where COD volume is significant.
- What happens during a webhook or API outage? A real answer describes a recovery mechanism.
- Can historical orders be backfilled? A switch shouldn't mean losing continuity with everything before it.
How Kayan Sync implements each item
Kayan's Shopify integration — Kayan Sync — is built around the list above; worth being specific about what's true today rather than aspirational.
Orders, order payment status, products and variants, fulfillments, and customers all sync from Shopify to Kayan by webhook, with new and updated orders arriving within seconds. Inventory is the one data type that runs bidirectionally: Kayan pulls the initial stock counts from Shopify on connection, and pushes adjustments back to Shopify after they're made inside Kayan — an adjustment, a transfer receipt, a work order completing — so an ERP-side correction reaches the storefront instead of staying invisible to it. Push-back can be disabled per location for stores that manage fulfilment separately for specific warehouses.
On reliability: every webhook delivery is verified against an HMAC signature over the raw request body before processing, and each Shopify order is stored against a unique (organization, order ID) key — so a webhook delivered twice still produces exactly one order. A reconciliation poll runs independently of the webhook stream to catch orders an outage might have missed.
Gateway payments and fees attach to the order they belong to and post as their own journal lines rather than one lumped figure, and refunds post as proper reversing entries, including restocking any returned units. Fulfillment status — including cash-on-delivery orders carried via Bosta — flows through delivery-and-refund accounting whether an order ships, is delivered, fails, or is returned, and carrier costs post into the ledger as a freight accrual.
Connecting the integration is a short flow: enter a store domain, approve the requested scopes in the Shopify admin, then a backfill pulls in past order history and the full product catalogue automatically. What doesn't sync — deliberately — is storefront content: themes, blog posts, pages, and discount codes stay in Shopify, because Kayan Sync is scoped to operational and financial data, not content management.