What Freight Needs Before You Request a Quote: The Order Data Checklist
Key Takeaways
Updated October 20, 2026
Freight software needs a released shipping requirement, reliable shipment identifiers, locations, timing, freight characteristics, and service needs before requesting usable carrier quotes. The ERP can supply some of these fields; warehouse or product records may supply the rest. Wilson, by Cartage, connects to the order flow and coordinates freight within company rules. Exact field mapping depends on the customer environment.
- An order number alone does not identify every release or split shipment.
- Weight and dimensions need units and a clear handling-unit definition.
- A requested shipping date does not establish that goods are ready.
- Missing data needs a named owner before the workflow asks carriers to price uncertain freight.
What data does AI freight software need from an ERP?
AI freight software needs the data that defines the specific movement and authorizes the next freight action. Use this checklist to map fields to their source. The table is an implementation framework, not a universal ERP schema.
| Data group | Fields to establish | Source or owner to identify | Freight decision supported |
|---|---|---|---|
| Identity | Order, release, shipment, and revision references | ERP or fulfillment owner | Distinguish a new load from an update |
| Locations | Pickup, delivery, facility, and contact details | Order or location master | Define the actual movement |
| Timing | Readiness, requested windows, and receiving restrictions | Warehouse and operations | Request feasible pickup and delivery |
| Freight | Product, handling units, pieces, weight, dimensions, and units | Product master and warehouse | Request suitable equipment and comparable rates |
| Service | Handling needs and mode-specific information | Logistics and order owner | Establish the service carriers must price |
| Authority | Release condition and applicable carrier or spending rules | Operations and authorized approver | Determine which action may proceed |
Some authority rules belong in the operating playbook rather than the ERP export. Identify the source instead of forcing every input into one system.
Separate the order, release, and physical shipment
The data model should distinguish the commercial order from the freight that will actually move. One order can produce several releases or shipments.
Record the relationship among those identifiers. A partial release should not accidentally become another instruction to move the entire order. A revised file should not automatically become a second booking. These are buyer controls to define and test, not assumed default behavior in every product.
Also specify the event that permits quoting or booking. Order creation, stock allocation, production completion, and shipping release can mean different things. The customer must explain which event carries which authority.
The ERP order-to-booked-load guide traces the operating handoff. Its success depends on usable order data and an agreed release condition, not merely a technical message arriving without an error.
Describe the freight as the carrier will receive it
Freight data should describe the packed shipment and required service. Product-level information may need warehouse confirmation before it represents the freight tendered to a carrier.
Specify pieces and handling units separately where relevant. Record weight and dimensions with their units. Identify whether measurements describe individual items, packed cartons, pallets, or the total shipment. A number can pass a technical validation while describing the wrong physical object.
For LTL, obtain applicable classification information and accurate shipment measurements. NMFTA identifies density, handling, stowability, and liability as classification factors. Do not assume density alone determines every freight class or that a historic product value always remains applicable.
FedEx Freight's shipping guidance identifies addresses, classification, weight, readiness, and handling needs among the information used for LTL shipping. Carrier requirements and the applicable service still determine the actual fields your workflow must provide.
Give missing and uncertain fields an operational owner
A missing field should create an explicit information task with a responsible person. Guessing can move the question downstream into a rejected pickup or an invoice investigation.
Assign product facts to the relevant product or warehouse owner. Assign readiness to the facility that releases the freight. Assign receiving restrictions to the team that can confirm them. IT can transport a value without owning its business accuracy.
In an illustrative manufacturer, the ERP holds an item weight but the warehouse must confirm the packed pallet dimensions. The quoting workflow should know which information is provisional and which person can supply the final requirement.
Wilson creates and coordinates freight from the agreed order flow within customer rules. Define the required validation and missing-data handoff for the selected deployment. Do not infer automatic measurement, universal master-data correction, or every classification rule from a general integration claim.
Define how changed data reaches an active load
The connection needs a procedure for revisions after the first release. A complete original record does not establish that a later correction reached the freight workflow.
Identify the changed field, source revision, affected shipment, and action required. A corrected destination before quoting differs from a destination change after carrier acceptance. The second case can require carrier confirmation and another commercial decision.
Define which shipment results return to the ERP and how the receiving system identifies them. Booking acceptance, pickup, delivery, and document availability represent different facts. Do not merge them into one ambiguous shipped label.
The shipment updates back to the ERP guide helps select the return fields. The method and permissions depend on the environment; a read connection does not automatically include write-back or every later order change.
Test the field map before expanding the connection
The field-map test should show that the proposed inputs support usable freight work and predictable handling of uncertainty. Use representative records from the operation.
Start with one complete order, then remove a required measurement. Send a repeated release and a genuine second partial shipment. Finally, change a required date after booking. Ask the supplier to explain the resulting shipment identity, open question, permitted action, and escalation owner.
These are evaluation requirements, not claims that Wilson includes every validation control automatically. The test should reveal configuration work and responsibilities that remain with the customer.
Wilson replaces the TMS for freight execution and connects to the ERP order flow. It requests approved-carrier quotes, follows up, and handles the agreed execution work within targets and approval boundaries. A useful connection delivers enough correct information for those actions and preserves the questions that still require a person.
FAQs
What information do we need before requesting a freight quote?
Provide shipment identity, locations, readiness, timing, freight details, units, and required services. Add the applicable mode-specific information and identify who supplies missing facts.
Does every required field have to come from the ERP?
No. Warehouse, product, location, or operating records may supply part of the requirement. Map each field to a reliable source and owner.
Can software use an item weight as the shipment weight?
Only when it accurately represents the freight being priced. Define packaging, handling units, quantities, and measurement units before using the value.
Does a successful import mean the load is ready to book?
No. The shipping requirement must be complete and authorized. Carrier acceptance and any required approvals remain separate operating results.