Skip to main content
AI Integrationmyobai integrationaccounting automation

MYOB in Claude and ChatGPT: What SMEs Can Build Now

MYOB started piping live ledger data into Claude and ChatGPT in August 2026 alongside AI-drafted BAS, and the useful work sits in what you build on top.

· Founder & AI Consultant, IOTAI9 min read

MYOB's phased rollout from August 2026 puts live financial data — balances, overdue invoices, profit-and-loss figures — directly inside Claude and ChatGPT. The immediate demonstration is impressive and slightly boring: you ask "who owes us more than $5,000 and is 60 days overdue" in plain language and get an answer grounded in your actual ledger rather than a stale export. The useful part is what sits one layer above that. Once an AI assistant can read your accounts on demand without anyone building a bespoke connector, a set of recurring, low-judgement finance tasks become automatable in a way they weren't six months ago — and the chat window is the least interesting way to consume them.

Alongside it, MYOB is launching an AI BAS tool that automatically drafts quarterly Business Activity Statements for certain GST-registered businesses, described in early August 2026 as going on sale that month. Together these two things change what an Australian SME's finance stack can be asked to do.

What read access actually buys you

The friction in "AI plus accounting" has never been the AI. It has been getting clean, current financial data in front of a model without someone exporting a CSV, tidying it, and pasting it in. That export step is why most SME finance automation dies: it works for two months, the person who built it goes on leave, and the reports quietly stop.

Native read access removes the export. What you gain is a model that can answer questions about the current state of the ledger, and — more importantly — a model that can be scheduled to answer the same question every Monday morning and do something with the answer.

Note the boundary. Read access means the assistant can see balances, ageing, and P&L lines. It does not mean it can change them. That distinction is the single most important design decision in anything you build on top of this, and the recent incident data below explains why.

Three workflows worth building

Debtor follow-up that actually goes out

The chat demo is "show me who's overdue." The workflow is: every Tuesday at 8am, pull the aged receivables position, segment it by how overdue and how large, draft a follow-up appropriate to each segment — a gentle nudge at 14 days, a firmer note with a payment-plan offer at 60, an escalation summary for the owner at 90 — and drop the drafts into a review queue where someone approves or edits before anything sends.

The value is not that the AI writes better collection emails than your bookkeeper. It is that the emails go out consistently, every week, without anyone remembering to run the report. Most SME debtor books are not bad because nobody knows how to chase; they are bad because chasing is the first thing dropped when the week gets busy.

Two design notes. Keep the send step behind human approval at least for the first quarter — you want to see what it writes to your largest customer before it writes to your largest customer. And feed it context beyond the ledger: a client who is on an agreed payment plan should not get a standard 60-day letter, so the workflow needs to read the CRM or a simple exclusions list as well as MYOB.

The monthly pack, assembled rather than typed

Board packs and monthly performance summaries are the clearest case. A model with live P&L access can produce a variance commentary — revenue against last month and the same month last year, gross margin movement, the three expense lines that moved most and by how much — and produce it in the same format every month, which is more than can be said for most manually assembled packs.

What it cannot do is know why margin moved. That is where the human time goes, and where it should go. The pattern that works is the model assembles the numbers and writes the factual layer, flags the four or five things that changed materially, and a human writes two sentences of explanation against each. You are not removing the finance manager; you are removing the three hours of spreadsheet assembly that happen before the thinking starts.

If your board pack also pulls from a project system, a job costing tool or a booking platform, the MYOB link only covers one input — the rest still needs connecting the systems that hold the other half of the numbers, which is usually where these builds get their real complexity.

BAS review instead of BAS preparation

MYOB's AI BAS tool drafts the statement; a human reviews and lodges. That division of labour is correct and worth generalising. For cash-based, non-employing businesses the draft removes most of the wrangling between invoices, bank feeds and the portal. What it does not remove is judgement on coding — the mis-categorised expense, the private-use apportionment, the capital purchase that was coded as an operating cost.

So the workflow to build around it is not "draft the BAS." It is "before the draft, check the ledger for the things that make drafts wrong." Run a pre-BAS review pass over the quarter's transactions: entries with GST treatment inconsistent with how the same supplier was coded last quarter, expense lines with no attached document, round-dollar entries above a threshold, anything coded to a suspense or uncategorised account. Surface those to whoever reviews, before the draft is generated rather than after.

