Yes AI. AI consulting for Australian businesses.
Forms and calculators require JavaScript. You can still read this page and contact us by phone or email.
Call (03) 9003 0111 | hello@yesai.au
Interactive controls are loading. Phone and email links are available.
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.
These four account for the overwhelming majority of unexplained differences between a sales system and a ledger.
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.
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.
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.
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.
The six areas that need an explicit decision before an integration posts its first transaction.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
Five steps. A mapping review on an existing integration is normally a week, and the correction work depends on what it finds.
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.
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.
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.
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.
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.
The six patterns and the decisions behind them.
Posting into the ledger with the codes mapped properly.
Matching payouts, fees and chargebacks to the ledger.
Selling on channels where the operator may remit the GST.
Exports, imports and currency in connected systems.
When the connector you need does not exist yet.
In our experience there are four usual causes and it is often more than one. Rounding applied at different levels, meaning one system rounds tax per line and the other on the invoice total. Freight or surcharges treated differently in each place. Discounts applied across a mix of standard rated and GST free lines without an apportionment rule. And refunds posted with a default treatment instead of reversing the original. Each produces small amounts on individual transactions and a persistent, unexplainable difference over a quarter. The fix is a written mapping and an agreed rounding method rather than a monthly hunt.
They should be recorded as sales with the GST identified as remitted by the operator rather than collected by you, so your activity statement reflects your actual liability. What makes this awkward in practice is that the money arriving in your bank is net of commission, fees, refunds and that tax all at once. The workable pattern is to book gross sales, then each deduction to its own account, then reconcile the resulting total against the actual payout. If the treatment for a particular channel is unclear, confirm it with your accountant, because it depends on the arrangement and on how the operator characterises the supply.
Map at product level, even if every product you sell today carries the same treatment. The cost of doing it now is one extra field and a rule; the cost of adding it later includes correcting every transaction posted in the meantime, which for a busy store can be tens of thousands of records across several periods. Businesses also add product categories more often than they expect, and the first GST free line usually arrives without anyone thinking to check the integration. A per product mapping means that arrival is uneventful.
It should not sync and it should not go on sale. Put it in a queue that a person clears, ideally with a notification the same day. The instinct is to let it through with a sensible default so nothing is blocked, and that instinct is what produces quiet overcollection or undercollection that only appears at a quarterly reconciliation. Blocking feels obstructive for the first week while people adjust, and after that it becomes a routine five minute task that prevents an entire class of correction work.
The essential point is that selling a gift card and redeeming it are different events, and the GST generally attaches to the supply of the goods at redemption rather than to the sale of the card. An integration that records a gift card sale as ordinary revenue overstates sales and GST in one period and understates them later, which distorts both the activity statement and the sales reporting people manage the business with. The liability side also matters: unredeemed balances sit as a liability rather than revenue. Get your accountant to confirm the treatment for your specific programme, then implement exactly that.
Yes, and the sequence matters. First establish the scope by identifying every affected transaction type and counting the records and dollars involved, rather than sampling. Then correct the mapping so the error stops immediately. Then decide with your accountant how the historical period should be dealt with, which may involve amended activity statements depending on the size and nature of the error. Do those three in that order, because correcting history while the cause is still live means doing it twice, and the second pass is always harder than the first.
No, and you should be wary of an integration supplier who does. We build systems that implement the treatment your accountant or tax adviser confirms, and we are careful to ask rather than assume when a situation is unclear. What we do bring is knowledge of where integrations typically get tax wrong, which means we ask the questions that surface a problem before it is built rather than after. The mapping table we produce is designed to be reviewed and signed off by your adviser, and that review is a required step in our process, not an optional one.
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.