Case Study: Transport Company Automates Lorry Receipts and Reduces Billing Cycle by 3 Days

The Client

A mid-size road transport company operating across three states, running a fleet of roughly 80 vehicles and handling freight for manufacturing and FMCG clients. Like most transport operators of this size, freight documentation, particularly lorry receipts (LRs), was almost entirely manual.

The Challenge

Every trip generated a physical lorry receipt filled out by hand at the loading point: consignor and consignee details, freight charges, vehicle number, and delivery terms. Drivers carried these documents through the trip, and once delivery was confirmed, the paperwork made its way back to the billing office, sometimes days or weeks later, depending on the route and how quickly drivers returned.

This created a chain of downstream problems. Billing couldn't raise an invoice until the physical LR was back in hand, which meant freight already delivered sat unbilled for a week or more in many cases. Data entry errors were common: handwriting misread, freight amounts transposed, vehicle numbers mistyped, and each error meant a corrected invoice and a delayed payment. Clients frequently disputed freight charges because there was no easy way to cross-check an invoice against the original LR without physically locating the paper document. And the finance team had no real-time visibility into how much freight was pending invoicing at any given point, making cash flow forecasting mostly guesswork.

The company estimated that its average billing cycle, from delivery to invoice raised, was running close to 12 to 14 days, driven almost entirely by how long it took physical LRs to reach the billing office and get processed.

What They Tried Before

The company had experimented with asking drivers to send photos of LRs over WhatsApp as a stopgap. It helped a little: billing staff could at least see the freight details earlier. But someone still had to manually re-key every field from the photo into the accounting system, so the data entry bottleneck remained. It reduced the wait time but didn't fix the underlying process.

The Solution: Digitizing Lorry Receipts Inside Odoo

Sunray Datalinks implemented a custom Odoo-based solution built around digital lorry receipt capture and automated billing, tailored to how this company's operations actually ran.

Digital LR Creation at the Point of Loading

Instead of a handwritten paper form, loading point staff now create the LR directly inside a mobile-friendly Odoo interface. Vehicle number, consignor and consignee details, and freight terms are entered once, digitally, at the source. Where trip details are already known in advance, for recurring routes with regular clients, much of this data pre-populates automatically.

Automated Freight Calculation

Freight charges are calculated automatically based on pre-configured rate cards by route, vehicle type, and client agreement, removing manual calculation errors that previously required correction after the fact.

Real-Time Delivery Confirmation

When a shipment is delivered, confirmation is captured digitally, with proof of delivery, and immediately updates the LR status in the system. Billing no longer waits for a physical document to travel back through the network; the trigger for invoicing is the digital delivery confirmation itself.

Automatic Invoice Generation

Once delivery is confirmed, Odoo automatically generates the invoice using the freight details already captured on the digital LR, matched against the client's rate agreement. What used to require someone manually re-keying freight data from a paper LR into the accounting system now happens without manual intervention.

Centralized LR and Invoice Records

Every LR, along with its corresponding invoice and proof of delivery, is stored in one searchable system. When a client disputes a charge, billing staff can pull up the original LR and delivery confirmation in seconds instead of tracking down a physical file.

Rolling It Out Across the Fleet

The rollout didn't happen all at once. Sunray Datalinks and the transport company agreed on a phased approach, starting with two of the company's busiest routes before extending to the full network. This gave loading point staff and drivers time to get comfortable with the new digital process while any configuration gaps, missing rate cards, unusual delivery terms for specific clients, could be caught and fixed on a smaller scale rather than across the entire fleet at once.

Driver adoption was the part the company was most concerned about going in. Many drivers had spent years working entirely with paper LRs, and the shift to digital delivery confirmation on a mobile device was a real change to their daily routine. In practice, the transition went smoother than expected once drivers realized the digital process was actually faster at the loading point than filling out a paper form by hand, and that confirming delivery took a photo and a tap rather than carrying documents back over long routes.

Loading point staff needed slightly more hands-on training, since they were the ones entering the bulk of the trip details into the system. Sunray ran on-site training sessions at each loading point during the rollout phase, followed by a support window during the first few weeks to handle questions as real trips started flowing through the new process.

Results

Three months after go-live, the company measured the impact against its previous baseline.

Beyond the numbers, the company also noted a less quantifiable but real benefit: fewer disputes escalating to management. When a client questioned a freight charge, billing staff could resolve it themselves on the same call by pulling up the digital LR and delivery proof, instead of the query sitting unresolved for days while someone tracked down a physical file.

What the Transport Manager Said

Why This Matters for Other Transport Operators

The core problem this company faced, billing delayed by the physical movement of paperwork, is close to universal in road transport, particularly for operators running multi-state routes where LRs can take days to physically return to the billing office. Digitizing the point of LR creation, rather than just digitizing the invoice afterward, is what actually removes the bottleneck. A photo of a paper LR sent over WhatsApp still requires manual re-entry; a digitally created LR doesn't.

For transport companies still relying on physical lorry receipts and manual invoice generation, the billing cycle improvement here is a useful benchmark. The bigger the fleet and the longer the routes, the more this delay can compound across the operation.

Where This Fits Into a Broader Transport ERP Setup

Digital LR automation on its own solves the billing delay problem, but it's typically one part of a wider Odoo implementation for transport operators. Route planning, fuel and toll expense tracking, driver payment reconciliation, and compliance documentation, like e-way bills and permits, all benefit from sitting in the same system rather than being managed through separate tools or spreadsheets.

Companies that start with LR digitization, as this one did, can extend the same system to cover these other areas once the initial benefits are clear and the team is comfortable working digitally.

Lessons From the Rollout

A few things stood out from this implementation that are worth passing on to other transport operators considering a similar move. Starting with the busiest routes first, rather than the full fleet at once, made it far easier to catch configuration issues, like an incorrect rate card or an unusual client-specific delivery term, before they affected a large volume of trips.

Involving loading point staff early, rather than presenting the new process as a finished system, also made adoption noticeably smoother, since their day-to-day feedback shaped small but meaningful interface adjustments before the wider rollout.

The company also found it useful to keep a short transition period where both digital and a lightweight paper backup were available at each loading point, mainly to build driver confidence in the new process rather than out of any real technical necessity. Within the first month, the paper backup was barely being used, but having it available reduced early resistance from drivers who were naturally cautious about a new system affecting whether they'd be paid correctly for a trip.

Timeline and Investment

From initial requirement discussions to the first two routes going live took a little under six weeks, with the remaining fleet onboarded over the following two months as staff across other loading points completed training.

This phased timeline is fairly typical for a transport ERP project of this scope, since most of the early weeks go into configuring rate cards accurately across the company's full range of clients and routes, which is where a rushed implementation tends to create problems later.

Looking Ahead

With billing now running largely on autopilot, the company's finance team has shifted its focus from chasing paperwork to reviewing aging reports and following up on actual payment delays, rather than delays caused by internal processing.

The next phase under discussion is extending the same digital-first approach to driver payment reconciliation, tying trip completion and freight collection more directly to how drivers are paid, closing another gap that historically relied on manual matching between trip sheets and payment records.

Key Takeaways

For any road transport operator still running on physical lorry receipts, the pattern in this case study is worth paying attention to. The billing delay wasn't caused by the finance team being slow; it was caused by information trapped on paper that had to physically travel before anyone could act on it.

Digitizing the point of capture, not just the invoice at the end, is what actually closes that gap. A three-day improvement in billing cycle may sound modest on paper, but across an 80-vehicle fleet running continuous freight, that translates into a meaningful, recurring improvement in cash flow, month after month.