How to Reconcile Credit Card Processing Statements to Bank Deposits

Your processor reports one set of activity. Your bank shows what actually landed.

For example, a merchant might report $52,400 in card sales while only $46,754 reaches the bank.

The reconciliation question is straightforward: what explains the difference, and is every dollar accounted for?

Merchant statement reconciliation compares processor-reported activity with bank deposits, explains the differences between the two, and isolates anything that still needs review.

The process becomes harder as the number of merchant accounts, processors, statements, and bank deposits grows. The same reconciliation logic still applies. The challenge is keeping that logic consistent across the portfolio.

Why bank deposits often differ from gross sales

The amount deposited into a merchant's bank account often differs from gross card sales because activity occurs between the original transaction and settlement.

That activity might include:

• Processing fees and assessments
• Refunds
• Chargebacks and dispute-related fees
• Reserve holds and releases
• Adjustments
• Timing differences between processing and funding

None of those items automatically indicates a problem. The reconciliation work is determining what explains the difference and what does not.

Step 1: Define the reconciliation scope

Start by deciding exactly what you are reconciling.

For each reconciliation, define:

• The merchant account or MID
• The statement period
• The bank account receiving the deposits
• The cutoff treatment for deposits that post after period end

A batch processed at the end of the month might appear on the processor statement for that period while the corresponding bank deposit posts several days later.

Establish the cutoff logic before matching activity so the same rules apply each time.

Step 2: Gather the source records

A complete reconciliation starts with the records needed to explain both the deposit and the deductions around it.

At minimum, gather:

1. Processor or merchant statements showing sales, fees, refunds, chargebacks, reserves, and adjustments
2. Bank activity showing the deposits that actually posted
3. The contracted rate schedule or fee agreement used to verify what the merchant should have been charged

The third record set matters because a deposit might reconcile mathematically even when a fee was calculated incorrectly.

Matching the deposit and verifying the fee answer two different questions.

Step 3: Calculate the expected deposit

Use the processor statement and related funding records to determine what should have reached the bank.

The exact calculation depends on how the processor funds the merchant and when fees or adjustments are deducted.

A simplified calculation might look like this:

Here is an illustrative example:

The reconciliation now has a defined gap. Instead of investigating the entire $52,400 in activity, the finance team needs to explain the remaining $25 difference.

Step 4: Match at the right level

Reconciliation gets harder when statement activity and bank deposits do not follow a one-to-one relationship.

Common patterns include:

• One deposit representing one batch or processing day
• One deposit combining several batches
• One batch funding across multiple deposits
• Deposits delayed by weekends, holidays, or cutoff timing
• One deposit containing activity from multiple merchant accounts

Start with the processor's funding or settlement records rather than comparing bank deposits directly to gross sales.

Those funding records already reflect much of the activity that changed the original sales amount before the funds reached the bank.

Step 5: Classify the result

FeeSuite organizes reconciliation results into three review states:

Using the example above, the reserve hold is not an unexplained loss. It accounts for part of the difference between gross sales and the deposit.

The remaining $25 stays an exception until its source is identified.

Instead of reviewing every transaction equally, the finance team can focus on the smaller group of items that still need judgment.

Step 6: Verify fees against contracted terms

A successful reconciliation does not automatically prove the fees were correct.

If the processor deducted a fee and reported the same deduction on the statement, the deposit might reconcile perfectly even if the fee did not match the merchant's contracted terms.

Fee verification adds a second control.

Compare the fees charged on the statement against the applicable rate schedule or agreement.

Look for:

• Rates that differ from contracted terms
• Per-item fees that do not match the agreement
• New or changed fees
• Duplicate charges
• Unexpected changes in the merchant's effective processing cost

Fee verification belongs inside the reconciliation workflow because both checks rely on the same statement activity.

One confirms where the money went. The other confirms whether the amount charged was consistent with the agreed terms.

Step 7: Investigate the exceptions

When a difference remains unexplained, work through the most common causes in a consistent order.

Start with timing. Did the deposit post in an adjacent period?

Then check related activity. Is there a refund, reserve movement, chargeback, or adjustment that explains the difference?

Next, review fees. Was a fee deducted somewhere other than where you expected to find it?

Then check grouping. Was the activity combined with another batch, merchant account, or deposit?

If none of those explains the gap, the item remains a true exception that needs further investigation.

Once the supporting activity is identified, document the explanation and attach it to the reconciliation record.

Step 8: Review and preserve the record

A reconciliation should leave behind more than a final number.

Keep the support that explains how the result was reached, including:

• The processor or merchant statement
• The related bank activity
• The explanation behind offsets
• The resolution of exceptions
• Relevant fee-verification results
• Review and approval history

If someone asks months later why a deposit differed from processor activity, the explanation should already exist with the reconciliation rather than requiring the finance team to rebuild the work.

Common reconciliation problems

Reconciling deposits directly to gross sales

Gross sales and funded amounts measure different stages of the payment process. Comparing the bank directly to gross sales often creates differences that normal fees, holds, refunds, and other activity already explain.

Ignoring reserves

Reserve holds and releases frequently cross reporting periods. Without tracking both sides, legitimate timing differences can look like missing funds.

Using different methods for different accounts

When each merchant account relies on its own spreadsheet logic, the reconciliation process becomes harder to repeat, review, and scale.

Treating fee verification as a separate project

A clean deposit match does not establish that the processor charged the contracted amount.

Losing the explanation

An exception that gets resolved without documented support becomes a future reconciliation problem when someone needs to understand the same activity again.

What changes at portfolio scale

The mechanics above are manageable for a small number of merchant accounts.

As the portfolio grows, so do the statements, bank deposits, fee schedules, timing differences, and exceptions that need review.

That is where standardizing the repeatable part of reconciliation starts to matter. The finance team should reach review with routine matching already organized and the remaining exceptions clearly identified.

How FeeSuite handles merchant reconciliation

FeeSuite is built specifically for merchant statement reconciliation.

The workflow moves through three stages.

FeeSuite also compares charged fees against contracted rate schedules within the same workflow.

Your team reaches review with the reconciliation already organized instead of rebuilding it account by account.

For broader context on payment data and reconciliation, Arkonyk has published an overview of FeeSuite alongside its work across the payments ecosystem. Read Arkonyk's FeeSuite overview, or see the full FeeSuite How It Works walkthrough.