Skip to main content
Process a sale by checking the order evidence that entered AIM, confirming the right sale and line are linked to the right inventory, and handing the order to the next supported work queue. A provider order, accepted webhook, or provider status is an inbound signal; it is not proof that AIM persisted the sale, matched inventory, completed a reservation, or completed fulfillment. Who does this: A sales or operations operator with access to the relevant Sales and fulfillment work. Who else is involved: An inventory operator when the line needs attribution or a unit decision, and a Shopify or marketplace administrator when the source record, account, or channel connection needs attention.

​
Before you start

  • Have the provider order number and the channel account or store that owns it.
  • Have the line item evidence: line ID when shown, product, size or option, SKU, quantity, and the source order’s financial, fulfillment, and cancellation state.
  • Confirm that you can open the relevant Sales, Fulfillments, inventory, or Inventory Reservations surface for your role. The available actions depend on your access and your business setup.
  • If you are working on a Shopify order, have the store, order, line, Variant link, and Location link evidence. If you are working on eBay, keep the order, line-item, SKU, and variation evidence together.
What this touches: The channel-native sale status and its operational stage; the sale-to-line and inventory links; an Inventory Reservation when the named flow creates one; selected inventory units and cost evidence when present; and post-sale, fulfillment, failure, or cancellation history. These records answer different questions, so one row or one provider page is not enough to prove the whole sale is processed.

​
Keep the boundaries visible

The shape is intentionally conditional. Marketplace orders enter through their channel sync and do not universally create an Inventory Reservation. Shopify order webhooks are authenticated and queued before acknowledgment, with a recovery sync for missed events. In both cases, a queued or accepted operation still needs durable AIM evidence before you call the sale processed.

​
Process

​
Channel variants

​
Marketplace orders

StockX, GOAT/Alias, and eBay orders arrive through their channel sync. AIM scopes the match to the business, credential or account, marketplace, order, and listing context. eBay can require order plus line-item and variation identity; an ambiguous multi-variation match is a review condition, not permission to pick the first similar offer. Marketplace processing does not have one universal reservation step. Depending on the channel and sale path, inventory evidence can be distributed across the sale, inventory item, selected unit, cost evidence, and post-sale records. Check those records and the channel-native source status before calling the sale processed. Marketplace order-ingestion failures follow the channel’s own retry and cursor boundary. GOAT and StockX hold the poll timestamp when an order in the batch fails, so the next sync can revisit that point; eBay isolates order-level processing errors. This is an ingestion rule, not a universal rule for every line or every later operation. A post-sale inventory adjustment is a separate stage: a failed adjustment is not a successful deduction or provider completion, and the current eBay follow-up can still call post-sale listing management after logging that failure. The explicit no-relist guard is channel-specific, so check the current path rather than claiming that a failed adjustment always suppresses relisting. If inventory cannot be matched, AIM may queue inventory resolution or put the sale in Attention. Use Match sale to inventory or escalate with the exact order and line evidence.

​
Shopify orders

Shopify order webhooks are authenticated and placed into durable work before the webhook is acknowledged. That acknowledgment means accepted for processing, not that the sale is complete. A recovery sync can find a missed event and fill a missing line, while line-level duplicate checks protect an existing sale. Shopify attribution is store, order, and line specific. Check the Shopify line ID, product and variant, SKU, Variant link, Location link, and the matching AIM sale. A multi-line order can have different locations or different outcomes; verify each line rather than declaring the whole order complete from one line. For the Shopify SHIP, PICKUP, or DELIVERY flow that creates an Inventory Reservation, order-time allocation can prefer a requested location and use Available inventory. The reservation lowers Available and raises Reserved, and its linked cost evidence is part of the check. When the supported fulfillment transition consumes the reservation, Reserved falls once; do not subtract Reserved from Available a second time. A shortfall or negative Available remains visible and needs review. Shopify financial and fulfillment evidence also affects the operational stage. Paid or authorized and unfulfilled is still pending; fulfilled evidence can move the sale to completed; a partial order remains pending unless durable line-level truth proves completion. A linked Shopify status correction does not remove the need to inspect the status-sync or operation result.

​
Per-line, partial, and unit-tracked work

Treat every line as its own identity and evidence set. A sale can persist while a line is unmatched, queued for resolution, or in Attention. Do not fill a missing Variant link, inventory item, or location by choosing a similar row. When the sale is linked to an inventory unit, inspect the unit and cost history that proves the attribution. A Pre-owned or consigned unit can have a different condition, ownership, custody, or fulfillment path; those differences do not authorize a universal restock or a channel-independent status claim.

