Outgrowing MYOB: what Australian finance teams hit first

Michael Dean
Sales and Marketing Director
Accounting Software Reviews
Cloud Accounting Solutions
Tax Compliance Solutions

MYOB has a genuine claim on the Australian market that no international vendor can match: it has been built around Australian compliance for decades. Payroll that understands awards and superannuation. BAS preparation that reflects how the ATO actually wants it. Single Touch Payroll handled properly. For a domestic business with domestic staff, that is worth a great deal.

Where it gets difficult is when an Australian company stops being purely Australian, or stops being purely simple. Here is the order in which we usually see the pressure appear.

First: the second entity

MYOB handles a single trading entity well. It does not natively consolidate a group. Once you incorporate a subsidiary — an NZ entity for trans-Tasman customers, a US entity to take American revenue, a separate services company for professional services delivery — you are managing separate files and building the group view manually.

The finance team notices this before anyone else, because they are the ones rebuilding the consolidated P&L each month. The board notices it later, when group numbers arrive three weeks after period end.

Native intercompany consolidation and elimination is the structural answer here — the group view computed from entity data rather than assembled from exports.

Second: foreign currency

The moment you invoice in USD or hold a USD bank account, you inherit a set of accounting requirements that are easy to get subtly wrong: transaction-date rates for the original entry, period-end rates for monetary balance sheet items, historical rates for equity, and a currency translation adjustment that has to land in the right place in reserves.

Most teams in this position translate everything at a single month-end rate because it is what the system makes easy. That is not compliant with AASB 121, and it is the kind of thing a serious auditor will find. Moving to a system that handles FX properly does not create this problem — it exposes one that already existed.

Third: subscription revenue

MYOB was built for businesses that invoice for goods delivered or services performed. Subscription revenue does not fit that model cleanly. There is no native deferred revenue schedule, no automated release across a contract term, no handling of mid-term upgrades or usage-based components.

If you are running an annual contract billed upfront, you are posting the cash, holding the liability, and manually releasing one-twelfth each month. That is manageable at twenty contracts and unmanageable at four hundred. Revenue recognition automation exists specifically for this.

Fourth: reporting depth

Growing companies want to see the business from several angles at once — by product, by segment, by channel, by entity, by cohort. That requires dimensions on every transaction, and reporting that can slice across them without a data export.

When the system cannot do it, the finance team exports to Excel or builds a BI layer on top. Both work. Both add a reconciliation point and a person who has to maintain it.

What MYOB still does better

It is worth being fair about this, because the trade-off is real.

If you have a substantial Australian workforce, MYOB's payroll and award interpretation is genuinely strong, and most global ERPs are weak there. Many companies that move their ledger to a modern platform keep a dedicated Australian payroll system and integrate it, rather than trying to force payroll into an international product. That is usually the right call, and it is a legitimate best-of-breed architecture rather than a compromise — a point we argued in rethinking the single platform play.

Similarly, if your compliance burden is heavily domestic and your structure is a single entity in a single currency, the case for moving is weak. Do not migrate because a vendor told you that you had outgrown something.

The honest test

Ask your financial controller two questions.

First: how many days a month do you spend doing things the software should do? Not analysis — mechanical work. Rebuilding consolidations, calculating FX, releasing deferred revenue, exporting to Excel.

Second: what happens to that number if we double? If it doubles too, the system is the constraint. If it stays flat, you have process headroom and should use it.

Where Cynder fits

We implement Campfire.ai for ANZ finance teams, and a meaningful part of our work is helping companies decide whether to move at all, and how to keep the parts of their existing stack that genuinely work — including local payroll.

If you would like to talk it through, our implementation practice begins with scoping rather than a pitch. Start a conversation.