For product businesses that run as a group of related entities

Intercompany Transactions: When the Shop Sells Stock Another Entity Owns

Plenty of Australian product businesses are not one business on paper. An importing company sells to a retail company. A trading trust sits behind a corporate trustee. A separate entity holds the stock or the brand. A New Zealand company sells the same range across the Tasman. The website and the shop counter look like one business to customers, but every sale quietly creates obligations between entities, and those obligations have to land in two sets of books, the same way, every time.

Most groups handle this with a monthly spreadsheet and a set of invoices someone raises by hand, and the intercompany accounts never quite agree. This page explains how the flows should work: who owns the stock at each step, how one source event can create the invoice and the matching bill on both sides, why intercompany balances drift and how to stop them, what changes with GST groups and New Zealand, and when a single ERP holding several companies is a better answer than integrating separate ledgers.

Book an Intercompany Review (03) 9003 0111

The Shape of the Problem

2 ledgers

Every intercompany transaction must land in

A sale on one side and a purchase on the other, same amount, same date, same reference, or the balances drift

1 source event

Should create both sides

When two people or two processes raise each side separately, mismatches become likely

2 to 5 entities

Is common for an Australian product group

Varies by group. A common mix is an importer, a retailer, a trust or trustee, and perhaps a stock or IP entity and an NZ company

Zero

Is what intercompany should net to on consolidation

Receivables, payables, revenue and cost between group entities should eliminate cleanly, if both sides were posted the same way

Four Decisions That Come Before Any Intercompany Automation

The integration is the easy part. These four questions are the hard part, and they belong to the owners and the accountant, not the developer.

Which entity owns the stock, and when

Is the retail company buying stock from the importer when it arrives in the shop, or only at the moment a customer buys it? Is the retail entity acting as an agent selling on behalf of the stock owner? Each model produces different entries, different stock balances, different GST outcomes and a different answer to who records the revenue. Pick one deliberately, document it, and get your accountant to confirm it before anything is built, because the integration will faithfully repeat whatever model you choose thousands of times.

How the intercompany price is set

The price one entity charges another is a business and tax decision, usually cost plus a margin, a percentage of retail, or a fixed price list. It needs to be set with advice from your accountant, written down, and reviewed periodically. The integration should read that price from one maintained source, a price list or a rule table, rather than having it typed into invoices. When New Zealand or any other overseas related party is involved, transfer pricing considerations apply and professional advice is not optional.

Which system creates which side

For each flow, one system and one process must be the origin. The usual pattern is that the selling entity generates the intercompany invoice from a real event, a daily sales summary, a stock receipt, a monthly service charge, and the integration creates the matching bill in the buying entity from that same record. If finance in one entity can also create intercompany invoices by hand, you need a rule that says how those reach the other side, or they will not.

Which entity owns the customer

When a storefront run by one entity collects a customer who buys stock owned by another, someone has to be the business the customer is dealing with for privacy, consumer law and marketing purposes. That should be clear in your privacy policy and terms, and it determines where the customer record lives and who may use it. Deciding this after a group wide email list has been built from every entity is far harder than deciding it first.

How Intercompany Flows Are Automated

Six mechanisms that replace a monthly catch-up with regular postings and reconciliation checks, with exceptions on a short list.

Rules per flow

Stock ownership model

The design starts by writing down every movement between entities: stock received by the importer then supplied to the retailer, stock held by a stock entity and sold by a trading entity, services charged by a head entity, brand or IP fees, staff costs recharged. For each one: who owns it before and after, what triggers the transfer of ownership, what price applies and how often it is invoiced. Check the structure too: a trading trust and its corporate trustee are often one set of books, not two, because the trustee trades on behalf of the trust. This document is short, usually two or three pages, and it is the specification every later step depends on.

Both sides at once

Paired invoice and bill

