Return Serial Provenance Evidence

Review a serialized returns intake batch against the original fulfillment units and prior receipt records you supply. The report shows which serials have supported original-shipment provenance, which appear only outside the declared source, and which remain unresolved because a serial, source record or fulfillment link is missing or ambiguous.

This is useful when a returns specialist already works with exports or disconnected warehouse records and needs a repeatable evidence report before a human completes the returns workflow. It does not connect to NetSuite, modify an ERP, authenticate a physical unit, or decide whether to issue a refund. It does not determine fraud, warranty coverage, recalls or restocking eligibility.

What you supply

Use opaque identifiers rather than names, email addresses or contact details. Each source row represents one physical serialized unit; aggregate quantities are unsupported.

• Original shipment rows contain rowId, fulfillmentId, orderId, customerId, itemId and serialNumber.
• Current receipt rows contain rowId, receiptId, rmaId, sourceOrderId, customerId, itemId and serialNumber. An optional sourceFulfillmentId restricts the original candidates to that exact fulfillment.
• Optional prior receipt rows use the same format as current receipts.
• shipmentCoverage and priorReceiptCoverage explicitly declare complete, partial or none for the submitted export scope. Complete prior coverage requires an explicit array or CSV, even when empty. These declarations are not independently checked against a live system.

All identifiers remain strings. Case, leading zeros and nonblank whitespace are significant. A null, empty or whitespace-only receipt serial produces an unknown result. No serial normalization, timestamp ordering or “latest fulfillment” selection occurs.

JSON arrays are the easiest starting point. Alternatively, provide strict CSV for each table and remove that table's array. CSV accepts a BOM and quoted cells, requires exactly the unique declared headers and rejects irregular row widths. A complete column mapping supports renamed headers. For receipt CSV include the optional sourceFulfillmentId header; a blank cell means it was not supplied. Blank serial cells are unknown. Unknown fields and quantity columns are rejected so an aggregate export cannot silently become unit evidence.

How the evidence works

A supported row requires one unambiguous submitted shipment with the exact serial, item, customer and declared source order, plus the explicit fulfillment when provided. If two fulfillment candidates match, the report preserves both and chooses neither. Duplicate shipment row IDs or duplicate/conflicting fulfillment units block a clean conclusion.

A known serial found only outside those source restrictions becomes outside-declared-source evidence with references to the submitted records. No match means only no match in this export. Neither outcome establishes that a unit was never sold or that a return is ineligible.

The same receipt/item/serial re-exported is duplicate-record evidence, rather than another physical return. Distinct receipt IDs are grouped for human review only when they claim the same serial against the same uniquely established original fulfillment cycle. A refurbished serial legitimately shipped again on a different order or fulfillment remains a separate cycle. Conflicting receipt source records remain unresolved. Missing or ambiguous related prior units prevent an absence-of-prior-record conclusion even with complete declared coverage. Partial or absent prior coverage always leaves unobserved history incomplete.

Results and downloads

Each completed run produces one dataset item containing the full report, a rows array for the current receipt units, findings, duplicate/conflicting record groups, repeated receipt groups, and all submitted rows. References include the original table, zero-based array index and row ID. Displayed reference lists are capped at 50 and clearly flagged when abbreviated; the complete supplied rows remain in JSON.

Download full JSON, current-unit CSV, findings CSV and standalone HTML. CSV cells are formula-neutralized and HTML escapes supplied content. Download the HTML attachment and open it locally. Results describe supplied evidence and need a human review; they are not a certification or live inventory report.

Limits and pricing

The input must fit within 4 MB and contain at most 2,000 combined shipment, current receipt and prior receipt unit rows. Full JSON must stay below 8 MB and each export below 9 MB. Highly repetitive evidence can exceed the report limit even within the input limits; split that batch. Output limits are checked before a report charge.

The configured price is $0.25 per completed report, with platform usage included and no startup or per-row fee. Invalid input or insufficient report budget produces no completed report event. A fresh run creates a new report and is billable again. Resuming the same run verifies saved input/result integrity and repairs missing exports without intentionally adding another dataset item or report charge. An interrupted export write can leave partial files; completion is confirmed only after the report dataset and event receipt. Apify stores inputs and results in your run's storage, so upload only exports you are authorized to process.