You have three statement documents for July: a checking account, a savings account and a credit card. You want one workbook, because the client's month makes no sense split across three files and nobody wants to reconcile three tabs by eye.
They can go in one file. Two things have to be true first, and neither can be fixed after the rows are stacked without going back to the source statements.
The account identifier has to survive as a column
Concatenate three sheets and every field survives except one. Dates, descriptions and amounts arrive in the merged file unchanged, because each of them is written into the row itself. The account a row came from is not written anywhere in the row. It exists only in the fact that the row was sitting in the savings sheet rather than one of the others, and stacking the sheets is exactly what destroys that.
That loss is not cosmetic. Without an account column you cannot rebuild any account's running balance, which removes the only check that ties the file back to the bank. You cannot recognise the two sides of a transfer, so the same money gets counted twice in any total. You cannot re-verify a figure against the statement it came from, because you no longer know which statement that is. And you cannot answer the one question a reviewer always asks, which is which account a given transaction went through.
Some of it can be guessed at afterwards, badly. A row for 5,000.00 that appears twice on the same date is probably a transfer, but a client with two identical standing payments turns that guess into a wrong answer, and nothing left in the file will catch it. Add the column before the merge, populate it with something stable like the last four digits of the account number, and the merge stays reversible.
A credit card runs in the opposite direction
The second condition is about signs. A bank statement reports what you hold; a card statement reports what you owe. Spending 200.00 reduces a current account balance and increases a card balance, so the identical transaction carries opposite signs on the two documents. Card layouts commonly print purchases as positive figures and payments received as negative or flagged CR.
Stack those sheets without touching the signs and card spending is added as though it were income. Here is a month where that happens.
The checking account opens at 8,420.15, takes 24,600.00 in credits and 21,180.40 in debits, and closes at 11,839.75. The savings account opens at 15,000.00 and receives 5,012.30, made up of a 5,000.00 transfer in from checking and 12.30 of interest, closing at 20,012.30. The card opens owing 2,310.60, takes 3,940.85 of purchases and a 2,310.60 payment that clears the previous balance in full, closing at 3,940.85 owed. The 5,000.00 transfer and the 2,310.60 card payment are both inside the checking account's debits.
Read as prose: checking moved by 24,600.00 less 21,180.40, which is 3,419.60. Savings moved by 5,012.30. The card sheet as printed moves by 3,940.85 less 2,310.60, which is 1,630.25. Adding the three gives 10,062.15.
The real figure is smaller. The combined position is cash held less card owed: 8,420.15 plus 15,000.00 less 2,310.60 at the start, which is 21,109.55, and 11,839.75 plus 20,012.30 less 3,940.85 at the end, which is 27,911.20. The month moved the position by 6,801.65.
That figure checks out from the external flows as well. Only 24,600.00 came in from outside, and only 13,869.80 left the checking account for outside parties once the 5,000.00 transfer and the 2,310.60 card payment are removed. Add 12.30 of interest and subtract 3,940.85 of card purchases: 24,600.00 less 13,869.80 plus 12.30 less 3,940.85 is 6,801.65.
The naive answer is 3,260.50 too high, and the overstatement decomposes exactly. Card purchases were added rather than subtracted, which is wrong by twice 3,940.85, or 7,881.70. The card payment was then counted as money leaving on the checking side and again on the card side, when the two should cancel, which is wrong by twice 2,310.60 in the other direction, or 4,621.20. The difference between them, 7,881.70 less 4,621.20, is 3,260.50.
The columns worth merging into
A canonical column set makes each statement's quirks somebody else's problem once rather than every month. Date, account identifier, account type, description, amount with one convention throughout, currency, the balance as printed on that statement, and the source page. The balance as printed is the column people leave out, and it is the one that lets you re-verify each account inside the merged file rather than reopening the statements.
- 1
Convert each statement on its own
Convert the three statement documents separately and confirm each one's balance chain closes against its own printed closing figure before anything is merged. - 2
Add the account identifier
Put a stable identifier on every row of every sheet. Do this while the sheets are still separate, when the value is obvious. - 3
Normalise the card signs
Invert the card amounts so spending is negative across all three accounts, and record that you did it. - 4
Stack the sheets
Concatenate into the canonical column set, keeping the printed balance and source page columns. - 5
Re-verify per account
Filter to one account, rebuild its running balance from its own opening figure, and compare every row against the balance printed beside it as well as confirming the last row lands on that account's printed closing figure. Repeat for each. - 6
Flag the transfer pairs
Mark the 5,000.00 checking to savings movement and the 2,310.60 card payment as internal on both sides so combined totals can exclude them.
Step five is the one to insist on. Rebuilding a single running balance down a merged sheet of three accounts produces a number that matches nothing printed anywhere, so the check has to be run per account. When a chain fails after a merge that passed before it, the cause is almost always a row that lost or gained a sign in step three. Finding the exact row that broke a balance narrows it down quickly.
Three institutions in one month is where per-bank templates cost the most, because each layout has to be described before a single row can be read out of it. Convert·Into identifies the issuing bank and its layout from the document itself, so the checking statement, the savings statement and the card statement go through the same pass, and each one arrives with its running balance already rebuilt and compared against the figure printed on it. What you stack, then, is three files that have each closed on their own, rather than three files one of which turns out after the merge never to have closed at all.
What the balance check gives you here
A merge invites the weak version of the check. Confirming that an account's opening figure and its closing figure differ by the sum of its rows tests one number, and a merge is an unusually easy place to create a pair of mistakes that cancel inside it: a sign inverted on one row and inverted back on another leaves that account's opening-to-closing movement exactly where it should be, and so does a row lost from the stack alongside a row of the same value duplicated into it. Step five asks for more than that. Rebuild the balance row by row from the account's own opening figure and compare each result against the balance printed beside that row on the statement. A misread amount then lands on a named row, and both cancelling pairs are flagged too, because the first inversion throws every subsequent recalculated balance out until the second one puts it back.
The limits are the ones that make a merge different. The arithmetic never reads a date or a description, and a row for 0.00 satisfies it whatever else is wrong. It never reads the account column either. That column is only protected indirectly, by the fact that you kept the balance as printed and rebuilt each account on its own, so a misfiled row shows up as a chain that will not close. Take the printed balance away and the protection goes with it: an export format that drops the column, or a card layout that never printed a balance beside each transaction, leaves that account testable only at its two ends, and a row assigned to the wrong account passes everything left in the workbook. A chain that holds is strong evidence the amounts came across faithfully. It is not proof that the file is right or that nothing is missing, and after a merge the account tag is the field most likely to be wrong while everything reconciles.
Three banks, one month, no templates
When the merge covers more than one month
Everything above scales, with one addition: a period column alongside the account column, so a twelve month merge can be filtered to a single account for a single month. That is the unit the balance check works on, and losing it costs the same thing losing the account column costs. The full-year mechanics, including statement periods that do not align to calendar months, are in converting a year of statements at once.
Transfers get worse at scale too. Three accounts over twelve months produce dozens of internal movements, and every one of them inflates both income and spending until it is paired off. Tracing transfers between accounts covers matching the two sides when dates differ by a day or an amount is split. Before you settle on how the workbook is written out, choosing an export format matters more for multi-account files than single ones, because a format that drops leading zeros will quietly damage the account identifier you just worked to preserve.
Frequently asked questions
Can I put checking, savings and credit card statements in one spreadsheet?
Yes, on two conditions. Every row must carry an account identifier so the rows can be separated again, and the credit card amounts must be sign-normalised to match the bank accounts before the sheets are stacked. Meet both and a merged workbook behaves exactly like three separate ones plus a filter.
Why does the account identifier have to be a column?
Because it is the only field that cannot be reconstructed after the merge. Dates, descriptions and amounts survive concatenation intact, but the fact that a row came from the savings account exists nowhere in the row itself. Once the sheets are stacked without it, no running balance can be rebuilt for any account and the only fix is to redo the merge from the source statements.
Why are credit card statement amounts the opposite sign to a bank account?
Because the balance they report is what you owe, not what you hold. A purchase increases a card balance and decreases a current account balance, so the same spending carries opposite signs on the two documents. Many card layouts print purchases as positive figures and payments received as negative or marked CR.
What happens if I stack a card statement onto bank statements without changing the signs?
Card spending is counted as money coming in. In a month with 3,940.85 of card purchases, a naive sum of the three accounts came to 10,062.15 while the real change in position was 6,801.65. The 3,260.50 overstatement is the card purchases counted the wrong way, 7,881.70, less the card payment counted as an outflow on both the checking and the card side, 4,621.20.
How do I check a merged workbook is still correct?
Filter to one account at a time and rebuild its running balance from its own opening figure, comparing every row against the balance printed beside it rather than only checking where the last row lands. Do this per account rather than on the merged sheet as a whole, because a combined running balance across three accounts corresponds to nothing printed anywhere. Checking only the closing figure lets a sign inverted on one row and inverted back on another pass unnoticed.
Should transfers between my own accounts be removed from the merged file?
Flag them, do not delete them. Each transfer appears twice in a merged workbook, as a debit in one account and a credit in another, and both sides are needed for the individual account balances to reconcile. Mark the pair as internal so any combined total can exclude them while the per-account chains stay intact.