3PL Inbound Pre-Alert and ASN Checklist: Make the Warehouse Ready Before Arrival

Send one controlled pre-alert before cargo reaches the warehouse

For an Australian importer, a useful 3PL inbound pre-alert tells the warehouse exactly what is expected, how the delivery will be identified, which product and packaging records govern the planned receipt, and who owns a pre-arrival information mismatch. Send it through the provider's current channel and within any provider-agreed timing, then retain evidence that the identified version was operationally accepted or returned for correction.

At minimum, connect one inbound reference to:

• the importer and receiving account;
• the purchase order and supplier packing record;
• the carrier, transport reference and expected delivery window;
• each SKU, expected quantity and agreed counting unit;
• carton, pallet or other logistics-unit identifiers where used;
• the document version and submission time;
• the warehouse's acceptance, requested changes or appointment response; and
• the exception owner and next action if the physical receipt differs.

A forwarded packing list is not automatically a controlled pre-alert. It may describe what the supplier says was packed without giving the 3PL its own inbound reference, appointment information, item mapping, counting basis, receiving instructions or exception route.

Treat the ASN as a receiving input, not proof that every gate is clear

Pre-alert, advance shipping notice and ASN are used differently across providers and systems. Some 3PLs provide a portal record. Others accept an EDI or API message, spreadsheet, PDF or email template. Use the exact method and mandatory fields in the receiving guide agreed with your warehouse.

The underlying job is stable: tell the receiver what is coming before it arrives. The GS1 Logistics Interoperability Model distinguishes an inbound despatch notification from the later receipt notification. Microsoft's current inbound ASN documentation describes items, quantities and packaging that a warehouse can prepare to receive. These are useful models, not proof that every 3PL uses the same fields or technology.

An operationally accepted ASN does not prove that:

• the cargo has arrived;
• carrier, customs or biosecurity release is complete;
• the physical count matches the expected count;
• product condition or quality has passed inspection;
• the stock has been put away; or
• the units are available for orders.

Keep those states separate. Your carrier arrival-notice reconciliation controls the carrier's arrival information. The warehouse pre-alert prepares the receiver. The physical receipt and inspection provide later evidence.

Anchor the pre-alert to one shipment identity

Start with one importer-owned inbound reference that remains stable from preparation through receipt closure. Do not replace the purchase order, booking, bill of lading, air waybill, container, parcel or 3PL reference with this new number. Link them.

The header should identify:

• importer or inventory owner;
• 3PL account and receiving site;
• inbound reference and current version;
• supplier and ship-from location;
• purchase-order number and revision;
• packing-list number and revision;
• transport provider and mode;
• carrier tracking, waybill, bill-of-lading or container reference as applicable;
• expected delivery date or agreed window, including the receiving site's time zone; and
• named importer and 3PL contacts.

Stable identity matters when the warehouse uses different product codes. Microsoft documents source-system item mapping in its ASN process and reports an error when a referenced external item has no mapping. Do not copy that system design blindly. Apply the operational lesson: show the supplier SKU, importer SKU and accepted 3PL item code where they differ, and resolve the mapping before delivery.

If the transport document is an ocean bill of lading or sea waybill, use the cargo-release document guide for its separate role. The pre-alert should link the current reference, not reinterpret the transport document.

Give the warehouse the fields it can actually receive against

The required fields depend on the provider, product and receiving method. The following minimum record is OPL analysis; adapt it to the 3PL's accepted template.

SAP Ariba's ASN instructions identify packing-slip ID, tracking number and ship-from address as minimum fields in that product. Your 3PL may require a different set. Record its requirements directly rather than presenting any software example as an industry-wide rule.

Reconcile the expected contents before submission

Do not make the warehouse discover a source conflict at the dock. Reconcile the intended purchase, supplier packing data and transport identity before the pre-alert is sent.

Match purchase and packing data

For each expected line, compare the current purchase-order revision with the supplier's final packing list. Check SKU, description, quantity, unit of measure, case pack and controlled product or packaging revision. Use the commercial-invoice and packing-list reconciliation guide where those import documents need to be compared; EVG-171 only carries the reconciled receiving facts forward.

If the supplier reports a quantity or revision that differs from the controlled order, do not silently edit the pre-alert until it agrees. Record the difference in the open purchase-order exception board, obtain the appropriate decision and show the approved receiving basis.

Describe the logistics-unit hierarchy

A single quantity can become ambiguous when the supplier, importer and warehouse count at different levels. Write the hierarchy and units explicitly. For example:

• 12 sellable units per inner carton;
• 4 inner cartons per master carton;
• 20 master cartons on pallet P01; and
• 960 sellable units expected on that pallet.

