Inventory Reconciliation Checker

Reconciles supplied opening inventory, enumerated movements, system closing, and physical count into deterministic MATCH, REVIEW, or ERROR evidence per bounded SKU-location-period scope. It is built for inventory-control teams, warehouse operations analysts, ERP and reconciliation engineers. The main result is structured, deterministic evidence that can be consumed from the default dataset or an Apify automation.

When to use this Actor

• Explain a cycle-count shortage or overage from enumerated movements.
• Compare movement-derived expected closing with system closing and physical count.
• Produce stable reconciliation evidence before a warehouse adjustment workflow.

How it works

• Validate each bounded SKU, location, UTC period, unit, quantity, and movement record.
• Apply exact decimal signed movement arithmetic without unit conversion or inference.
• Persist scope-level evidence and complete reports before charging each reconciled scope.

The Actor validates only the declared product contract. It does not infer facts outside the supplied data or claim outcomes that the source material cannot prove.

Quick start

1. Open the Actor's Input tab or create a Task from one of the public examples.
2. Paste or adapt this bounded example.
3. Click Start and inspect the default dataset plus the output links shown on the run page.

{
  "scopes": [
    {
      "id": "cycle-count-shortage",
      "sku": "SKU-100",
      "location": "WH-A01",
      "period": {
        "start": "2026-09-01T00:00:00.000Z",
        "end": "2026-09-02T00:00:00.000Z"
      },
      "opening": {
        "quantity": "100",
        "unit": "each"
      },
      "movements": [
        {
          "id": "RECEIPT-1",
          "type": "RECEIPT",
          "quantity": "10",
          "unit": "each",
          "occurredAt": "2026-09-01T08:00:00.000Z"
        },
        {
          "id": "SHIPMENT-1",
          "type": "SHIPMENT",
          "quantity": "7",
          "unit": "each",
          "occurredAt": "2026-09-01T15:00:00.000Z"
        }
      ],
      "systemClosing": {
        "quantity": "103",
        "unit": "each"
      },
      "physicalCount": {
        "quantity": "100",
        "unit": "each"
      }
    }
  ]
}

Expected result: one REVIEW reconciliation showing expected/system closing 103 and a physical shortage of 3.

Input

The quick-start example is intentionally small. These are the material controls; the Input tab remains authoritative for the complete current schema.

Field	Purpose and format	Default	Important bounds or interaction
scopes	Independent SKU, location, and half-open UTC-period scopes containing opening, movement, system-closing, and physical-count evidence in one explicit unit.	No implicit default	minimum items 1; maximum items 1000

Unknown top-level fields and invalid field combinations fail validation rather than being guessed.

Output

The default dataset contains typed records. The run's Output tab links the dataset and any key-value-store reports declared by the current output schema.

Field	Meaning
recordType	Identifies reconciliation or error evidence.
scopeId	Current dataset field.
scopeKey	Current dataset field.
sku	Current dataset field.
location	Current dataset field.
period	Current dataset field.
unit	Current dataset field.
status	MATCH for agreement, REVIEW for a truthful variance, or ERROR for invalid scope evidence.
movementDerivedExpectedClosing	Current dataset field.
systemReportedClosing	Current dataset field.
physicalCount	Current dataset field.
variances	Current dataset field.
movements	Current dataset field.
findingCount	Current dataset field.
findings	Current dataset field.
errorCode	Current dataset field.
errorMessage	Current dataset field.
evidenceFingerprint	Stable identity for the normalized scope and result.
engineVersion	Current dataset field.

Representative current-schema dataset item:

{
  "recordType": "reconciliation",
  "scopeId": "cycle-count-shortage",
  "scopeKey": "SKU-100|WH-A01|2026-09-01T00:00:00.000Z|2026-09-02T00:00:00.000Z",
  "sku": "SKU-100",
  "location": "WH-A01",
  "status": "REVIEW",
  "unit": "each",
  "movementDerivedExpectedClosing": "103",
  "systemReportedClosing": "103",
  "physicalCount": "100",
  "findingCount": 1,
  "evidenceFingerprint": "example-evidence-hash",
  "engineVersion": "1.0.0"
}

