Which MYOB product am I on, and why does it matter so much?

The three you are most likely to be running are AccountRight, which is the long standing product with a company file that may be hosted or local, MYOB Business, which is the cloud product many smaller businesses moved to, and the enterprise platform aimed at larger operations. They have different data models, different capabilities and different integration surfaces, so an approach designed for one does not transfer. The quickest way to tell is how you open your file and what the interface looks like, and it is the first thing we establish on any call because almost every subsequent answer depends on it.

Can you integrate with an AccountRight file stored on our office computer?

Yes, but with a caveat worth taking seriously. A local file is only reachable when the machine holding it is on, connected and running the software that exposes it. That makes an office computer part of your production infrastructure, with all the weekend, power cut and Windows update risk that implies. We can build around it with a queue that holds transactions while the file is unreachable and posts them in order when it returns, plus alerting so someone knows the same day. In most cases though, moving the file to a hosted arrangement costs less over a year than working around a local one, and we will usually recommend it.

Should each online order become its own invoice in MYOB?

It depends on the business, and it is worth deciding deliberately. Individual invoices give you customer level debtor history, statements and aged receivables, which is what a wholesale or trade business needs. For high volume retail they make the ledger enormous and hard to read, and every individual payment then has to be reconciled against a bulk payout. In that case a daily sales summary, split by payment method and tax code, is usually better: it reconciles cleanly against the merchant deposit, keeps the file manageable, and preserves the detail in the store where it belongs. Mixed businesses sometimes use both, with trade accounts invoiced individually and retail summarised.

Will an integration keep our inventory accurate in MYOB?

Only if MYOB is genuinely your inventory system. If you run a dedicated inventory, point of sale or warehouse platform, the right design is for that system to own quantities and MYOB to hold the financial position, usually through a daily cost of goods and stock movement summary rather than item level invoices. Trying to maintain accurate quantities in both places produces two ledgers that disagree and a monthly ritual of working out which one is wrong. Choosing a single owner is nearly always cheaper and calmer than the reconciliation that the alternative requires.

What happens when a transaction arrives after the period is locked?

It fails, and the important thing is that the failure is visible and handled by a rule you agreed in advance rather than discovered later. The usual options are to hold the transaction in a queue until the period reopens, to post it into the current period with a clear reference back to the original date, or to route it to the bookkeeper to place deliberately. Any of the three can be right depending on how your accountant works. What is never right is an integration that silently drops the record, which is how a month end ends up short with no obvious explanation.

Is an off the shelf MYOB connector good enough?

Often, and we will say so rather than quoting a build you do not need. For a single store posting straightforward retail sales into a standard chart of accounts, a supported connector is usually the sensible answer. The point where a custom integration earns its cost is fairly specific: a mix of tax treatments that has to be mapped per product, multiple sales channels landing in one ledger, a separate inventory system that must not be duplicated, job or category coding that has to be populated automatically, supplier bills matched against purchase orders, or settlement reconciliation that has to account for fees and chargebacks precisely.

How do we know the integration is actually working?

By reconciling rather than by the absence of complaints. A working integration produces a daily check that the number of transactions leaving the source system equals the number arriving in MYOB and that the totals match to the cent, with anything unmatched listed by reason. That check is the deliverable, not a dashboard nobody opens. On top of it you want alerting to a named person the same day a flow fails, a record level log of what moved and when, and the ability to replay anything that did not land once the cause is fixed.

For Australian businesses on AccountRight or MYOB Business

MYOB AccountRight Integration: What Actually Works and What Does Not

MYOB is three quite different products wearing one brand. AccountRight, MYOB Business and the larger enterprise platform behave differently, hold data differently and are reached differently, and a plan built for one of them will not simply transfer to another. Working out which one you are on is not a formality, it is the first design decision.

This page covers what matters once you know: whether your company file lives in the cloud or on a machine in the office and why that changes everything, when an integration should raise an item invoice against inventory and when a service invoice is the right answer, how tax codes have to be mapped rather than assumed, why customer card matching causes more grief than any technical problem, and where the honest limits of the platform sit.

Book an MYOB Integration Call (03) 9003 0111

Realistic ROI

3 products

AccountRight, Business and the enterprise platform

Different data models and different integration surfaces under one brand

2 file locations

Cloud hosted or on a local machine

A local file needs something running on your network to be reachable

2 invoice types

Item invoices and service invoices

One moves inventory and one does not, and the choice is not reversible in bulk

3 to 12 hours a week

Commonly spent re-keying into MYOB

Typical range for a small finance team, and worth measuring before budgeting

Four MYOB Realities That Shape the Integration

None of these are criticisms of MYOB. They are the four things that decide whether an integration is straightforward, awkward or genuinely a poor fit.

Where the company file lives changes what is possible

