What should IT check before connecting freight software to an ERP?
Key Takeaways
Before connecting freight software to an ERP, IT should check seven things: which data moves in each direction, the connection method, the access the software needs, what it may write back, what happens when the connection fails, what records it keeps and who owns the data. An AI logistics agent such as Wilson, by Cartage, can start from a data flow the ERP already produces, such as a scheduled order file, so the first lanes do not need a full integration project. A deeper connection can follow once the business sees the value.
- Start with the data the freight work actually needs: orders, ship-to addresses, item weights and dimensions, and dates.
- Choose the lightest connection that works: a scheduled file or email is often enough to start; an API comes later if needed.
- Give the software the least access it needs, and read access before write access.
- Decide which fields, if any, may be written back to the ERP, and who approves that.
- Ask what happens when a file is late, a record is malformed or the connection is down.
- Confirm that the company owns its data and can export it.
What should be on the IT checklist?
The IT checklist should cover the data, the connection, the access, the write-back, the failure cases, the records and the ownership. An AI logistics agent connects to the ERP to get shipment work, so the checklist is about that flow. The table can be used as a working list in the first conversation with any freight software vendor.
| Area | Question for the vendor | What a good answer looks like |
|---|---|---|
| Data in | Which ERP fields do you need, and why? | A short list tied to quoting, booking and invoicing |
| Data out | What will you send back to the ERP, if anything? | Named fields, optional, agreed in scope |
| Connection | Which methods do you support? | File, email, API or database view, with a way to start simple |
| Access | What credentials or permissions do you need? | Least access, read first, a named service account |
| Write-back | Who approves changes written to the ERP? | Rules agreed with the business, with a record of each write |
| Failures | What happens if a file is late or a field is wrong? | Alerts to a named owner, no silent guessing |
| Records | What do you keep, for how long, and can we export it? | Searchable, exportable records with change history |
| Ownership | Who owns the shipment, rate and carrier data? | The company does |
| Effort | What does IT need to build or maintain? | Little or nothing to start; clear tasks if deeper |
What does a good vendor answer look like?
A good vendor answer is specific. "We need the sales order number, ship-to, ship date, item weights and pallet count, sent as a CSV at 6 a.m. and 1 p.m." is specific. "We integrate with every ERP" is not. A good answer also says what the vendor does not need, and what happens when data is missing. IT should ask for the field list in writing and keep it with the project notes. If the vendor cannot list the fields, it probably has not done this with a similar ERP before.
Why should IT be involved early?
IT should be involved early because the connection method shapes the timeline and the risk. A logistics team may choose software and then learn that the ERP export it assumed does not exist, or that write-back needs a change request. When IT sees the data list and the method at the start, it can say which route is fastest and safest. Early involvement also prevents a common problem: a project that waits months for an integration, when a scheduled file could have started the work in the meantime.
Who else should be in the conversation?
The logistics lead, finance and the ERP owner should be in the conversation with IT. The logistics lead knows which data the freight work needs. Finance cares about invoices, freight accruals and payments. The ERP owner knows how orders, items and customers are set up and which fields are reliable. A thirty-minute review with all four usually answers most of the questions on the checklist.
Which data does freight software need from the ERP?
Freight software needs the data that describes each shipment: what is shipping, from where, to where, when and with which requirements. An AI logistics agent uses this data to request quotes, book carriers, track loads and audit invoices. IT should ask the vendor to explain each field it needs, and push back on anything that is not tied to the work.
| Data | Used for | Common source in the ERP |
|---|---|---|
| Order or sales order number | Linking the load to the order | Sales order header |
| Ship-from location | Pickup address, dock hours, contact | Warehouse or site master |
| Ship-to address and contact | Delivery, appointments, customer updates | Customer or ship-to master |
| Items, quantities, weights, dimensions | Quoting, freight class, equipment | Item master and order lines |
| Pallet or package count | LTL and parcel quoting | Order, pick or pack data |
| Requested ship and delivery dates | Scheduling and carrier choice | Order header |
| Special handling | Liftgate, temperature, hazmat, appointment | Order notes or ship-to attributes |
| Customer PO | Matching documents | Order header |
How should IT test the data before go-live?
IT should test the data by running the planned export on a recent day of real orders and reviewing it with the logistics team. Look at a dozen orders across different customers, items and modes. Check that every order has a ship-to, a date, a weight and a count, and that special requirements appear somewhere the software can read. Look for orders that ship from more than one location, orders with partial shipments and orders with unusual units. The review usually takes an hour and finds the gaps that would otherwise show up as wrong quotes in the first week.
What data is often missing?
Data that is often missing includes accurate weights and dimensions, pallet counts, freight class and delivery requirements such as appointments or liftgates. Many ERPs store item weights but not packed dimensions. Pallet counts may only exist after picking. Delivery requirements may be in a free-text note. IT should expect the first weeks to reveal these gaps. An AI logistics agent like Wilson asks for missing details before requesting quotes, so the gap is visible instead of causing wrong quotes, but fixing the source data in the ERP is still worth doing.
Which items need special attention?
Items that need special attention include products shipped in mixed pallets, items with variable weights, hazardous materials and anything with temperature requirements. Mixed pallets make the pallet count and density hard to know from the order alone. Variable-weight items, common in food and metals, may only have an estimated weight until the order is picked. Hazardous materials need class and handling details that some carriers require before they will quote. Temperature-controlled freight needs the range. IT and the logistics lead should list these items early so the export carries the fields the carriers will ask for.
Should the software see financial data?
Freight software usually does not need general ledger or customer credit data. It may need freight terms (prepaid, collect, third party) and, if it pays carriers, the information required for that payment flow. IT and finance should agree on exactly which financial fields are shared. Less is better.
What about customer data?
Customer data should be limited to what the freight work needs: ship-to addresses, receiving contacts and delivery requirements. If the software will send delivery updates to customers, it needs the contact for those updates. IT should confirm how this data is stored and that it is not shared with other companies.
Which connection method should IT choose?
IT should choose the lightest method that delivers the data reliably and on time. An AI logistics agent like Wilson works from the connection or data flow the company already has: an ERP feed, a scheduled file drop, a spreadsheet, email or an API. The exact connection depends on the company's data flow and scope. No integration project is required to start.
| Method | Effort for IT | Good for | Watch for |
|---|---|---|---|
| Scheduled file (CSV or report) | Low: schedule an existing report | Starting fast; daily or several-times-a-day orders | Timing; changes after the file is sent |
| Email of orders or reports | Very low | Small volumes; teams already emailing orders | Formatting consistency |
| Shared folder or SFTP drop | Low to medium | Regular files with clear timing | Access control on the folder |
| API | Medium to high | Orders that change during the day; write-back | Build and maintenance effort; ERP licensing |
| Database view | Medium | Stable read-only access | Security review; schema changes |
When is a scheduled file enough?
A scheduled file is enough when orders are released in batches and the freight work can start from that batch. Many manufacturers and distributors release shipping orders once or a few times a day. A report scheduled at those times gives the agent everything it needs. Changes after the file can arrive in the next file or by email. For a deeper comparison, see using a scheduled ERP file instead of an API.
How often should the file run?
The file should run as often as orders are released for shipping. If the warehouse releases orders once in the morning, one file is enough. If orders are released throughout the day, several files or an hourly drop may be better. The timing should leave enough time for carriers to quote and accept before the pickup. A hypothetical example: a plant releases orders at 6 a.m. and 1 p.m. for next-day pickup. Two scheduled files, at 6:15 and 1:15, give carriers the full afternoon to respond.
When is an API worth building?
An API is worth building when orders change often during the day, when timing is tight, or when the business wants freight status written back to the ERP as the work happens. It is also worth it when volume is high enough that file handling becomes a burden. IT should treat the API as a second phase: start with a file, prove the value, then build the API with a clear list of fields.
Which ERPs are supported?
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. IT should ask any vendor for the specific method it will use with the company's ERP version, not only whether the ERP is "supported".
What does IT need to maintain?
IT should ask what it will need to maintain after go-live. With a scheduled file, maintenance is usually limited to keeping the report running and telling the vendor if the format changes. With an API, there is code or configuration to maintain, credentials to rotate and upgrades to test. A clear owner on both sides prevents a quiet failure months later.
What access, write-back and data rules should IT set?
IT should give the software the least access it needs and decide in advance what, if anything, it may write to the ERP. An AI logistics agent can do the freight work with read access to orders. Write-back is useful but optional, and it should follow rules the business approves.
What does least access mean in practice?
Least access means the software can reach only the data and actions it needs for the freight work, and nothing else. With a file, the software sees only what is in the file. With an API or database view, the account should be limited to the order, item and ship-to data agreed, with no access to payroll, general ledger or unrelated modules. With email, the address should receive only freight messages. Least access also means removing access that is no longer used, for example a test account from the first weeks.
Should access start read-only?
Access should start read-only whenever possible. Reading orders is enough to quote, book and track. Read-only access limits the risk while the team learns how the software behaves. Write access can be added for specific fields once the business is confident and the rules are agreed.
What could be written back?
Common write-back fields include the carrier name, the carrier's tracking or PRO number, the freight cost, the ship date, the delivery date and the status. Some companies also want the freight cost posted as an accrual or the carrier invoice matched in accounts payable. Each field should have a clear owner and a rule. Wilson's write-back to the ERP depends on scope, and many teams begin without it.
Who approves write-back changes?
The business owner of each ERP area should approve the write-back rules: logistics for shipment fields, finance for cost and invoice fields. IT implements the access. The software should keep a record of every write, so anyone can see what changed and when. If a write fails, it should be reported, not retried silently in a way that creates duplicates.
How should email access be set up?
Email access should be set up with a dedicated address for the freight work. Wilson has its own email address on the company's domain, which carriers and the team use the way they would email a coordinator. IT creates the address under its normal policies. This keeps freight conversations out of personal mailboxes and gives the company control over the address if anything changes.
How should credentials be handled?
Credentials should belong to a named service account, not to a person. The account should have only the permissions agreed. IT should know how to rotate or revoke it. If the method is a file or a folder, access to that folder should be limited to the people and systems that need it.
What should IT confirm about records and data ownership?
IT should confirm that the software keeps complete records, that the company can export them and that the company owns its data. An AI logistics agent creates a large amount of operational history: messages, quotes, documents, status changes and payments. That history is valuable to the business and should not be locked in.
What records should exist?
Records should exist for every load: the order it came from, the quotes, the tender, the acceptance, the rate confirmation, the tracking updates, the documents, the invoice and the payment. Wilson keeps searchable and exportable records with a change history, so the team can see what happened and when.
Who owns the data?
The company owns its data. Cartage states that a customer's lanes, rates and carriers are never sold or shown to another shipper, and that the customer can take them at any time. IT should ask every vendor for the same commitment in writing.
How should the vendor be reviewed?
IT should review the vendor the way it reviews any system that touches company data: ask for the security documentation the company requires, confirm where data is stored and confirm how access is controlled. The answers should be specific and in writing. For a broader view of ERP connections, see carrier management system and ERP integration.
What should happen when the connection fails?
When the connection fails, the right person should know quickly and the freight work should not continue on wrong data. An AI logistics agent should treat a missing or malformed file as an exception with an owner, not as an empty day. IT should ask the vendor to walk through each failure case.
| Failure | What should happen | Who is told |
|---|---|---|
| Order file did not arrive | Alert after the expected time | IT and the logistics lead |
| File arrived with a changed format | Hold the file; report the problem | IT and the vendor |
| An order is missing required fields | Ask for the missing detail before quoting | The order owner |
| Duplicate order lines | Detect and hold the duplicate | The logistics team |
| API or credentials down | Pause writes; continue reading if possible | IT |
| Write-back rejected by the ERP | Record the failure; do not retry blindly | The ERP owner |
What happens on holidays and weekends?
On holidays and weekends, the expected file may not arrive, and that should not trigger false alarms. IT should tell the vendor the plant and warehouse calendar, or the schedule of the report, so a missing file on a closed day is expected. The opposite case matters too: if the warehouse ships on a Saturday but the report only runs on weekdays, Saturday orders would be missed. The schedule of the export should match the schedule of the shipping.
How should errors be reported?
Errors should be reported in the channel the owner already watches, with enough detail to act. "The 7 a.m. order file did not arrive" is useful. "Integration error" is not. Wilson reports to the team in Slack, Microsoft Teams or email, depending on the company's setup.
What about order changes after the file is sent?
Order changes after the file is sent should be caught in the next file or sent by email, and the agent should compare them with the load. A changed weight, address or date may change the quote or the booking. A hypothetical example: an order's ship-to changes after the morning file. The afternoon file shows the new address. Wilson sees the change, compares it with the booked load and asks the carrier to confirm the new delivery before pickup.
What should IT monitor after go-live?
After go-live, IT should monitor whether the file or feed arrives on time, whether the format stays stable and whether write-back succeeds if it is turned on. A short weekly look in the first month catches drift early: a report someone edited, a new warehouse that is not in the export, or a field that started coming through empty. After that, alerts on missing files and failed writes are usually enough. The logistics team watches the freight results; IT watches the pipe.
What should change management look like?
Change management should be simple: when the ERP or the report changes, the vendor hears about it before the change goes live. ERP upgrades, new custom fields, new sites or a changed report layout can all break a file-based flow. A short note to the vendor with the date and the change prevents most failures. The vendor should also tell IT before it changes what data it reads or writes.
Should there be a test period?
There should be a period where the team checks the results closely, using real orders on a few lanes. This is the company's own check, not a vendor program. Cartage doesn't run pilots; most customers start Wilson on a few lanes and expand from there. IT can use those lanes to confirm the data, the timing and the failure alerts work as expected.
How does Wilson, by Cartage, connect to the ERP?
Wilson, by Cartage, is an AI logistics agent that starts from the ERP data flow the company already has and does the freight work from order to paid carrier invoice. It quotes, books, schedules, tracks, audits and pays across LTL, FTL, ocean, drayage, parcel and cross-border freight. Wilson replaces the TMS for freight execution and connects to the company's ERP.
For IT, the typical path is:
- Agree on the data list and the first lanes.
- Schedule an existing ERP report, or set up an email or folder drop.
- Give Wilson its own email address on the company's domain.
- Review the first loads with the logistics team.
- Decide whether to add write-back or an API once the lanes are running.
How long does the IT part take?
The IT part is usually short when the work starts from an existing report or email. Scheduling a report, creating an email address and agreeing on the data list are tasks most IT teams can finish quickly. Timing depends on scope: most teams start on a few lanes and expand from there. A deeper connection, such as an API with write-back, takes longer and can run in parallel while the first lanes are already moving.
What does IT not need to do?
IT does not need to build an integration before the first loads move, install a TMS or migrate data. For how this looks from the logistics side, see automating carrier quote requests without replacing your ERP.
What does Wilson do once the order arrives?
Once the order arrives, Wilson checks it for missing details, requests quotes from approved carriers, books within the company's rules, confirms appointments, tracks the load with the best source available, handles exceptions, collects the POD, audits the carrier invoice and pays the carrier from the Wilson Wallet. The team approves anything outside the rules.
How is Wilson priced?
Wilson is free on Wilson's network: the shipper pays the freight rate and nothing on top. When a shipper keeps its own carriers, the fee is 2% to 0.5% of what Wilson pays them, falling with volume. There are no seat fees, no setup cost and no contract.
FAQs
What should IT check before connecting freight software to an ERP?
IT should check the data in and out, the connection method, the access needed, the write-back rules, the failure handling, the records and data ownership. An AI logistics agent like Wilson, by Cartage, can start from a scheduled ERP file with read-only data, so the first lanes need little IT work.
Does freight software need an API to the ERP?
Not to start. An AI logistics agent can work from a scheduled file, email or folder drop. An API is worth building later if orders change often or the business wants freight status written back to the ERP.
Should freight software write to the ERP?
Only for fields the business approves. An AI logistics agent can write back carrier, tracking number, cost or status where the connection allows it. Many teams start read-only and add write-back later.
Who owns the shipment data?
The company should own it. An AI logistics agent like Wilson keeps searchable, exportable records, and Cartage states that customer lanes, rates and carriers are never sold or shown to another shipper.
Sources
- Cartage, Wilson product FAQ and product scope, November 2026: https://cartage.ai
- Cartage, About page FAQ on data ownership, November 2026: https://cartage.ai/about
If IT is the bottleneck between your logistics team and automated freight work, book a demo to see how Wilson, the AI logistics agent by Cartage, starts from the ERP data you already have.