How channel orders sync
Most orders in SKU.io don't start in SKU.io. They start on a sales channel — a Shopify storefront, an Amazon marketplace, a WooCommerce site, a Faire wholesale account, or a register at the point of sale. SKU.io pulls each of those in, mirrors it into a single canonical sales order, and — once you ship — pushes the tracking and fulfillment back to the channel so the marketplace order and the SKU.io order tell the same story. This page explains that round-trip: what gets imported, who is authoritative for which field, what writes back, and how SKU.io detects and heals the moments when the two sides drift apart.
Words like shipment, fulfillment order, and sales channel are defined the first time they appear below and collected in the glossary.
One canonical order, many channels
Whatever channel an order comes from, SKU.io stores it as one ordinary sales order — the same object you'd create by hand — plus a link back to the original channel record it was built from. That link points at the channel's own copy of the order, so you can always trace a SKU.io order to its source and read the raw channel data on the order's Channel tab.
| Channel | What the sales order links back to |
|---|---|
| Shopify | The imported Shopify order |
| Amazon | The imported Amazon order |
| WooCommerce | The imported WooCommerce order |
| Faire | The imported Faire order |
| Point of sale | The POS transaction that created the order |
An order you key in by hand carries no channel link — it's a local order. Everything else in SKU.io treats channel orders and local orders identically: the same lifecycle, the same status axes, the same fulfillment workflow. The channel link only matters at the two ends of the round-trip — import and writeback.
Import: How a channel order becomes a sales order
When a channel order arrives, the connected integration reads it and builds (or updates) the matching sales order — copying the customer, the addresses, the line items, the prices, the currency, and the requested shipping method. Two things happen during that mirror that are worth understanding:
- Product mapping. A channel line arrives with the channel's own SKU or product title, not a SKU.io product. SKU.io matches that identifier to one of your products so the line can draw down real inventory. A line that matches becomes a normal product line. A line that doesn't match is left unmapped — see Unmapped lines block fulfillment below.
- A sync timestamp. Every time SKU.io mirrors from the channel, it records when it last did so. That timestamp is what lets a later re-sync tell "this order hasn't changed" apart from "the channel edited this order after we imported it."
The order also carries a few channel attributes that steer the rest of its life — the channel it came from, its fulfillment channel (whether it ships from your own stock or from the channel's warehouses), and whether it's an Amazon FBA order. Those flags decide, for example, whether fulfilling the order moves your inventory at all. Amazon FBA and other externally fulfilled orders are covered in Amazon FBA, MCF, and externally fulfilled orders.
If SKU.io can't build a sales order from a channel order — malformed data, an unresolvable customer, a product it can't place — the import is recorded as a failure rather than dropped. That failure can drive an automation trigger so you're told an order didn't land. See Order events and automation.
Who is authoritative for what
The most important idea on this page: the channel and SKU.io are each the source of truth for different parts of the same order. Knowing which side "wins" for a given field tells you where to make a change and which direction it flows.
| Part of the order | Source of truth | Why |
|---|---|---|
| Order contents — customer, lines, prices, addresses | The channel, at import | SKU.io mirrors the channel order. A later channel edit re-syncs into SKU.io; the sync timestamp guards against overwriting with stale data. |
| Which product a channel line maps to | SKU.io | The channel supplies its own SKU or description; you decide which SKU.io product it represents. |
| Shipped state and tracking | SKU.io's shipment | When you fulfill in SKU.io, the shipment record is authoritative for "this shipped" and is pushed back to the channel. |
| Amazon FBA (channel-fulfilled) orders | Amazon | Amazon ships these entirely outside SKU.io, so SKU.io pins them fulfilled and closed rather than recomputing from records it doesn't own. |
| The partial-fulfillment signal on channels that don't expose per-line shipment data | The channel | Some channels (for example Temu) report only a whole-order status. SKU.io honors the channel's own "partially fulfilled" rather than guessing from the lines — unless it detects an over-fulfillment, which is a stock-integrity signal the channel has no concept of and which is allowed to win. |
Writeback: Fulfilling in SKU.io updates the channel
The return leg of the round-trip fires when you fulfill an order in SKU.io. The moment a shipment reaches its shipped state, SKU.io pushes the fulfillment and its tracking number back to the originating channel:
- Shopify — SKU.io creates a fulfillment on the Shopify order with the carrier and tracking, so the buyer's Shopify account and notification emails reflect the shipment.
- Amazon — SKU.io submits a merchant-fulfilled (MFN) shipping confirmation feed carrying the carrier and tracking.
The goal is one-to-one parity: your SKU.io shipment and the channel's fulfillment record describe the same box with the same tracking. SKU.io's shipment stays authoritative for shipped state — it's the record that decides the order is fulfilled, and the channel is brought into line with it.
To see whether the two sides agree, open the order's Fulfillment tab. For channels that itemize their fulfillments (Shopify, Faire), SKU.io lists the channel's own fulfillment records alongside your SKU.io shipments and highlights any per-line quantity difference between them — with a Show differences only toggle — so you read the divergence off a side-by-side comparison rather than reconciling the two by eye. See the order detail reference for the layout of that tab. For the mechanics of recording a shipment in the first place, see Fulfill a sales order, and for the shipment-versus-plan distinction, see Two-tier fulfillment.
Pushing a fulfillment to the channel is a network call to someone else's system, and it can fail (an expired connection, a channel-side error, a deleted order). When it does, your SKU.io order is still fulfilled and correct, but the channel order stays showing as unfulfilled until the writeback succeeds. SKU.io retries pending fulfillments, so most gaps close on their own — but if a channel order looks stuck unfulfilled while SKU.io shows it shipped, a failed writeback is the usual cause.
Merged shipments write back to every order
When you combine several orders into one physical shipment — for example by merging fulfillments across orders — that one shipment may originate from more than one channel order. SKU.io writes the same tracking number back to each contributing channel order independently, so every buyer sees their order marked shipped with the correct tracking even though the goods travelled in a single box.
When the two sides drift: Out-of-sync and unmapped
Because the channel and SKU.io are separate systems editing the same order, they can fall out of step. SKU.io has two distinct signals for this, and they mean different things.
Unmapped lines block fulfillment
If a channel line's SKU doesn't match one of your products, the line imports as unmapped. An unmapped line has no product behind it, so it can't draw down inventory — and SKU.io won't let you fulfill an order while any line is unmapped. Unmapped lines are highlighted (amber) with a Link to product action, and the order's Channel tab shows a count of how many lines still need mapping.
Resolving them is a mapping task, not a fulfillment task: map each line to the right product (once, for that order, or permanently so future orders with the same channel SKU resolve automatically). See Map an unmatched line to a product.
The same rule that stops you fulfilling an order with unmapped lines also stops you closing it. An order can't reach a clean terminal state while part of it isn't tied to real inventory. See How sales order status works.
Out of sync: SKU.io removed a shipment the channel still shows
The Out of Sync fulfillment status is narrower and more specific. It appears when SKU.io has removed submitted fulfillments from a shipping provider — typically because the order's lines changed after a fulfillment was already dispatched — while the channel may still be showing those fulfillments. Rather than silently pretend everything is aligned, SKU.io flags the order Out of Sync, adds an order note explaining what it removed, and stops trusting the derived fulfillment status until you tell it to recompute.
An out-of-sync order is resolved by resetting its fulfillment status, which recomputes it from the actual fulfillment records. That reset is the only way out of the state, and it's available only while the order is out of sync. See Void, restore, or reset a shipment for the exact action, and the status reference for where Out of Sync sits among the other fulfillment values.
A related, line-level flag marks individual lines whose channel fulfillment is out of sync. Those lines are deliberately excluded from allocation and from the "needs allocating" worklist — they're tracked separately rather than expected to be reserved from stock.
Other import quirks
A handful of smaller channel-import behaviors are worth recognizing when you meet them:
- Phantom shipments. Some orders arrive already shipped — the channel reports the order as fulfilled at the time SKU.io imports it. SKU.io records a shipment for those units even though no carrier hand-off happened inside SKU.io, so the order reads fulfilled without you shipping anything. When the channel supplied a tracking number on that shipment, SKU.io carries it (and the carrier/company) onto the imported shipment so it shows on the order; what never happens for these is a dispatch to a shipping provider from your side — the carrier hand-off already took place on the channel.
- Sub-channels. An order can arrive tagged with a sub-channel (a marketplace within a marketplace, or a named storefront), which drives list filters and reporting. An order whose sub-channel can't be resolved is still imported and usable.
- Held and pre-start-date orders. An order dated before your configured inventory start date, or one placed on hold, is imported but kept out of the active allocation and fulfillment flow until it's eligible — so historical or held channel orders don't disturb your live stock picture.
OCR ingestion: A second, human-in-the-loop import
Not every "channel" is an API. When a customer emails you a purchase-order PDF, SKU.io can read it with optical character recognition (OCR) and turn it into a draft order — but this path is deliberately staged, not automatic.
An uploaded PDF becomes an extraction: a staging record, not yet a sales order. SKU.io reads the header and lines, matches the customer's SKUs against your products, and parks the extraction in a Pending review state for you to check. From there you can:
- Create the order — only from the pending-review state, and only after any unmatched customer SKUs are mapped by hand. This is the step that finally mints a real sales order.
- Rescan the document if the first read was poor, clone an order to seed the extraction, or reclassify it as a supplier invoice if the PDF turns out to be a bill rather than an order.
Because the extraction is separate from the order, a bad scan never creates a bad order — you review and correct first. The full walkthrough lives in Import sales orders, alongside the bulk CSV import path.
Next steps
- Import sales orders — bulk CSV and OCR ingestion, step by step.
- Map an unmatched line to a product — clear the unmapped lines that block fulfillment.
- Fulfill a sales order — the action that triggers writeback to the channel.
- Void, restore, or reset a shipment — resetting an out-of-sync order.
- How sales order status works — where Out of Sync fits among the fulfillment statuses.
- Amazon FBA, MCF, and externally fulfilled orders — channel-fulfilled orders that ship outside SKU.io.
- Order events and automation — reacting to imported and failed orders.