One Number, Everywhere
Ask a fuel jobber what a customer owes and you will get a different answer depending on where you look. None of them is lying — each was true when it was made, and each has drifted since, because each was built from its own copy of the truth.
The balances page says one number. The overdue list says another. The statement that went out last week says a third.
That drift is the receivables problem. It is not that the office cannot add. It is that the same customer's position lives in several places at once — invoices here, payments there, card batches somewhere else, drafts in a fourth place — and every view reconstructs it slightly differently. The fix is not a better report. It is one live position, calculated once, that every view reads from.
In FuelJobberX, a customer's receivables position is not stored as a number that gets updated and goes stale. It is calculated live, from the same shared math, every time any view asks for it. Balances, Overdue, Receivables Recap, and Statements all read that one position — so they cannot disagree with each other, because there is only one number to disagree about.
That sounds abstract until it saves an argument. The collector calls a customer about an overdue balance, the customer says "I paid that," and the office can look at the same live position the collector is looking at — invoices, memos, payments, card credits, and drafts all already netted in — instead of pulling three reports and trying to reconcile them on the phone. The overdue list is not a separate list that might be out of date; it is the live position, filtered to what is past due. The receivables recap is the same position, summarised. The statement is the same position, printed for the customer.
Aging works the same way. An invoice does not become overdue because somebody moved it to an overdue list; it becomes overdue because the live position says its due date has passed and it is still open. The office sees the age of every open balance from the same calculation, so "how old is this money" has one answer no matter who asks.
Money comes in messily: a check that covers three invoices, a partial payment, a card credit that nets against an invoice, a draft that settles a week's worth of billing. The payments ledger and apply-payment flow exist so that mess lands in the right places.
A payment is applied across invoices, not just recorded as a lump against a customer. Credit and debit memos adjust the position the same way invoices do — a memo is a real entry, not a note in the margin — so a price correction or a goodwill credit changes what the customer owes immediately, in every view, instead of living as a promise the next statement has to remember.
Card credits net in too: where a customer's card batch leaves a credit, it is applied against what they owe rather than sitting as a separate balance nobody looks at. The result is that the live position is the position after everything — invoices, memos, payments, card netting, drafts — not the position after the easy parts.
A statement is only useful if the customer can reconcile it against their own records — and only safe if it matches what the office believes. Because statements are built from the same live position as Balances and Overdue, the statement a customer receives and the balance the office sees are the same number, on the same day. There is no version where the statement says one thing and the collector's screen says another.
Statements go out by email from the system, and the office can see what was sent and when. That matters more than it sounds: the most common receivables argument is not "I didn't owe it" but "I never saw it." A statement with a sent record ends that argument before it starts, and the live position behind it means the customer is looking at the same balance the office is.
Bank drafts are how many jobbers actually get paid — not invoice by invoice, but in scheduled runs that pull what is owed. The drafts workflow runs on the same position: a draft worksheet built from the open balances, draft batches and runs that collect them, customer draft notices so nobody is surprised by the debit, and NACHA files generated from the same builder that handles card payouts.
The weekly rhythm is the point. A draft run is not a scramble to work out who owes what this week; it is the live position, turned into a batch, with notices sent and the debit file generated. And because drafts, card activity, and invoices all feed the same position, a customer who paid by card this week does not get drafted for the same money next week — the position already knows.
When a customer does dispute a balance — and sooner or later one will — the question is not "what do they owe" but "how did it get to this number." The Payment Trail answers that per invoice: every payment, card reconciliation allocation, netted credit, draft, and settlement state that touched it, in order, so the office can walk a customer through the invoice's whole life instead of defending a total.
Customer Overview gathers the same story at customer level: a full-history timeline of invoices, memos, edits, payments and reversals, card batches, reconciliations, payouts, and statements sent — with a profitability view that shows, for that customer, revenue against fuel, freight, and other carrier cost, in dollars, percent, and cents per gallon. It is the view you open when the question stops being "what do they owe" and becomes "is this customer worth what they cost us."
We already have a balances report — what does a live position change? A balances report is a snapshot; a live position is the number itself, recalculated whenever anyone looks. The difference shows up the day a payment lands after the report was run: with a snapshot, the collector is working from yesterday's number; with a live position, every view — balances, overdue, recap, statement — updates at once, because they all read the same calculation.
How do partial payments and memos fit in? They are entries in the same position, not adjustments applied later. A partial payment applies across the invoices it covers; a credit or debit memo changes the balance the moment it is posted. Nothing waits for month-end to be true.
Do statements really match what the office sees? Yes — because they are built from the same live position as Balances and Overdue, not from a separate statement file. The number on the statement and the number on the collector's screen are the same number, calculated the same way, on the same day.
What about customers who pay by bank draft? Drafts are part of the position, not a side system. The draft worksheet is built from open balances, batches collect them on schedule with customer notices, and the NACHA debit file comes from the same builder as the card payouts. A drafted amount is settled in the position like any other payment.
Can I see the full history behind one customer's balance? Yes — Customer Overview shows the customer's complete timeline (invoices, memos, edits, payments, card batches, reconciliations, payouts, statements), and the Payment Trail shows the same story per invoice. If a customer asks "how did you get to this number," you can show them, line by line.
Does this replace the credit and collections work in article 6? No — it is the ground that work stands on. Article 6 was about the decisions: credit limits, when to hold a load, how to collect without losing the account. This article is about the numbers those decisions are made from: one live position, so the collector, the statement, and the draft run are never arguing with each other about what a customer owes.
Receivables work fails quietly. Nobody notices the day the balances page and the overdue list start disagreeing; they notice it months later, in a phone call with a good customer, when the office cannot say with confidence what is owed or how it got there.
One live position ends that. Balances, overdue, recap, statements, drafts, and the payment trail all read the same calculation, so the number is the same wherever you look — and when a customer asks how it was reached, the trail is there to show them.
FuelJobberX keeps every customer's receivables position live and shared: balances, overdue, and statements that always tie out, payments and memos applied where they belong, bank drafts collected on schedule, and a full trail behind every dollar. If you want to see your receivables run from one number instead of five reports, you can book a demo at fueljobberx.com — a walkthrough with real data in under 30 minutes, no sales pressure.
We'll walk you through the full platform in under 30 minutes — with real data, no sales pressure.
Book a Demo →