An empty scopes array is invalid under the current schema; the Actor does not invent a reconciliation scope.

Pricing and billing

This Actor uses PAY_PER_EVENT; platform usage is included in event prices. A charge is eligible only after the billable unit described below is durably completed. Validation failures and the non-billable failure classes in the product contract do not emit the custom completion event. Higher Store tiers use the complete tier matrix below; Platinum and Diamond match Gold under the current policy. The Apify Pricing tab is authoritative if a later approved pricing change takes effect.

Event	What triggers it	FREE	BRONZE	SILVER	GOLD	PLATINUM	DIAMOND
inventory-scope-reconciled	One readable SKU, location, and period scope reaches a durable MATCH or REVIEW result.	$0.00500000	$0.00460000	$0.00420000	$0.00375000	$0.00375000	$0.00375000
apify-actor-start	Platform-managed Actor start event.	$0.00005000	$0.00005000	$0.00005000	$0.00005000	$0.00005000	$0.00005000

The Actor does not have Task-specific prices: public Tasks use this same live Actor pricing. Third-party costs are not implied; see the data and security section for external services actually contacted.

Limits and bounds

• Only bounded inline scopes accepted by the current schema are supported.
• All quantities in one scope must use the declared unit; no unit conversion is attempted.
• Movements must be enumerated within the explicit UTC period; connectors and inferred transactions are unsupported.

These are product-facing limits, not targets. Use smaller inputs when you need faster feedback or simpler evidence.

Failure and edge-case behavior

• Invalid top-level input fails closed; an invalid individual scope produces non-billable ERROR evidence.
• A shortage or overage is a successful REVIEW result, not an Actor failure.
• Duplicate movement IDs, inconsistent units, malformed decimals, or out-of-period movements are not silently corrected.

Operationally:

• Use stable scope and movement identifiers for reproducible evidence.
• Review findings before any separate inventory adjustment; this Actor never mutates inventory.

Use with Tasks and automation

Public Tasks provide reusable saved inputs for distinct supported workflows. Start with the closest Example Task, review its visible fields and scope caveat, then save your own Task for schedules or repeated runs. Do not treat an Example Task as evidence that unsupported behavior exists.

• Reconcile a synthetic cycle count with a three-unit shortage: Reconstruct closing inventory from safe synthetic movements, compare the system balance and physical count, and inspect the derived three-unit shortage evidence.
• Find a synthetic system balance discrepancy: Reconstruct closing inventory from synthetic movements and identify a one-unit gap in the system balance even when the physical count matches that balance.
• Triage a synthetic multi-location inventory batch: Evaluate the same synthetic SKU at two locations, preserving an exact match while isolating a unit-mismatch error in its independent peer scope.

Integration and API usage

Every saved Task can be started manually, through the Apify API, or from an Apify schedule. Run-completion webhooks can notify a downstream system after output is durable. Actor-to-Actor calls should consume the typed dataset/output links instead of scraping the Store page.

• Run a Task after cycle-count export and route REVIEW findings to an exception queue.
• Use evidenceFingerprint and scopeKey for downstream idempotency.

No third-party integration is claimed unless it is named above and supported by the current product contract.

Data, privacy, and security

• Inventory inputs and evidence remain in Apify run storage under account retention settings.
• No external service is contacted and no warehouse or ERP credential is required.

Set Apify storage retention and access according to the sensitivity of your inputs and outputs. This documentation does not create legal, privacy, compliance, or security certification.

Support and known limitations

• The Actor performs no login, connector, OCR, valuation, forecasting, or external API call.
• It reconciles declared quantities and cannot prove that the supplied movements or counts are complete.

For support, use the Actor Issues page. Include the run ID, a minimal reproducible input with sensitive values removed, the failing record or error code, and what you expected. Do not post credentials, private source files, customer data, or full confidential payloads.