From one source record the integration posts an invoice in the selling entity and the matching bill in the buying entity, with the same reference, date, lines, tax treatment and amount, then links them so either can be traced to the other. In Xero or MYOB that means two separate organisations or company files written to in one controlled step. In NetSuite OneWorld or Business Central, the native intercompany features can create the paired transaction for you, and the integration feeds them rather than replacing them.

Readable ledgers

Summarised, not per order

A retailer selling stock owned by a related importer does not need an intercompany invoice per online order. A daily or weekly summary invoice per entity pair, listing quantities sold by SKU at the agreed intercompany price, is easier to read, reconcile and audit. As an illustrative example, a group with 400 online and in store orders a day might produce one intercompany invoice per day rather than 400, with the order level detail kept in the integration log for anyone who needs it. The same SKUs should be used in every entity, from one product catalogue owned by one entity, so an intercompany line always matches the item the customer bought, while each entity holds its own cost: the intercompany price becomes the cost of goods in the buying entity.

Cleared balances

Settlement and netting

Intercompany invoices are often settled by netting rather than cash: the retailer owes the importer for stock, the importer owes the retailer for shared rent or wages, and once a month the difference moves. Netting is fine if it is recorded as a payment on both sides against specific invoices. It goes wrong when one entity records a lump sum transfer to a loan account and the other allocates it to invoices, which is the most common cause of balances that agree in total but not in detail.

Same month, both sides

Cut-off and period locks

Both sides of an intercompany transaction take their date from the source event, not from when the integration ran or when a person got to it. A sale on the last evening of June belongs in June in both ledgers. The integration runs a final pass after midnight on the last day of the month, posts anything outstanding with the correct date, and only then are periods locked. Without this rule, year end produces timing differences that look like errors and consume an afternoon to explain.

Clean consolidation

Reconciliation and eliminations

A daily or weekly check compares the intercompany receivable in each entity with the matching payable in its counterpart, transaction by transaction, in the currency of the invoice. Differences go to an exception list with the reason. At month end the matched balances feed consolidation, where intercompany sales and purchases, receivables and payables, and any unrealised profit in stock still held inside the group are eliminated. Whether that consolidation happens in the ERP, a reporting tool or a spreadsheet, it is only as good as the matching underneath it.

Common Intercompany Flows and How They Should Work

Task	Traditional	Done Properly	Notes
Retailer sells stock the importer owns	Monthly invoice from a stock report	Daily summary invoice and bill from actual sales	Priced from the agreed intercompany price list. The sales data already exists, so the invoice should come from it rather than from a count.
Stock moved into the retail entity in bulk	Transfer recorded in one ledger only	Supply invoice and matching bill on receipt	Physical movement between warehouses is covered by stock transfer processes. This is the ownership and accounting side of the same event.
Head entity charges a management fee	Recurring invoice, bill entered by hand	Generated both sides from one schedule	Basis and amount set with your accountant. Automation removes the typing, not the need to justify the charge.
Brand or IP entity charges a licence fee	Calculated quarterly in a spreadsheet	Calculated from reported sales, posted both sides	The calculation inputs should be visible and reproducible, because these charges attract questions from advisers and occasionally the ATO.
NZ company buys from the AU company	Invoice in AUD, bill keyed in NZD later	Invoice currency agreed, both sides posted from one record	Cross-border related party dealings raise transfer pricing considerations. Get advice on pricing and documentation before automating.
Customer pays the wrong entity	Journal in each ledger, often mismatched	Paired receipt and intercompany clearing entry	Common when one bank account or one payment gateway serves several entities. The integration records who received the money and who earned it.
Shared wages, rent and software	Annual recharge, argued about	Monthly recharge from an agreed allocation	The allocation basis belongs in writing. Small, regular recharges are far easier to reconcile than one large catch-up.
Month end consolidation	Days chasing differences between entities	Matched balances, short exception list	Eliminations are mechanical once both sides agree. The time saved comes from the matching, not the consolidation step itself.

