Reconcile Card Settlements With Bank Statements

Your shop records €2,500 in card payments, but the bank statement shows a deposit of €2,262.50. The difference might contain processing fees, customer returns, money temporarily held by the processor, or adjustments from an earlier period. Subtracting a guessed commission rate will not explain it.

To reconcile card settlements with bank statements, connect three records: card sales, the payment service provider’s settlement report, and the bank deposit. First prove which transactions and adjustments belong to a settlement; then prove that its expected payment reached the correct account.

This guide is for merchants receiving card proceeds. It covers a practical worksheet, a worked settlement example, and a month-end control for money still outstanding. Every amount in the examples is hypothetical, not a quoted processing rate or an industry benchmark.

BankStatementLab can match the bank-credit side to a prepared payout control table. Import one row per expected net settlement, compare it with already extracted bank statements, review the suggestions and export an Excel, CSV or PDF report. Keep the sales-to-settlement calculation as the evidence behind each row.

Reconcile my settlement deposits

Build two checks, not one comparison of totals

A payment service provider, or PSP, sits between customer payments and your bank balance. Its report explains how individual payments become a settlement. A bank statement confirms the cash that arrived, but cannot identify every sale or deduction behind that cash.

Keep the records separate:

Record	What to collect	What the check establishes
POS or sales records	Card payment ID, amount, currency, store and status	Which completed card payments should enter the processor’s records
PSP settlement report	Batch or payout ID, included transactions, fees, adjustments and expected payment	How the provider calculated this settlement
Bank statement	Account, credit amount, currency, posted date and reference	Whether the expected settlement reached that account

Check each report’s scope: all sales, card payments only, completed settlements or separately invoiced fees. A sales total is not evidence that exactly those transactions belong to a particular bank deposit.

The first check is card payments → settlement detail. The second is expected settlement → bank credit. Passing the second does not prove that every sale was processed: a missing card transaction could be absent from both the payout and the bank statement.

Prepare a worksheet around the settlement identifier

Choose one merchant account, settlement currency and destination bank account for the first review. Include dates just before and after the target period so you can investigate timing differences without silently expanding the totals being reported.

Gather the POS card-payment export, detailed settlement report, fee documentation and bank statement. Prefer the bank’s structured export when available. If the historical bank record exists only as a PDF, extract its rows and verify them against the source before matching.

Create one settlement-summary row per payout. Keep transaction detail in a separate table so a batch containing 80 payments does not repeat the same bank credit 80 times.

Useful columns are:

• Merchant account, store and settlement currency.
• Payout or batch identifier and source-report filename.
• Gross included card payments and each documented adjustment.
• Expected bank amount and destination account.
• Payout initiation date, bank posted date and bank reference.
• Actual bank amount, difference, review status and explanation.

Preserve identifiers as text, including leading zeroes. Keep original descriptions alongside cleaned labels. A normalized label helps search; it is not evidence that two transactions are the same.

Look for a payout reference that is available in both the settlement detail and the bank record. Keep the merchant account and currency beside it so an identifier reused across stores does not become a false match.

Check the card payments before matching the deposit

Start with completed card payments rather than total till takings. Remove cash and other tender types from this comparison, while preserving original sales records. Distinguish a completed payment from a pending authorization or failed attempt.

Match payment IDs against settlement detail. For an unmatched sale, record whether it is awaiting capture, assigned to another settlement, reversed, or unexplained. Do not force it into the nearest batch because the dates look close.

For each settlement, check:

1. The number and total of included card payments.
2. The customer returns or reversals listed in that batch.
3. Fees and other deductions actually applied to the payout.
4. Any funds retained or released by the processor.
5. The resulting amount scheduled for the bank account.

An adjustment from an earlier sale may enter the current payout. Keep both its original payment reference and current settlement identifier. Otherwise, a later correction can appear to be a missing sale in one month and unexplained income in another.

Explain the net settlement before accepting a match

Consider the hypothetical €2,262.50 deposit from the introduction. Its settlement report contains these movements:

Settlement component	Effect on this payout
Gross included card payments	+€2,500.00
Customer returns	−€100.00
Processing fees withheld	−€37.50
New reserve retained	−€125.00
Earlier reserve released	+€25.00
Expected bank credit	€2,262.50

The calculation is €2,500 − €100 − €37.50 − €125 + €25. Every component needs a corresponding report entry. Reserve retention reduces this payout but remains money tracked as due from the processor; it is not a processing expense. Releasing an earlier reserve increases cash paid without creating another sale.

Fee handling needs particular care. If €37.50 was already withheld here, do not subtract it again when matching the bank credit. If your provider instead pays without withholding that fee and collects it through a separate bank debit, reconcile that debit separately. Follow the actual report and collection method.

Compare the expected payouts in BankStatementLab

For the example above, prepare one accounting/control row for +€2,262.50, with the payout reference and expected payment date. Keep the six components in a separate worksheet. The engine does not add card sales together or invent a fee to explain a net deposit.

In My Documents → Bank reconciliation, upload the XLSX/XLS or CSV accounting/control export. Check the currency and mappings in Review; the optional account filter sits under Advanced configuration. Select the already extracted, checked bank statements for the destination account, run the preview and create the report.

