Common GST coding mistakes and how to catch them

Why GST coding goes wrong

GST looks binary, ten per cent or nothing, but the system actually runs on taxable, GST-free and input taxed categories, plus bills that mix components on a single line. Accounting software then applies whatever code got set once, right or wrong, to every future transaction through bank rules and defaults. One wrong default, multiplied by twelve months, is exactly how a small misunderstanding turns into a material BAS error.

The classic mistakes

• Claiming GST on bank fees and merchant charges, most of which are input taxed financial supplies with nothing to claim; some merchant service fees do include GST though, so check the statement rather than assuming either way
• Coding wages, superannuation and PAYG withholding with GST attached; payroll has no GST component at all
• Claiming GST on government charges such as ASIC fees, council rates, vehicle registration components and stamp duty
• Treating a whole insurance premium as creditable when part of the bill, stamp duty for instance, carries no GST
• Claiming GST on purchases from suppliers who aren't GST registered, where the invoice shows none because none was charged
• Miscoding overseas software subscriptions and imports; some overseas suppliers do charge Australian GST and some don't, so read the invoice rather than guessing
• Claiming a full GST credit on items with private use, instead of apportioning the business share
• Coding GST-free basic food, exports or medical services as taxable sales, which overstates GST collected

Interest, loans and other traps

Loan repayments get a special mention here. The principal component isn't an expense at all, and the interest is input taxed, so nothing about a loan repayment belongs anywhere near a BAS as a creditable purchase. Transfers between your own accounts, owner drawings and dividend payments sometimes get scooped up as expenses with GST by overeager bank rules too. None of them belong in the GST report. Full stop.

How to catch errors before they lodge

The fix isn't more care per transaction, it's a review layer that runs before every BAS. A structured pre-lodgment check takes well under an hour on a reasonably clean file, and catches nearly everything worth catching.

Run the GST audit or exception views in your software and scan for accounts pairing with tax rates that don't belong: any GST showing up on wages, super, bank fee or government charge accounts is an instant flag. Compare this period's GST collected against sales, which should sit close to one eleventh of GST-inclusive taxable sales; a drifting ratio means coding has shifted somewhere. Then check the bank rules directly, because fixing a bad rule fixes every future transaction, while fixing one transaction only fixes the one.

Correcting past mistakes

Finding historical errors is normal, and usually manageable. Many GST errors can be corrected on a later activity statement within limits the ATO sets, rather than amending old lodgments outright. The right path depends on the size and direction of the error, so quantify it first and let your BAS or tax agent choose how to fix it. What actually matters is fixing the cause at the same time, otherwise the same correction turns up again next quarter, and the quarter after that.

Where NextEra fits

Every NextEra file runs through a structured GST review before lodgment, and because the books are managed monthly, coding errors get caught within weeks rather than compounding across a year. Suspect your file's drifted? The Strategic Finance Review includes exactly this kind of coding health check.