How to Reconcile Merchant Settlements Without Gaps

A processor deposit is not revenue arriving in your bank account. It is the net result of sales, refunds, processing fees, chargebacks, reserves, and timing decisions made inside a payment platform. That distinction is the foundation of how to reconcile merchant settlements correctly. If the bank deposit is posted directly to sales income, the books may look tidy for a day, but gross revenue, fees, liabilities, and cash timing will drift apart.

For a business with meaningful card volume, merchant settlement reconciliation is not a month-end cleanup task. It is a controlled process that connects customer payment activity to processor reports, a clearing account, and the actual cash deposit. Every number should trace back to its rows and every clearing balance should be explainable.

How to Reconcile Merchant Settlements Using a Clearing Account

The most reliable structure separates the economic event from the cash movement. When a customer pays by card, revenue may be earned immediately, but the cash is held by the processor until the scheduled payout. A merchant clearing account records that temporary claim on the processor.

Assume your business captures $10,000 in card sales on Monday. The processor deducts $290 in fees and sends a $9,710 payout to the bank on Wednesday. The accounting should preserve all three facts:

| Event | Debit | Credit | |---|---:|---:| | Card sales captured | Merchant clearing $10,000 | Revenue $10,000 | | Processor fee assessed | Processing fee expense $290 | Merchant clearing $290 | | Net settlement reaches bank | Cash $9,710 | Merchant clearing $9,710 |

After these entries, the clearing account is reconciled to $0.00 for that settlement group. Revenue remains gross, fees are visible as an operating cost, and the bank movement equals the actual payout.

The exact timing depends on your processor and accounting policy. Some platforms report fees at capture, others at payout. Some businesses recognize revenue when an order is fulfilled rather than when a card is authorized. Those choices can differ without weakening the reconciliation, as long as the rule is explicit, consistently replayed, and supported by source evidence.

The failure mode is netting. If you credit revenue for $9,710 when the payout lands, your income statement understates sales and hides payment costs. If you record $10,000 of sales but do not establish the processor receivable, your cash flow will imply that cash arrived two days before it did. Both errors reduce the usefulness of the ledger for operating decisions.

Start With the Settlement Report, Not the Bank Feed

The bank feed confirms that money arrived. It rarely explains why the amount arrived. The settlement report is the source document that identifies the population of transactions behind each payout.

For every settlement, capture a stable processor payout ID, payout date, gross charges, refunds, fees, disputes, reserves, adjustments, and net amount. The payout ID should be the reconciliation key across imported reports, clearing-account entries, and the bank transaction. Dates alone are not sufficient: processors can send multiple payouts on one day, delay weekend activity, or combine activity from different dates.

A practical control is to create one settlement record per processor payout, then attach the underlying activity rows to it. Your system should be able to answer four questions without manual reconstruction:

1. Which customer transactions make up this payout?
2. Which fees, refunds, and adjustments reduced it?
3. Which bank deposit clears it?
4. What remains unmatched, and why?

The first two questions establish the accounting evidence. The third establishes cash reconciliation. The fourth is where operational discipline matters most.

Reconcile Gross Activity Before Matching the Net Deposit

Begin with the processor's reported gross activity for the settlement period. Map successful charges to sales receipts or invoices, then map refunds and disputes to their original transactions where possible. Treat processor fees as separate expense rows, not as unexplained reductions in revenue.

Next, calculate the expected net payout:

Gross charges - refunds - fees - chargebacks - reserve holds +/- processor adjustments = expected payout

Compare that expected payout to the processor's stated net amount. Only then match it to the bank deposit. This order prevents a common shortcut: finding a bank transaction with the right amount and declaring the work complete even though the settlement composition is wrong.

Amount matching alone is weak evidence. A $4,820 deposit may match a payout total by coincidence, especially when volumes are regular. Use the payout ID when it reaches the bank narrative, processor metadata, deposit date, amount, and account as a combined matching rule. Where identifiers are absent, record the evidence used to support the match.

A deterministic matching rule is more valuable than an opaque suggestion. It can be rerun when source data changes, reviewed by a controller, and audited months later. AI may help identify a candidate for review, but it should never override the replay or post an unsupported match into the live ledger.

Handle the Exceptions That Keep Clearing Accounts Open

An open merchant clearing balance is not automatically an error. It is a signal that needs a specific explanation. The most common cases are timing differences, processor reserves, refunds settled in a later payout, chargebacks, currency conversion, and manual processor adjustments.

Timing differences

A sale recorded late in the day may be included in the next payout cycle. Likewise, a Friday settlement may not arrive until Monday or Tuesday. Keep the clearing balance open until the payout is issued and matched, but age it by processor and expected settlement date. A balance that is normal for two days can become an exception after ten.

Rolling reserves and held funds

Some processors retain a percentage of card receipts as a reserve. That amount is not a fee and should not disappear into an expense account. Record it as a separate receivable or restricted processor balance, depending on the facts and your accounting policy. Reclassify it back through clearing when released.

Refunds and chargebacks

Refunds can be deducted from a later payout rather than returned from the original settlement. Chargebacks may include separate dispute fees and can remain provisional while the case is open. Preserve separate transaction types and references. Combining every reduction under refunds prevents finance teams from seeing whether product returns, fraud, or customer disputes are driving the cash impact.

Negative payouts

When refunds and disputes exceed current sales, the processor may pull cash from your bank instead of sending a deposit. The same reconciliation logic applies, but the bank leg is a withdrawal. Do not force it into an expense category simply because it is cash leaving the account. First clear the underlying merchant liability or receivable.

Put Reconciliation on a Daily Operating Cadence

Monthly reconciliation can validate historical financials, but it is too slow for businesses managing payroll, vendor commitments, and tight working capital. A daily process makes processor cash timing visible before it becomes a forecast surprise.

The daily cadence should ingest bank activity and processor exports, apply deterministic classifications, construct or update settlement groups, match completed payouts, and surface exceptions. A controller should review unmatched payouts, aging clearing balances, and material adjustments. Month-end then becomes a close control: verify that processor clearing accounts, bank accounts, and the settlement subledger agree, with documented explanations for valid in-transit items.

This is also where direct-method cash flow becomes more useful than a retrospective bank balance. The forecast should project payout dates and expected net cash, not merely show sales booked on the income statement. If $80,000 of card sales will settle after payroll, the timing gap matters even when the monthly P&L is strong.

Shekl is designed around this evidence chain: raw processor and bank rows become classified transactions, replayable ledger entries, reconciled balances, and day-level cash projections. The objective is not to automate away judgment. It is to make the applied rules, source rows, and remaining exceptions visible to the person responsible for the books.

Controls That Make Settlement Reconciliation Defensible

A reliable workflow needs controls that can withstand review. Lock posted settlement groups after approval, retain the original report or export reference, and record who resolved every exception. If a rule changes, rerun the affected data with versioned logic rather than editing historical amounts without an audit trail.

Set materiality thresholds carefully. A one-cent rounding difference may be acceptable when documented. Repeated small variances are not automatically immaterial: they can indicate tax treatment differences, FX handling errors, or an import mapping problem. The right threshold depends on transaction volume, processor complexity, and the risk of the account.

The standard is simple: gross sales, deductions, net payout, and bank cash must reconcile through a defined path. When that path is deterministic, merchant settlements stop being a black box between checkout and cash. The next payout should arrive as confirmed evidence, not as a number someone has to explain after the fact.