MYOB Integration
Connect MYOB properly - starting with what your environment can actually do.
MYOB integrations fail more often at scoping than at build. The product family spans very different generations of technology, so the responsible first step is confirming which environment you run and what it exposes, then designing the sync around that reality rather than around an assumption.
At a glance
- First question
- Which MYOB product, edition and hosting arrangement is in use.
- Common connections
- CRM, ERP, ecommerce, job and field-service systems into MYOB.
- Design principles
- One owner per object, replayable writes, visible failure, reconcilable totals.
Business problem
What businesses are usually trying to remove.
Almost always the same thing: a person acting as the connector between the system where work happens and the system where money is recorded.
Sales to finance handover
Won deals, signed quotes or approved orders create the customer and invoice in MYOB without a person retyping them from another screen.
Ecommerce and order intake
Online and wholesale orders flow through to finance with consistent customer records, tax treatment and item coding.
Operational billing triggers
Delivered jobs, despatched goods or completed milestones drive invoicing on a defined schedule instead of ad-hoc requests to the finance inbox.
Payment visibility outward
Payment and outstanding-balance status surfaced in CRM or service tooling so non-finance teams stop asking finance for it.
Supplier and purchase flow
Approved purchases created as bills with coding already applied at the point of approval.
Environment
Not every MYOB environment behaves the same way.
Treating MYOB as a single API is how projects end up re-scoped mid-build. We establish the constraints first and let them shape the architecture.
Scope first
What we confirm before designing
- Exact MYOB product, edition and version in use
- Hosting arrangement and how the data is reachable
- Available interface: API, connector service or batch
- Who administers the environment and holds credentials
- Existing add-ons already writing to the ledger
Design consequence
How the environment shapes the build
- Live API access supports near-real-time patterns
- Constrained access pushes toward scheduled batches
- Limited write endpoints may require staged approvals
- Existing add-ons can create ownership conflicts
- Access constraints change monitoring and alerting design
Data model
Objects and events typically exchanged.
| Object | Ownership and mapping considerations |
|---|---|
| Customer / card record | Confirm which system owns creation and which fields are editable where. Card-style records often carry conventions the CRM does not. |
| Sales invoice | Mapping covers line items, account or category coding, tax codes, terms and the reference used to trace back to the source document. |
| Payment | Best owned by the ledger and read back outward. Writing payments from upstream systems increases reconciliation risk. |
| Credit note / adjustment | Needs an explicit rule on where a credit originates and how it is reflected in the upstream record. |
| Purchase / bill | Typically created from an approval event with coding applied at source rather than corrected later. |
| Item and inventory | Only sync where the ledger is genuinely the inventory master. Otherwise keep item mastery upstream and map to accounts. |
| Job / category coding | Decide early which upstream field drives job, category or department coding, because retrofitting it is painful. |
Sync design
One-way, two-way and the honest middle ground.
Two-way sync sounds better than it usually is. Most durable finance integrations are one-way with a narrow, well-defined return path.
One-way into the ledger
Customers and invoices created from the upstream system. Simple, predictable and the right default for most businesses.
Narrow return path
Payment status, balance or document number read back so upstream teams have visibility without editing rights.
Genuine two-way
Only where both systems legitimately create records - and then only with field-level ownership rules and conflict handling defined in advance.
Scheduled versus event-driven
Event-driven where the environment supports it; scheduled batches with reconciliation where it does not. Both are valid; pretending a batch is real-time is not.
Approach
How we typically deliver a MYOB integration.
A recommended methodology; the shape changes with the environment and the risk attached to the data.
01
Environment discovery
Confirm the MYOB product and access path, and what other tools already write to the ledger. Nothing is scoped before this is established.
02
Process mapping
Trace how a financial document is created today, including the manual steps and the exports nobody documented.
03
Ownership model
Agree the system of record per object and the direction of flow per field.
04
Mapping specification
Field mapping, tax and account coding, validation rules and failure behaviour written down before build.
05
Build and test
Implemented against a test environment with edge cases: part payments, credits, unusual tax treatment and retries.
06
Cutover and operate
Data preparation, a parallel checking period, then switchover with monitoring, reconciliation and documented runbooks.
Questions we are asked about MYOB integration
- Do all MYOB products integrate the same way?
- No, and assuming they do is the most common scoping error. MYOB's product family has evolved over many years and different environments expose different interfaces and capabilities. The first task on any MYOB integration is confirming exactly which product, edition and hosting arrangement is in use, because that determines what is technically possible before anything is designed.
- What if our MYOB environment is an older on-premise install?
- It is still workable, but the constraints are real: access may depend on a connector service, a file-based path or scheduled batches rather than live API calls. That usually pushes the design toward scheduled synchronisation with strong reconciliation, rather than real-time two-way flow.
- Should we integrate MYOB or move to an ERP?
- If accounting is working and the pain is re-keying between systems, integrate. If the underlying pain is inventory valuation, manufacturing cost, procurement or multi-entity operations being managed in spreadsheets around the ledger, integration will not fix the structural problem and an ERP assessment is the more honest conversation.
- How do we keep customer records consistent between CRM and MYOB?
- Decide which system owns the customer record, store a shared external identifier on both sides, and match on that identifier rather than on name or email. Existing duplicates are cleaned during data preparation, before the sync is switched on.
- How is failure handled?
- Every write operation should be safe to replay, failures captured with the payload and reason, and anything that cannot be retried escalated to a person. Alongside that, a scheduled reconciliation compares counts and totals so drift is detected rather than discovered at month-end.
Where to go next
Tell us which MYOB environment you run.
That single answer determines what is possible, what it costs to maintain, and whether a connector or a custom build is the sensible route.