Fuel bills by the gallon. Industrial gases and dry ice bill by the pound. A dispatch tool built around a single flat linehaul number cannot hold either one correctly, and for a bulk carrier, the billing problem is the whole problem. Moving the truck is straightforward. Getting the quantity off the meter, onto the invoice, and into the driver settlement without a spreadsheet in the middle is where generic software falls apart.
This guide covers how tanker carriers, fuel jobbers, and industrial gas and dry ice haulers actually bill their work, what software has to handle to keep up, and how HaulerPro approaches both pricing bases in one load. If you are running a handful of tanks and you are tired of computing linehaul in a spreadsheet before you can invoice, read on.
The Billing Problem Is the Real Problem
Ask a fuel jobber what makes dispatching hard and the answer is rarely the route. The answer is the billing. A tanker load out of the rack might split across three retail stations, with a different gallon count at each. Each stop has its own unit price in some markets, its own delivery ticket, and its own invoice line. The dispatcher who can assign the truck in two minutes may spend an hour after delivery reconstructing the invoice from a stack of paper tickets.
Generic dispatch software assumes one flat rate per load. That assumption works fine for a dry van running a lane from shipper to receiver, paid by the mile. It does not work for a fuel jobber whose revenue is a function of what came off the meter at each stop. Software that holds only a flat linehaul number has not solved the billing problem for a bulk carrier. It has relocated it. The real work moves into a spreadsheet, the total gets pasted back in, and the dispatcher now owns two data entry steps instead of one.
The same structural problem applies on the gas side. A CO2 hauler billing by the pound at a beverage plant does not have a linehaul rate in the conventional sense. The rate is per pound times the pounds delivered, and the pounds delivered are what the meter at the customer site says they are. A system that forces that hauler to compute the load total outside the software before entering a flat rate has not adapted to the work. It has adapted the carrier to the software's limitation.
The opinion stated plainly: a tanker load is a billing problem before it is a dispatch problem. Any TMS for this audience has to solve the billing correctly or it has not solved anything.
The Per-Stop Reality of Bulk Hauling
In many bulk fuel operations, a single tanker load is not a single delivery. Carriers commonly report that a load from the terminal serves multiple retail stations on one run, with the driver pulling a varying number of gallons at each drop. The invoice the customer expects itemizes every stop with its own quantity, its own price per gallon, and its own subtotal. A single lump sum is not acceptable to most fuel buyers, and a carrier that can only produce one is going to produce disputes.
The same pattern applies on dry ice runs. A carrier serving grocery distribution points in one day takes a different weight off the same load at each stop. The billing for each stop depends on the weight dropped at that stop, not on some average across the route. Per-stop quantity capture is worth more than any dashboard feature to a carrier whose revenue is a function of what came off the scale or the meter.
For cryogenic deliveries, the quantity billed commonly follows the meter reading taken at the customer site at the time of delivery. The dispatcher's estimate at booking is not the number that ends up on the invoice. If the software cannot accommodate a quantity entered at the stop level, the carrier is back to a paper process for the number that actually drives the bill.
Multi-stop loads also change how load profitability is read. A carrier who knows the total gallons or pounds delivered, the price per unit at each stop, and the miles run has the actual picture of that load. A carrier who backed into a flat linehaul number from a spreadsheet and pasted it in may have the right revenue figure, but they do not have the per-stop breakdown that tells them which drops are profitable and which are not.
Two Pricing Bases, One Dispatcher
Fuel prices by the gallon. Industrial gases and dry ice price by the pound. A dispatcher running both types of loads in the same afternoon, which is common for carriers serving a mix of petroleum and industrial gas customers, needs a system that handles both without switching modes or workarounds.
Consider a realistic afternoon: the dispatcher assigns a diesel delivery that bills by the gallon, then turns around and assigns a CO2 delivery to a beverage plant that bills by the pound. The truck, the driver, and the basic dispatch workflow are the same. The pricing basis is entirely different. A system that assumes gallons as the only unit does not fit the CO2 work. A system that assumes pounds does not fit the fuel work. A system that holds a single flat linehaul number fits neither, because in both cases the linehaul is derived from quantity times unit price, not set in advance as a flat figure.
This is not a theoretical edge case. Bulk carriers who have diversified across fuel and industrial gas haul both types of freight, often with the same power units and the same dispatch team. The software has to carry both pricing bases without requiring the dispatcher to export to a spreadsheet for one type and import the result back.
The unit also matters for the invoice. A fuel customer who receives a bill in pounds has been sent the wrong document. A gas customer who receives a bill in gallons has been sent the wrong document. The unit of measure is a billing accuracy issue, not a formatting preference.
Delivered Quantity and the Ticket That Governs
Loaded quantity and delivered quantity can differ on bulk liquid loads. Product is lost to vapor, temperature correction can affect net versus gross calculations, and in some operations the quantity metered at the delivery site is the contractually binding figure regardless of what left the terminal. The number that governs the invoice is the delivery ticket reading, not the booking estimate.
This creates a specific software requirement: the system has to allow quantity to be entered or confirmed at delivery, not locked in at dispatch. If the dispatcher enters a quantity at booking and the software treats that as the final billing number, the carrier has a problem every time the delivered quantity differs. In many bulk operations, that is most loads.
Net versus gross gallon accounting, temperature correction factors, and terminal measurement standards are areas the carrier reconciles against their own delivery tickets and their agreements with their customers. That reconciliation happens at the carrier level, not inside a TMS. What the TMS has to do is accept the number the driver reports from the ticket and use it correctly in billing. The system does not resolve measurement disputes. It records the quantity the driver enters and builds the invoice from it.
For cryogenic loads where the meter reading is taken at the customer site, the driver is the one who holds the number. A system that lets the driver enter that reading at the stop, and that builds the invoice line from what was entered, keeps the delivery ticket and the invoice in agreement without an intermediate step.
Driver Settlements on Multi-Stop Bulk Loads
A percentage-pay driver on a multi-stop fuel delivery has a reasonable expectation of understanding how the settlement figure was calculated. If the load rate was derived from gallons dropped at three stops, entered into a spreadsheet, and pasted back into the dispatch system as a flat number, the driver cannot verify the math. The driver does not have the spreadsheet. The driver has a settlement statement that shows a percentage of a number with no lineage.
That is a trust problem. In many operations, carriers commonly report that driver disputes over settlements slow the pay cycle, create friction with drivers, and cost administrative time to resolve. A settlement statement that cannot be explained from the software's own records is a recurring source of that friction.
The correct structure is for the billing computation to happen inside the dispatch system, so the linehaul the driver is paid on is derived from the same per-stop quantity and price data that produced the customer invoice. The driver's percentage, flat per-load rate, or per-mile rate applies to a number that has a documented source. If a driver asks how the settlement figure was reached from the gallons dropped on a four-stop run, there is an answer in the system rather than a trip to a spreadsheet.
No per-gallon or per-pound driver pay basis exists in HaulerPro. Driver pay derives from the load rate. Percentage-pay, per-load, and per-mile drivers all settle from the derived rate that the per-stop quantity entries produce. The pay basis is the load rate. The load rate comes from the per-stop math. That chain is visible in the system.
Proof of Delivery from the Field
Delivery and meter tickets are paper at many terminals and plants. In many bulk operations, the proof of delivery reaches the office days after the drop, because the driver brings paper tickets back at the end of a run or at the end of the week. A carrier cannot invoice until the POD is in hand, and a POD that arrives three days after delivery is three days of cash flow the carrier does not have.
Phone scanning changes that timing. A driver who photographs the delivery ticket at the stop, attached to the specific load in the dispatch app, has put the document in the office's hands at the time of delivery rather than at the end of the week. The dispatcher can review it, the billing team can pull it, and the invoice can go out without waiting for the driver to bring paper back to the yard.
Proof of delivery documents scanned through HaulerPro attach to the load. When the invoice is generated from the load, the POD is already there. The document that validates the delivery and the invoice that bills for it travel together, which is what customers expect when they ask for documentation with the invoice.
The practical benefit for a bulk carrier is not abstract. A fuel jobber who can invoice the day after delivery, rather than waiting a week for paper tickets, is running a tighter operation. The POD scan is one step the driver takes at the stop. The payoff is days removed from the invoice cycle.
IFTA for Tanker Carriers
Bulk carriers running interstate owe IFTA on the same quarterly cycle as every other carrier. A tanker-specific billing workflow does nothing to reduce that obligation. The truck crossed state lines. The fuel tax follows.
IFTA requires a carrier to report miles driven in each member jurisdiction and gallons of fuel purchased in each jurisdiction. The tax owed per jurisdiction is calculated from those two numbers plus the jurisdiction's tax rate, with credit applied for fuel tax already paid at the pump. Missing or incomplete mileage records typically result in assessment at an unfavorable default rate, so the record-keeping obligation is real even for small operations.
Carriers commonly report that IFTA preparation is time-consuming when miles per jurisdiction have to be reconstructed from trip logs or odometer readings at the end of the quarter. The math is not complicated, but the data collection is, especially when routes cross multiple state lines on a single load.
HaulerPro captures per-jurisdiction miles automatically from dispatched loads using routing data. The coverage is the 48 contiguous states plus the District of Columbia. At the end of the quarter, the miles are aggregated by jurisdiction in the quarterly IFTA panel. The carrier exports the per-jurisdiction mileage data from that panel and uses it as input when filing with their base state's administering agency. Carriers should verify current filing requirements and procedures with their base state, as requirements are subject to change.
Fuel purchase records are a separate part of IFTA. Drivers enter fuel purchases as expense entries tied to loads. Those records are stored in HaulerPro and available for reference at filing time. The mileage and the fuel data are both in the system, which reduces the quarter-end reconstruction effort.
HaulerPro does not produce a filing-ready IFTA return. The exported mileage data is input to the carrier's filing process. The carrier, or their accountant, completes the filing with their base state's administering agency. IFTA coverage does not extend to Canadian provinces, Alaska, or Hawaii.
Operating Under Hazmat Rules
Fuel haulers, industrial gas carriers, and cryogenic liquid operators run under federal hazmat regulations. Placarding requirements, shipping papers, driver endorsement requirements, emergency response information, and DOT hazmat rules govern a significant part of this audience's daily operation. That is a factual description of the compliance environment these carriers work in.
HaulerPro does not provide hazmat compliance features or tooling of any kind. No placard guidance, no shipping paper generation, no hazmat manifest handling, no endorsement tracking, no emergency response documentation. A carrier looking for software that manages hazmat compliance will need dedicated tools for that work.
What HaulerPro handles is the dispatch, billing, settlement, and mileage tracking side of the operation. For a bulk carrier, those are the functions that most directly affect daily cash flow and administrative workload. Hazmat compliance sits alongside that work, handled through the carrier's own procedures, their safety officer, and the regulatory requirements that apply to their specific commodities and operations.
Acknowledging this cleanly matters. A software vendor that implies their dispatch tool handles hazmat compliance is overstating what any general TMS does. A carrier who reads that framing and acts on it has been misled. This page will not do that.
What to Look for in a TMS for Bulk Hauling
If you are evaluating dispatch software as a fuel jobber or bulk liquid carrier, the questions that separate a tool built for this work from one that is not come down to billing structure, per-stop handling, and settlement transparency. Here is how to evaluate them:
Billing structure
Can the system hold a rate in gallons or pounds, not just a flat dollar amount? Can it derive the linehaul from quantity times unit price at the load level, so the invoice is computed inside the software rather than outside it? If the answer is no, the billing problem is not solved. It is relocated.
Per-stop quantity capture
Does the system allow quantity and unit price to be entered per stop, not just at the load level? A fuel delivery to three retail stations is three billing events. The system has to hold three quantities and produce three invoice lines. A single-stop load model does not fit this work.
Unit flexibility
Does the system support gallons and pounds as distinct units? A carrier running both fuel and industrial gas deliveries on the same day needs both. A system that assumes gallons as the only unit, or that uses generic "volume" or "units" without supporting the actual measure, has not adapted to the work.
Settlement traceability
When a percentage-pay driver asks how their settlement figure was derived, can the dispatcher show the per-stop quantity entries that produced the load rate? A settlement that cannot be traced to documented quantities is a recurring source of driver disputes.
Document handling
Can the driver scan and attach delivery tickets and meter tickets at the stop, attached to the specific load, without routing through a separate app or a shared inbox? The closer document capture is to the delivery moment, the shorter the invoice cycle.
IFTA mileage capture
Does the system capture per-jurisdiction miles from actual routes, or does the carrier reconstruct them from trip logs at quarter end? Automated mileage capture is worth disproportionate time savings at filing time.
Setup cost and complexity
Many enterprise TMS products are designed for fleet operations well above 15 trucks and carry implementation costs, onboarding fees, and integration requirements that do not scale down to a six-truck fuel operation. Bulk carriers with small fleets are commonly pushed toward these products because small-carrier tools assume a flat rate per load. That assumption, not fleet size, is the actual gap. The right tool fits the billing structure of the work, not just the size of the fleet.
How HaulerPro Handles Bulk Carrier Billing
HaulerPro is built for independent carriers and small fleets running the full range of equipment. The platform handles fuel jobbers, industrial gas and dry ice haulers, and bulk liquid carriers through a Tanker Mode that changes how loads are structured at the billing level.
Tanker Mode and per-stop quantity
When Tanker Mode is toggled on for a load, the load captures quantity and unit price per stop rather than a single flat linehaul amount. The dispatcher enters the unit, gallons or pounds, and the price per unit for each stop. The per-stop totals aggregate automatically to produce the load linehaul and the invoice line items. No spreadsheet. No paste-in. The billing math happens inside the load record.
That structure covers the three-station fuel delivery: each station gets its own stop with its own gallon count and unit price, and the invoice shows three lines. It covers the CO2 delivery to the beverage plant: pounds delivered times price per pound, producing one stop line on the load and one line on the invoice. It covers the dry ice run with several grocery distribution points: each stop takes a different weight, each stop produces its own invoice line.
The unit of measure is gallons, pounds, or each, entered per stop. The system does not assume gallons. It accepts the unit that matches the load.
Driver settlements from derived rates
Because the linehaul is derived inside the load from the per-stop quantity entries, driver settlements consume that derived rate directly. A percentage-pay driver on a four-stop fuel delivery settles on a percentage of the load rate that was computed from the gallons dropped at each stop. The per-stop data is in the system. The load rate is in the system. The settlement is in the system. When a driver asks how their settlement figure was reached from the gallons dropped, the dispatcher has an answer in the software, not a reference to a spreadsheet that may no longer exist.
Per-load and per-mile pay drivers settle from the same derived rate. The pay basis varies. The source of the rate does not.
Document scanning
Drivers scan delivery tickets and meter tickets from the field using the driver app. Scanned documents attach to the specific load the driver is working on. Proof of delivery auto-attaches to the invoice when the invoice is generated. The document that validates the delivery and the invoice that bills for it are linked without a separate filing step.
IFTA mileage across the contiguous states
Per-jurisdiction miles are captured automatically from dispatched loads for the 48 contiguous states and the District of Columbia. At quarter end, the mileage data is aggregated in the quarterly IFTA panel and available for export. That export is the carrier's input to their state IFTA filing process, reducing the data collection burden without producing the filing itself.
What HaulerPro does not do for this audience
No hazmat compliance tooling of any kind. No tank washout tracking. No terminal or rack system integration. No Canadian provinces, Alaska, or Hawaii in IFTA coverage. No IRP reporting. Load visibility comes from driver and dispatcher status updates, not from GPS or real-time location services. These boundaries matter. A carrier who knows what the software does and does not handle can plan their operation accordingly.
Setup and pricing
HaulerPro starts at $95 per month for up to 5 users, which includes managers, dispatchers, and driver logins. A 15-user plan runs $250 per month. Pricing is per user, not per truck. The 14-day free trial requires no credit card. First load live in under 10 minutes from signup.
Support is founder-led support from someone who built the software around how carriers actually work.
HaulerPro is built for the carriers who built themselves. That includes the fuel jobber running six tanks out of a regional terminal, the industrial gas carrier with a handful of cryogenic trailers, and the bulk liquid operator who has been managing per-stop billing in a spreadsheet because no small-carrier tool handled it correctly. The spreadsheet workaround is not a solution. It is a symptom of software that was not built for this work.
If you haul bulk and you bill by the gallon or by the pound, start your 14-day free trial and see how Tanker Mode handles the billing structure of your actual loads. No credit card required. No onboarding fee. No implementation consultant standing between you and your first dispatched load.