Can AI Logistics Automation Work With a Legacy ERP?

Key Takeaways

A legacy ERP with no modern API can still feed freight execution. Most old systems can already export what freight needs through a scheduled report, an emailed file or a spreadsheet.
Wilson, by Cartage, can start from a scheduled file drop, email or spreadsheet the old system already produces, and add an API connection later only if one exists and adds value.
The hard part is rarely the file format. It is the quirks inside the export: codes instead of addresses, weights stored on the item master, orders re-exported after a change.
Test the export with real files before anything else: a clean order, a changed order, a duplicate, a missing weight and a late file.
Write-back to the old ERP is optional. It can be an updated file the ERP imports, a shared table, or an API connection where available.

Can AI logistics automation work with a legacy ERP that has no modern API?

Yes. If the old ERP can produce a report on a schedule, it can usually start freight execution. The connection can be file-based first, with no new development inside the ERP.

Many manufacturers run ERPs that are heavily customized and understood by one or two people. Asking that system for a modern API often means an upgrade or a long IT project, while coordinators keep retyping orders into carrier emails and portals.

The faster route is to use what the system already does well: produce reports. Almost every legacy ERP can run a saved report of orders released to ship and write it to a folder, attach it to an email, or export it to a spreadsheet. That output is enough for an AI logistics agent to create shipments, request quotes and book freight, if the right fields are in it and it arrives on a predictable schedule.

For the broader question of which connection to build first, see Legacy ERP, modern freight: what has to connect first?.

Five steps from an old ERP export to an executed load

Start from the export the system already produces, then tighten it until every order in it can become a shipment without a person rebuilding it.

Find the existing output. Ask who runs the ERP which reports already list orders ready to ship. A pick list or daily open-orders report is often close.
Pick the delivery path. A scheduled file drop to a shared folder, a report emailed to a dedicated inbox, or a spreadsheet the shipping team already keeps. Choose one that runs without anyone clicking export.
Set the trigger and timing. Decide which status makes an order eligible (released, picked, staged) and how often the file runs.
Map the fields once. Agree which column means what, which values are codes, and which fields must be present before quoting.
Run a few lanes first. Send real exports for a small set of lanes and compare the shipments created against what coordinators would have built.

What fields does the export need, and where do old systems hide them?

The fields freight needs usually exist in a legacy ERP, but rarely in one table or one report.

The core set: an order reference, ship-from location, ship-to name and full address, requested pickup and delivery dates, pieces or pallet count, weight, dimensions where the mode needs them, freight class for LTL, accessorials such as liftgate or appointment, and a contact for the receiving dock. A fuller list is in what freight needs before you request a quote.

In older systems those fields tend to live in specific places:

Ship-to addresses often appear on the order only as a code; the report must join it to the customer master.
Weight is often stored per item, not per order. The report must roll it up, or shipping adds a packed weight after staging.
Freight class and dimensions may not be stored at all; a product lookup table maintained by logistics can supply them.
Dock hours and special instructions often sit in a free-text notes field. Keep that field in the export.
Dates may use two-digit years or local formats. Agree on one.

When is a file-based connection enough, and when should you push for more?

A file-based connection is enough when orders are released in batches, the file runs reliably, and changes after release are rare or easy to flag. It needs more when orders change often after they leave the ERP.

Use these rules to decide:

Keep the file-based connection if the export runs on schedule, orders have stable references, and the gap between runs is acceptable.
Add a change flag before anything else if orders are edited after export. A simple "revised" column or a change timestamp lets the workflow tell an update from a new order and avoid booking the same load twice.
Fix it at the source when a field such as weight is missing on most orders.
Route to a person when an order arrives without a required field. The workflow should ask for the missing value, not guess it.
Consider an API connection later only if a usable interface exists and a need justifies it, such as intraday changes.

A legacy export test you can run with real files

Before trusting the connection, send these files built from real orders.

Test file	What it checks in a legacy export	Pass condition
One clean order released normally	Field mapping, code lookups and date format	Shipment is created with the full ship-to address and correct dates, with no retyping
The same order exported again unchanged	Duplicate rows from repeated report runs	No second shipment is created
The same order with a new quantity	Changes made after the first export	The existing shipment is updated or flagged, not duplicated
An order with no weight	Item-level data the report did not roll up	The order is held and the right person is asked for the weight
An order with dock notes in free text	Instructions buried in a notes field	Appointment or liftgate needs appear on the shipment
A file that arrives late or empty	Scheduled job failures on the ERP side	The team is told the file is missing instead of assuming there were no orders

The last row matters most: an old system that stops exporting quietly is a common way a file-based connection breaks.

How does Wilson, by Cartage, work from a legacy ERP export?

Wilson starts from the data the old system can already send and runs the freight work from there. Orders can reach Wilson through a scheduled file drop, email, spreadsheet, ERP feed or API connection, depending on what the environment supports. Wilson works with SAP, NetSuite, Microsoft Dynamics 365, Oracle, Infor, Epicor, Sage, Acumatica, and other ERP environments, with the exact connection depending on the customer’s data flow and scope.

Wilson then creates the shipment, requests quotes from the company's approved carriers, negotiates against the company's rate targets within approval limits, books the selected carrier, confirms pickup, tracks the load using the best source available for that carrier, handles configured exceptions, collects the POD, and audits and reconciles the carrier invoice. Wilson replaces the TMS for freight execution.

Write-back is optional and scoped. For a legacy ERP, that often means an updated file the ERP can import on its own schedule, a shared table, or an API connection where one is available. Messages, confirmations and changes are recorded in each shipment's change history.

Wilson starts with assisted execution. The company sets which actions need approval and can expand the scope step by step as the workflow proves reliable. See what an AI logistics agent actually does.

If your ERP can run a report but not much else, bring last week's export and one order that changed after it was released, and we'll walk through how each would become a shipment.