Inspect Suggestions, Bank only and Accounting only. Matching uses equal signed amounts and currencies, with unique one-to-one candidates. Complete dates can match on the same date, or within three days when the normalized reference or description also agrees. Longer settlement delays can legitimately remain unmatched.

Approve checked proposals individually or choose Validate all after review and confirmation. Each validation can be undone. Download the complete Excel, CSV or PDF report, preserving statuses, source rows and match reasons without altering the original accounting entries.

Create my card-settlement reconciliation report. Reading the structured export and reconciling it add no credits; PDF extraction uses the applicable credits. See pricing and the privacy policy.

Match the payout to the correct bank credit

Look first for the payout reference, then verify amount, currency, destination account and plausible timing. When a reference is missing or shortened, combine the remaining evidence and leave ambiguous matches for review.

Two €2,262.50 credits are not interchangeable. Check which merchant account, store or settlement each represents. Mark a bank row as used only after approving its match, and prevent the same row from satisfying a second payout.

Inspect the payments assigned to the actual transfer and distinguish merchant locations. Use the provider’s cutoff definitions when an otherwise valid sale belongs to another settlement.

Keep these dates separate:

• Payment date: when the card payment occurred.
• Settlement or payout date: the provider’s reported event, using its definition.
• Bank posted date: when the credit appears in your bank records.

A date difference alone is not an unexplained financial loss. Conversely, an exact date match does not prove the identity of a deposit. Use the provider’s schedule, not a universal assumption that card proceeds arrive the next working day.

Check payout frequency, the sales-day cutoff and any documented delay against the provider’s agreement. Preserve the expected date alongside the posted date so a timing exception has a concrete basis.

Carry outstanding money across month-end

Individual payout matches answer whether particular deposits arrived. A period-end control answers another question: how much remains due from the processor? Include amounts pending settlement, retained reserves and payouts initiated but not yet received, using a consistent boundary.

For this worksheet, define the balance as total processor-related receivables including reserve and funds in transit to the bank. A hypothetical monthly bridge is:

Movement	Amount
Opening total due	€400.00
Completed card payments entering the control	+€10,000.00
Customer returns	−€200.00
Fees withheld within this control	−€150.00
Settlements received by the bank	−€9,350.00
Closing total due	€700.00

The closing €700 could comprise €125 retained reserve and €575 in other outstanding items. List those items individually with references and expected follow-up dates. Do not treat €575 as a balancing figure without evidence.

Moving €125 from available funds into a reserve changes the composition of this total, not the total itself. Moving money from the provider’s payable balance into funds in transit likewise does not reduce this combined control until the bank receives it. That prevents an initiated payout disappearing between the two records.

This example assumes the €150 fee was withheld by the processor. A fee collected separately from the bank sits outside this receivable bridge. Add other documented adjustments when present; do not hide them in the closing balance.

Investigate exceptions without inventing a fee

An unexplained difference deserves a reason code and next action. Useful categories include missing payment, timing difference, separate fee collection, reserve movement, disputed payment, wrong account and ambiguous reference.

Common mistakes undermine otherwise careful work:

• Matching daily sales directly to daily bank deposits. A settlement can follow a different cutoff or combine activity from several days.
• Calling every shortfall a commission. Retained funds, customer returns and prior-period adjustments need their own evidence.
• Counting fees twice. Confirm whether a fee was withheld, separately debited, or merely displayed in an informational invoice.
• Combining different currencies. Verify the settlement currency and any documented conversion before comparing amounts.
• Closing an exception because next month’s total looks right. Resolve the specific reference and preserve the explanation across periods.

Keep pending items visible rather than deleting them. For a delayed payout, check its status and destination account, then retain the provider’s response beside the original reference.

Finish with a reviewable settlement record

A completed reconciliation should let another person trace a bank credit back to its settlement and underlying card activity. Preserve original exports, the reviewed worksheet, approved matches and outstanding-item list together.

Before closing the period, confirm each bank row is used once, each payout has a status, every adjustment has support and the total still due agrees with the outstanding schedule. A zero payout difference is useful; a documented chain from card payments to cash is stronger.

Create the bank-to-payout reconciliation in BankStatementLab, review the proposed associations and export the full report. Keep the settlement calculations beside it so every net credit has an explanation.

For a separate settlement-detail worksheet, Microsoft documents how Power Query merges tables. Check key uniqueness before expanding joined rows so duplicated keys do not multiply a payout.

Frequently asked questions

Can BankStatementLab reconcile card settlements?

It can compare extracted bank credits with a prepared accounting or settlement table containing one row per expected net payout. It proposes unique one-to-one matches for review, supports individual or bulk validation, and exports Excel, CSV and PDF reports.

Does it automatically add sales and subtract processing fees?

No. Reconstruct the net payout from the processor report first and retain the component details separately. The reconciliation engine does not group sales, infer a fee or apply an amount tolerance to force a match.

Can I review several months of settlements together?

You can select 1–50 already extracted statements for the same account and currency, within 10,000 rows per side. All selected bank rows are included; select the source documents and prepare the accounting export for the intended scope.

Related articles

• Automate bank reconciliation using PDF statements
• Convert bank statement PDFs to Excel
• Prepare bank statements for your accountant
• Batch convert bank statement PDFs to a spreadsheet