MYOB automation: what the API, Zapier and Make can actually do

Through the MYOB Business API. It is the same API that used to be called the AccountRight API: MYOB renamed it in 2021, when it brought AccountRight and Essentials together as MYOB Business, and said nothing changed technically. It still connects to files on AccountRight and Essentials as well as MYOB Business. Anything that creates an invoice in MYOB from another system, whether that is a monday.com board, a booking form, a CRM or a shop, ends up calling it, directly or through a tool that does.

Our position: treat MYOB automation as a small integration build, not a Zap you switch on. Zapier's own MYOB page says MYOB has not built an integration on Zapier, and points to webhooks, custom actions, code and its developer platform instead. We searched Make's app directory and found no MYOB app either. So the choice is how to build the connection, not whether a step exists. That is more work than Xero needs, and it is still very doable. Most of the hard parts are the same for every ledger: matching the customer, getting tax right on each line, and never invoicing twice.

Where this breaks: if a product on MYOB's App Marketplace already does exactly your flow, from your booking system or shop to MYOB, use it first. A maintained connector beats a custom build when the job is standard. The build earns its keep when the invoice has to wait for something, such as a status on a board, an approval or a completed job, or when the lines and tax codes follow rules no connector knows.

This is the first question we ask, and the answer changes the build. MYOB has been consolidating AccountRight and Essentials into MYOB Business, and one API serves all three. MYOB's own developer pages say endpoint access is the same across products, but some features are only visible in the AccountRight interface, and its product and API matrix maps which data each product shows. An invoice layout, a field or a report your flow relies on may exist in the API and be invisible to the person checking the books in a lighter product. The API has a read-only flag, UIAccessFlags, that tells an integration which kind of file it is talking to, and we read it before anything else.

If your file is still offline, the honest advice is that no cloud automation, on Zapier, Make or anywhere else, can reach it, and MYOB is steering everyone online anyway. Moving the file online is a job for you and your accountant before it is a job for us.

New Zealand businesses use the same API with New Zealand tax settings. GST there is 15 per cent, against 10 per cent in Australia, and the tax codes in a New Zealand file are its own. Everything below about tax codes applies, with your file's codes in place of the Australian examples.

Everything a normal invoicing flow needs. These are the parts we use, as MYOB's developer reference describes them.

Connecting: OAuth, an Admin user and one company file

To use the API you register an app in my.MYOB, which gives you a key and secret, and the business connects it through OAuth 2.0. Since March 2025, only an Admin user of the company file can approve that connection, and each approval covers one company file, which comes back as a businessId on the redirect. MYOB has also moved to granular data scopes, so the connection asks for customers, invoices and so on rather than the whole file. In practice, the person who approves needs to be an Admin on the file, so book that person in before the build starts.

Tokens are short-lived. MYOB's support pages give the access token 20 minutes and say the refresh token can last up to one week, and that a new refresh token may be issued each time you refresh, so the latest one has to be stored. The newer authentication guide does not restate the refresh lifetime, so test it on your own connection. The practical consequence: a flow that runs rarely, say a monthly invoice run, can find its connection lapsed and need the Admin to approve it again. A scheduled keep-alive or a weekly run avoids that.

Limits, and no webhooks

MYOB enforces a per-second and a daily call limit, and documents the errors for both; we did not find the thresholds published, so pace any backfill of old records and handle the limit error with a retry later. MYOB's support article on webhooks says the API does not support them and suggests polling with filters instead: paid invoices are marked Closed, and a LastModified filter picks up recent changes. So any flow that starts in MYOB, such as 'when an invoice is paid, update the CRM', runs on a schedule, not instantly.

Two smaller details save hours. A POST to create a record does not return the new record's ID unless you add returnBody=true to the request, and you need that ID to write back. And updates need the record's current RowVersion; send a stale one and MYOB returns a conflict, so read before you update.

Yes, but not with a ready-made MYOB step, and the two platforms differ in how much work the connection takes.

Zapier

Zapier's MYOB page says MYOB has not built an integration on Zapier. Two of Zapier's general-purpose tools do not fit well. Webhooks by Zapier supports only basic authentication, so it cannot manage the OAuth tokens MYOB's cloud API needs. API Request actions reuse an existing app connection, so they only work for apps that already have a Zapier integration. That leaves three routes. A private integration on Zapier's Developer Platform, which supports OAuth 2.0 with automatic token refresh, gives you MYOB steps your team can use in any Zap, and is the one we would choose for a business that lives in Zapier. A code step that handles tokens itself is possible but fragile, because the rotating refresh token has to be stored somewhere outside the step. Or a third-party connector from MYOB's App Marketplace that offers its own API or Zapier app, which adds another vendor between you and your books.

