On this page
- The short answer
- Which transport business you run
- Map the customer movement
- What makes transport different
- Can a generic ERP work?
- The trip as the spine
- What the customer asked you to move
- Plan before allocating
- Owned fleet vs hired capacity
- Allocate an eligible resource
- Tanker and equipment
- FOLLOW THE TRIP
- Planned vs actual execution
- POD as an operating event
- Cost against the movement
- ONE EXPENSE. TWO VIEWS.
- Fuel, movement and asset
- Maintenance and eligibility
- Freight billing and execution
- ONE TRIP. TWO COMMERCIAL SIDES.
- Close the trip financially
- Trip vs vehicle economics
- Route in operational context
- C&F, warehouse, final delivery
- Receivables and freight billing
- ERP, TMS, telematics, mobile, HRMS
- Driver information
- Multi-location operations
- Owned + hired utilisation
- The difficult scenarios
- Standard or custom?
- Red flags
- Evaluation record
- What customer proof?
- Evidence: Al Mashaweer
- How exactllyERP fits
- Checklist
- Go Deeper
One company may run an owned fleet. Another may use hired vehicles. Many use both. Some operate tankers, some run line-haul transport, some combine transport with clearing, forwarding, warehousing or final delivery, and some coordinate movement without owning vehicles at all.
That is why an ERP should not be judged simply by asking whether it has fleet management, billing or vehicle masters.
The buyer needs to know whether the operating record can stay connected from the customer requirement through trip planning, resource allocation and execution to delivery evidence, operating cost, billing, receivables and financial outcome.
The useful question is not “Does your ERP support transport?”
It is “Can you show us the complete movement—from what we committed to the customer, through what actually happened on the trip, to what that movement cost, earned and left outstanding?”
The short answer
A transport or logistics company should evaluate ERP by following the real movement.
Depending on the business, the operating chain may look like:
- customer requirement / booking
- transport order or service commitment
- trip planning
- owned vehicle / hired carrier allocation
- driver assignment where relevant
- dispatch / gate-out
- trip execution
- delivery event
- POD / delivery evidence
- trip expense / carrier cost
- customer freight billing
- receivable / collection
- financial outcome
For some businesses, the movement may also pass through:
- clearing / forwarding
- warehouse / inventory
- final delivery
Not every operator uses every stage.
The important test is whether the proposed ERP can preserve the relationship between the customer commitment, the trip, the resource used, the events that actually occurred, the costs incurred, the billing raised and the money still to be collected.
A feature checklist alone cannot prove that.
First identify which transport business you actually run
Before comparing ERP vendors, define your operating model.
You may be:
Do not force your operation into a generic “fleet company” model if that is not how you work.
Ask:
Which part of the movement do we own, which part do we coordinate, and which part do we buy from another service provider?
That answer should shape the ERP evaluation.
Map the full customer movement before choosing software
Do not begin with the vehicle master.
Begin with the customer movement.
At minimum, map the stages that apply to your business:
Then ask:
At which points can the movement, cost, responsibility, service status or commercial outcome change?
Those are the points the ERP evaluation must test.
What makes Transport & Logistics ERP requirements different?
A transport business still needs ordinary ERP capabilities:
The difference is in how those transactions connect to the movement that created them.
A vehicle expense is not only a finance transaction.
A fuel issue is not only a stores issue.
A POD is not only an attachment.
A transporter payable is not only a vendor bill.
A freight invoice is not only a sales invoice.
Each of these can be the financial consequence of a specific movement.
So the buyer should not ask whether the ERP has isolated modules.
Ask whether the operating and financial records remain connected to the same trip or logistics activity.
Can a generic ERP still be right for a transport company?
Yes.
A transport or logistics company should not choose industry-specific software merely because it carries a transport label.
Some operations are simple.
Some businesses use a specialist TMS, telematics platform, fleet system, mobile application or warehouse system around a broader ERP.
Some generic ERP platforms may support the required model through configuration, connected applications or development.
The decision should depend on what your critical workflows require.
Ask:
Which transport concepts must the ERP understand directly?
Which can be configured?
Which should remain in TMS, telematics, mobile, warehouse or HR systems?
Which require development or integration?
The label matters less than the evidence.
A transport-specialist claim should make the demonstration more demanding, not less.
Make the trip the spine of the operating record
For many transport businesses, the trip is where the customer promise becomes an operating event.
The trip can connect:
- customer requirement
- resource
- driver where relevant
- route
- dispatch
- execution
- delivery
- POD
- expense
- billing
- receivable
That does not mean every logistics business must use the word “trip.”
The principle is more important:
The movement that fulfils the customer commitment should remain one connected operating record.
This gives management a way to ask:
- What was promised?
- What was planned?
- What actually happened?
- Which resource performed it?
- What did it cost?
- What was billed?
- What remains outstanding?
Start with what the customer asked you to move
A transport order can contain more than origin and destination.
Depending on the business, the requirement may include:
Do not assume every operator uses the same fields.
The important buyer question is:
Can the customer commitment remain connected to the trip that eventually fulfils it?
A trip created separately from the customer requirement can force operations, billing and finance to reconcile the same movement later.
Plan the trip before allocating the resource
Trip planning should answer more than:
“Which vehicle is free?”
Depending on the business, planning may need to consider:
a resource that exists
a resource that is actually eligible and available for this movement.
Ask the vendor:
Show us how the trip is planned before a vehicle or carrier is committed.
Distinguish owned fleet from hired capacity
Owned and hired vehicles can fulfil the same customer movement, but they do not create the same cost structure.
Owned capacity
An owned vehicle may create, where relevant:
- fuel;
- driver expense;
- toll;
- maintenance;
- repair;
- other asset-related operating costs.
Hired or contract capacity
A hired or contract vehicle may create:
- transporter rate;
- trip payable;
- detention or additional charge;
- other vendor settlement.
The customer may still see one transport service.
The ERP should preserve the difference between how the service is sold and how the capacity is provided.
Ask:
Can the same movement be fulfilled by an owned vehicle or a hired vehicle without losing the different cost and settlement treatment?
Allocate a resource that is actually eligible
A vehicle may exist in the master but still be unavailable for the trip.
Operational status may include:
Confirmed exactllyERP capability includes vehicle availability/status such as available, on trip and under maintenance.
The buyer should test:
What happens when operations tries to allocate a vehicle that is already on another trip or otherwise unavailable?
Exactlly can partially support visibility/prevention of conflicting or double vehicle allocation and can configure or develop this further according to implementation requirements.
So the buyer should insist that the exact conflict rule required by the operation is demonstrated rather than assumed.
Tanker and equipment requirements may matter
Some operators require particular vehicle or equipment characteristics for a movement.
Confirmed exactllyERP capability includes tanker allocation by relevant load or route requirement where applicable.
The same evaluation principle can apply to other transport-specific equipment requirements:
Can the system distinguish a vehicle that is merely available from one that is suitable for this load or service?
Do not assume every transport business operates tankers or specialised equipment.
FOLLOW THE TRIP
This should be one of the hardest tests in a Transport ERP evaluation.
A possible operating chain is:
- trip plan
- resource allocation
- dispatch / gate-out
- in transit
- operational event / exception
- arrival / delivery
- POD
- completed movement
- billing
- collection
The exact event model differs by business.
The principle does not:
Can the ERP preserve what was planned, what actually happened and what remains commercially incomplete?
The trip should not become “complete” operationally while billing, POD or settlement remains invisible elsewhere.
Track planned vs actual execution
Confirmed exactllyERP capability includes trip execution status from dispatch through completion and dispatch/gate-out recording.
The buyer should test how the system distinguishes:
Do not focus only on timestamps.
Ask:
When the trip deviates from plan, who can see it, what changes, and what downstream activity is affected?
That may influence customer communication, billing, fleet availability or future scheduling.
Treat POD as an operating event, not merely an attachment
Confirmed exactllyERP capability includes:
That enables useful operating questions:
Which completed trips are still waiting for POD?
Which customer or driver is associated with the pending document?
How long has it been pending?
POD-linked billing eligibility or workflow is partially supported and can be configured or developed according to customer requirements.
So the buyer should ask the vendor to demonstrate the exact rule:
Does receiving POD merely complete documentation, or does it change billing eligibility in our process?
Do not assume every transport business requires POD before billing.
Capture cost against the movement that caused it
Transport cost should not be reconstructed only from finance ledgers after the month closes.
Confirmed exactllyERP capability includes trip-wise expense capture.
Depending on the business, trip expenses may include:
Do not prescribe one universal cost list.
The key question is:
Can the cost of this movement be understood from the trip itself?
That lets the operating record become the source of later cost analysis.
ONE EXPENSE. TWO VIEWS.
A transport expense can be useful in at least two analytical contexts.
TRIP VIEW
What did this individual customer movement cost?
VEHICLE VIEW
What has this asset cost across the work it performs?
Confirmed exactllyERP capability includes:
The important control is:
The business should not have to enter the same expense twice merely to analyse it two different ways.
This distinction is particularly useful when the same vehicle performs many trips over time.
Connect fuel to movement and asset
Confirmed exactllyERP capability includes:
The buyer should ask:
Can we explain which trip and which vehicle consumed the fuel, rather than only how much fuel the company purchased?
Depending on the operation, management may then compare fuel by:
Do not impose one universal fuel-efficiency benchmark.
The useful question is whether the operating context behind the fuel is available.
Make maintenance affect operational decisions
Confirmed exactllyERP capability includes:
The buyer should not evaluate maintenance only as a historical register.
Ask:
If a vehicle is under maintenance or approaching a service requirement, what does dispatch see when trying to allocate it?
The exact blocking or warning behaviour should match the customer’s operating policy.
This is especially important because double-allocation/conflict prevention is partially supported and may require configuration or development for the specific implementation.
Keep customer freight billing attached to execution
Confirmed exactllyERP capability includes customer freight billing from trip, contract or rate information.
The billing basis may differ by customer and service.
Confirmed rate structures can include, where required:
Do not assume every business uses each rate model.
The buyer should ask:
Can the commercial rate agreed with the customer be applied to the movement that actually occurred?
The freight invoice should not have to be recreated manually from trip records.
ONE TRIP. TWO COMMERCIAL SIDES.
A hired-fleet movement can have two different commercial relationships.
SELL SIDE
What the customer owes the transport company.
BUY SIDE
What the transport company owes the hired carrier or transporter.
These are related to the same movement, but they are not the same transaction.
Hired vehicle/transporter payable or settlement separately from customer billing is partially supported in exactllyERP and can be configured or developed according to implementation requirements.
The buyer should therefore demonstrate the actual commercial workflow before assuming that customer billing and transporter settlement follow the same rules.
The key question is:
Can we keep revenue and carrier cost connected to the same movement without confusing one for the other?
Close the trip to its financial outcome
A trip is operationally meaningful, but management also needs to understand its financial result.
Confirmed exactllyERP capability includes trip-wise profitability / revenue-versus-cost analysis.
The useful relationship is:
- customer freight revenue
- less relevant movement cost
- trip financial contribution / result
Do not impose one universal profit formula.
Different operators include different costs.
The buyer should ask:
Can we compare what this movement earned with what this same movement cost?
This is what closes the loop from operations to finance.
Trip economics and vehicle economics are different
A profitable trip does not automatically mean the vehicle is economically healthy across the month or year.
Confirmed exactllyERP capability includes vehicle-wise profitability / cost analysis.
Vehicle analysis may consider, where relevant:
Do not impose one universal vehicle-profitability formula.
The buyer should keep the two questions separate:
Was this trip economically sound?
What is this vehicle costing and contributing across all its work?
Keep route performance in operational context
Confirmed exactllyERP capability includes route-wise fuel / cost analysis.
Broader route-wise performance/profitability analysis is partially supported and can be configured or developed according to implementation requirements.
A buyer may want to analyse:
But no route KPI is universally correct.
Ask:
Which route measures actually influence pricing, scheduling, fleet choice or customer commitments in our business?
Then make the vendor demonstrate those measures.
Connect transport, C&F, warehouse and final delivery where the business needs them
Some logistics businesses extend beyond transport.
The movement may continue through:
- transport
- clearing / forwarding
- warehouse / inventory
- final delivery
Confirmed exactllyERP capability includes warehouse/inventory operations connected to transport activity.
Clearing & forwarding operations and final-delivery activity connected to the movement are partially supported and can be configured or developed according to implementation requirements.
There is also customer-specific evidence from Al Mashaweer of transport, clearing & forwarding, warehouse/inventory and delivery operating within the wider Exactlly environment.
The buyer should ask:
When the goods move from one logistics stage to another, does the customer activity remain connected—or do we create another manual reconciliation point?
Do not assume every transporter needs warehouse or C&F functionality.
Keep receivables connected to freight billing
Transport operations do not end when an invoice is raised.
Confirmed exactllyERP capability includes:
The buyer should be able to ask:
- What has been billed?
- What remains outstanding?
- Which customer owes it?
- Which invoice?
- How old is it?
- Which transport activity created it?
This connects operating work to working-capital visibility.
Decide what belongs in ERP, TMS, telematics, mobile and HRMS
Not every transport capability has to live in one application.
A transport environment may include:
Confirmed exactllyERP capability includes external integration for GPS, telematics, mobile and POD systems according to implementation requirements.
Mobile application support for relevant transport/field workflows is partially supported and can be configured or developed according to implementation requirements.
HRMS integration/connection for employee/driver, attendance and payroll where exactllyHRMS is used is also partially supported and can be configured or developed according to implementation requirements.
The useful architecture questions are:
Which system owns the trip?
Which system owns live location?
Which system owns driver/workforce data?
Which system owns maintenance?
Which information must move between them?
What happens when the connection fails?
A single application should not be selected merely because it promises to replace every surrounding system.
Driver information should serve the trip, not create another silo
Confirmed exactllyERP capability includes:
Driver assignment to vehicle/trip is partially supported and can be configured or developed according to implementation requirements.
The buyer should ask:
- Which driver executed this movement?
- Which trips has the driver performed?
- Which trip-related expenses belong to the driver?
- Which driver information belongs in ERP?
- Which belongs in HRMS?
Where exactllyHRMS is used, employee, attendance and payroll connectivity can be implemented according to requirements rather than assumed as one universal standard workflow.
Multi-location operations should preserve the same movement history
Confirmed exactllyERP capability includes multi-location fleet, depot and branch operations where required.
The buyer should test whether a trip remains understandable when activity spans:
Ask:
Can another branch or depot see the same movement without recreating it locally?
A multi-location system is useful only if the customer, trip, resource, cost and billing context remain connected.
Owned + hired utilisation needs a clearly defined metric
Many operators use both owned and hired capacity.
Owned + hired fleet utilisation visibility is partially supported and can be configured or developed according to implementation requirements.
The buyer should first define what “utilisation” means.
Possible measures include:
Do not accept a generic utilisation percentage without understanding how it is calculated.
The useful question is:
What decision will this utilisation measure help us make?
Make the vendor demonstrate the difficult transport scenarios
Do not allow the Transport ERP demonstration to become a tour of vehicle masters, trip screens and invoices.
Give every shortlisted vendor the same difficult scenarios.
Customer booking / transport-order-to-trip creation is partially supported in exactllyERP and can be configured or developed according to implementation requirements, so this scenario should be demonstrated against the buyer’s exact workflow.
POD-linked billing workflow is partially supported and should be configured or developed according to the customer’s rule where required.
The last scenario should be demonstrated according to the actual scope required, because C&F and final-delivery linkage can require configuration or development.
The point is not that every ERP should navigate identically.
The point is that every vendor should prove the same business outcome.
Record what is standard, configured, extended or custom
After every important transport scenario, classify how the proposed result is delivered.
The proposed product supports the requirement as part of its normal capability.
The result depends on settings, masters, workflow or configurable behaviour.
Another application or integration is part of the proposed solution.
Development is required specifically for the requirement.
The claim remains proposed until evidence is provided.
None of these labels is automatically good or bad.
This distinction is particularly important in transport, where ERP, TMS, telematics, mobile, warehouse and HR systems often coexist.
The buyer needs to understand what will actually have to exist in production.
Transport & Logistics ERP red flags
The demo begins with vehicle dispatch
The customer commitment and trip planning may already be disconnected.
The vehicle master is shown, but resource allocation is not
A master record does not prove operational control.
Owned and hired vehicles use identical cost logic without explanation
The economics and settlement obligations may be getting mixed.
The same vehicle can be allocated to conflicting trips
Resource availability is not controlling dispatch.
Maintenance does not affect resource eligibility
The maintenance record is historical rather than operational.
Trip status depends on phone calls or separate registers
Execution visibility is outside the operating system.
POD can be uploaded but has no operational status
The system stores a document but does not manage the process around it.
Billing is recreated manually from trip details
The customer invoice can diverge from the executed movement.
Customer rate is disconnected from the trip
Commercial terms have to be reconstructed at billing time.
Carrier payable and customer revenue are mixed together
The two commercial sides of a hired movement are not clearly controlled.
Trip expense is captured only in finance after the movement
Operations cannot understand cost from the trip record itself.
Fuel cannot be related to trip and vehicle
Consumption has no operating context.
Vehicle cost requires separate manual consolidation
Asset economics remain outside the same data.
Trip profitability is calculated from unrelated monthly totals
The movement is not a genuine cost/revenue unit.
Route profitability is presented without defining the route metric
The report may look precise without being operationally useful.
C&F or warehouse activity breaks the movement chain
The customer activity becomes multiple disconnected records.
Customer receivable cannot be traced back to freight activity
Operations and working capital are separated.
Mobile or external systems create duplicate data entry
Integration has created another reconciliation problem.
“Fleet management” means only GPS location
Live location alone does not prove planning, execution, costing or billing control.
Customer proof is only a fleet-size logo
The reference does not reduce uncertainty about the buyer’s actual movement model.
A practical Transport & Logistics ERP evaluation record
For each critical workflow, record the evidence.
| Evaluation area | What the buyer should establish |
|---|---|
| Operating model | Which movement stages are owned, hired or coordinated |
| Customer requirement | How booking/service commitment remains connected |
| Trip planning | How route, load, service and schedule become an executable trip |
| Resource eligibility | How availability, maintenance and existing commitments are checked |
| Owned fleet | How owned-vehicle operating cost is captured |
| Hired fleet | How carrier/vendor cost and settlement are treated |
| Driver | How assignment/history/expense works where required |
| Dispatch | How actual gate-out/start of execution is recorded |
| Trip execution | How status, delay and exception remain visible |
| POD | How pending/received POD is controlled |
| Billing eligibility | Whether POD or another event changes billing status |
| Customer freight billing | How rate/contract and executed movement remain connected |
| Carrier payable | How buy-side movement cost remains separate from customer revenue |
| Trip expense | How movement-level cost is recorded |
| Vehicle expense | How the same operating expense contributes to asset analysis |
| Fuel | How fuel is connected to trip, vehicle and route |
| Maintenance | How service/repair history and due status affect availability |
| Trip economics | How movement revenue and relevant cost are compared |
| Vehicle economics | How vehicle cost/profitability is understood across trips |
| Route analysis | Which route measures are meaningful and how they are derived |
| Outstanding / ageing | How freight receivables remain visible |
| Collections | How receipts are tracked against freight invoices |
| C&F | How required clearing/forwarding activity connects to movement |
| Warehouse | How inventory activity connects to transport |
| Final delivery | How last delivery activity remains linked |
| Multi-location | How depots/branches share the same operating record |
| Utilisation | How owned/hired capacity usage is defined and measured |
| Integration | Which TMS/GPS/mobile/POD/HRMS/warehouse systems remain |
| Management reporting | How trip/vehicle/route/customer/receivable/warehouse views are produced |
| Delivery method | Standard / configuration / extension / custom / not demonstrated |
| Follow-up | What evidence remains unresolved |
Do not turn this into a percentage score.
One unresolved critical movement, billing or settlement requirement can matter more than many minor feature matches.
What customer proof should a Transport ERP vendor provide?
A useful customer reference is not simply another logistics company with a large fleet.
Ask for proof closest to the uncertainty you are trying to remove.
If your concern is trip control, ask:
Which customer uses the trip as an operating record from planning through completion?
If your concern is trip costing, ask:
Which customer captures operating expense directly against the trip?
If your concern is vehicle economics, ask:
Which customer can analyse the same operating expenses vehicle-wise without entering them again?
If your concern is mixed fleets, ask:
Which customer uses both owned and hired capacity and keeps their economics distinct?
If your concern is POD and billing, ask:
Which customer can show how trip completion and documentation connect to billing?
If your concern is wider logistics, ask:
Which customer connects transport with C&F, warehouse or final-delivery activity?
Customer evidence should validate the difficult workflow.
Not decorate the proposal.
Relevant operating evidence: Al Mashaweer
Al Mashaweer provides strong evidence across a connected transport and logistics operating model.
Its confirmed Exactlly environment includes:
The customer operates from Dubai, UAE, with a substantial transport and warehousing environment.
The value of the evidence is not the fleet size by itself.
The stronger proof is how the movement remains connected across operations and finance.
Trip expenses are captured against the trip.
That allows the movement itself to become a meaningful unit of cost analysis.
The same operating information can be analysed vehicle-wise without requiring another independent expense record.
This supports the principle:
ONE EXPENSE. TWO VIEWS.
Al Mashaweer’s environment includes transport, clearing & forwarding, warehouse/inventory and delivery activity.
That is useful evidence for buyers whose logistics process extends beyond the truck movement alone.
Billing, receivables, finance and MIS remain connected with transport operations.
That supports the governing idea:
FOLLOW THE TRIP. CLOSE THE LOOP.
Customer evidence should still supplement the buyer’s own demonstration.
It should not replace it.
How exactllyERP fits into this evaluation
exactllyERP should be evaluated against the same difficult transport scenarios.
Do not ask Exactlly only:
“Do you have Transport ERP?”
Bring the actual operating model.
Include:
- customer booking / order process;
- routes;
- load or service requirements;
- owned fleet;
- hired fleet;
- tankers/equipment where applicable;
- driver process;
- resource-availability rules;
- trip-status model;
- POD process;
- freight-rate structures;
- hired-carrier settlement;
- expense categories;
- fuel process;
- maintenance;
- warehouses / depots / branches;
- C&F or final-delivery stages where applicable;
- receivables / collections;
- external GPS / telematics / mobile / POD systems;
- HRMS requirements;
- management reporting.
The following are confirmed current capabilities:
- trip planning by route, load/service requirement and schedule;
- owned vehicle allocation to trip;
- hired/contract vehicle allocation to trip;
- vehicle availability/status such as available, on trip and under maintenance;
- tanker allocation by relevant load/route requirement where applicable;
- trip execution status from dispatch through completion;
- dispatch/gate-out recording;
- POD tracking against trip;
- pending POD visibility by trip/customer/driver where relevant;
- customer freight billing from trip/contract/rate information;
- different freight-rate structures such as per trip, kilometre, tonnage, full-load, partial-load or contract where required;
- trip-wise expense capture;
- vehicle-wise expense analysis from operating expenses;
- fuel issue/consumption capture by trip and vehicle;
- route-wise fuel/cost analysis;
- vehicle maintenance/service records and maintenance-due tracking;
- vehicle repair/maintenance cost tracking;
- trip-wise profitability / revenue-versus-cost analysis;
- vehicle-wise profitability/cost analysis;
- customer-wise freight outstanding and ageing;
- collection tracking against freight invoices;
- multi-location fleet/depot/branch operations where required;
- warehouse/inventory operations connected to transport activity;
- trip history by vehicle;
- trip history by driver;
- driver-related trip expense/allowance capture where required;
- finance/MIS connected with trip, billing and receivables;
- external integration capability for GPS/telematics/mobile/POD systems according to implementation requirements;
- management reporting by trip, vehicle, route, customer, receivable and warehouse where applicable.
The following are partially supported and can be configured or developed according to customer requirements:
- customer booking / transport order to trip creation;
- prevention/visibility of conflicting or double vehicle allocation;
- driver assignment to vehicle/trip;
- POD-linked billing eligibility or billing workflow where configured;
- hired vehicle / transporter payable or settlement separately from customer billing;
- route-wise performance/profitability analysis;
- clearing & forwarding operations;
- final delivery activity connected to the movement;
- owned + hired fleet utilisation visibility;
- HRMS integration/connection for employee/driver, attendance and payroll where exactllyHRMS is used;
- mobile application support for relevant transport/field workflows.
This distinction matters.
The buyer should know whether the workflow being demonstrated is standard, configured, extended or developed for the implementation.
The relevant questions remain:
What did the customer ask us to move?
What actually happened on the trip?
What did that movement cost?
What was billed?
What do we owe the carrier where relevant?
What remains outstanding from the customer?
The right Exactlly implementation is the one that can demonstrate the buyer’s actual operating loop.
Transport & Logistics ERP Evaluation Checklist
Operating model
Customer requirement
Trip planning
Vehicle / resource allocation
Driver
Execution
POD
Trip expense
Vehicle expense
Fuel / route
Maintenance
Customer billing
Hired-carrier settlement
Trip economics
Vehicle economics
C&F / warehouse / final delivery
Receivables / collections
Multi-location
Integration / coexistence
Vendor evidence
The buyer is evaluating the ERP as an operating system for the complete transport movement rather than as a list of fleet and billing features.