Bookkeeping · Daily Workflows · Brief · Intro level
Recording transfers between your own accounts correctly
Bank-to-bank moves are neither income nor expense — they are the same money changing pockets. The entry, the double-count trap when both feeds report the same move, and how to prevent it.
Moving money from business checking to business savings — or from a payment processor to the bank, or from one checking account to another — is not income and not expense. Both pockets are yours; the business is neither richer nor poorer. The entry lives entirely on the balance sheet, and the whole skill of handling transfers is recording each move exactly once, even though two bank feeds will each report their half of it.
The entry
Moving $2,400 from checking to a tax-savings account:
| Account | Debit | Credit |
|---|---|---|
| Cash — tax savings | 2,400 | |
| Cash — operating checking | 2,400 |
Two asset accounts, no P&L line. Total cash is unchanged; only its location moved.
Every software package has a transfer function that posts exactly this. Use it — or match the second feed item to the first — and the books stay true.
The double-count trap
Here is how the trap springs. The checking feed shows "−$2,400 TRANSFER TO SAVINGS" and you categorize it as, say, "Taxes" or "Miscellaneous expense." Days later the savings feed shows "+$2,400 TRANSFER FROM CHECKING" and you categorize it as income. You have now invented $2,400 of expense and $2,400 of income out of a move that was neither. Profit may net to roughly zero, but revenue and expenses are both inflated — which distorts margins, can overstate gross receipts figures that various tax thresholds key off, and makes the books unreconcilable against reality.
The prevention is procedural, and it is question one of the categorization decision tree:
- Scan every feed session for transfer-shaped items first — the word TRANSFER, round amounts, your own account numbers in the description.
- Record (or accept) the transfer once, from whichever side appears first.
- When the mirror item arrives on the other feed — often one to three days later — match it to the existing transfer instead of adding anything.
- At month-end, confirm every transfer out has a partner in: an unmatched half is either in transit or a mistake.
Transfers in disguise
Three common transactions are transfers wearing costumes:
- Credit card payments. Checking to card is a transfer against a liability, not an expense — the expenses were the charges. Full treatment in credit card transactions.
- Processor payouts. A Stripe or Square deposit is a transfer from your processor clearing account, where the individual sales (and fees) were already recorded. Categorizing payouts as sales double-counts revenue.
- Owner money crossing the business boundary. Moving money between the business and your personal account is not an internal transfer — it is an owner contribution or draw, a genuinely different entry covered in mixed personal and business spending.
The habit that catches all of this is the weekly feed review with match-before-categorize discipline — and clean transfers are half of what makes month-end reconciliation take minutes instead of hours. Your reported income ultimately rests on the books telling cash movements straight, which is precisely the recordkeeping standard Publication 583 describes.
Frequently asked questions
- Is a transfer between my business checking and savings income or an expense?
- Neither. Both accounts belong to the business, so the move changes where cash sits, not how much you have earned or spent. The entry touches only balance-sheet accounts: debit the receiving account, credit the sending account. Nothing reaches the profit-and-loss.
- Why does the same transfer show up twice in my bank feeds?
- Because both banks report it — the sending account shows money out, the receiving account shows money in. Those are two views of one transaction. Record the transfer once and match the second feed item to it; categorizing each side separately creates a phantom expense and a phantom income entry.
- How should payment processor payouts like Stripe or Square be recorded?
- As transfers from a clearing account, not as income. Sales are recorded when they happen, into a processor clearing account; the payout that lands in checking days later is a transfer out of that clearing account. Categorizing payouts as sales double-counts revenue and hides processing fees.