Order Shipment Reconciliation

What does Order Shipment Reconciliation do?

Reconcile order-line quantities against supplied shipment records, including split dispatches from multiple warehouses. Upload CSV text or JSON arrays and receive an evidence report showing remaining units, over-shipments, cancellation overlap, duplicate shipment lines, orphan references and ambiguous matches.

This is a read-only report for an operations handoff. It uses your supplied data and does not connect to stores, carriers or warehouse accounts, change fulfillment status, or send customer messages. Use it through Apify, its API, or a saved task when you have a new comparable snapshot.

Why use a shipment reconciliation report?

A line ordered for ten units may be dispatched as four units from warehouse A and six from warehouse B. Both records should count once. A repeated export row must not create another shipment. The report retains source references so a reviewer can trace a quantity back to the original data records and resolve exceptions with the warehouse team.

The included sample has seven order lines and nine shipment rows. It counts five shipment rows totaling nineteen units, isolates four rows, and reports ten remaining units, one over-shipped unit and one unit of inferred cancellation overlap. Remaining totals can include incomplete lines; review their accountingComplete field before acting.

How to use it

1. Export complete comparable order lines and shipment lines. Supply cumulative shipments for each order snapshot, including prior split dispatches where applicable. A daily-only shipment file compared with lifetime orders would overstate remaining quantities.
2. Remove names, addresses, payment details and other unnecessary columns. Preserve identifiers as text, including leading zeros.
3. Enter exactly one of orders or ordersCsv, and exactly one of shipments or shipmentsCsv. An empty JSON shipment array is valid.
4. Map differing column names with orderMapping and shipmentMapping, then run the Actor.
5. Review isolated shipment rows first. Download the JSON, flat CSV or standalone HTML report from the Output tab.

Input and matching rules

See the Input tab for all settings. examples/input.json is a worked two-warehouse sample and examples/csv-input.json demonstrates column mapping. A mapping reads from the named source column: {"orderId":"Order Number","orderedQty":"Quantity"}. Mapping applies to JSON keys as well as CSV headers. Unmapped canonical fields retain their default names. Additional scalar source columns are ignored and omitted from the report; they remain part of your stored Actor input.

Order fields are orderId, lineId, optional sku, explicit orderedQty, explicit cancelledQty, and optional dueAt. Shipment fields are shipmentId, shipmentLineId, orderId, lineId, optional sku, explicit shippedQty, optional shipmentNamespace, and optional informational warehouseId.

Identifiers must be strings, no more than 128 characters, without surrounding whitespace or control characters. They are case-sensitive and never trimmed, numerically converted or filled from another row. Missing identity fields appear as report findings. Quantities must be nonnegative safe integers, supplied as JSON numbers or plain digit strings; no decimals, grouping commas, signs or units. Cancellation cannot exceed ordered quantity. Use the same base unit on both sides: the Actor performs no carton-to-piece conversion.

Exact orderId + lineId is the default join. With allowSkuFallback:true, a shipment without a line ID may use exact orderId + sku, only when that pair identifies exactly one supplied order row. A supplied unknown line ID never falls back to SKU. Conflicting supplied SKUs, duplicate order identities and ambiguous fallback matches are isolated. No fuzzy matching or proportional allocation occurs.

Duplicate shipment identity is shipmentNamespace + shipmentId + shipmentLineId. Every occurrence of a repeated key is excluded, even identical copies. The default namespace is an empty shared namespace. Use explicit stable namespaces for genuinely independent 3PL systems that reuse shipment IDs; use the same namespace for repeat exports from one system. warehouseId is evidence only and does not establish an independent shipment identity. Do not change namespaces merely to make a duplicate pass.

UTF-8 comma-delimited CSV supports BOMs, quoted commas and quoted multiline fields. Duplicate or blank headers, irregular record lengths and malformed quoting fail the run. Blank lines are skipped. Source references count data records, beginning at one and excluding the header. Shopify exports can have blank continuation cells, according to Shopify's export documentation; prepare explicit stable keys before submitting them. Order status and generic fulfillment-status fields are never used to infer shipped quantities.