Where Intercompany Automation Goes Wrong

Automating before the ownership model is agreed

If nobody can say in one sentence when the retailer becomes the owner of a unit of stock, the integration will encode a guess. That guess then shows up as stock on hand in the wrong entity, GST reported by the wrong entity, or revenue recognised twice in group reporting. Write the model down for each flow, have your accountant confirm the accounting and tax treatment, and only then specify the integration.

Assuming a GST group makes intercompany invisible

Entities in a GST group generally do not account for GST on supplies made between group members, and one representative member reports for the group on the BAS. That simplifies tax, but it does not remove the need for intercompany invoices and balances: each entity still has its own profit and loss and balance sheet. Forming a GST group has conditions, including GST registration for every member, common ownership and an Australian resident representative member, and an NZ company also has its own NZ GST position, so confirm with your accountant what applies and set the tax codes on intercompany lines accordingly.

Different GST rounding on each side

One system rounds GST per line, the other per invoice. The difference is a few cents per invoice, and it is enough to stop intercompany balances agreeing. When the group is not in a GST group, or a line is taxable for another reason, post the bill with the exact tax amounts from the invoice rather than letting the receiving ledger recalculate them.

Comparing AUD and NZD balances at different rates

An NZ entity holding a payable in AUD, or an AU entity holding a receivable in NZD, will revalue at month end. If each side uses a different rate source or a different revaluation date, the balances will never agree in either currency. Agree the invoicing currency for each flow, reconcile intercompany in that transaction currency, use one rate source for both entities, and treat the residual exchange difference as an expected consolidation item rather than an error.

Manual credits on one side only

Someone in the retail entity raises a debit note for damaged stock, or someone in the importer issues a credit for a pricing error, and the other entity never hears about it. This is the slow leak that makes intercompany reconciliation a quarterly argument. Route intercompany credits through the same automated flow as invoices, or at minimum have the reconciliation flag any intercompany transaction that exists on one side only within a day or two.

Sharing customer data across entities without a basis

Personal information collected by one entity is not automatically available to every company in the group for every purpose. The Privacy Act 1988 has a specific provision for related bodies corporate, but it carries the original purpose of collection with it, and trusts and other structures do not necessarily fit that definition. Check what your privacy policy and collection notices say about group entities, and get advice before building a shared customer database or a group marketing list.

How Yes AI Approaches Multi Entity Work

We map the real money and stock flows first

Which entity buys from suppliers, which holds stock, which runs each storefront and each POS, which bank account each gateway pays into, and which invoices currently move between entities. The map usually shows two or three flows nobody had written down, and those are often where the reconciliation differences come from.

Your accountant sets the rules, we encode them

Ownership model, intercompany pricing, GST treatment, invoicing frequency, currency and netting are agreed with whoever prepares your accounts and tax returns before anything is built. We will ask pointed questions, but we do not set transfer prices or give tax advice, and we will tell you when a question needs a specialist.

Built, hosted and monitored by us

Paired invoices and bills, intercompany receipts, recharges and the reconciliation checks run on a managed cloud automation layer we operate, with every posting logged against its source record and alerts when one side fails to post. If a ledger rejects a transaction, the other side is held or reversed rather than left orphaned.

Straight advice on integrate versus consolidate

Sometimes the right answer is a single ERP holding all entities as separate companies, with native intercompany and consolidation. Sometimes it is two Xero organisations and a monthly recurring invoice nobody needs to automate. We will say which, and why, before quoting for anything.

From Monthly Catch-Up to Automated Intercompany Postings

Five steps. The first automated flow, usually the highest volume stock flow, is typically live within four to six weeks.

Map entities and flows

Every legal entity, every system each one uses, every movement of stock, services, money and customer data between them, with the current volumes and the current intercompany balances.

Agree the rules with your accountant

Ownership model, intercompany price source, GST treatment and GST group status, invoicing frequency, currency, netting and settlement, cut-off and the chart of accounts for intercompany on each side.

