In a typical transport business, one run gets typed in again at almost every step: from the allocator's run sheet to the driver's docket, from the docket into payroll or an owner-driver payment, from the docket again into the customer invoice, with the fuel levy worked out in a separate spreadsheet. When the workflow is joined up, the run is created once, the driver confirms what actually happened, and that one record drives driver pay, the customer invoice and the levy. People still check exceptions and sign off pay. They stop retyping dockets.
This post is part of our series One workflow, one business like yours. Owners often say what would help most is a working example in a business like theirs. So each post follows one workflow through one typical business. The business below is a composite: it's put together from how many general freight and bulk carriers work, not a story about one client, and there are no invented figures in it.
The business and its systems
Picture a carrier running a mix of company trucks with employed drivers and a few owner-drivers, doing regular runs for a set of contract customers plus casual work. The office is an allocator, someone doing accounts and payroll, an operations manager and the owner.
The systems are ordinary:
- a dispatch or transport management system (TMS), or a run sheet spreadsheet
- paper dockets or con notes, sometimes photos from the driver's phone, sometimes a driver app
- a rate card spreadsheet per customer, including the fuel levy
- payroll in Xero, MYOB or a separate payroll system, with timesheets from logbooks or the driver app
- owner-driver payments by RCTI (a recipient-created tax invoice: you create the invoice on the subcontractor's behalf and pay it)
- Xero or MYOB for customer invoices and the accounts
What happens today, step by step
- Allocation, Sunday night or Monday morning. The allocator builds the week's run sheets in the TMS or a spreadsheet: customer, pickups, drops, truck, driver.
- The run. The driver does the work. Things change: an extra drop, two hours waiting at a DC, a pallet exchange, a tail-lift delivery. The driver writes it on the docket, if they remember.
- Dockets back. Paper dockets arrive in a pile at the end of the week, some in the truck's door pocket for longer. The office matches them to the run sheet by hand and chases the missing ones.
- Driver pay. Payroll types hours from logbooks or timesheets into the payroll system, checking award allowances and overtime. For owner-drivers, someone works out each run's payment from the subbie rate sheet and types up the RCTIs.
- Customer invoices. Accounts types the same dockets again into Xero or MYOB as invoice lines, using the customer's rate card. Waiting time and extras only get charged if they're on the docket and someone notices them.
- Fuel levy. When the diesel price moves, the owner or ops manager updates the levy in a spreadsheet and emails customers. Whether every invoice and every owner-driver rate picks up the new levy depends on who remembers.
- The owner, at night. Before invoices go out, the owner flicks through them against the dockets, because they've been caught before by a customer still on last quarter's rate.
The same run has now been typed at least three times: run sheet, pay and invoice. That's double entry (the same information typed into more than one system), and every copy is made by a different person from a different piece of paper.
Where it breaks
- Retyping. Hours, drops and extras are copied from paper twice: once for pay, once for billing. A mistake in one rarely gets fixed in the other.
- Waiting. Invoicing waits for dockets. Last week's work isn't billed until the paperwork is complete, so cash comes in later than it should. Our post on proof of delivery to invoice goes into this step.
- Revenue that never gets charged. Waiting time, extra drops and surcharges noted on a docket nobody reads don't appear on the invoice. That money is never recorded as a loss. It just never arrives.
- Levies out of step. A fuel levy change has to reach customer invoices and owner-driver rates together. When it lives in a spreadsheet, it reaches some and not others. See fuel levy changes and owner-driver rates.
- Pay and super under pressure. Pay errors cause disputes with drivers, and under Payday Super, employee super now has to reach the fund within days of each payday. Some owner-drivers can count as employees for super purposes too. Our post on owner-driver super under Payday Super explains when.
- No picture of profit per run. Because pay and revenue are captured separately, nobody can line them up against the same run without a spreadsheet afternoon. More on that in why you can't see profit per run.
What it looks like when it's joined up
Same business, same people, mostly the same software. What changes is that the run is one record from allocation to invoice.
- Allocation. The allocator builds runs in the TMS as now. Each run carries the customer, the truck and the driver or owner-driver.
- The run. The driver confirms each drop on their phone: a photo of the signed POD (proof of delivery), the arrival and departure times, and a tap for any extra (waiting time, extra drop, tail-lift). If the business stays on paper dockets, scanned dockets can be read automatically with AI doing the first pass and a person checking.
- Exceptions only. The office sees a list of runs with something unusual: missing POD, waiting time above the free period, an extra not on the run sheet. They check those, not every docket.
- Driver pay. Confirmed hours flow to payroll as timesheets for employed drivers. Owner-driver payments and RCTIs are calculated from completed runs and the current subbie rates, using RCTI automation. The payroll person reviews and approves the pay run, as now.
- Customer invoices. The same completed runs create invoice lines in Xero or MYOB using each customer's current rate card, with extras and the current fuel levy applied. Accounts reviews and sends.
- Fuel levy. The levy is set in one place with an effective date. From that date it applies to customer invoices and owner-driver rates together, and anything charged at the old rate shows up as an exception.
- The numbers. Because pay and revenue come from the same run records, on Monday you can see last week's revenue and direct cost for each run, truck and customer.
Who still checks what:
- The allocator or ops manager reviews the exception list daily.
- Payroll approves every pay run and every RCTI batch.
- Accounts reviews invoices before they're sent.
- The owner approves rate card and fuel levy changes, and looks at the weekly run margin report instead of reading invoices at night.
You don't need to replace your TMS to get here. Often it's a driver app or docket capture step, one connection to payroll and one to the accounts, and the rates held in one place. Our transport and logistics page covers the systems we usually connect.
What to measure before and after
Count these in your own business for two or three weeks before anything changes, then count the same things again a couple of months after. Your own numbers are the only ones that matter.
- Times each run is typed between the run sheet and the invoice.
- Days from delivery to invoice, on average and for the slowest customers.
- Dockets missing or late at the end of each week.
- Hours spent each week matching dockets, preparing pay and RCTIs, and typing invoices.
- Extras on dockets that didn't make it to the invoice, found by checking a sample of past runs.
- Pay corrections and driver queries after each pay run.
- Invoices at the wrong rate or levy, and credit notes issued.
The free Admin Time Count gives you a quick starting estimate of the time your office spends re-keying and chasing.
The next step: one workflow, done properly
Most carriers don't need a new system for everything. Pick the workflow that costs you most (often docket to invoice, sometimes docket to driver pay) and fix that first.
Our Process & Systems Audit ($5,000) maps how runs, dockets, pay and invoices really move through your systems, counts a few baseline measures like the ones above before anything changes, and gives you a written report on what to fix first. If you then go ahead, we fix that one workflow as a First Workflow Sprint: a fixed-scope project with a fixed quote and timeframe, handed over with written steps your team can follow, and you own everything we build. Part of your audit fee comes off the sprint.
Frequently asked questions
Is this example a real client?
No. It's a typical example built from how many transport businesses work, so you can compare it with your own. It doesn't describe a specific client, and the steps will vary with your customers, award and systems.
Do our drivers have to use an app?
No. An app makes it faster, but scanned or photographed paper dockets can be read automatically, with a person checking each one. The key is that the docket becomes one record that pay and invoicing both use.
Can the fuel levy be different for each customer?
Yes. Many carriers have different levy arrangements by contract. Those rules can be held per customer with effective dates, so the right levy applies automatically and changes are recorded.
Will this work with our payroll system?
Most payroll systems used in Australia, including Xero and MYOB payroll, can accept timesheets from another system. Award interpretation stays in payroll (or a rostering tool) where it belongs; the change is that the hours arrive without retyping.
How long does fixing one workflow like this take?
It depends on your systems, how many customers and rate cards you have, and whether drivers move to an app. We scope it first and give you a fixed quote and timeframe. Single-workflow projects are usually measured in weeks, not months.
If your dockets are typed out more times than they should be, book a free initial chat and we'll talk it through.