One deposit that covers many jobs
The bank balance can be right while the job-level picture is wrong.
Money can be exactly right in the bank and still be wrong about which jobs actually made it.
Not every business has this problem, and some should leave it alone.
Most of these can be done better. Whether it's worth doing is a separate question. What follows is one common form of the problem, described in general terms, because your version will differ. These are possible challenges, not a description of your business, and some should be left exactly as they are. If it sounds like your week, that's worth a conversation.
Watch: The Books Agree and the Details Do Not
Watch: Money That Isn't Where the Total Says It Is
Sound familiar?
- A single payout covers a week of transactions, fees already taken out.
- A job is marked unpaid even though it was settled inside a batch.
- Nobody has checked a payout statement against what was actually billed.
- Overall margin looks fine while individual job margins don't add up.
What it looks like
Money doesn't always arrive one job at a time. A payout covers a week of card transactions, a platform settlement, or a batch of invoices, and the figure is almost never the sum of what was billed, because fees, adjustments and refunds have already come out. Somebody has to open a statement and work out what the lump represents.
What it costs
The money is genuinely in the account and the total genuinely reconciles, which removes the pressure that would otherwise force the detail to be sorted out. Underneath, individual jobs are in the wrong state: some marked unpaid because the payment arrived inside a lump never broken apart, some marked paid in full when a deduction means less was actually received. Two things follow. Job profitability is overstated, because a fee taken out before the money arrived belongs to the job that generated it, and booking it as one lump expense makes every job look like it earned its full invoiced amount. And customers get chased for money they already paid, from a list with no way to detect the mistake.
Where it goes wrong
- The statement is a different shape than the ledger and has to be reorganized by hand, every time.
- Deductions are netted rather than recorded, so nobody can tell whether the rate agreed is the rate charged.
- Timing splits the batch across reporting periods, mapped manually.
- Nobody checks the statement against what was billed, only against the total received.
What a better version looks like
The lump gets broken back down automatically against the detail the sender already provides, with each deduction recorded against the job that generated it rather than pooled into a monthly total. The comparison that becomes possible is the valuable part: the payout checked against what was actually billed, with differences raised as specific questions while the answer can still be found. Nothing gets adjusted automatically; a difference means the two records disagree, not that either is wrong.
Questions worth asking about your own operation
- Can you see, job by job, what a batch payout actually paid for?
- Has a fee rate ever quietly changed without anyone noticing?
- Is anyone chased for money that was already collected inside a batch?
If this sounds familiar
Bring me the version you actually have. I'll learn how the process really works before I suggest anything. If it isn't worth changing, or isn't a fit for me, I'll say so. Talk through a problem