Inbound Orders: The Manifest That Doesn’t Lie

Every truck that pulls into the dock has a story. The contract says one thing. The driver says another. The pallet labels say a third. The inbound order is where those stories converge — and where, if it’s done right, they get reconciled before the assets become inventory.

Five inbound types

An inbound order has a type that tells the platform how to treat it: standard (one-off purchase or trade-in), lease_return (end-of-lease asset return with chargeback rules), buyback (you sold it, the customer is sending it back), recycling (downstream-only, no resale), or donation (NGO / education flow with different paperwork). The type controls which workflow stages run, which fields are required, and which documents the system generates at completion.

Manifests

Every inbound order can carry an expected manifest — the line items the client said are coming. The manifest is not the truth, it is the claim. The receiving session is where the manifest gets reconciled against reality: what arrived, what didn’t, what arrived but wasn’t on the manifest. Discrepancies are flagged on the inbound detail page, with a column showing expected vs. received per category.

Photo report

For lease returns and high-value lots, the inbound photo-report (/core/inbound/[slug]/photo-report) is the artefact that prevents the "this Dell had a cracked hinge when it arrived, no it didn’t" argument three weeks later. Photos are taken at intake, anchored to the inbound order, and survive in the evidence bundle. The chargeback math, when it happens, is grounded in the photos.

Why an order is not a session

An inbound order is the contractual claim. A receiving session is the physical reception. They’re separate entities for a reason — see the receiving-sessions article. The order can stay open across multiple receiving sessions if a single shipment arrives in two trucks, and a single session can close when the order is fully reconciled or partially completed against an SLA.