Pull any practice's list of BAS amendments and a specific pattern shows up more often than it should: a client's own money, moved from one of their accounts to another, counted as income on the way in or an expense on the way out. Nobody intended it. It is also one of the easiest categories of error to prevent, because it has a mechanical signature almost every time.
Why it happens, specifically
A transfer between two accounts the same client controls produces two bank lines: a debit in one account, a credit in the other, usually for the same amount, usually within a day or two of each other. On its own, neither line carries any information that says "this is a transfer." A $12,000 credit into a business account looks, by itself, exactly like a $12,000 invoice payment. A $12,000 debit out of a different account looks exactly like a $12,000 supplier payment or a drawing.
The two legs almost never get coded in the same sitting. The receiving account might be reconciled the day the money lands. The paying account — often a personal account, a second business account, or a loan facility the bookkeeper doesn't look at every week — might not be touched for another fortnight. By the time it is, the context that made the first leg obvious has evaporated. Whoever codes it is looking at a bank line in isolation, not at a pair.
The two shapes this takes
Shape one: counted as income. A director tops up the business account from a personal savings account to cover a wages run. The deposit lands, gets coded to trading income because it is a credit with no invoice attached and the description is unhelpful, and it flows straight into G1. The client's GST turnover is now overstated by the exact amount of money that was never a sale.
Shape two: counted as an expense. The reverse of the same transaction — a loan repayment, an owner drawing, or a transfer to a related entity — gets coded as a business expense because it is a debit and something has to be picked. If it lands on a GST-coded account, the practice has just claimed input tax credits on money that was never a purchase.
Both are usually caught eventually. The expensive version is the one caught after lodgement, because an amendment costs real time and a credibility hit with the client, compared with a few minutes caught before you submit.
Why a coding rule doesn't solve this on its own
The instinct is to build a rule: "payments to Personal Savings Account → transfer, no GST." That works for exactly one client, on exactly the pattern you noticed. It breaks the moment the same bank, same description format, is used by a genuine third party — a supplier whose BSB happens to resolve to a description that looks identical to the client's own account, or a related entity that is sometimes a transfer and sometimes a genuine invoiced transaction between related parties.
The reliable signal isn't the description at all. It's the pairing: an amount, a date within a day or two, and a debit in one of the client's own accounts matched by a credit in another. That is a reconciliation-time check, not a per-transaction rule, because it requires looking at two accounts at once rather than one line at a time.
The habit that actually prevents it
Keep a standing register of every account a client controls, not just the ones you reconcile weekly. Business transaction account, savings account, a loan or line of credit, a related trust or company account if the client runs several entities. This takes ten minutes once and should be reviewed whenever a client mentions a new account — which happens more often than most practices update the register.
Before coding a large or round-numbered credit or debit as income or expense, check it against that list. Does the amount and the rough date match something on the other side of a known account? If the client has a loan account and a transfer of almost exactly that amount lands the same week, ask before you code it, don't guess.
Match at reconciliation, not at data entry. Whoever reconciles the second account needs visibility into what already happened on the first one. In practice this means the two legs should be flagged to each other — a note, a linked transaction, anything that survives the gap between when the first leg was coded and when the second one is.
Treat "GST" as the default-wrong answer for anything that turns out to be a transfer. A transfer has no GST code at all — not GST-free, not input-taxed, simply outside the scope of the BAS. If a transaction has been sitting coded with a GST code and it turns out to be a transfer, that is the signal the rule above wasn't applied, not just a one-off typo.
Where this fits with the rest of your reconciliation process
This sits alongside, not instead of, the balance check you should already be running. A transfer that is coded correctly as a transfer still has to actually clear both accounts — if the paying account's statement doesn't show the matching debit, you have a timing difference or a missing import, not a coding problem, and the fix is different.
ReconLink reads the PDF, CSV and Excel statements for every account a client gives it, and every coded line shows the rule that put it there — so a transfer that was coded as income stands out the same way any other rule mismatch does, because the rule used is visible rather than buried in the posting. It codes around 99% of lines before you look at them, which is exactly why the remaining 1% — the unusual round-numbered transfer with no invoice behind it — deserves the few minutes of attention this one takes. $99 a month, ex GST, unlimited clients and unlimited seats. Thirty days free, no card.
Frequently asked questions
How do I tell a transfer apart from a real payment at a glance?
Look for a round or matching amount, a date within a day or two of a corresponding entry in another account you know the client controls, and the absence of an invoice or bill behind it. None of those alone is proof — together, they are the pattern worth checking before coding.
What GST code should a confirmed transfer get?
None. A transfer between a client's own accounts sits outside the scope of the BAS entirely — it is not GST, not GST-free, and not input-taxed, because it was never a supply.
Can a coding rule catch inter-account transfers automatically?
Only partially, and only per client. A rule built on the receiving bank's description can misfire against a genuine third-party payment that happens to carry a similar description. The reliable check is matching the amount and date against a known list of the client's own accounts, which is a reconciliation-time check rather than a rule applied to one line.
What if the two legs are reconciled by different people on different days?
That is exactly when this error happens. Keep a shared, standing register of every account the client controls, and have whoever codes a large or unexplained credit or debit check it against that list before assuming it's income or an expense.
Does this only affect clients with multiple bank accounts?
It affects any client who moves money between two accounts you both reconcile — which includes a business account and a personal account used for drawings, a business account and a loan facility, or two related entities. A client with a single account has nowhere for this error to come from.
The short version
A transfer between a client's own accounts should have zero effect on the BAS, and it usually does — right up until the two legs are coded separately, days apart, by someone who no longer has the context that made the first one obvious. Keep a standing list of every account a client controls, check unexplained round-numbered movements against it before coding, and treat a GST code on a confirmed transfer as a sign the check was skipped.