A Square settlement CSV is not a deposit log. It is the explanation behind a deposit, and that is why the same day's card sales, refunds, and fees rarely show up on your bank statement in the same shape as the export.
That mismatch turns into wasted time when the bank shows one neat deposit line and Square shows a batch of payments, fee deductions, refund rows, and a settlement date that lands on a different day. The files are describing the same money from different levels.
To reconcile Square settlement CSV bank deposits accurately, start from the bank deposit that actually arrived, identify the Square settlement behind it, and only then break down the transactions inside that settlement. If you reverse that order, correct data looks wrong.
Read the mismatch before you touch the files
Most failed matches fall into a small number of patterns. Identify the pattern first. That tells you what you are trying to prove and what kind of mismatch you are looking at.
| What it looks like on screen | How the Square settlement CSV stores it | How the bank statement stores it | Result when you try a raw match |
|---|---|---|---|
| Same money, different day | settlement_date: 2026-05-30, net_total: 4,912.60 | posted_date: 2026-06-02, amount: 4,912.60 | Same settlement, bank posting lag |
| Gross sales are higher than the deposit | gross_collected: 5,080.00, fees: -142.40, refunds: -25.00, net_total: 4,912.60 | amount: 4,912.60 | False mismatch if you compare gross to the bank |
| Reference text looks shorter on the bank side | transfer_reference: SQ-TRF-240530-A19 | description: SQ TRANSFER A19 | Same deposit, truncated descriptor |
| One expected deposit appears as two bank lines | split_deposit: 2,500.00 + 2,412.60 | Two credits on the same day | False mismatch if you expect one line only |
| Month-end numbers refuse to tie out | settlement_period_end: 2026-05-31, transfer_date: 2026-06-01 | Credit posted on 2026-06-02 | Timing difference across periods, not a missing sale |
These are different problems. A posting delay is not solved the same way as a gross-versus-net gap. A truncated reference is not solved the same way as a split deposit. If you know which case you are in, the reconciliation becomes mechanical instead of speculative.
Match the deposit first, then explain it
The bank deposit is the cash event. That is the amount that must reconcile first.
If Square shows this:
| Square settlement summary | Amount |
|---|---|
| Gross card payments | 5,080.00 |
| Refunds | -25.00 |
| Processing fees | -142.40 |
| Net deposit | 4,912.60 |
and the bank statement shows this:
| Bank date | Description | Amount |
|---|---|---|
| 2026-06-02 | SQ TRANSFER A19 | 4,912.60 |
then the first match is already visible. The deposit is not supposed to equal gross card payments. It is supposed to equal the net effect of that settlement after Square has already deducted fees and applied any refund activity inside the batch.
That is the mental model that matters. You are not proving that sales equal cash on the same line. You are proving which settlement created the cash and what inside that settlement explains the difference between gross and net.
Use the files at the right level:
| Compare this | Against this | Expected result |
|---|---|---|
| Net total or deposit total | Bank deposit amount | Should match or be traceable |
| Transfer or settlement date | Bank posting date | Often close, not always identical |
| Transfer reference or descriptor | Bank description text | Useful confirmation, sometimes shortened |
| Gross collected | Nothing on the bank statement directly | Explains the starting total, not the deposit |
| Fees, refunds, adjustments | Nothing on the bank statement directly | Explain why cash is lower than gross |
| Location or destination account | Receiving bank account | Should point to the same destination |
This is where a lot of Square reconciliations go wrong. The operator exports sales activity, sees a lower bank deposit, and assumes the payout is wrong. In most cases the payout is fine. The comparison started on the wrong number.
Pull the right exports before you compare anything
If you export the wrong Square report, the reconciliation fails before you begin. A sales summary is useful for performance review. It is not the file you want for matching bank deposits. You need the report that shows how money moved from Square into the bank.
For a file-first workflow, pull these three exports:
| File | Minimum fields you need | Why it matters |
|---|---|---|
| Bank statement CSV | Date, description, amount, account | This is the cash record you must prove |
| Square settlement or reconciliation CSV | Net total, gross collected, fees, refunds, transfer date, transfer reference, location | This identifies the deposit and explains how the net amount was built |
| Optional Square transaction detail export | Payment ID, order or ticket reference, payment amount, refund rows, fee rows | Use this only when the settlement total is matched but the internal makeup still needs explanation |
If your bank CSV itself is hard to compare because the layout shifts between exports, the cleanup problem is separate from the settlement logic. In that case, start by fixing the file comparison method with comparing two bank statement CSV files without formulas, then come back to the Square-specific match.
Column names vary by export and by region. That does not change the logic. Look for the fields that behave like net deposit, gross collected, fee total, refund total, transfer date, and transfer reference. Once you have those equivalents, you have enough to reconcile.
A workflow that gets you to one defensible answer
The fastest reliable workflow is short. The order matters.
1. Isolate the bank deposit you are reconciling.
Filter the bank statement to the Square credit you are testing. Record the posted date, amount, description text, and bank account. If the business has more than one receiving account, this matters immediately.
2. Search Square by the net amount first.
In the settlement CSV, look for the bank amount as the net total. Do not begin with gross sales. The net field is the closest bank-side equivalent.
3. Narrow by date window, not exact same-day matching.
Square settlement dates and bank posting dates often sit a business day apart. Weekend batches and month-end periods make the shift more visible. If the amount matches and the date is off by a day or two, that is a clue, not a contradiction.
4. Use the transfer reference only as confirmation.
The bank description may shorten or partially hide the Square reference. That is normal. If the amount and date window already point to one settlement, even a partial descriptor can be enough to confirm it.
5. Open the settlement breakdown only after the deposit is identified.
Once the net deposit is tied to a bank line, explain the contents of the batch. Separate gross payments, refunds, fees, disputes, and any other adjustments that changed the payout. That gives you the reason the deposit is lower than the sales activity in the period.
6. Write the result as a proof, not as a guess.
The answer should read like this: the bank credit of 4,912.60 posted on 2026-06-02 matches the Square settlement dated 2026-05-30; the date gap is posting lag; the difference from gross card payments is explained by 142.40 in fees and 25.00 in refunds. That is a finished reconciliation note.
The useful part of this workflow is that it forces each file to do one job. The bank statement proves cash landed. The settlement CSV proves which batch created it. The detail export explains the activity inside the batch. When one file is asked to do all three jobs, false mismatches multiply.
The cases that make a correct Square deposit look wrong
The stubborn mismatches usually come from one of these situations:
| Case | What it looks like | Correct treatment |
|---|---|---|
| Weekend or month-end timing | Friday or month-end sales appear in a Monday or next-month bank line | Reconcile by settlement or transfer date, not by sales day |
| Refunds from earlier sales | The current settlement is lower than this week's sales, but the gap equals refund activity | Treat the refund as part of the current settlement reduction |
| Instant deposits mixed with normal transfers | Some deposits hit the bank the same day while others follow the regular schedule | Keep instant deposits separate from standard settlements |
| Split deposits | One expected transfer appears as two bank credits | Add the related bank lines together before rejecting the match |
| Duplicate net amounts | Two different settlements have the same net value | Use date window, location, and reference text to break the tie |
| Multiple locations or bank destinations | The amount exists in Square but not in the account under review | Confirm the destination account and location before treating it as missing |
The timing issue is the one that traps most people. They reconcile by the day the payment happened because that is how a sales export is organized. Square settles cash by transfer logic, not by the way the sales day looks in a summary report. If you force calendar-day matching, every weekend and month-end becomes a false exception.
Refunds create the second most common confusion. A refund can hit today's settlement even when the original payment was taken days earlier. That makes the bank deposit look short if you are staring only at current-day sales. The settlement CSV is the better source because it shows the adjustment in the batch that actually affected cash.
Instant deposits deserve their own lane. If the account uses them, do not mix them into the same rule set as standard transfers. Same-day cash movement, separate fees, and different identifiers can make a correct instant deposit look like a duplicate or a missing standard settlement.
If you also reconcile processor batches from more than one platform, the same bank-first logic used in matching a Stripe payout CSV to a bank statement applies here as well: identify the net deposit first, then explain the batch behind it.
What the finished reconciliation should prove
A highlighted spreadsheet is not enough. The finished output should let another person understand the result without reopening Square.
Include these sections in your reconciliation note or report:
| Output section | What it should show |
|---|---|
| Bank-to-settlement match | Bank date, bank amount, matched Square net amount, settlement or transfer date, and reference used |
| Gross-to-net explanation | Gross collected, fees, refunds, disputes or adjustments, and resulting net deposit |
| Exceptions list | Anything unmatched, duplicated, split, or still pending review |
| Final status | Reconciled, timing difference, split deposit, partial match, or unresolved |
That structure matters because it separates explanation from exception. A one-day posting lag should not sit in the same bucket as a missing settlement. A truncated bank descriptor should not be treated the same way as a true amount difference. Once those are separated, the reconciliation becomes easier to review and easier to defend.
The test is simple. Can someone else read your note tomorrow and understand why the bank received 4,912.60 instead of 5,080.00? If the answer is no, the reconciliation is not complete yet.
When the export routine becomes the work
Manual Square reconciliation is workable when the volume is low and the deposit patterns are clean. It becomes expensive when every close repeats the same routine: export the bank file, export the settlement CSV, search the net amount, check the posting lag, confirm the reference, open the detail rows, explain the refunds, and rebuild the same audit note again.
At that point, the finance work is no longer deciding what happened. It is repeating a file comparison process. If the same Square settlement mismatch lands on your desk every week or every month, the issue is not accounting judgment. The issue is that the file workflow is consuming the time that should go into review.