An AccountRight file hosted in the cloud can be reached over the internet by an integration running anywhere. A file that lives on a computer in the office cannot, unless something on that network stands between the file and the outside world and stays running. That distinction decides whether your integration is a normal cloud arrangement or one that depends on an office machine being switched on, patched, backed up and not moved. Businesses with a local file should price the move to a hosted file into any integration project, because it usually pays for itself in avoided fragility.

Item invoices and service invoices are not interchangeable

An item invoice references stocked items and moves inventory and cost of goods sold. A service invoice posts revenue to an account without touching stock. Which one your integration raises depends on whether MYOB is genuinely your inventory system or whether stock is owned elsewhere. Businesses that run a separate inventory or point of sale system usually want service invoices or a daily summary, and posting item invoices instead creates a second stock ledger that immediately starts disagreeing with the first.

Card records are matched by a person, not a key

Customers and suppliers are card records identified by a display name, and an online store cheerfully produces the same person as three different spellings. Match on email where you have it, fall back to a normalised phone number, use the ABN for trade accounts, and route anything ambiguous to a review queue rather than creating a new card. The alternative is a card list that doubles every year, debtor reports that cannot be trusted, and a statement run that sends three letters to the same customer.

The ledger has rules the integration has to respect

Locked periods, closed financial years, the linked accounts that MYOB requires for particular transaction types, and the treatment of undeposited funds all constrain what an integration may post and when. A sync that tries to write into a locked period simply fails, usually at the worst moment, so the design has to decide what happens to a late arriving transaction: hold it, post it to the current period with a note, or queue it for the bookkeeper. Deciding that in advance is the difference between a controlled exception and a month end argument.

The MYOB Flows Worth Building

Sequenced the way most Australian businesses should approach them, by the manual hours each one removes.

Invoice or summary

Sales into the ledger

Orders from the online store, point of sale or field service system arrive in MYOB either as individual invoices, which preserve customer level debtor history and suit wholesale and trade, or as a daily sales summary, which keeps a high volume retail ledger readable and reconciles cleanly against the payment provider payout. Freight, surcharges, discounts and rounding each need their own account and tax code agreed before the first record moves, because retrofitting a correction across a quarter is painful.

Reconciled

Payments and settlement

Payments recorded against the right invoices, with merchant fees, refunds and chargebacks posted to their own accounts rather than netted off quietly, and the total landing where the bank feed will meet it. Done properly this is the flow that removes the weekly spreadsheet where somebody works out why the deposit does not equal the sales figure, and it is usually the single most appreciated automation in a finance team.

Bills posted

Purchases and supplier bills

Purchase orders raised in an inventory or operations system flow through to MYOB, supplier bills are created with the correct tax treatment, and receipting against the order is reflected rather than re-keyed. This is where accounts payable automation earns its keep, and where the discipline of a three way match between order, receipt and bill stops overpayments before they happen rather than finding them at audit.

Matched once

Customer and supplier cards

A new customer created in the store, the point of sale or the CRM becomes a single card in MYOB, matched against what is already there rather than added blindly. Terms, credit limit and price level are owned by whichever system the business agrees is authoritative, and the others read it. The matching rules are written down and the ambiguous cases go to a person, which is what keeps the card file usable in three years.

One owner

Inventory decisions

If MYOB is genuinely your inventory system, item invoices and stock adjustments flow into it and it stays the source of truth. If you run a dedicated inventory, point of sale or warehouse system, MYOB should hold the financial position and not a second quantity ledger. Trying to keep both in step is the most common self inflicted wound in MYOB integrations, and choosing one owner is almost always cheaper than reconciling two.

Analysis intact

Jobs, categories and reporting

Jobs and categories carry the analysis the business actually manages by, whether that is a project, a branch, a store or a product division. If the integration does not populate them, every automated transaction lands unclassified and someone spends month end reclassifying by hand, which quietly cancels out the time the automation saved. Mapping them is a small piece of work with a disproportionate effect on whether the reports stay useful.

MYOB Tasks Before and After Integration

Task	Traditional	Integrated Properly	Notes
Daily online sales	Exported and keyed in	Posted automatically	Choose invoice per order or daily summary first. High volume retail almost always wants the summary.
Merchant payout reconciliation	Spreadsheet every week	Matched to the cent	Fees, refunds and chargebacks each posted to their own account rather than netted off.
New customer from the store	Card created by hand	Matched or created once	Email, normalised phone and ABN together. Ambiguous cases go to a queue, never an auto merge.
Supplier bill against a purchase order	Re-entered from a PDF	Created and matched	Three way match catches quantity and price differences before payment, not after.
Stock adjustments	Entered in two systems	Owned in one	Decide whether MYOB or the inventory system is authoritative. Running both is the expensive option.
Job or branch coding	Reclassified at month end	Coded on creation	Small mapping job, large effect on whether management reporting stays trustworthy.
Refund or credit	Manually mirrored	Credit note raised	Partial refunds and restocking fees need explicit rules including the stock consequence.
Transaction into a locked period	Fails, nobody notices	Held and flagged	The rule for late arrivals is agreed at design time rather than improvised at month end.

