GST and Tax Code Mapping: Why Your Systems Disagree and How to Fix It
Almost every integration that touches money eventually produces a small, stubborn discrepancy. The sales figure in the store does not quite match the ledger, the GST collected does not quite match the sales, and nobody can explain a difference small enough to ignore for months and large enough to matter at the end of a year.
It is very rarely a broken connection. It is almost always tax: a code that was never mapped, a rounding rule applied at a different level in each system, freight taxed one way in the store and another in accounting, or a marketplace remitting GST that your ledger has also recorded. This page sets out where those differences come from and how to design them out rather than reconcile them forever.
Realistic ROI
Four Reasons Integrated Systems Disagree on Tax
These four account for the overwhelming majority of unexplained differences between a sales system and a ledger.
Every system has its own tax vocabulary
An online store thinks in tax classes and rates. A point of sale thinks in tax groups. An accounting system thinks in tax codes with specific meanings and specific effects on the activity statement. None of these vocabularies map one to one, and the translation has to be written down deliberately. The dangerous cases are the codes that look equivalent but are not, such as a zero rate applied to something that is genuinely GST free versus a zero rate applied to something out of scope entirely, because both produce a zero on the invoice and different lines on the BAS.
Rounding is a design decision, not a detail
Tax can be calculated and rounded on each line and then totalled, or calculated on the invoice total. Prices can be held inclusive or exclusive of GST, and converting between the two introduces fractions of a cent. Two systems that make different choices will disagree by small amounts on almost every multi line transaction, and those amounts are individually too small to chase and collectively large enough to make a reconciliation impossible. Agreeing the rounding approach once, and making the integration respect the receiving system’s method, removes an entire class of problem.
It is the edges that break, not the standard sale
A standard rated product sold to an Australian customer is easy and every system handles it. The differences appear on freight, on surcharges, on discounts that span mixed tax lines, on deposits and layby, on gift cards where GST attaches at redemption rather than sale, on refunds and partial refunds, and on adjustments. Each of these needs an explicit decision about which account it lands in and which code it carries, and each one left to a default is a future difference nobody will be able to trace.
Somebody else may already be collecting the tax
When you sell through a marketplace, the operator can be liable to collect and remit GST on the sale rather than you. The money that reaches your bank is then net of tax somebody else has already accounted for. If your integration records those sales as though you collected the GST, your activity statement will overstate what you owe and the settlement will never reconcile. The same category of problem arises with low value imported goods and with exports, where a sale that is GST free still has to be recorded as GST free rather than as taxable or out of scope.
What a Proper Tax Mapping Covers
The six areas that need an explicit decision before an integration posts its first transaction.
The code translation table
A table with a row for every tax situation your business encounters and a column for each system, showing what the code is called in each place and which one is authoritative. Taxable sales, GST free food or medical lines, input taxed supplies, exports, capital purchases, purchases from suppliers who have not quoted an ABN, and anything genuinely out of scope. Producing this table is usually a couple of hours with your accountant and it prevents more reconciliation work than any other single artefact.
Product level assignment
The tax treatment attaches to the product, not to the channel, and the source of truth for it is normally the ERP or accounting system rather than the store. A business selling a mix of standard rated and GST free lines needs each product to carry its own treatment through every system it appears in, and needs a rule for what happens when a new product arrives without one. Blocking a new product from selling until its treatment is set is inconvenient once and much cheaper than correcting a quarter of transactions.
Freight, surcharges and discounts
Delivery charges, card surcharges, packaging fees and discounts each need their own account and code rather than being absorbed into the product line. Discounts that span a mix of standard rated and GST free lines need an apportionment rule, because applying the whole discount to one or the other quietly changes the tax collected. These are small decisions that take minutes to make in advance and hours to unpick per period afterwards.
Rounding and price basis
Whether prices are held inclusive or exclusive of GST in each system, whether tax rounds at line or invoice level, and which system’s method the integration defers to when they differ. Where a difference is unavoidable, it is directed to a designated rounding account with a threshold that triggers an alert if it grows, so a systematic problem is visible rather than absorbed.
Refunds, credits and adjustments
A refund has to reverse the original tax treatment rather than apply a default, which means the integration needs the link back to the original transaction. Partial refunds, restocking fees, price adjustments and goodwill credits each behave differently. Under Australian Consumer Law a remedy for faulty goods is a different transaction to a change of mind return, and the finance treatment and the stock consequence should both reflect that.
Reconciliation to the activity statement
A monthly check that sales and GST recorded in the source systems equal what reached the ledger, split by tax treatment, with any difference listed by reason rather than netted off. Doing this monthly rather than quarterly means a mapping error is found while the period is still open and the volume of affected records is small, which is the difference between a correction and a project.
Tax Situations and How They Should Be Handled
| Task | Traditional | Mapped Properly | Notes |
|---|---|---|---|
| Standard rated sale | Works everywhere | Mapped and verified | The easy case, and the reason mapping errors elsewhere go unnoticed for so long. |
| GST free food or medical lines | One store wide rate | Per product treatment | Needs the treatment on the product record, owned upstream and carried into every channel. |
| Freight and delivery | Absorbed into the sale | Own account and code | Treatment can follow the goods. Agree the rule with your accountant rather than guessing. |
| Marketplace sale where the operator remits | Recorded as your GST | Recorded as remitted by the operator | Otherwise the activity statement overstates the liability and the payout never reconciles. |
| Gift card sold, redeemed later | Taxed at sale | Recognised at redemption | Sale and redemption are different events. Getting this wrong shifts revenue between periods. |
| Discount across mixed tax lines | Applied to whichever line is first | Apportioned by rule | Small per transaction, systematic over a quarter, and hard to explain afterwards. |
| Partial refund with restocking fee | Entered manually | Linked to the original | The reversal must follow the original treatment, and the fee is its own taxable supply. |
| A product with no tax treatment set | Defaults to standard | Blocked and queued | Stopping the record is cheaper than correcting three months of transactions later. |
Where Tax Mapping Goes Wrong
A single default code was applied to everything
The fastest way to get an integration live is to map every transaction to one code, and it works perfectly until the business sells something that is not standard rated. From then on the error is systematic and invisible, because nothing fails and the totals still look plausible. Map at product level from the outset even if today every product happens to carry the same treatment, because the cost of adding the capability later includes correcting everything posted in between.
Zero rated and out of scope were treated as the same thing
Both produce no GST on the invoice, and they belong on different lines of the activity statement. A GST free sale is a taxable supply that happens to be free of GST and it counts towards your reported sales. Something genuinely out of scope does not. Collapsing the two makes the invoice look right and the statement wrong, which is the hardest kind of error to detect because every document a customer sees is correct.
Nobody decided what happens to an unmapped product
A new product arriving in the store without a tax treatment will be given whatever the default is, and defaults are almost always standard rated. For a business selling GST free lines that means quiet overcollection until somebody notices. The right behaviour is to refuse to publish or refuse to sync the product and put it in a queue that a person clears the same day. It feels obstructive for a week and it saves a correction project.
Marketplace settlements were reconciled net
Marketplace payouts arrive net of commission, fees, refunds, promotional contributions and, where the operator is liable, GST it has already remitted. Recording only the net amount that hits the bank makes the ledger balance and destroys the detail, so gross sales, fees and tax cannot be reported separately and any discrepancy in the operator’s calculation is invisible. Book each component to its own account and reconcile the total against the payout, rather than the other way around.
The mapping was never rechecked after a change
A new product category, a new sales channel, a new payment method, a change in what a supplier charges, or a platform update that adds a tax class can all invalidate a mapping that was correct when it was written. Review the table when any of those happen and at least annually, and keep the reconciliation running monthly so a new gap shows up while the period is open. Treat the mapping as a living document with an owner, not a one off configuration.
Records were kept only in the integration
The Australian Taxation Office expects records supporting your activity statements to be retained and to be in a form that can be produced, generally for five years. If the only place a transformation is recorded is inside an integration nobody can see into, you cannot demonstrate how a figure was derived. Keep the mapping table, the transformation rules and record level logs of what moved and when, and make sure they survive a change of supplier or platform.
How Yes AI Handles Tax in an Integration
The mapping table before the build
We produce the code translation table, walk it through with your accountant or bookkeeper, and get it signed off before any transaction posts. It takes a couple of hours and it is the cheapest insurance in the project. The table is yours to keep whoever operates the integration afterwards.
Product level treatment, owned upstream
Tax treatment attaches to the product record in the system that owns it and travels with the product into every channel. New products without a treatment are blocked and queued rather than defaulted, so the error is a five minute task instead of a quarterly correction.
Monthly reconciliation by treatment
A monthly check that sales and GST recorded in the source systems match the ledger, split by tax treatment, with differences listed by reason rather than absorbed. Rounding differences go to a designated account with a threshold that alerts if it grows beyond noise.
We work with your accountant, not around them
Tax treatment decisions belong to your accountant or tax adviser and we implement what they confirm rather than substituting our judgement for theirs. Where a situation is genuinely unclear, we will say so and ask rather than pick a plausible default and move on.
From Unexplained Differences to a Clean Reconciliation
Five steps. A mapping review on an existing integration is normally a week, and the correction work depends on what it finds.
Inventory the tax situations
Every kind of supply the business makes and every kind of purchase it records: standard rated, GST free, input taxed, exports, capital, and anything unusual to your industry. Confirmed with your accountant rather than inferred from the current configuration.
Build the translation table
A row per situation and a column per system, with the authoritative source named for each. Freight, surcharges, discounts, deposits, gift cards, refunds and adjustments each get their own row rather than being assumed to follow the goods.
Settle rounding and price basis
Inclusive or exclusive pricing per system, line or invoice level rounding, which method the integration defers to, and where unavoidable differences are posted. Documented with a threshold that triggers an alert if the rounding account grows.
Test against real transactions
A sample covering every row in the table, including the awkward ones, posted into a copy of the ledger and checked line by line against what your accountant expects. Nothing goes live on the assumption that the standard case working means the rest will.
Reconcile monthly and review on change
A monthly check by tax treatment with differences explained rather than netted, the table reviewed whenever a channel, product category or platform changes, and record level logs retained so any figure can be traced back to its source.
Related Reading
SaaS Integration Explained
The six patterns and the decisions behind them.
MYOB AccountRight Integration
Posting into the ledger with the codes mapped properly.
Payment and Settlement Reconciliation
Matching payouts, fees and chargebacks to the ledger.
Marketplace Integration
Selling on channels where the operator may remit the GST.
Cross Border and Multi Currency
Exports, imports and currency in connected systems.
Custom API Integration
When the connector you need does not exist yet.
FAQ
Stop Chasing Cents Every Quarter
Book a tax mapping review. We build the translation table, check it with your accountant, and tell you where your current integration is quietly getting it wrong. The table is yours either way.
All discussions held in confidence. Australian-based consultants.