Where the operation uses SSCCs or GS1 logistics labels, link each expected identifier to the packaging hierarchy. The SSCC and logistics-label guide covers identifier setup. The pre-alert's role is to tell the receiver which identifiers and quantities to expect.

The GS1 Logistic Label Guideline describes a standards-based model in which a despatch advice or ASN identifies each logistics unit by SSCC and its contained trade items. Use that only where the parties have adopted the relevant GS1 process; it is not a universal 3PL requirement.

Do not invent detail that the supplier has not verified. Mark an unknown field as unresolved, assign an owner and decide whether the warehouse can accept the inbound without it.

Make the delivery plan explicit

The 3PL needs enough transport information to connect the physical arrival with the accepted inbound. Record the carrier or transport provider, reference, planned date or window, delivery site, contact and appointment state.

Do not treat an ocean ETA as a warehouse appointment. The container tracking milestones guide separates planned and actual carrier events. A warehouse booking must use the receiving site's own availability and acknowledgement.

If the date changes, update the pre-alert through version control and retain the warehouse response. If the delivery arrives outside the accepted window, follow the provider's current instruction rather than assuming it will be received, refused or charged.

This article does not advise on vehicle access, unloading method, dangerous goods, regulated storage, biosecurity or workplace safety. Those matters require the site, provider and qualified controls relevant to the cargo.

Define states and change control

State labels should reveal what must happen next. The following model is OPL analysis.

Do not overwrite an accepted version after the supplier changes quantities, labels, cartonisation, ETA or transport references. Create a revision, identify what changed and obtain the 3PL's acceptance of the replacement. Preserve the old version so the receiving team can explain which information was available at each point.

Route exceptions before the truck arrives

Agree how pre-arrival information problems will be corrected before the delivery. Keep the instruction operational and product-appropriate. A minimum exception handoff can record:

• inbound reference and affected SKU or logistics unit;
• expected value and conflicting or missing source value;
• exception class, such as unknown inbound, unresolved item mapping, quantity conflict, unaccepted label reference, missing appointment information or outdated document version;
• source extracts, documents or master-data evidence required under the agreed procedure;
• 3PL contact and importer decision owner;
• response due time agreed for that operation; and
• evidence needed to close the discrepancy.

Do not use a generic article to tell a warehouse how to handle regulated, dangerous or safety-sensitive goods. Those cases must follow the site's approved procedures and qualified review.

For ordinary products, the key is still separation of facts from disposition. This pre-arrival record resolves the receiving input; it does not determine what the warehouse later observes or how stock is handled.

Worked example: one container, two pre-arrival exceptions

This hypothetical example does not represent an OPL client, supplier or result.

Importer AU-NORTH submits inbound INB-260914-03, version 2, for a container due at its 3PL. The accepted record links PO 4581 R03, packing list PL-4581-2, container reference and appointment APT-771. It expects two palletised SKUs.

The pre-alert does not decide whether the supplier owes a replacement, whether the carrier is responsible or whether stock can be sold. It makes the expected basis and owner visible before arrival. The incoming quality inspection guide controls the later physical inspection and release decision.

Freeze the accepted version and hand it to receiving

Once the usable version and any required appointment are operationally accepted, preserve that version as the warehouse's planned receiving input. The handoff should show:

• the inbound reference and accepted version;
• expected SKU mapping and quantities;
• expected logistics-unit identifiers where used;
• agreed counting level and provider-specific instructions;
• delivery window or appointment reference where required; and
• unresolved pre-arrival exceptions and named owners.

Do not keep rewriting that version to mirror later physical events. The receiving team should link its receipt record and any discrepancy record back to the accepted pre-alert. Physical count differences, condition evidence, stock status and discrepancy closure belong to the receiving control, not this pre-arrival checklist.

Launch with the next inbound shipment

Use one real inbound to test the method:

1. obtain the 3PL's current receiving guide and accepted submission channel;
2. assign one stable inbound reference and document version;
3. reconcile purchase, packing, SKU, quantity and packaging hierarchy;
4. add the transport reference and receiving plan without treating an ETA as an appointment;
5. submit the record and retain the 3PL's response;
6. correct rejected fields through a new version rather than overwriting history;
7. freeze the operationally accepted version as the planned receiving input; and
8. require later receipt and discrepancy records to link back to that version without overwriting it.

The goal is not a longer form. It is a receiving handoff another person can execute: one expected shipment, one current version, one agreed counting basis and one clear route when reality differs.

Sources

• GS1 Logistics Interoperability Model Application Standard 1.1.1
• GS1 Logistic Label Guideline 1.3
• Microsoft Learn: Import inbound ASNs as despatch advice messages
• SAP Help: How to create an advanced ship notice