Where MYOB Integrations Quietly Fail

Tax codes were assumed to line up

MYOB uses its own tax code set, and the codes a store or point of sale exports rarely match it without translation. Standard rated sales, GST free food and medical lines, input taxed items, exports, capital purchases and transactions with suppliers who have not quoted an ABN all need an explicit mapping, product by product where necessary rather than one code for the whole file. The failure mode is not dramatic, it is a small persistent discrepancy that nobody investigates until a BAS reconciliation forces the issue.

A local company file became a single point of failure

When the file lives on an office computer, the integration depends on that machine being on, connected, updated and not reallocated to someone else. Weekend outages, power interruptions, a Windows update and an office move have all taken integrations down for days. If the file cannot move to a hosted arrangement, the design has to include a queue that holds transactions safely while the file is unreachable and posts them in order when it returns, plus alerting that tells someone the same day rather than at month end.

The card file was allowed to grow unchecked

Automated card creation without matching rules produces thousands of near duplicates within a year, and once they carry transactions they are genuinely difficult to merge. Decide the matching keys before go live, load the existing card file and clean it first, create nothing automatically that the rules cannot confidently match, and give the ambiguous cases to a person in a daily queue of a handful rather than a monthly cleanup of hundreds.

Retries created duplicate invoices

A network drop or a timeout mid post is normal, and the retry that follows will create a second invoice unless the write is idempotent. Every posted transaction needs a stable external reference carried into a field on the MYOB record so a repeat attempt updates or is recognised as already done. Without it you get duplicate revenue at the busiest times of year, which is precisely when the retries are most frequent and the finance team has least capacity to spot them.

The integration used a person’s login

Credentials tied to a staff member stop working the day they leave and carry whatever access that person had. Use a dedicated integration user with the narrowest permissions that work, store credentials in a proper secret store rather than a configuration file, rotate them on a schedule, and keep a record of what has access to the file. Since the flow carries customer names, addresses and payment references, the Privacy Act 1988 and the Australian Privacy Principles make least privilege and access records an expectation, not an optional refinement.

Nobody planned for volume or throttling

The API is not built for unlimited traffic and a large historical backfill or a peak trading day can push you into throttling, where a slowed integration looks exactly like a stopped one. Pace the calls, queue the backlog rather than dropping it, prefer daily summaries over individual invoices where volume is high, and test a peak day before November rather than during it. If the honest answer is that your volume has outgrown the product, we would rather say so than build something that limps.

How Yes AI Handles an MYOB Integration

Product, file and chart of accounts review first

Which MYOB product you are on, where the file lives, how the chart of accounts and tax codes are set up, how clean the card file is, and how many hours a week the current process costs. We put that in writing before quoting because it genuinely changes the answer.

Built on the official interface and hosted by us

We use the supported MYOB interfaces rather than screen automation or database access, and the integration runs on a managed cloud automation layer we operate, with queuing so a temporarily unreachable file delays transactions rather than losing them.

Reconciliation designed in

A daily check that what left the source system arrived in MYOB, at record level and to the cent, rather than trusting that no news is good news. Anything that did not land is queued with the reason and can be replayed once the cause is fixed.

Honest advice about fit

If a supported connector covers what you need, we will tell you to use it. If your volume or complexity has genuinely outgrown AccountRight, we will say that too, and help you evaluate the move rather than building an integration that papers over it for a year.

From Re-Keying Into MYOB to a Connected Ledger

Five steps. A first flow such as sales into the ledger is usually live in two to four weeks.

Review the file and the manual work

Product and version, file location, chart of accounts, tax code setup, card file quality, jobs and categories in use, and a timed list of what the finance team re-keys today with a dollar figure attached.

Decide the posting model and ownership

Invoice per order or daily summary, item invoices or service invoices, who owns inventory, who owns the customer record, and how a late transaction into a locked period is handled. Documented and signed off before any build.

Map accounts, tax codes and matching rules

Every account, tax code, job and category mapped explicitly, with the customer and supplier matching keys written down. Checked by your bookkeeper or accountant, because they are the ones who will live with the result.

Build, test against a copy, go live watched

Idempotent writes with a stable external reference, tested against a copy of your real file including the awkward historical records, then a watched go live with a parallel period where the automated result is checked against the manual one.

Reconcile, monitor and extend

Daily record level reconciliation, same day alerting to a named person, tax and account mappings reviewed after the first BAS cycle, and further flows added once the first one has proven itself over a full month end.

FAQ

Stop Re-Keying Into MYOB

Book a call. We review the file, the chart of accounts and the hours your team spends re-entering data, then tell you plainly what to automate first and whether a connector will do the job for less.