> ## Documentation Index > Fetch the complete documentation index at: https://docs.aimventory.com/llms.txt > Use this file to discover all available pages before exploring further. # Reports and audit trails > Choose the AIM surface that exposes the evidence you need before you investigate inventory, listings, sales, fulfillment, or Shopify state. **The question this answers:** which current AIM surface should you use when you need to investigate a number, a product or unit, a listing, an automation failure, a sale, a fulfillment stage, or Shopify publication state? Use the surface that owns the question, then preserve its filters, scope, coverage, source, and timestamp. A report is an observation. It does not itself repair data or authorize an inventory, listing, fulfillment, or sync write. A row can identify what to check next without proving that the provider accepted AIM's value or that a write is safe. Treat a partial scan, a missing result, a stale observation, a warning, or an identity mismatch as an escalation signal. ## Report decision table | Operational question | Surface | Scope and filters | Freshness or trigger | Evidence it exposes or records | What it does not prove | Escalation boundary | | ------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | What does AIM currently show for a product, variant, location, or stock level? | [Inventory](/inventory) | Search the product or variant and filter by location, sublocation, and inventory level. Check whether you are reading Available, Reserved, or a sellability view. | Read the current inventory view. The result is a current AIM projection at the time you viewed it. | Product, SKU, size, location, unit, and quantity context in AIM. | It does not prove a physical shelf count, provider publication, or every channel's accepted quantity. | Compare the same product, variant, location, and time in the audit trail or Inventory Counts; escalate identity or quantity mismatches before changing anything. | | What did a cycle or full location count record? | [Inventory Counts](https://aimventory.com/inventory/counts) | Filter by count name, location, status, and count type. For a finalized count, use discrepancy, variance, resolution, search, sort, zero-counted, or sublocation filters where available. | A count is tied to its count window and lifecycle state. Use a completed or applied count for a discrepancy report. | Expected, counted, and variance context, count scope, original variance, resolution state, and a count-scoped export. | It does not prove the current quantity after later events, and the observation does not apply a repair by itself. | Preserve the count and its filters; compare later changes in the audit trail and follow the approved correction workflow only after identity and scope are confirmed. | | Which AIM event changed this inventory item, and what were the before and after levels? | [Inventory Audit Trail](https://aimventory.com/analytics/inventory-audit-trail) | Select the product, variants, and locations. Review event timestamps and pagination; the current report has no displayed date-window control. | Run or refresh the timeline for the question you are investigating. Keep the selected scope, event timestamps, and pagination with the result. | AIM purchase-order receive events, sales, manual adjustments, transfers, reservations, before/change/after levels, source context, and unit or cost fields when present. | It is not a provider publication history. Shopify sync observations are intentionally separate from ordinary AIM unit movements. | Stop when the event identity, quantity basis, or running level is uncertain; compare source records and use the approved inventory investigation path. | | Which product or physical unit is involved? | Inventory product or unit evidence from [Inventory](/inventory) and the audit trail | Start with product, SKU, size, location, serial, or inventory-item context. Open the unit and audit evidence available to your role. | Current item and unit identity is read from AIM; event history has its own timestamps. | Product and unit identity, location, serial or cost context when available, and linked AIM events. | It does not prove that a marketplace listing or Shopify product is published or that a provider has the same identity. | Stop on a missing unit, duplicate identity, wrong location, or product/variant mismatch; include the identifiers and report times in the escalation. | | Which StockX or GOAT listings are orphaned, zero-stock, or ghost listings? | [Sync Health](https://aimventory.com/sync-health) | Choose the report type and selected marketplaces. Use the available match or confidence filters, then inspect inferred credential coverage in the result. The UI has no credential selector. | Run a manual check or inspect the stored/current result. A scan is queued and its result has a generated or observed time; it is not a real-time guarantee. | Finding rows, provider/listing identity, selected marketplace coverage, inferred credential coverage, scan status, stored report details, and any cleanup result recorded with that run. | It does not prove Shopify or eBay coverage, complete cross-channel health, or that an incomplete scan found no issues. A current finding is a replaceable projection, not the whole history. | If coverage is partial, credential coverage is not set up, no result exists, or prior findings were preserved, run the narrowest supported check and escalate with the coverage and timestamp. | | Did a listing or other automation fail in a way AIM recorded? | [Automation Failures](https://aimventory.com/ebay/automation-failures) | Filter by status, platform, automation type, search, and page. The default view focuses on open and retrying records; include resolved records when needed. | The ledger updates when AIM records an attempt or state transition. Read the status, seen times, retry count, and any retry or resolution details shown on the row; the UI does not promise a resolution timestamp on every row. | Failure category, reason, fix hint, platform/resource identity, attempt and retry context, occurrence count, last error, and the resolution details displayed for that row. | A missing row does not prove success or provider acceptance. The ledger only covers failures AIM recorded, not every provider-side event. | Inspect the identity and reason before retrying. A retry is an operation, not a report observation; escalate when the resource, credential, or provider result is unclear. | | What sale or order evidence entered AIM? | [Sales](https://aimventory.com/sales) | For the main sales list, filter by channel/platform, status, location, tracked state, search, and pagination. Use the separate StockX-vs-GOAT report for its date range. | Query the current list for the relevant sale or order and note the result time. The list is paginated and filter-scoped; its date range is not the StockX-vs-GOAT report's date range. | Sale identity, native channel status, product/variant and inventory links, quantity/price/payout context, order identifiers, and fulfillment history when present. | It is not a universal immutable event archive or proof that a provider has accepted an AIM status. Derived fulfillment history is not the same as a stored event ledger. | Compare the provider order, AIM sale, inventory identity, and audit events; escalate instead of rewriting a status when those identities disagree. | | What fulfillment stage is currently waiting for work? | [Fulfillments](https://aimventory.com/fulfillments) | Filter by location, fulfillment type, account, status, search, sale date, and the available queue fields. Export only after checking the active filters. | Refresh the current queue and keep its filters and result time. The queue is a current operational view, not a promise of provider delivery state. | Sale identity and the pick, pack, ship, tracking, custody, and review context available on the row. | It does not prove carrier acceptance, delivery, or a missing provider event. A queue row is not a complete fulfillment history for every sale. | Stop on a status, order, line, unit, or tracking mismatch; preserve the row and source evidence before any custody or sale correction. | | Which Shopify products were observed as hidden, draft, archived, or not published while AIM showed available stock? | [Shopify Status Report](https://aimventory.com/shopify-status-reports) | Use the latest report shown in the current UI and inspect its source, run time, store scope, checked products, publication state, available inventory, and product-level checked time. Historical stored reports are available only on a surface that exposes report history. | The report is stored provider observation evidence. A latest report is not automatically a live read; check its source and timestamp. | Report source and status, stores checked, products/units checked, hidden products/units, Shopify publication state, available inventory, and status-checked time. | It does not prove AIM inventory truth, all Shopify channels, other marketplace coverage, or that a publication or inventory write is authorized. | Compare the report with the applicable Shopify sync evidence and AIM product/unit state; use the supported Shopify write path only after its freshness and authority checks pass. | | Does a Shopify quantity or publication disagreement need a Shopify-specific comparison? | [Shopify Status Report](https://aimventory.com/shopify-status-reports) and the Shopify comparison screen | Use the product, variant, store, and comparison scope offered by that surface. Do not substitute Sync Health for Shopify evidence. | Follow the comparison or refresh result's source and time. A cached observation and a live provider read have different authority. | The comparison choice and Shopify/AIM values exposed by the supported flow. | It does not establish a universal cross-channel quantity or publication history. | Escalate when identity, authority, or live provider evidence is missing; do not infer a write from a cached report row. | ## Surface-specific report contract This page is a routing reference across multiple surfaces, not one calculated metric. It has no shared formula or unit. Each surface owns its row grain, quantity unit, included or excluded states, timestamp meaning, and time-zone display; capture those details from the selected surface instead of combining values as if the filters or clock were identical. ### Fictional worked comparison Use this fictional capture to compare evidence without treating the surfaces as one history: | Capture | Surface and scope | Fictional observation | What to compare, and what it does not prove | | ------- | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | Inventory — product **Northstar Runner**, variant **10**, location **Main Room** | At operator capture time `2026-08-09 10:05` (not a report timestamp), Available is `3`. Record the product, variant, location, quantity label, and capture time. | This is a current AIM observation for that row scope; it is not a provider read or a complete history. | | 2 | Inventory Audit Trail — the same product, variant, and location scope | The underlying fictional event time is `2026-08-09T14:02:00Z`; the captured row shows a reservation with Before `4`, Change `-1`, and After `3`. Record the event type, quantity basis, pagination, and displayed timestamp. | This is AIM event evidence that explains a captured change; it is not provider publication history, and it does not establish that another surface used the same filters or timestamp semantics. | | 3 | Shopify Status Report — the applicable provider-facing report for the same fictional product/variant investigation | The fictional stored observation is captured at report time `2026-08-09T14:04:00Z`; its row shows the source, publication state, Available `2`, and status-checked time. Record the report scope and those displayed fields. | This is a stored provider observation in its reported scope, not a live provider read or universal history. | | 4 | Comparison result | Compare the captured AIM value `3` with the captured provider observation `2`, while keeping the Inventory location, Audit Trail event scope, provider report scope, and each timestamp attached to the evidence. | The one-unit difference is an investigation lead, not proof of identical filters, provider acceptance, automatic repair, or mutation authority. Preserve the scoped evidence and escalate when identity, freshness, coverage, or permission is unclear. | This example does not claim a live provider read, universal history, identical filters, automatic repair, or mutation authority. ## How to read a result safely ### Observation and repair are different Opening a report exposes evidence but does not itself persist a snapshot. Preserve a copy by exporting where the surface offers it or by recording the filters, scope, source, coverage, timestamps, and page behavior. A stored run exists only where that surface implements report history. A delist, retry, cost-layer heal, inventory adjustment, or Shopify publication is a separate operation with its own permission and safety checks. A zero-stock or failure row can guide the next check; it does not authorize that operation. Sync Health makes this distinction especially important: a scan can be requested with optional cleanup, while individual delist and cleanup actions are separate write paths. Treat the report row and the action result as two records. ### Provider truth and AIM truth are different AIM's Inventory and Inventory Audit Trail answer questions about AIM's quantity, unit identity, and recorded events. Sync Health and Shopify Status Report answer questions about provider observations in their selected scope. Compare the same product, variant, location, listing or publication identity, and observation time before deciding that one side is wrong. The channel surfaces are intentionally separate. Sync Health's listing scan does not establish Shopify status, and the Shopify Status Report does not establish StockX, GOAT, or eBay health. A cleanup action that fans out to more than one listing is still not proof that each provider was scanned successfully. ### Current state and historical evidence are different Inventory is a current AIM projection. Inventory Counts preserve a count-window observation and its original variance. Inventory Audit Trail preserves AIM event context. Sync Health stores report runs and maintains replaceable current findings. Sales and Fulfillments expose current rows plus whatever persisted or derived history is available. Shopify status reports preserve stored provider observations with report and checked times. Do not use a current row to rewrite history, or use an old report as proof of the current state. Keep the report source, coverage, filters, and timestamp alongside any escalation. ### Manual scan and automatic cleanup are different A manual scan is a requested check. A stored result may also come from a monitor, and an enabled zero-stock cleanup can perform a delist operation. The cleanup setting, trigger, status, and result must remain visible in the evidence. A clean manual scan does not mean an automatic cleanup ran, and a cleanup result does not mean every channel was scanned. ## Scope, freshness, and exports Every surface has its own scope and timing. Some results are current reads; some are queued scans; some are stored provider observations; some are count-window or event-history records. There is no single real-time freshness promise for all reports. Use the timestamp and coverage shown by the selected surface rather than assuming that a page or export updates on a common schedule. Where a surface provides an export, check the active filters, the selected business or location, the report source, and whether the result is paginated. An export may omit active UI filters or cover only the fetched page, so verify the exported scope and page behavior. Exports are surface-specific copies, not universal archives. AIM does not document one retention period for every report, audit trail, count, failure, or Shopify evidence record; keep the export and report time when the evidence may be needed later. ## When to stop and escalate Stop the investigation and preserve the evidence when: * a scan is partial, failed, or has no current result; * a finding is older than the question, or its source and coverage are unclear; * the product, variant, unit, location, listing, order, or Shopify identity does not match; * an audit level is inferred, a warning is present, or the count and current quantity disagree without a clear intervening event; * the next button is a retry, delist, adjustment, heal, publication, or sync operation rather than a report view; * the required report or repair permission is missing. Include the surface, filters, scope, source, coverage, report or event time, and the relevant AIM/provider identifiers in the escalation. Reports guide the next safe check; they do not authorize a write. ## Related * [How the inventory numbers fit together](/concepts/inventory-numbers) — read Available, Reserved, and Ready to list before comparing a number. * [What syncs and who wins](/understand/what-syncs-and-who-wins) — keep AIM authority and provider observations separate by channel. * [Product, inventory, and listing](/understand/product-inventory-listing) — trace product and listing identity before investigating drift. * [Fulfillment lifecycle](/understand/fulfillment-lifecycle) — interpret custody stages before treating a queue row as history. * [Process a sale](/operations/process-a-sale) — preserve order, sale, line, and inventory evidence together. * [Pick, pack, and ship](/operations/pick-pack-and-ship) — follow the supported custody workflow after the evidence is reconciled.