​
When it does not go to plan

Cancellation, return, refund, size swap, and reversal each have a channel and physical-outcome boundary. A cancelled source status does not by itself prove that a unit returned, that a reservation was released, or that inventory was restored. Follow the named cancellation or return path and verify the physical result before choosing a restoration action.

​
Cancellation, return, and reversal handoff

  1. Keep the original sale, order, line, and source status together. A cancellation is not permission to create a new sale or apply an unscoped inventory change.
  2. For Shopify, use the line-level cancellation, refund, or return evidence, including the restock choice and destination when shown. The supported path releases a reservation and restores existing authoritative units only when its evidence calls for that outcome; it avoids creating a synthetic unit.
  3. For eBay, the reviewed cancellation refresh changes sale status without performing inventory or cost restock. Refund or restock is a separate manual or evidenced operation.
  4. For marketplace cancellations that are represented in Cancelled Sales, use that supported marketplace surface to choose the physical outcome only after checking whether the unit stayed in stock, moved to a buyer or provider, was returned, or remains at consignment. The surface excludes Shopify and retail. For Shopify, stay with the line-level cancellation, refund, or return path and its Returns & Exchanges evidence when applicable. For retail, use Retail Sales and Returns & Exchanges rather than Cancelled Sales. Do Nothing, Restock Inventory, Restock & Relist, and Leave at GOAT Consignment are different marketplace outcomes, not interchangeable labels.
  5. If the return destination, existing unit, cost evidence, or line identity is ambiguous, stop and escalate. Do not promise automatic inventory restoration.

​
Safe retry and escalation

Use this order of operations:
  1. Search the current AIM record by business, channel account or store, order, and line. Check whether a sale, reservation, inventory operation, or failure record already exists.
  2. If an inbound operation is queued, processing, or retry scheduled, refresh its current state and do not submit a second order event. For marketplace order ingestion, use only the channel-specific boundary: GOAT/StockX cursor handling and eBay per-order isolation are separate from a later post-sale adjustment or listing-management failure. Do not apply the ingestion retry rule to that later stage.
  3. If the operation is failed or in Attention, read the failure reason and choose only the recovery action that the channel supports. Some failed-sale retry surfaces intentionally reject unsupported marketplaces.
  4. If the evidence remains unmatched, partially applied, ambiguous, oversold, or inconsistent with the provider, escalate with the exact source and AIM evidence. Include the provider order number, account/store, line ID, SKU, size, quantity, source status, AIM stage, operation state, and the inventory or reservation result.

​
Fictional example

Harbor Kicks receives a fictional Shopify order HB-2048 for two lines. The first line is paid and unfulfilled. The operator checks the store, order ID, line ID, SKU, size, Variant link, and Location link, then sees the Shopify operation as Queued. The operator waits for the existing work, rather than creating a second sale. After the operation is durable, the first line shows a sale and an Inventory Reservation: Available moved from 2 to 1 and Reserved moved from 0 to 1 for the selected location, with linked unit and cost evidence. The operator checks the reservation and sale, then leaves fulfillment for the Fulfillments queue. When the fictional line is picked or shipped through the supported flow, the reservation is consumed and Reserved falls once; Available is not reduced a second time. The second fictional line has no clear Variant link. AIM shows the line as unmatched/Attention. Harbor Kicks records the line ID and SKU, uses Match sale to inventory only after confirming the exact product and size, and escalates if the evidence cannot be established. It does not select a similar variant, call the order complete, or promise that cancellation would restore stock automatically.

​
Check it worked

  1. The sale exists for the correct business, account or store, order, and line; the channel-native source status and AIM operational stage are visible.
  2. Each line is either linked to the intended inventory evidence or is clearly Attention, unmatched, queued, or otherwise awaiting a supported action.
  3. When the named Shopify flow creates an Inventory Reservation, its quantity, state, Available, Reserved, and linked unit/cost evidence agree. No second Available subtraction was made when fulfillment consumed Reserved.
  4. Fulfillments shows the next custody step when fulfillment applies. A provider acceptance or completion page is not a substitute for the AIM evidence.
  5. Any cancellation, return, refund, size swap, or reversal has a recorded physical-outcome decision. Restoration is called complete only when the channel-specific evidence and the existing-unit or inventory history support it.

​
What was recorded

Keep the source order/account or store, line identity, source status, AIM stage, operation state, inventory attribution, reservation state when applicable, unit/cost evidence, fulfillment result, and any failure or cancellation decision with the sale history. This lets another operator distinguish provider evidence, AIM persistence, inventory movement, and the remaining handoff.
Last modified on August 9, 2026