Separating business from personal on a mixed account

Everything went through the one current account: client payments, the weekly shop, software subscriptions, a car repair that was half for work. Twelve statements, several hundred rows, and no marker anywhere on the account that says which side of the line a transaction belongs on.

Converting the statements is step one, and it is the short step. The extraction gives you a clean, dated, verified table. What it cannot give you is purpose, because purpose was never written on the account in the first place. The split itself is a tagging pass done by someone who was there, and the useful question is how to make that pass checkable rather than how to avoid it.

Convert and verify before you tag anything

Tagging a file whose amounts have not been checked wastes the tagging. Convert every statement for the period, confirm each one's opening balance plus credits less debits lands on its printed closing balance, and confirm each month's closing balance equals the next month's opening balance.

That second check is strong evidence that the months you hold run continuously into one another. It is not proof that the set is complete. It cannot show that a statement was never issued for a period you never obtained, and a quiet month that closes on the balance it opened with will chain onto the wrong neighbour without breaking any arithmetic. So read the period dates as well: the periods have to form an unbroken calendar, with no gap between one period's end and the next period's start. A missing month in a mixed-account reconstruction becomes invisible once the rows are shuffled into categories, which is why it has to be caught before the tagging starts.

Only when all of that holds should you add a tag column, because from that point on you are building on figures that agree with the bank.

The control total is what makes the pass auditable

Before tagging, record the total you are splitting. In this example the year's debits total 61,482.90. When the pass is finished, the categories have to add back to that figure exactly.

• Business: 18,940.35
• Personal: 42,010.55
• Internal transfers to own savings: 532.00

Those three sum to 61,482.90, matching the untagged total, so no row has fallen out of the pass unaccounted for. Like any control total it can be defeated by two errors that cancel each other, but it catches the common failure at the cost of one formula. A pass without it can look finished while three rows sit untagged in the middle of March, and nothing on the screen will say so.

Tag by description group, not row by row

Working down a year in date order is the slowest possible order, because it makes you decide the same merchant thirty times. Sort by description instead and the work collapses.

1. 1

   Sort by description and group

   Bring every occurrence of each merchant together. A subscription that appears monthly becomes one decision applied twelve times.
2. 2

   Clear the unambiguous merchants first

   Anything that is always business or always personal gets tagged in a block. This usually clears most of the row count in a single sitting.
3. 3

   Sort the remainder by amount, descending

   Work down from the largest. The rows near the top carry the value; the ones at the bottom are worth less than the time spent arguing about them.
4. 4

   Decide the one-off rows individually

   These are the genuine judgements. Note the reason on any row you would struggle to explain in six months.
5. 5

   Close the control total

   Confirm undecided is empty and the categories add back to the untagged figure exactly.

Descriptor grouping has one trap. Banks truncate and reformat descriptions inconsistently, so the same merchant can appear under three strings, one of which carries a store number or a date. Group on the stable leading portion of the description rather than on an exact match, and check the residue for strings you have already decided under another spelling. The same grouping technique applied to a whole year of spending is worked through in categorising a year of spending.

Rows that are genuinely both

A card payment covering a work laptop and a household item needs splitting rather than labelling. Push the whole row into either category and the figure is wrong by the size of the portion you ignored.

Add two allocation columns, a business portion and a personal portion, with the rule that they sum to the transaction amount. A 412.60 purchase allocated as 275.00 business and 137.60 personal satisfies that: 275.00 plus 137.60 is 412.60. The transaction row itself is untouched, so the statement's running balance still recalculates correctly and the file remains verifiable against the bank.

If you instead split the row into two rows, the two amounts must sum to the original to the cent, and the balance chain has to be rebuilt afterwards to confirm it still closes. The allocation column approach avoids that entirely, which is why it is the one to prefer on a file that anyone else will review.

What the verification does and does not settle

It is worth being exact about this, because a mixed-account split is where people most often overstate what a check has proved. A running balance that recalculates line by line and lands on the printed closing figure proves the amounts in the file match what the bank recorded. That is the strongest automatic check a converted statement can carry, and it catches the error that matters most, a wrong digit in an amount, because a misread amount breaks the arithmetic and cannot pass silently.

It does not verify dates or descriptions, a pair of errors that perfectly offset one another survives it, and it has no opinion on categorisation at all. A row tagged business that was personal sits inside a chain that closes perfectly. The verification secures the numbers you are tagging; the tags remain your work and your responsibility.

Keep the split defensible

What separates a split you can stand behind from one you merely remember doing is what survives alongside it. Keep the converted statements with the balance check evidenced. Keep the tag column in the same file as the transactions rather than in a separate summary, so any figure can be traced back to the row that produced it. Keep a short note of the rules you applied, including the merchants you tagged in blocks and the basis for any allocation percentage you used more than once.

Where the tagged business figures feed a return, what a statement line can and cannot establish about a cost is set out in using bank statements as proof of a deduction, and the mapping into a sole-trader schedule is covered in building a Schedule C from bank statements. Whether a tagged cost qualifies is a decision for your own tax preparer, working from the split you produced rather than in place of it.

If the business also ran through a second card or a savings account, do not tag them in isolation. Merge them into one workbook with an account identifier on every row first, then tag once across the combined file. Tagged in isolation, a transfer between two of your own accounts lands as income on one side and a cost on the other, and both figures are wrong. The mechanics of that merge, including the sign convention a credit card brings with it, are in combining several accounts into one workbook.