Logistics ERP: fleet, dispatch, settlements and reconciliation
What should you know about logistics ERP development before building a transport management system?
Logistics ERP centres on order intake, dispatch, fleet, proof of delivery, cash reconciliation and seller settlements. The build order matters: get order intake and dispatch working with a driver app first, because proof of delivery and cash data from the field are what make reconciliation and settlements possible.
Logistics ERP development is a question of sequence. The six functions that matter are order intake, dispatch, fleet management, proof of delivery, cash reconciliation and seller settlements, and each one depends on data the previous one produces. An operator who builds settlements before there is reliable proof of delivery will reconcile by hand forever. This article sets out what each module has to do for an Indian transport or last-mile operator, why the driver app is the foundation rather than an add-on, and how a custom build compares with a packaged transport management system.
Why logistics operators outgrow packaged transport management systems
Packaged transport management systems handle the standard case well: a consignment, a route, a vehicle, a delivery. The fit breaks on the parts that make an operator's money or lose it. Cash on delivery collected by hundreds of drivers and deposited across branches. Sellers who need settlement statements that match every rupee. Fleet that is part owned, part attached, with different cost rules for each. Multi-leg movements through hubs where a shipment changes vehicle twice. Those are where the spreadsheets appear, and where a custom logistics software build earns its cost.
The alternative is not always full custom. Many operators keep a packaged product for standard consignment tracking and build the settlement and reconciliation layer around it; the same hybrid logic as in custom CRM versus off the shelf.
Logistics ERP modules and what each must handle
| Module | What it must handle | Data it produces for later modules |
|---|---|---|
| Order intake | Orders from sellers via API, portal, bulk upload and email; pincode serviceability; rate cards; COD flags | Consignments with rates and payment terms |
| Dispatch | Batching by route and vehicle; hub handovers; manifests; rescheduling; exception queues | Trip and manifest records, driver assignment |
| Fleet | Own and attached vehicles; driver documents and licences; fuel, maintenance, tolls; per-trip cost | Trip cost per vehicle and driver |
| Proof of delivery | Driver app with OTP, signature, photo, geotag; failed-delivery reasons; returns | Delivery status per consignment with evidence |
| Cash reconciliation | COD collected per driver per day; deposits by branch; shortfalls; digital payments at doorstep | Cash position per driver, branch and day |
| Seller settlements | Rate application, COD remittance, deductions, GST invoices, statements and disputes | Payables per seller with audit trail |
Order intake and dispatch: the operational core
Order intake sounds simple until you list the sources: a seller's e-commerce platform pushing orders by API, a portal where smaller sellers type them, a spreadsheet upload from a large account, and a WhatsApp message from a walk-in. The module has to normalise all of them into one consignment record, check serviceability by pincode, apply the seller's rate card and mark the payment mode. Errors here propagate everywhere, so validation at intake is worth more than any later report. A wrong pincode or a missing COD flag at intake becomes a failed delivery, a cash dispute and a settlement query three weeks later.
Dispatch turns consignments into trips. A planner groups by route and vehicle capacity, prints or sends manifests, records hub handovers and reassigns when a vehicle fails. Automated route suggestions help, but the first version needs to be a fast, trustworthy screen where a planner can see the day and move things. AI-assisted exception handling, such as flagging consignments likely to miss their window, comes later and is covered in AI in logistics.
The driver app is the foundation, not a feature
Every downstream module depends on what happens in the field. Proof of delivery, failed-delivery reasons, cash collected, returns picked up and vehicle odometer readings all come from the driver. If the app is slow, needs signal in a basement, or asks for too much, drivers will use WhatsApp instead and the ERP will be fiction. The app has to be offline-first: it stores every action locally and syncs when there is connectivity, with no lost captures and no duplicates when the sync retries.
Doorstep digital payment through a UPI QR code reduces cash handling and makes reconciliation cleaner, because the payment confirmation arrives from the payment provider rather than from the driver. Where cash remains, the app records the amount collected against each consignment, and the branch records the deposit. The dispatch platform and offline-first driver app we built for a last-mile operator is the reference implementation.
Fleet ERP: cost per trip
Fleet management in a logistics ERP is about cost per trip, not vehicle records. Own vehicles carry fuel, maintenance, driver salary and depreciation; attached vehicles carry a per-trip or per-kilometre rate. Documents such as permits, insurance and licences need expiry alerts because a lapsed document can stop a truck at a checkpoint. When each trip records its vehicle, driver, distance, tolls and fuel, cost per trip and per consignment become a report rather than an estimate, and route profitability becomes visible.
Cash reconciliation: where the money leaks
Cash on delivery is where operators lose money quietly. A driver collects across forty stops, deposits at the branch the next day, and the branch deposits at the bank two days later. Without a system, shortfalls are discovered weeks later and disputed. The module tracks cash at three levels: consignment (what should have been collected), driver-day (what was collected and handed over), and branch (what was deposited). Each handover is recorded by both parties. Shortfalls are flagged the same day, not at month end, and digital payments are matched automatically from the provider's settlement file.
Anomaly alerts fit naturally here: a driver whose collections diverge from delivered COD value, or a branch whose deposits lag. The modelling is described in fraud and anomaly detection.
Seller settlements: the statement that must be right
Sellers are paid their COD remittance minus freight, minus deductions for returns and damages, plus or minus adjustments, and they check every line. The settlement module applies the seller's rate card to each delivered consignment, nets COD remittance against freight, produces a GST-compliant invoice and a statement, and records disputes against specific lines. It has to be auditable: every figure traces to a consignment, a proof of delivery and a cash record. That is why it is built last; without the earlier modules, the statement cannot be defended.
E-invoicing and e-way bills are part of the same finance layer; see GST and e-invoicing in custom business software for the integration.
A worked example
A regional last-mile operator ran intake through a packaged product, dispatch through a WhatsApp group per hub, and settlements through spreadsheets that two people maintained full time. Sellers disputed statements monthly, and COD shortfalls surfaced weeks late. The build started with the driver app and dispatch, because the field data was the missing foundation: offline-first, with OTP and photo proof, cash capture per consignment and a UPI QR for doorstep payment. Cash reconciliation followed, giving branch managers a same-day shortfall view. Settlements came last, generating statements that traced every line to a delivery and a cash record. The packaged product stayed for intake, integrated by API. Disputes fell to a manageable queue, and the two settlement staff moved to exception handling.
Team and timeline
A logistics ERP build needs a product lead who has ridden along with drivers, two to three engineers including one for the mobile app, a designer for the dispatch board and driver screens, and on the client side an operations head and a finance lead for settlements. Rate cards, seller lists and vehicle records are the client's data to clean before each phase.
The scope is fixed in a Sprint Zero at $3,250 / ₹2,00,000, credited to the build. ERP and CRM development starts at $28,000 / ₹18.4L per phase; the driver app is scoped as a React Native mobile module from $17,500 / ₹11.2L. Driver app and dispatch typically go live in ten to twelve weeks, with reconciliation and settlements as subsequent phases. The pricing page lists Care Plans for operations afterwards; the Standard plan's 24×5 cover suits operators with night dispatch.
Before you start: a checklist
- List every order source and the format each arrives in
- Document the hub network and where consignments change vehicles
- Write down the COD cash flow from doorstep to bank, with who signs what
- Collect seller rate cards and the deductions actually applied
- Audit driver devices and connectivity on real routes
- Decide the doorstep payment provider for UPI collection
- Agree which module goes first and what the parallel run looks like
- Name the finance owner who will sign off the first settlement statements
Glossary
- Consignment: a single shipment from a seller to a consignee, the unit everything else tracks
- Manifest: the list of consignments loaded on a vehicle for a trip
- Proof of delivery (POD): evidence a delivery happened: OTP, signature, photo, geotag
- COD: cash on delivery, collected by the driver and remitted to the seller after deductions
- Attached vehicle: a vehicle owned by a third party and paid per trip or per kilometre
- Settlement: the periodic payment and statement to a seller, netting remittance against freight
Related reading
See phased ERP delivery, our logistics industry page and custom enterprise software. For UPI collection at the doorstep, the primary source is NPCI.
Build the field app and dispatch first, reconcile cash daily, and settle sellers from evidence rather than spreadsheets.
Frequently asked questions
Should we build a logistics ERP or buy a transport management system?
▾
Buy for standard consignment tracking if your operation is simple. Build the driver app, cash reconciliation and settlement layers when COD, attached fleet or seller statements are where you lose money and time.
Why does the driver app come first?
▾
Because proof of delivery and cash data come from the field. Without a reliable, offline-first app, reconciliation and settlements have nothing trustworthy to work from.
What does logistics ERP development cost?
▾
Phase one under ERP and CRM development starts at $28,000 / ₹18.4L, with the driver app from $17,500 / ₹11.2L. A full build is priced per phase after a ten-day Sprint Zero.