Engineering
How we built a billing engine that never loses a cent
Leasing invoices look simple until you meet partial months, mileage true-ups and three kinds of sales tax. Here's how FleetForge keeps every cent accounted for.
Avi Technologies · · 6 min read
Most billing bugs aren’t dramatic. Nobody loses $10,000 in one go. They lose a cent here on a rounding step, a day there on a partial month, a mileage charge that was estimated and never trued up. Over a few hundred invoices a year, those small leaks add up to real money and, worse, to customers who stop trusting the numbers.
When we built FleetForge, our leasing and accounting platform for truck and equipment rental companies, we treated the billing engine as the part of the system that’s never allowed to be “nearly right”. This is how it works and why.
Rule one: money is never a floating-point number
Computers store most decimals as approximations. Ask a typical programming language to add 0.1 and 0.2 and you get 0.30000000000000004. That’s harmless in a game and dangerous on an invoice. Multiply it by a monthly rate, a tax rate and a currency conversion and the error moves into the cents column.
FleetForge never does money maths with floating-point numbers. Every amount is carried as a decimal string and calculated with arbitrary-precision arithmetic (PHP’s bcmath), with an explicit number of decimal places at every step. Rates, distances, engine hours, taxes and totals all go through the same discipline.
If a number ends up on an invoice, it was calculated exactly — not approximately and then rounded to look right.
Rule two: one engine, one writer
Billing logic tends to spread. A bit of proration in the lease screen, a tax calculation in the PDF generator, a “quick fix” in a report. Then two parts of the system disagree about what a customer owes.
In FleetForge, exactly one class writes invoices to the database. It calls a dedicated rental engine for the rent maths, a tax calculator for tax and a late-fee engine for late fees, and nothing else in the system is allowed to compute a billed amount. Every invoice is built in the same fixed order:
- Base rental for the period
- Mileage lines — pre-charges, usage, and any drawdown credits
- Add-ons such as insurance, warranty and GPS
- Damage charges, if any
- Subtotal, with credit lines netted correctly
- Discount (percentage or flat)
- Tax on the net amount — GST, PST or HST per the lease’s rules
- Total, then credits applied, then the balance due
Because the order never changes, two invoices with the same inputs always produce the same result, and an accountant can follow any line back to its source.
Rule three: bill the running truth, not the month in isolation
The classic way to bill a lease is month by month: work out what this month costs, invoice it, move on. The trouble is that each month is calculated independently, so small differences never get corrected. A partial month bills a little high, the next bills a little low, and the lease ends a few dollars out.
FleetForge’s rental engine uses running reconciliation instead. For every invoice it asks two questions:
- What should this lease have cost from its first day to the end of this period?
- What have we already billed?
The invoice is the difference. If an earlier period was ever slightly off, the next invoice corrects it automatically. At the end of the lease, the total billed matches the correct total for the whole term, down to the cent.
Short periods and partial months
Short rentals have their own ladder of rules, all driven by the rates on the lease:
| Period length | How it’s billed |
|---|---|
| Up to 7 days | The cheaper of the daily rate × days or the weekly rate |
| 8 days to under a month | Weekly maths, capped at the monthly rate |
| A calendar month or less | Flat monthly rate |
Days are counted inclusively and consistently everywhere. And the rates themselves are locked onto the lease when it’s signed. If you raise your standard rates next spring, existing leases keep billing at the price the customer agreed to.
Rule four: usage gets trued up, not guessed
Mileage is where leasing billing usually goes wrong. Some operators charge an estimate and forget it. Others wait for the odometer at the end and send one large surprise.
FleetForge supports both models and reconciles either way:
- Estimated mileage: the customer is billed an estimate each period, then a running true-up compares cumulative actual distance against everything billed so far, adding or crediting the difference.
- Pre-charged mileage: an allowance is charged up front, drawn down as the truck is used, and anything unused is refunded at close as a credit or cash.
Actual distance comes from the odometer chain, from Samsara GPS where a unit is tracked, or from the closing reading. Engine-hour billing works the same way for equipment that’s measured in hours.
Rule five: sent invoices never change
Once an invoice is sent, its financial fields are frozen: subtotal, taxes, totals, line items, dates and the snapshots of the customer and unit at the time. The system rejects any attempt to edit them.
Mistakes still happen, of course. The fix is a credit note or a void-and-reissue, both of which leave a full audit trail. Invoice numbers are sequential within each year with no gaps and no reuse, allocated inside the same database transaction that creates the invoice, so two people generating invoices at the same moment can’t collide. Voided invoices keep their number, and invoices are never deleted.
That’s partly good practice and partly about the Canada Revenue Agency: a gap-free, immutable trail is far easier to defend than a spreadsheet that was quietly edited.
Rule six: tax is a rule, not a guess
Canadian sales tax is genuinely fiddly. FleetForge applies GST, PST or HST from a rates table by jurisdiction, and the jurisdiction is set per lease (defaulting to the customer’s province but overridable when equipment works across a border). GST and PST exemptions are tracked separately, because some customers are exempt from one and not the other. Exemption certificates carry expiry dates, and when one lapses the system treats the customer as taxable and flags it rather than quietly continuing.
Tax is calculated when the invoice is created, on the net amount after credits and discounts, and frozen with the invoice.
Rule seven: prove it, every time
Good intentions don’t keep a billing engine correct. Tests do. FleetForge ships with invariant checks that run against the live data shape and fail loudly when something impossible appears, such as:
- a draft invoice with a zero subtotal and no legitimate reason for it,
- a lease whose rate tiers have a hole (a daily rate but no monthly rate),
- usage billed against a lease that has no usage rate,
- a closed lease with a leftover balance that was never settled.
Alongside those sit stress tests for the trickiest flows, such as mileage drawdown and refunds at close, plus a schema parity check so the code and the database never drift apart. They run before changes go live, not after a customer notices.
What this means for you
If you lease or rent equipment, your invoices are your relationship with your customers. When they’re exact and explainable, disputes disappear and month-end gets quiet. When they’re nearly right, everything downstream, from collections to your books to your accountant’s fees, gets harder.
That’s the standard we build to. If your billing lives in spreadsheets, or in a system nobody fully trusts, tell us about it.