Our Upwork evidence is a Zapier build. The brief, from a Sydney business, was a Zapier automation that creates MYOB invoices when a specific condition is ticked on a monday.com item, so that invoicing starts from the board instead of being retyped. The contract ran from late May to early June 2026 and has no client review, so we make no claims about its results, and this article does not describe how that Zap reached MYOB. What follows is the design we recommend for that kind of flow.

Make

Make has no MYOB app that we could find, but its HTTP app can hold an OAuth 2.0 connection of its own: you enter MYOB's authorise and token URLs and your app's client ID and secret, and Make keeps the token and sends it with each request. That turns MYOB into a set of HTTP modules inside an ordinary scenario, with routers, iterators and aggregators around them. In our view this is the lower-effort route for MYOB, because the connection is configuration rather than a developer-platform project. If you outgrow it, a custom Make app wraps the same calls into named modules.

Which platform? If the team already runs everything on Zapier and someone can own a private integration, stay on Zapier. If the flow has per-line logic, such as tax codes by product, grouped invoices or conditional lines, Make's HTTP app and its iterator and aggregator are easier to follow. Our WooCommerce to Xero article covers the line-item mechanics on both platforms, and our Make vs Zapier vs n8n comparison covers cost and control flow.

These are the patterns that come up most for Australian and New Zealand small businesses. Each starts somewhere other than MYOB and ends with the books right and the source record updated.

1. A board or CRM status raises the invoice

The Sydney brief is this pattern: work is tracked on a monday.com board, and when the job is ready to bill, the item raises a MYOB invoice. The steps we recommend: trigger on a billing status set on purpose, stop if the item already holds a MYOB invoice ID, find the customer by stored UID or email, build the lines with their tax codes, create the invoice with returnBody=true, and write the invoice ID and number back to the item at once. Our monday.com invoice automation article covers the board side in detail, including why a deliberate status beats a checkbox: a box is easy to untick and tick again, and each tick can raise another invoice.

2. A form or booking creates the customer and the invoice

A booking, enrolment or order form submits, and MYOB should hold a customer and an invoice for it. The customer step matters most here, because forms bring typos and new people. Match on email first, create only when nothing matches, and store the UID against the form record or the CRM contact so the next booking does not search again. If the invoice should wait for a check, for example a deposit or a manual approval, create a sale order instead and convert it later, since MYOB has no draft invoice. For contrast, the SmartSuite brief from a Sydney tutoring centre went to Xero, where draft invoices exist: one draft per guardian, with each enrolment as a line, for a person to review.

3. A payment in MYOB updates the CRM

The reverse direction: when an invoice is paid in MYOB, mark the job or deal as paid where the team works. MYOB has no webhooks, so this runs on a schedule. Every hour or each morning, ask MYOB for invoices that are Closed and modified since the last run, match each back to its source record by the invoice ID you stored when you created it, and update the status. Without that stored ID, this pattern turns into fuzzy matching on names and amounts, which is where errors creep in. If payments come in through a gateway rather than the bank, the same flow can run the other way and record the customer payment in MYOB, applied to the right invoice; decide which system is the source of truth for 'paid' with your bookkeeper first.

Where these break: all three assume one integration writes to MYOB. If a booking platform's own MYOB connector is also switched on, both will create customers and invoices. Pick one.

Every line on a MYOB invoice carries a tax code, referred to by its ID in your file, and so does the freight. In an Australian file the common sales codes are GST for the standard 10 per cent, FRE for GST-free sales such as many medical services and educational courses, and N-T for amounts that are not reported. The invoice also says whether its amounts include tax, through IsTaxInclusive, and that has to match the prices your source system holds. A board that stores prices including GST, sent to MYOB as tax exclusive, overcharges every customer by a tenth.

• Decide the codes with your accountant or BAS agent, not in the automation. Which code a service takes is a tax judgement, and it belongs with them.
• Keep a small mapping table: product, service or job type to MYOB tax code and income account. The automation reads it; nobody types codes into a step.
• Look up the tax code IDs from GeneralLedger/TaxCode once, store them, and refresh them only if your accountant changes the codes.
• Send the inclusive or exclusive flag on every invoice, matching where the prices came from.
• Check the arithmetic before writing: the lines and their tax should equal the total your source system shows, within a rounding tolerance you have agreed.