Build the paired postings

Invoices and bills created together from one source record, linked by reference, posted with exact tax amounts, and replayed safely if anything fails. Tested against a full historical month first.

Run in parallel and reconcile

One or two month ends where the automated postings run alongside the existing process, with the intercompany reconciliation proving both sides agree before the manual process is retired.

Monitor, then add flows

Daily one sided transaction checks, a month end cut-off pass and an exception list with an owner, then recharges, licence fees, NZ flows and consolidation inputs added to the same framework.

FAQ

What are intercompany transactions?

Intercompany transactions are dealings between related entities in the same group: one company selling stock to another, a head entity charging a management fee, a brand entity charging a licence fee, shared costs being recharged, or one entity paying a bill on behalf of another. Each one must be recorded in both entities, as a sale or income on one side and a purchase or expense on the other, with matching receivable and payable balances. At group level they cancel out, which is why they are eliminated when the entities are consolidated.

Can one Shopify store or POS sell stock owned by another entity?

Yes, and it is common. The storefront belongs to one entity, usually the retail or trading entity, and its payouts land in that entity. The stock may be owned by a related importer or stock holding entity until it sells, or transferred in bulk beforehand. Either way, the integration needs to know the ownership model so it can generate the right intercompany invoice and matching bill, at the agreed intercompany price, from actual sales or stock movements. The model itself should be confirmed with your accountant, because it affects GST, inventory values and who recognises the revenue.

How do we automate intercompany invoices in Xero or MYOB?

Xero organisations and MYOB company files are separate ledgers with no native link between them, so an integration posts the invoice in one and the matching bill in the other from the same source record, with a shared reference and identical lines and tax amounts. If either posting fails, the other is held or reversed so you never have a one sided transaction. For a handful of fixed monthly charges, a recurring invoice and a recurring bill set up by hand may be all you need, and we will say so.

Does a GST group mean we do not need intercompany invoices?

No. Entities in a GST group generally do not account for GST on supplies between group members, and the representative member reports GST for the group, which removes the tax from intercompany invoices. But each entity still keeps its own accounts, so the intercompany sale, purchase, receivable and payable still need to be recorded. Whether your entities are eligible to form or join a GST group, and how a trust or an NZ entity fits, is a question for your accountant.

Why do our intercompany balances never agree?

Usually for a small number of repeat reasons: one side posted without the other, the two sides dated in different months, credits or adjustments raised in one entity only, payments allocated to invoices on one side and to a loan account on the other, GST rounded differently, or foreign currency balances revalued at different rates. Each has a structural fix. Creating both sides from one source record, dating them from the source event, and checking daily for one sided items removes most of the drift before it accumulates.

What changes when one of our entities is in New Zealand?

Three things. Currency: decide which currency each intercompany flow is invoiced in, reconcile in that currency and use one rate source for both entities. Tax: NZ has its own GST system, separate from Australian GST and from any Australian GST group, and the GST treatment of goods moving between the countries depends on the facts. Transfer pricing: cross-border dealings between related parties raise transfer pricing considerations in both countries, so pricing and documentation should be set with professional advice before the flow is automated.

Should we move all entities into one ERP instead?

It is worth considering when there are more than two or three entities, high volume intercompany trading, an overseas subsidiary or a need for monthly consolidated reporting. NetSuite OneWorld subsidiaries, Business Central companies and MYOB Acumatica multi company setups handle paired intercompany transactions and consolidation natively, which removes most of the integration work. The trade-off is cost, migration effort and the change for staff. For two entities on Xero with modest intercompany volume, integrating the existing ledgers is usually the cheaper and less disruptive answer.

Get Both Sides of Every Intercompany Transaction to Agree

Book a call. We map your entities and the flows between them, show you where the intercompany differences come from, and give you a recommendation on integrate or consolidate with a priced plan. The map is yours either way.