How to Reconcile Card Deposits Without Guesswork
A $9,842 bank deposit is not proof of $9,842 in revenue. It may represent two days of card sales, less processor fees, a refund, a chargeback adjustment, and a reserve release. To reconcile card deposits correctly, finance needs to prove the path from each transaction through the payment processor settlement and into the bank account. Anything less leaves revenue, cash, and working capital exposed to quiet errors.
For businesses with meaningful card volume, this is not a month-end cleanup task. It is a control over the relationship between commercial activity and available cash. The objective is simple: every deposit should reconcile to $0.00, every difference should have a documented cause, and every number should trace back to its source rows.
Why card deposits rarely equal card sales
Card processors operate on settlement schedules, not on your revenue-recognition calendar. A sale made on Tuesday may be included in a Wednesday or Thursday payout. The payout can be net of fees, refunds, disputes, rolling reserves, currency conversion, or prior-period adjustments.
That creates three distinct facts that must not be collapsed into one number:
| Financial fact | Evidence source | What it answers | | --- | --- | --- | | Gross customer payment | Order system or processor transaction report | What did the customer pay? | | Processor settlement | Payout or transfer report | What amount did the processor release, and why? | | Bank receipt | Bank feed or bank statement | What cash actually arrived? |
When these facts are booked directly against revenue without a clearing account, a net deposit can make fees disappear or cause sales to be recorded twice. The bank balance may look reasonable while the income statement and balance sheet are wrong.
The accounting structure that makes reconciliation possible
Use a card clearing account, sometimes called a merchant receivable or payment processor clearing account. It represents money the processor owes the business after a customer payment has been authorized or captured but before the processor has transferred cash to the bank.
At the point of sale, record gross sales and the expected processor receivable. When the processor settles the payout, clear the receivable and record fees, refunds, or other adjustments separately. When cash reaches the bank, move the settled amount out of the clearing account and into the operating account.
A simplified example makes the mechanics clear. Assume a processor payout contains $10,000 in gross card charges, a $250 customer refund, and $291 in processing fees. The bank receives $9,459.
The economic record is not $9,459 of revenue. It is $10,000 of gross activity, offset by $250 of refunds or contra-revenue and $291 of processing expense, with $9,459 of cash received. The clearing account is the bridge that preserves those distinctions.
The exact journal design depends on whether orders, invoices, and payments are already posted through an accounting system. But the control principle does not change: gross sales, deductions, and cash movement need separate evidence and separate ledger treatment.
How to reconcile card deposits step by step
1. Start with the bank deposit, then identify the payout
Begin with the bank transaction because it is the cash event that must be explained. Capture the deposit date, amount, bank account, processor descriptor, and any transfer or payout identifier included in the bank feed.
Match that deposit to a processor payout record. Do not match it to a daily sales total merely because the amounts are close. A single payout can span multiple sales dates, while a daily sales report can contain transactions that have not yet settled.
If the processor pays out in a predictable cadence, use that cadence as an expectation, not proof. Weekend cutoffs, holidays, risk reviews, and account-level payout changes can shift timing.
2. Rebuild the payout from its component rows
The processor payout report should provide the source rows that explain the transfer. Rebuild the settlement using gross charges, refunds, disputes, fees, reserve movements, and other adjustments.
The basic reconciliation equation is:
`Gross charges - refunds - chargebacks - processor fees +/- reserves and adjustments = net payout`
The calculated net payout must equal the processor's reported payout. Then the processor payout must equal the bank deposit, allowing only for a known timing difference when the transfer is initiated before the bank posts it.
This two-stage match matters. A processor report can be internally consistent and still fail to reach the bank. Conversely, a bank deposit can arrive without a complete settlement report because the processor combined several transfers or applied an adjustment from an earlier period.
3. Clear the right balance, not just the right amount
Once a payout is verified, clear the corresponding items in the card clearing account. The remaining clearing balance should be a schedule of specific unsettled transactions, pending payouts, reserves, and identified exceptions.
A clearing account that has a plausible total but no item-level support is not reconciled. A controller should be able to answer: Which transactions make up this balance? When are they expected to settle? What evidence supports each amount?
This is especially important at month-end. Card activity posted near the cutoff often remains in clearing legitimately. The balance is acceptable if it is supported by processor detail and resolves in the expected settlement window. It is not acceptable because it is small.
4. Separate timing differences from true exceptions
Not every unmatched item is an error. A payment captured late in the day may settle in the next payout. A payout initiated on the last business day of the month may post to the bank on the first business day of the next month.
Treat those as timing differences only when they meet a defined rule: the amount appears in processor settlement detail, the expected bank date is known, and the item clears within the permitted aging window. Otherwise, classify it as an exception requiring investigation.
Useful exception categories include missing payout, duplicate deposit, unmatched fee, unexplained reserve movement, refund not tied to an original sale, and bank deposit with no processor source. Categories turn reconciliation from a collection of notes into an operating control with measurable failure modes.
5. Preserve evidence and approval history
A completed reconciliation should retain the bank transaction, processor payout, component transaction rows, applied accounting entries, exception notes, and reviewer approval. The evidence should be available from the reconciled balance, not scattered across inboxes and exported spreadsheets.
This provenance matters when a customer disputes a payment, a processor adjusts a prior payout, or an auditor asks why the merchant receivable increased at month-end. A journal entry without the underlying settlement logic is an assertion, not proof.
Reconcile card deposits without distorting cash forecasts
Card reconciliation also affects forward cash visibility. A sales dashboard may show a strong day, but payroll cannot be paid with authorized transactions that will not settle for three business days. The cash forecast needs to model actual expected payout dates and expected net amounts.
Use historical processor behavior to estimate settlement timing, then apply known exceptions. If the processor withholds reserves, pays certain channels on a longer schedule, or batches payouts across weekends, that logic belongs in the forecast model. Do not assume all recorded card revenue becomes available cash tomorrow.
The trade-off is precision versus maintenance. A simple business with one processor and next-day payouts may need only a short settlement lag rule. A business with multiple processors, marketplaces, refunds, subscription renewals, and reserve holds needs transaction-level or payout-level timing. The right level of detail is the one that produces a forecast that can be replayed against actual bank activity.
Shekl is built around that discipline: deterministic rules classify and project financial activity, while every displayed cash position remains traceable to transaction-level evidence. AI may assist a finance team outside the calculation path, but it should never override the reconciliation logic or alter the replay.
Controls that prevent the same break from recurring
Daily or near-daily reconciliation is usually appropriate once card deposits are material to payroll, vendor funding, or runway decisions. The review does not need to be manual line by line when rules are stable, but exceptions should never be auto-approved simply because a match is likely.
Set explicit thresholds for deposit aging, tolerated variance, and required approvals. For example, a payout unmatched after two expected bank days should enter an exception queue. A fee variance may be allowed only if it ties to the processor's fee schedule or a documented adjustment. Large refunds and reserve changes may require a separate operational review.
Also monitor the clearing account as an aging report, not just a general ledger balance. A rising balance can signal settlement delays, incomplete payout ingestion, duplicate sales posting, or a processor hold before it becomes a cash crisis.
A card deposit reconciliation is complete when the cash receipt, settlement record, and underlying commercial activity agree - and when the remaining open items are individually explained. That standard gives finance something more useful than a balanced bank account: a ledger that can support the next cash decision with evidence.