The same rule applies in Xero and QuickBooks, as our WooCommerce to Xero article explains, but MYOB is stricter about it because every code is an ID that must exist in your file. A mapping that works on a test file can fail on yours if the codes were set up differently, which is why we prove the first invoices against a copy of your own file.

MYOB invoices name their customer by UID, so every invoice starts with a lookup. Customers can be filtered by card ID or by an email in their address list. Name matching is the trap: two clients with the same name become one, and one client typed two ways becomes two. Our published Make write-up on CRM-triggered invoicing, which writes to Xero, records exactly this as its one error in 78 runs: a duplicate contact name in the create-contact step.

1. 01Use the MYOB customer UID stored on the source record, if there is one.
2. 02Otherwise search by email, and if exactly one customer matches, use it and store its UID.
3. 03If several match, stop and send it to a person. Guessing between two customers is how invoices go to the wrong company.
4. 04Create a customer only when nothing matches, and store the new UID straight away.
5. 05For business customers, check the ABN against the ABN Lookup service when the customer is first created, as our Australia automation page recommends.

Triggers fire twice, people re-run failed steps, and a box gets ticked again. Xero offers a short-lived idempotency key and QuickBooks a request ID for safe retries. We found no equivalent in MYOB's developer pages, and creating an invoice through MYOB's API is not something you can safely repeat. The guard has to be yours.

• Create with returnBody=true so the response includes the new invoice's UID and number, then write both back to the source record in the very next step.
• Make the first step after the trigger a check for that stored ID. If it is there, stop.
• Before retrying a failed create, search MYOB for an invoice with your reference, in case the first attempt succeeded and only the reply was lost.
• Write the ID back to a field the trigger does not watch. On monday.com an automation that updates its own item can trigger itself again.
• MYOB's sample code notes that invoice numbers must be unique. Do not rely on that as your only guard unless you have tested how your file behaves when a number repeats.

This is the same rule our fleet order automation case study runs on for an Australian client: a resent order corrects the existing row instead of creating a second one. Different system, same principle. The record knows what it has already produced.

Whether you should be on MYOB or Xero is a question for you and your accountant, and it turns on payroll, reporting, your accountant's practice and what your team knows, far more than on integrations. We build for both. What we can say plainly is where the integration tooling differs, as each vendor documents it.

Read the table as build effort, not quality. A MYOB invoice flow typically needs a connection you set up yourself, more ID lookups per invoice, and a scheduled poll where Xero would let you lean on a ready-made app. It makes the build bigger, not a different kind of project. If you are choosing a ledger for other reasons and integrations are on the list, it is fair to count; if you are happy on MYOB, it is not a reason to move.

The common thread is a failure nobody sees. An invoice flow that stops quietly leaves revenue out of the books until someone notices at BAS time. Send every failure, with the job or order reference, to a channel a person reads, and run a weekly count of jobs billed on the board against invoices in MYOB. Our article on why automations break covers the general pattern.

Skofi is paid to build integrations on Zapier, Make and ledger APIs, so we gain when you build. We still say: use a maintained connector if one fits. We are not a partner of MYOB, Xero, Zapier, Make or monday.com. Our accounting automation work includes the monday.com to MYOB brief above, the SmartSuite to Xero brief for a Sydney tutoring centre, and an accounts payable flow we built that logs emailed bills to a sheet for approval and posts approved bills to QuickBooks Online. The client on that last one left this mid-contract review: "Saveez is top notch. His work, communication and cooperation were all better than expected. I will absolutely continue to work with him." — Upwork review (mid-contract), QuickBooks accounts payable automation. As of 21 October 2026 we are Top Rated on Upwork with a 100% Job Success Score over 114 jobs. None of this is a published MYOB case study, and we make no claims about results.

Before you brief anyone, write down four things: your MYOB product and plan, whether the file is online, who the Admin user is, and the tax code and income account for each thing you sell, agreed with your accountant. Then pick one real job and say what its invoice should look like in MYOB. With those, a MYOB automation is a small, well-defined build. Without them, it is guesswork. Our Australia automation page covers the wider Australian context: GST and BAS, Single Touch Payroll and the Privacy Act.