Grameenphone Ltd. issued a requirement for an automated fleet billing system. Rather than answer with a brochure, we took every single line of it and checked it against VMS Pro — our live, in-production fleet platform. This is that assessment: what already exists, what we build, and the two problems that actually decide whether a project like this succeeds.
Project Simplex is an automated fleet billing system. Employees raise a vehicle requisition in OneGP, a vehicle is assigned, the trip runs, and the fleet system must then calculate the charge automatically and roll every trip into one consolidated monthly invoice — with the right rate per vehicle category and fuel type, overtime rules, exception flags, a full report suite, and two-way API integration with OneGP.
It is a substantial, well-specified requirement: master data, trip data, billing logic, billing rules, exception handling, integration, reports, security and audit — 90 individual line items in total.
Anyone can answer an RFP with "yes, we support that." We did the opposite: every requirement line was verified directly against the running VMS Pro system, and marked with one of three honest states. Where something only partly exists, we say so. Where it doesn't exist at all, we say that too.
The complete assessment. Filter by status or by section — the counts update live. This is the whole answer, with nothing hidden behind a summary.
Reading the two numbers. By item count, 47 of 90 lines are fully available and 74 of 90 already have a foundation in place. The headline ~65% is effort-weighted across the actual build — a fair reflection of how much work is already done, not just how many boxes are ticked.
Neither of them is "can you build it?" — that part is answered above. The risks that sink enterprise billing projects are almost never the code. These are the two we flagged, in writing, before quoting a timeline.
Roughly one third of the proposed work — the inbound and outbound OneGP APIs — depends entirely on cooperation from the OneGP side. We can build our half in a known amount of time. What we cannot control is the other half of the handshake.
Four things need confirming before any timeline is real:
It looks like a data question. It isn't. Our platform already includes a GPS-versus-logbook variance report — and it exists precisely because, in the real world, those two numbers do not always agree.
If the policy on which source constitutes billable distance — and what percentage of variance is acceptable — is not settled in the contract in advance, then disputes with vendors are likely in every single billing cycle. Not once. Every month, forever.
Reading the requirement closely, we noticed something that reframes the whole project: the billing described is not what a company charges its customers. It is what the company pays its vehicle owners and vendors. The evidence is explicit in the document itself — Partner and Vendor in the master data, Monthly Fixed Rent and Per KM Rate held per vehicle, and a "Vendor-wise Billing Report" in the report list.
That distinction is not academic. The hardest and most risk-bearing part of building a billing system is establishing the correct direction and shape of the data model. Get it backwards and every downstream report, rule and reconciliation is wrong — and you find out late.
What we build on top of what already runs. Estimates assume one dedicated developer and are indicative — they firm up once the two preconditions above are resolved.
The principal work: APIs to receive requisition, assignment and trip data, plus invoice and payment status push-back.
A new rate master and resolver, operating alongside the existing per-vehicle rates.
Automatic charge calculation on trip completion, with a configurable overtime rate master.
Field separation and new charge types; also requires changes to the driver app.
Vehicle/driver mismatch, duplicate ticket ID, and missing trip start/end detection.
Overtime Cost, Category-wise Cost, and Department-wise Utilization.
Requires cooperation from the OneGP team.
The 65%. None of this is a promise — it is running in production today, and we offered a live demonstration so it can be verified first-hand rather than taken on trust.
Period-wise consolidation with per-vehicle line items, totals, paid/due and payment tracking.
Configurable ignition litre and rate, flowing into the monthly bill.
Full itemised cost lines against each vehicle and period.
Identifies where tracked distance and driver-logged distance disagree.
Rent basis, duty days, minimum guaranteed days and garage rules.
Near-complete against the requirement — categories, fuel slots, documents and expiry.
Fully configurable roles; the specified roles are a configuration exercise, not a build.
Vehicle-wise and vendor-wise billing, distance, driver utilization — with PDF/print.
Review the OneGP API documentation and assess the integration surface together.
Written confirmation of the distance source and acceptable variance threshold.
Show the existing billing modules, so the 65% can be verified first-hand.
Present the final scope, a committed timeline and the commercial proposal.
Automated fleet billing, vendor-payable reconciliation, requisition-to-invoice integration with an internal system, GPS-versus-logbook disputes — these are not unique to one telecom operator. Any enterprise running a large vendor-supplied fleet eventually hits exactly this wall.
The method here is repeatable: assess the requirement line by line against a platform that already exists, be honest about the gaps, name the dependency and commercial risks before quoting, and build only the delta. It turns a year-long programme into a quarter — and it is how we would approach the same requirement for any organisation.
If your organisation is trying to automate vendor billing across a large fleet, the problem is almost certainly solvable — and probably faster than you have been told.
Talk to me about it →