Episode 03 · Payment Processor Audit
Your processor says one number. Your books say another.
Somebody reconciles the difference by hand, every month, and hates it. Here are the five ways the gap actually opens up — and what a reconciliation has to do to be worth trusting.
This episode is a write-up, not a downloadable template. Payment-processor matching depends on your processor’s payout schedule, your chart of accounts, and how your client handles refunds — a generic workflow would produce confident, wrong answers, which is worse than no workflow. What follows is the logic I build against, plus a sample of the report it produces.
The gap is rarely one big thing
When a client’s processor balance and their books disagree, the instinct is to look for one missing transaction. That is almost never what happened.
What actually happened is four small things, each individually defensible, none of them announcing itself. The reason nobody catches them is not carelessness — it is that every one of them produces books that look internally consistent.
Five exception classes
The payout that spans a period boundary
One deposit batches three days of sales across the month close.
Both months are now wrong, and neither looks wrong. The deposit reconciles against the bank perfectly — it is only the period attribution that is broken. Nothing in a standard bank-feed match will flag this, because nothing is missing.
The refund matched to the wrong original charge
A refund posts against a different sale of the same amount.
Both rows look correct in isolation. The totals tie. Only the pairing is wrong — which means your revenue by product, by channel, and by customer is quietly off, while the P&L total stays right.
Processor fees never booked
Gross amounts recorded, fee side missing for the period.
Revenue looks correct. Margin does not. This is the one that survives longest, because the number everyone checks — top line — is fine. It surfaces months later as a margin question nobody can answer.
The chargeback that reversed
The dispute was won and the processor returned the funds.
The original loss was booked. The reversal was not. Chargebacks get attention when they arrive and none at all when they resolve, so the write-off just sits there.
A deposit with no matching payout
Money arrived in the bank that the processor does not account for.
Usually an owner transfer, a loan draw, or a second processor nobody mentioned. Almost never fraud. But it has to be explained rather than absorbed, and 'plug it to suspense' is how a clean set of books starts rotting.
Match in both directions, or you miss the dangerous half
Most reconciliation checks one way: every processor transaction must appear in the books. That catches things the client never recorded.
It completely misses the opposite case — entries in the books with nothing behind them. A duplicated journal entry, a manual adjustment nobody reversed, revenue recognised twice. Those are the more dangerous errors, because they inflate rather than understate, and because they survive every check that starts from the processor side.
Exception 05 above only exists because the match runs the other way too.
Three decisions that make it usable
Matching is deterministic
The same inputs always produce the same output. No fuzzy scoring, no judgment call the run makes differently the second time. You may have to defend a number to a client or an auditor six months from now, and “the tool decided” is not a defence.
Tolerance on amounts, never on counts
Sub-cent rounding differences get absorbed. A missing transaction never does. The tolerance exists so the report stays readable — not so it stays short.
Silence is the success signal
On a scheduled run, a clean month sends nothing. An alert means a human is needed. A report that arrives every month regardless stops being read by the third month.
Every row carries its reason
An exception is only useful if the person reading it can act without re-deriving the whole thing. So each row carries the processor reference, the book reference where one exists, the amount, the rule that flagged it, and a plain sentence:
Book entry JE-2214 records the full amount in April.
Rule: period_boundary_split.
That sentence is written to be handed to a bookkeeper without further explanation. A flag you have to investigate from scratch is barely better than no flag.
Honest limits
- —It finds and reports. It does not post. Journal entries into the accounting system stay with your bookkeepers. I am not an accountant.
- —Accuracy depends on both exports covering the same window. A partial export produces false exceptions, so date coverage gets checked before anything is compared.
- —Where a processor exposes no API, this runs from exports. If those exports change shape month to month, that is the problem to fix first.
- —It reconciles what both sides report. Cash that never touched either system is invisible to it.
See the report it produces
A full sample exception report — the five classes above on an illustrative month, the matching logic, and the limits stated plainly. Free, no email required.
Sample exception report (PDF) →Know when the next workflow drops
One email per new episode. Built for accounting firms and finance teams.
No spam. One email per new episode. Unsubscribe in one click.
Want this built against your client’s actual data?
For accounting firms: I build and install the reconciliation per-client as a white-label service. Fixed scope, 2 weeks, your bookkeepers stay in the relationship. Matching rules written against that client’s processor and chart of accounts, not a generic template.
Book a 20-min call →