Your Custom ERP Can Start With One Order File

Key Takeaways

A custom ERP can prove freight execution with one real order file; no universal connector is needed first.
The acceptance test has five parts: the fields, the mapping, validation, rejected-row handling and a first-load run.
Wilson, by Cartage, starts from a file-based connection or an API connection, depending on what the custom ERP can produce, and write-back is optional and scoped.
A rejected row should be held with a reason and an owner, never dropped silently or filled in with a guess.
The test passes when the order in the file becomes a booked load with an approved carrier and the shipment history shows each step.

Can a custom ERP start freight execution with a single order file?

Yes. If the custom ERP can export one real ship-ready order in a consistent layout, that file is enough to test freight execution before anyone builds an API connection.

Homegrown and heavily modified ERPs often have one or two people who understand how orders are stored. Asking whether a freight vendor "has a connector" for that system has no useful answer. The better question is whether the file the system already produces can become a booked load, and what happens to the parts of the file that can't.

One file keeps the test small enough to inspect. Every column can be read, every mapping decision can be written down, and every rejection can be traced to a specific value. A batch of hundreds of orders hides those details behind a success rate.

The broader question of separating order intake from status return is covered in The ERP is custom. Does freight automation still work? This test sits inside intake and goes one level deeper, into the file itself.

The five-part test, from file to first load

Choose the order first, then run five parts in sequence; each one has a written pass condition.

Start by picking a real order that shipped recently on a typical lane. Avoid the cleanest record in the system. An order with a special requirement, such as a liftgate or a delivery appointment, shows more about the mapping.

Fields. Logistics and the ERP owner agree on the columns the file must carry, and which ones are required before a quote can go out.
Mapping. Each column is matched to its freight meaning once, including units, code tables and date formats. The mapping is written down so the ERP owner and logistics read it the same way.
Validation. Rules are set for each required field: present, readable and plausible. The file is checked as a whole too: column count, header row, encoding.
Rejected rows. Any row that fails validation is held with a reason, sent to a named owner, and corrected through a resubmission that does not create a duplicate.
First load. The valid order runs through quoting, booking and pickup confirmation with approved carriers, and the shipment history is reviewed against the file.

Changes to an order after it has been sent are a separate test. Keep them out of this one so a failure can be traced to the file, not to a revision.

What the file has to carry, and where custom systems trip up

A freight-ready order file needs about a dozen fields, and in a custom ERP the risk is less in finding them than in how they come out.

The core set: a unique order reference; ship-from location; ship-to name, full address and dock contact; ready date and requested delivery date; handling unit type and count; gross weight with its unit; dimensions where the mode needs them; commodity, SKU or freight class for LTL; accessorials such as liftgate, inside delivery or appointment; the customer PO for the bill of lading; and freight terms, so customer-routed orders are not booked by mistake. The longer list of what freight needs before a quote is in What freight needs before you request a quote.

Custom exports produce a familiar set of problems in mapping:

Generic column names. Headers such as FLD07 or ADDR2B mean nothing outside the ERP team. The mapping should name each one.
One row per line, not per order. A three-line order arrives as three rows. The rows have to be grouped by order reference, with weights summed and handling units counted once.
Codes instead of values. Ship-from and ship-to often appear as location or customer codes. A lookup table has to translate them into addresses.
Lost leading zeros. Opening the file in a spreadsheet tool can turn ZIP code 02134 into 2134 or an order number 000481 into 481.
Delimiters inside data. A comma in a street address breaks a comma-separated file unless fields are quoted.
Units without labels. A weight of 1,200 could be pounds or kilograms. The unit belongs in the mapping, not in someone's memory.

How should validation and rejected rows be handled?

Validation should separate hard stops from warnings, and every rejected row needs a reason, an owner and a clean way back in.

Hard stops hold the row before any carrier is contacted: a missing or repeated order reference, a ship-to that cannot be resolved to a full address, a missing weight, a date that cannot be read, or a ready date already in the past. Warnings let the row continue but flag it for a person: a missing dock contact, dimensions missing on a full truckload order, or a weight far outside what that SKU usually ships at.

Rules for rejected rows that a buyer should insist on:

Hold, don't drop. A row that fails is held with the exact reason, not silently skipped.
Don't guess. A missing weight is requested from the person who owns it, not estimated from a similar order.
Name the owner. Mapping errors go to the ERP owner; missing order data goes to customer service or the shipping team.
Let the rest proceed. One bad row should not stop the valid orders in the same file.
Resubmit by reference. A corrected row sent with the same order reference replaces the held row instead of creating a second shipment.
Fail the whole file only for file problems. A wrong column count, a missing header or an empty file should alert the team, not be read as a day with no orders.

When evaluating software, ask to see a held row: the reason, who was asked and what the resubmission looked like.

A worked example: one file, three rows, one first load

For the test, take one real order and add two copies with deliberate defects and their own test references. The file then exercises the clean path and both kinds of rejection. Values are illustrative.

Row	Content	Validation result	What should happen next
1	Real order 000481, ship-to code C-2207, 4 pallets, 2,180 lb, ready Tuesday	Passes; code resolves to a full address	Shipment created; quotes requested from approved carriers
2	Copy with reference 000481-T1, weight column empty	Hard stop: missing weight	Row held; shipping team asked for the weight; no carrier contacted
3	Copy with reference 000481-T2, ship-to code C-9999	Hard stop: code not in lookup table	Row held; ERP owner told the code is unknown; row 1 is unaffected

Then run row 1 as the first load and check it off:

Shipment details match the file, including the address resolved from the code and the summed weight.
Quotes went only to carriers the company has approved.
The selected rate sits inside the approval limit, or the approval request shows the options.
Booking and pickup are confirmed by the carrier, not just requested.
The bill of lading carries the customer PO from the file.
The shipment history shows the source file, the row, the mapping applied and every carrier message.
If write-back is in scope, the booked carrier and pickup date return to the ERP by the agreed method.
Resubmitting row 2 with a weight creates one shipment, not two.

How Wilson, by Cartage, runs the one-file test with a custom ERP

Wilson starts from what the custom ERP can already produce, so the first proof is the file, not a development project.

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 usually means a file-based connection, such as a scheduled file drop, a spreadsheet or an emailed export, or an API connection where the system has one. Wilson does not depend on a universal prebuilt connector.

Once the order is valid, Wilson replaces the TMS for freight execution: it requests quotes from the company's approved carriers, negotiates against the company's rate targets under configured rules and approval limits, books the carrier, confirms pickup, tracks the load and escalates when no approved carrier accepts. Messages, confirmations and changes are recorded in each shipment's change history. Write-back is optional and scoped: an updated file, a shared table, or an API connection where available.

Wilson starts with assisted execution, and the company decides which actions need approval. Timing depends on scope: most teams start on a few lanes and expand from there. More on the role is in What is an AI logistics agent?

Export one real order from the custom ERP exactly as production would, and bring that file to walk through how Wilson would map, validate and book it.