Quantity and date interpretation

For each valid order identity, expected quantity is orderedQty - cancelledQty. Counted shipments are summed, remaining is max(expected - shipped, 0), and over-shipped quantity is max(shipped - expected, 0). cancelledShippedQty is min(cancelledQty, overShippedQty): inferred quantity overlap, not evidence that shipping happened after cancellation. Cancellation chronology is unavailable.

Any isolated shipment carrying an order ID marks all reconciled lines on that order incomplete, conservatively. Other allocatable shipments still count. Duplicate or missing order identities have null remaining/over quantities and are excluded from those totals. An orphan with an unknown order ID cannot establish which existing order is affected.

Optional asOf is an explicit snapshot comparison time. dueAt requires it. Both require a valid ISO timestamp with seconds and Z or a numeric offset, for example 2026-09-28T18:00:00+03:00. A line is flagged overdue only if it has positive remaining quantity and its due time is strictly before asOf. Equality is not overdue. The Actor does not filter shipments by date or read the current clock: you must supply the snapshot appropriate to asOf. The flag describes unaccounted quantity at a supplied deadline, not carrier lateness or delivery failure.

Output

The default dataset contains one complete report, with summary and a rows array covering every order and shipment record. You can download the dataset in various formats such as JSON, HTML, CSV, or Excel. For a flat table, use the dedicated reconciliation.csv download; it contains one evidence row per source record.

Field	Meaning
rowId, sourceRef	Stable input-position reference such as orders:1
kind, status, severity	Order or shipment evidence and review priority
shippedQty	Counted total on order rows; submitted quantity on shipment rows, including isolated ones
remainingQty, overShippedQty	Difference from non-cancelled entitlement; null for unreconciled orders
cancelledShippedQty	Inferred overlap with cancelled units; chronology unknown
accountingComplete	Whether supplied evidence was fully allocatable for that row/order
issues, reason	Explicit finding codes and explanation
matchedOrderRef, shipmentRefs	Traceable links between counted records

Full JSON is saved as OUTPUT; downloads are reconciliation.csv and report.html. HTML has no scripts or external resources. CSV cells that could be interpreted as formulas receive a leading apostrophe. Import identifier columns as text in spreadsheet software to preserve zeros; full JSON retains original identifiers exactly.

Price and limits

The listed price is $0.25 per completed report, with platform usage included and one report-completed event. There is no separate startup or dataset-row charge. Each new run is billable again. Insufficient event budget, invalid input, arithmetic overflow or oversized exports stop before the report event is charged.

Limits are 10,000 combined order and shipment rows and 4 MB of encoded JSON input. JSON output must stay below 8 MB, and every download below 9 MB; unusually long identifiers or escaping can require a smaller batch. Do not split shipments for the same order across runs unless you also provide the necessary cumulative records for each comparison.

The complete dataset report is delivered before charging. Convenience file writes follow. If export writing is interrupted, the charged dataset report remains the primary deliverable. Resurrecting that same run verifies the saved result and repairs exports without a second event. A charged run whose dataset was deleted cannot recover automatically. No claim of atomic billing and storage across all platform failures is made.

Make, n8n and privacy

In Make's HTTP module or n8n's HTTP Request node, POST your input object to https://api.apify.com/v2/acts/ACTOR_ID/runs, using your own Apify authentication configuration. Poll the returned run ID until it succeeds, then read /v2/datasets/DATASET_ID/items or the output store records. Keep credentials in the automation platform's secret store. This recipe does not require a store token and does not send messages.

Only submit exports you are authorized to process. Input and results are held in your Apify run storage under your account's retention settings; the Actor does not delete them automatically. It does not log raw rows or need personal customer details. No tracking truth, delivery proof, returns, refunds, reservation changes, fractional units, cancellation history or operational write-back is supported. A balanced report means the supplied quantities balance, not that goods arrived. Report reproducible problems through the Issues tab, using synthetic examples without customer information.