Integration is where fleet software projects lose their schedule. Not because connecting systems is technically hard, but because nobody agreed what should flow, in which direction, how often, and who fixes it at 03:00 when it stops.
The integration map
Most fleet and route operations end up connecting six things:
| System | Flows | Direction | Typical frequency |
|---|---|---|---|
| ERP / order system | Orders, customers, products | In | Continuous or hourly |
| ERP / finance | Invoices, costs, GL postings | Out | Daily or per transaction |
| Telematics | Location, odometer, engine data, events | In | Near real time |
| Fuel cards | Transactions, volumes, prices | In | Daily |
| HR / payroll | Driver records, hours, absence | Both | Daily |
| Customer systems | ASN, POD, tracking, EDI | Both | Per event |
Add maintenance vendors, tyre suppliers, insurance and toll providers in larger operations. The pattern holds: each connection is a small product with its own lifecycle, not a one-off task.
Decide these six things per integration
Write them down before any development starts. Most integration failures trace to one of these being assumed rather than agreed.
- System of record. For each field, which system wins? Customer address, driver name and vehicle odometer are the classic contested fields.
- Direction and trigger. Push or pull, event-driven or scheduled, and what triggers it.
- Frequency and latency tolerance. "Real time" is expensive; ask what decision depends on the freshness.
- Failure behaviour. Retry policy, dead-letter handling, alerting, and whether the receiving system blocks or continues.
- Reconciliation. How you prove that what was sent was received. Daily count and total checks catch silent partial failures that go unnoticed for weeks.
- Ownership. A named person on each side, and a documented escalation route.
Integration patterns, ranked by durability
File exchange (SFTP, CSV). Still ubiquitous, especially with older ERPs. Cheap and well understood. Weaknesses: latency, silent partial failures, and encoding surprises. Acceptable for daily master data, poor for anything operational.
REST API, point to point. The current default. Good when both sides have documented, versioned APIs. Weakness: N systems require N×(N−1)/2 connections if you keep adding them point to point.
Webhooks / event streaming. The right pattern for operational events — delivery completed, defect raised, vehicle arrived. Push instead of poll, lower latency, less load. Requires an endpoint you can operate reliably.
Middleware / iPaaS. A hub in the middle handling mapping, retries, monitoring and transformation. Worth its cost above roughly four integrations, and it turns integration from bespoke code into configuration you can actually staff.
Native module. No integration at all, because it is the same database. Best when available, and a legitimate reason to prefer a suite — provided the module is genuinely good rather than merely present.
The ERP connection
Usually the largest single piece of work, and the one whose difficulty is most consistently understated.
Complications to expect:
- Customer master mismatch. ERP customers are billing entities; route software needs delivery locations. One ERP customer can be forty delivery points, and the mapping usually does not exist yet.
- Product and unit-of-measure conversion. Cases, layers, pallets, kilograms. Routing needs volume and weight; the ERP holds selling units.
- Order lifecycle differences. What ERP calls an order line, delivery software may treat as a stop, a task or several parcels.
- Timing. Order cut-off, pick confirmation and route planning must sequence correctly, or you plan orders that the warehouse cannot pick.
- Credit holds and cancellations. A change after planning must reach the driver's device, not just the office.
Allow more calendar time than the estimate, and insist on a test environment for the ERP. Integration testing against production is a decision you make once.
Telematics integration
The most standardised of the six, and still worth checking:
- Does the fleet platform support your device vendor natively, or via a generic feed?
- What is the odometer update frequency, and does it write into the maintenance module automatically?
- Are fault codes (DTCs) passed through, and can they trigger a work order?
- Are trips, idling and behaviour events available, or only positions?
- If you change telematics vendor, how much reconfiguration is required?
That last point matters commercially. A fleet platform that only integrates deeply with one hardware vendor has quietly locked you into that hardware.
Testing integrations properly
- Volume test at peak, not at average. Systems that handle 400 orders often behave differently at 4,000.
- Failure injection. Turn the endpoint off mid-transfer and confirm the behaviour matches the design.
- Duplicate handling. Send the same message twice; idempotency should be a designed property, not a hope.
- Bad data. A customer with no postcode, an order with zero quantity, a unicode character in an address. Production will contain all three.
- Reconciliation reports running from day one, not added after the first incident.
Frequently asked questions
Should integration be built by the vendor or by us?
Vendor-built integrations to their own standard connectors are usually cheaper and better supported. Custom integration is worth owning when it encodes something distinctive about your business — and when you have the capability to maintain it after the person who wrote it leaves.
How much should integration cost?
As a rough planning figure, a standard connector configuration might be 10–20% of first-year licence cost; a bespoke ERP integration frequently equals or exceeds it. Get the integration scope priced separately and explicitly in every proposal, not bundled into "implementation".
What is the most common integration failure in production?
Silent partial failure: a feed runs, reports success and delivers 80% of records. This is why daily reconciliation on counts and totals matters more than any amount of pre-go-live testing.
Do we need middleware?
Below about four integrations, usually not. Above that, or where you expect to change one system without rebuilding the others, middleware pays for itself in maintainability and in monitoring you would otherwise build yourself.
How do we avoid vendor lock-in through integrations?
Insist on documented, standard APIs on both sides; keep transformation logic in middleware you control rather than inside a vendor's proprietary configuration; and confirm contractually that you can export your full data set in a usable format at any time.