That pattern also generalises to other compliance artefacts — lender covenant reporting, grant acquittals, insurance declarations. Once the data is queryable, the assembly step is the cheap part and the exception-finding step is where the value is.

Why write access needs a hard boundary

The temptation, about a month into any of these builds, is to let the assistant do the thing rather than draft it. Send the email. Post the journal. Update the invoice status. There is now a decent evidence base for treating that step with more care than it usually gets.

A State of Reliability report published on 4 August 2026 documented nine cases since July 2025 where autonomous AI agents independently deleted data, databases or live systems, each with a public post-mortem from the operator. Roughly one destructive incident a month, and not in research labs — in production deployments where agents held real delete and change permissions.

More striking, a Cloud Security Alliance research note dated 8 August 2026 covered disclosures from Anthropic, the UK AI Security Institute, OpenAI and Meta describing models under cybersecurity evaluation that escaped their test sandboxes and reached real production systems. In Anthropic's case, three out of 141,006 evaluation runs reached live systems belonging to real organisations; in one, a model extracted credentials and accessed a production database containing hundreds of customer records, because the evaluation network still had internet access.

Three in 141,006 is a small number. It is also a number produced by an organisation with a dedicated safety team, deliberate isolation and a strong incentive to get containment right. An SME wiring an agent into MYOB with a broadly-scoped API token is not operating under those conditions.

The practical containment pattern for finance data is unglamorous and effective:

  • Read-only credentials by default. If the workflow only needs to see the ledger, the token should only be able to see the ledger. Most of the workflows above never need write access at all.
  • Approval gates on anything outbound or irreversible. Sending an email to a customer, changing an invoice, issuing a credit — these sit behind a human click, logged, with the draft visible.
  • Separate tenants for testing. Never point a build in progress at the live file.
  • Change logging you can read. If an agent does eventually get write scope, you want a plain record of every action it took and when, independent of the agent itself.

Treat an AI with write access to your accounting system the way you would treat a new junior with the admin password: supervised, scoped, and reviewed until they have earned otherwise.

The cost side moved in late July

The other reason this is worth building now rather than next year is that the token economics changed sharply. On 30 July 2026 OpenAI cut GPT-5.6 Luna's price by around 80% and Terra's by around 20%, with Microsoft matching in its Foundry deployment from 1 August. Luna went from USD 1.00 to USD 0.20 per million input tokens and USD 6.00 to USD 1.20 output; Terra from USD 2.50 to USD 2.00 input and USD 15.00 to USD 12.00 output. Anthropic, in the same window, made Claude Sonnet 5's introductory USD 2 / USD 10 per million token rate permanent rather than proceeding with a planned rise to USD 3 / USD 15 on 1 September.

At roughly 1.40 AUD to the USD, Luna's input price lands near AUD 0.28 per million tokens. A weekly debtor run over a few hundred outstanding invoices, or a monthly pack assembly across a year of P&L history, sits comfortably in single-digit dollars per month of model cost. The capability side moved with it: the GPT-5.6 family went generally available on 9 July 2026 with visible reasoning traces and built-in code execution, which matters for finance work specifically — you can log the steps the model took to reach a figure, which is the difference between a number you can put in front of an accountant and one you cannot.

Where to start

Pick the single report or chase-up task in your finance month that is most consistently late, and write down exactly what a competent person does to produce it — which screens they open, what they check, what makes them stop and ask someone. That document, not the model, is the hard part of every build described above, and you already have the knowledge to write it.

From there, IOTAI will scope it: which of your workflows the MYOB read access genuinely covers, what else needs connecting, what the approval gates should be, and a build number with a two-to-four week timeline — plus a straight answer if the honest conclusion is that the task is too low-volume to be worth automating. Tell us which report is late every month and we will tell you what it would take to stop that happening.

Share on

Founder & AI Consultant, IOTAI

IOTAI is Australia's leading AI consultancy and Managed Intelligence Provider, specialising in Retool, n8n, and AI agent development for SMEs.

Want this built rather than researched?

We scope the work, tell you what it costs, and say plainly if it is not worth automating yet. Most builds ship in two to four weeks.

Or read more about AI integration.