ARC
A vehicle fleet operation in Australia, and the system that keeps its money straight. Per-vehicle records, maintenance and a running ledger — monthly charges, payments and balances, reconciled to the cent.
- Vehicle records
- Maintenance tracking
- Running ledger
- Monthly charge generation
- Receivables
01 — The Problem
Knowing what a fleet earns is not the same as knowing what it is owed
ARC runs a vehicle fleet. Each vehicle carries its own records and its own maintenance history, and each one generates a monthly charge against whoever is responsible for it. Payments come in against those charges, and the difference is what ARC is owed.
The operator needs three things at any moment: what is outstanding, what has been collected this month, and what is overdue.
The instinctive build is a payments table — who paid, how much, when. It records history accurately and answers none of the questions above, because every one of them is about a balance rather than a transaction.
Money owed is not a row you can look up. It is what remains after everything charged and everything paid against a specific vehicle has been accounted for, and a system that stores payments without modelling that arrives at the answer by arithmetic performed hopefully, in a spreadsheet, later.
02 — The Approach
One ledger, and everything else is a view of it
The whole design follows from refusing to let any number in this system be calculated twice.
Make the vehicle the unit of account
The ledger is keyed to the vehicle, not the client. A charge, a payment and a balance all belong to a registration and a billing month — SKY-101, August — before they belong to anybody’s account.
WhyA client can hold more than one vehicle, and vehicles move between clients over their life. Aggregating money at the client level first makes the common question — which vehicle is behind, and since when — something you have to reconstruct. Aggregating at the vehicle level makes the client view a sum, which is the easy direction to travel.
Derive every headline figure from that ledger
Outstanding, collected this month, overdue and the receivables position are not separately maintained counters. They are projections of the same entries the per-vehicle ledger is built from.
WhyFour numbers computed independently are four numbers that will eventually disagree, and the day they do, nobody trusts any of them again. Derived from one ledger they cannot contradict each other, because there is nothing for them to contradict.
Put the collections queue where the dashboard starts
The dashboard leads with what needs attention — who owes what, oldest debt first — rather than with a chart of revenue.
WhyRevenue is a number you review. Receivables are a list you work. The operator opening this in the morning has one job, and the interface should already be pointed at it rather than making them go looking.
03 — Key Technical Challenges
Two problems worth solving properly
A ledger is a different thing from a list of payments
Storing payments is easy and almost right, which is what makes it dangerous. You end up with a complete and accurate record from which the single most important number in the business — how much is owed, right now — cannot be read directly.
So it gets worked out somewhere else. And once the real answer lives in a spreadsheet beside the system, the system has stopped being the source of truth no matter what it contains.
Every vehicle carries a running ledger of signed entries: a monthly charge adds, a payment received subtracts, and the balance is what those entries come to. The state of an account is not stored as an opinion — it falls out of the entries.
That is why a settled vehicle reads the way it does: a charge of +$850.00, a payment of −$850.00, and a balance of $0.00 marked settled. Nothing there was decided; it was derived.
“What are we owed?” is a question the system answers rather than a task somebody performs, and the dashboard totals are guaranteed to agree with the vehicles they summarise.
Billing that happens on a cycle has to be an event, not a side effect
Charges here are periodic: every vehicle is charged for a billing month. It is tempting to treat that as something that simply happens — accrue continuously, or generate a charge whenever a page is loaded.
Both approaches fail the same way. If charge creation is implicit, nobody can say with confidence which vehicles have been charged for which month, and the failure is silent: a vehicle charged twice, or missed entirely, looks exactly like one that was handled correctly until somebody complains.
The billing month is a first-class concept, and generating charges is an explicit, operator-triggered run against it — the dashboard names the active billing month and offers generation for that month as a deliberate action.
The system also tracks how much of the fleet has already been charged within the current month, so the run is answerable for what it has and has not done rather than being an action taken on faith.
Charging a fleet becomes a decision with a record, rather than a background behaviour nobody can audit after the fact.
04 — What We Built
Records, maintenance and money, per vehicle
Vehicles
- Per-vehicle records across the fleet
- Maintenance tracked against the vehicle
- Identified by registration
Ledger
- Monthly charges and payments received
- Running balance per vehicle, per month
- Settled and outstanding states
Money view
- Total outstanding across the fleet
- Collected in the current billing month
- Overdue, by vehicle and client
- Revenue and receivables
Operations
- Clients and their vehicles
- Charge generation for a billing month
- Needs-attention queue, oldest debt first
05 — The Result
The newest thing we have built
ARC is our most recent project and is not yet launched. What exists is the part that is hardest to retrofit later: a money model that is correct by construction, where balances are derived rather than maintained and the fleet-level figures cannot drift away from the vehicles underneath them.
That ordering is deliberate. Screens are cheap to change and a ledger is not — getting the accounting shape right before anything is built on top of it is the difference between a system that grows and one that gets rewritten.
There is no live URL to check yet, so this page makes no claims about frameworks, hosting or performance, and quotes no figures from the business. The ledger shown above is the product’s own illustrative example, not a real client account — real vehicles, clients and balances are not published here.
Money model first, screens after?
That is how we build anything that has to add up — ledgers, billing, receivables. Get the accounting shape right and the rest is furniture.
Start a conversation