The ERP is custom. Does freight automation still work?
Key Takeaways
- Wilson, by Cartage, is an AI logistics agent that works with custom ERPs through the data flow they already have.
- A custom ERP does not block freight automation. An undocumented hand-off does.
- Write a one-page order contract: the trigger, the fields, the units, and the order identity.
- A custom system changes over time. Name who updates the hand-off when it does.
- Test repeated events, draft records, new field values, and a connection outage.
- No integration project is required to start.
- Sending updates back to the custom ERP depends on scope.
Does freight automation still work when the ERP is custom?
Yes, freight automation works with a custom ERP once the order hand-off is written down. A custom system has no standard export to rely on. So the company defines its own. That definition is the whole job.
A custom ERP is a system built or heavily extended for one company's process. Some are homegrown databases. Others are packaged ERPs with years of custom fields and screens. Either way, the data model is unique. A field called "status" may mean something different here than anywhere else.
That uniqueness is the real risk. Picture a manufacturer whose system marks an order "complete" when production ends. Shipping, however, waits for a quality sign-off stored in a separate table. An automation that reads "complete" as "ready to ship" would book trucks for freight that cannot leave. Nothing in the code is broken. The meaning was never agreed.
So the question is not whether the ERP is custom. The question is whether anyone has written down what its order data means. When that exists, an AI agent can take the released order and run the carrier work. For a closer look at starting from one order file, see Custom ERP: start with one order file.
The one-page order contract a custom ERP needs
A one-page order contract tells the freight workflow exactly what the custom ERP sends. It fits on a single page. Developers and operations both sign off on it.
| Item | What to write down | Example |
|---|---|---|
| Trigger | The event that means "ready to ship" | Quality sign-off recorded and ship date set |
| Order identity | The number that stays fixed for the life of the order | Sales order number, never the internal row ID |
| Version | How a changed order is marked | A revision counter that rises with each edit |
| Required fields | What every order must include | Ship-from, ship-to, ready date, pallets, weight |
| Units | The unit for every measure | Weight in pounds, dimensions in inches |
| Allowed values | The valid entries for coded fields | Service codes: standard, liftgate, appointment |
| Delivery method | How the data leaves the ERP | A file every two hours, or an email per order |
Seven rows cover most custom systems. The "Version" row is the one teams skip most often. Without it, a changed order and a new order look the same. That is how one load becomes two bookings.
Keep the contract short on purpose. A long technical document gets filed and forgotten. A one-page contract gets read when something breaks.
Who maintains the hand-off when the custom ERP changes
A custom ERP changes every year, so the order hand-off needs a named maintainer. New fields get added. Codes get renamed. A developer leaves. Each change can break the freight feed without warning.
Three roles keep the hand-off healthy.
- The technical owner updates the export when the ERP changes. This is often an internal developer or an outside firm.
- The operations owner decides what "ready to ship" means and approves changes to that rule.
- The logistics lead reports when orders arrive wrong. This person sees the problem first, at the carrier.
The rule between them is simple. No change to the ERP's order fields goes live until the technical owner checks the contract. A two-line note is enough: "Added field X. Contract unchanged." Or: "Renamed code Y. Contract updated."
This sounds like overhead. It is less work than fixing a week of misbooked loads. It also keeps freight knowledge from living in one developer's head. For where custom systems often lose the hand-off, see Custom ERP: the missing freight hand-off.
Five custom-ERP situations and the rule for each
Five situations account for most custom-ERP freight errors, and each has a clear rule. Agree on the rules before the first load moves.
The same order is sent twice. Treat it as one order. Match on the order number and version. Do not create a second shipment.
A draft order is sent by mistake. Hold it. Only orders that meet the trigger should reach a carrier.
A coded field has a new value. Stop that order and send it to the logistics lead. Do not guess what "LG2" means.
The order changes after the carrier accepts. Flag it as an exception. If the new terms fall outside the rules, a person approves them.
The connection goes down. Carrier work already underway continues. New orders wait. The technical owner is told right away.
Rule 5 matters more than it looks. A custom connection may fail on a Friday afternoon. Loads already booked should still get picked up and tracked. The outage should affect only the next orders, and someone should own fixing it.
A four-event test for a custom ERP
Four events, sent in sequence, show whether the custom hand-off is ready. Use real orders from the past month.
Send a clean, released order. It should become one shipment. Carriers should receive the right weight and units. The booking should carry the order number.
Send the same order again. Nothing new should happen. The existing shipment stays as it is.
Send a revised version with a higher weight. The existing shipment should update. If the carrier already accepted, the change should reach a person.
Send an order with an unknown service code. It should stop and reach the logistics lead with a clear reason.
After the four events, ask a colleague who was not in the room to read the records. They should be able to answer three questions. How many shipments exist? What changed on the revised order? Who approved it? If they can, the hand-off is ready for real volume.
Wilson, by Cartage, and a custom ERP
Wilson, by Cartage, works from the order data a custom ERP already produces and runs the freight work from there. Wilson is an AI logistics agent. It runs the full shipment cycle: quote, book, schedule, track, deliver, audit, and pay.
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. For a custom system, that data flow can be an ERP feed, a scheduled file drop, a spreadsheet, email, or an API. No integration project is required to start. Writing updates back to the custom ERP depends on scope.
Cartage helps define the order hand-off during discovery. That includes the trigger, the fields, and the workflow with the highest impact.
Once orders flow, Wilson requests quotes from approved carriers and negotiates against the company's rate targets within approval limits. It books only carriers the company has approved. It tracks each load using the best source available. It audits each invoice against what was booked and pays carriers from the Wilson Wallet.
Wilson starts with assisted execution. Routine actions can run automatically within the rules as reliability is proven. Each shipment keeps a searchable, exportable history with its change history. For how the order and the shipment records divide, see The ERP owns the order. Which system owns the shipment?
To see Wilson run freight from your custom ERP's order data, talk to the Cartage team.
FAQs, conclusion, and sources
FAQs
The ERP is custom. Does freight automation still work?
Yes. Wilson, by Cartage, works from the data flow a custom ERP already has, such as a file, a spreadsheet, email, or an API. The company needs to define what "ready to ship" means and which fields each order includes.
Does a custom ERP need an API for freight automation?
No. A scheduled file, a spreadsheet, or email can carry the orders. An API is one option, not a requirement.
What is an order contract?
It is a one-page agreement on what the ERP sends. It names the trigger, order identity, version, required fields, units, and allowed values. Developers and operations both approve it.
Who should maintain the connection when the ERP changes?
A named technical owner. That person checks the order contract before any change to order fields goes live. Operations approves changes to the "ready to ship" rule.
Can Wilson write updates back to a custom ERP?
It depends on scope. Write-back is defined per customer. Wilson keeps every shipment's history in its own records either way.
Conclusion
A custom ERP is not a barrier to freight automation. An unwritten hand-off is. Define the order contract on one page. Name who maintains it. Test duplicates, drafts, revisions, and unknown codes before real volume. Wilson, by Cartage, then runs the carrier work from the order data the custom system already sends.
Sources
- Cartage, Wilson product FAQ and product scope, October 2026: https://cartage.ai