System of record
CRM owns customers and deals. Accounting owns invoices, payments and tax.
Why. Avoids two-way edits of the same field.
Trade-off. Some data is read-only on one side, which users must understand.
CRM and business systems · Xero and MYOB
CRM-to-accounting integration with Xero or MYOB
Quote, invoice and payment data moving safely between a CRM and Xero or MYOB: OAuth, idempotent writes, GST-correct line items, reconciliation and clear ownership of every record.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
- Australian Privacy Principles
- ACSC Essential Eight
- ATO GST and record-keeping obligations
Architecture
- SaaS and business systems
- Messaging, events and workflow
- Databases and data
- Network and edge
- Security and identity
- Monitoring, audit and analytics
- Request or data flow
- Asynchronous or optional
- Boundary: region, account, network or trust zone
Request and data flow
When a deal reaches Closed Won, the CRM sends a signed webhook carrying the deal ID, not the whole record.
The receiver verifies the signature, stores the event and enqueues a job, so the CRM gets a fast response.
A worker consumes the job, with retries and a dead-letter queue for failures.
It loads the deal, maps customer, items and tax codes through a maintained ID map and checks whether an invoice for this deal already exists.
It creates or updates the invoice in Xero or MYOB with GST tax types and account codes from configuration, and a reference holding the CRM deal ID.
Payment status returns by webhook or scheduled poll and updates the CRM, so sales can see whether the customer has paid.
Components and why they were chosen
| Component | What it does | Why this choice |
|---|---|---|
| CRM webhooks | Event trigger on deal or quote change. | Avoids polling and gives timely sync. |
| Integration service (Lambda, Azure Functions or an iPaaS) | Receiver, worker and mapping. | Small code or low-code. Choose by volume and team skills. |
| Queue with DLQ | Buffers and retries. | Accounting APIs have rate limits and occasional errors. |
| State store | CRM-to-accounting ID map, cursors and audit. | Required for idempotency and reconciliation. |
| Xero API and MYOB Business API | Contacts, invoices, payments and tax codes. | Both use OAuth 2.0 and are the supported integration routes. |
| Secrets store | Refresh tokens and client secrets. | Token handling errors are the top cause of broken syncs. |
| Reconciliation job | Daily comparison of totals and unmatched records. | Finds drift well before the BAS does. |
| Alerting | Notifies finance of failed invoices. | Failures must reach someone who can fix them. |
Design decisions and trade-offs
Sync trigger
Events first, scheduled reconciliation second.
Why. Timely and self-healing.
Trade-off. More code than a nightly job.
Idempotency
Deal ID as the invoice reference plus an ID map, so replays update rather than duplicate.
Why. Retries are routine.
Trade-off. Needs a state store.
Tax handling
Tax types come from accounting configuration, never calculated in the CRM.
Why. The ledger must be GST-correct and match the BAS.
Trade-off. Product to tax-code mapping needs upkeep.
Well-architected pillars
Security
OAuth scopes limited to invoicing, encrypted refresh tokens, signed webhooks and no card data.
Reliability
Queue, retries, DLQ, idempotency and reconciliation.
Performance
Batching and backoff for rate limits, which are modest for these APIs.
Cost optimisation
Mostly integration runtime, which is small. iPaaS licensing can dominate at low volume.
Operational excellence
A finance-facing exception queue and a documented re-sync process.
Sustainability
Event-driven rather than polling.
Network, identity and data
Networking
Public SaaS APIs over TLS. The receiver sits behind an API gateway with WAF and an IP allow list where the CRM supports one. Egress from the worker is limited to the vendors' endpoints.
Identity and least privilege
A dedicated integration connection in each system, authorised by an organisation administrator. Staff access is by SSO. Token expiry is monitored.
Data and encryption
Customer names, addresses and ABNs are business and personal information. Send minimal fields, keep audit records for the tax record period and log IDs, not full payloads.
Security and compliance mapping
| Control | How this design addresses it |
|---|---|
| Multi-factor authentication | Enabled on accounting and CRM admin accounts. Essential Eight. |
| Restrict administrative privileges | The integration connection has invoicing scope only. Essential Eight. |
| Record keeping | The audit trail supports ATO record-keeping expectations. |
| Privacy | Minimisation and access control support APP 11. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
Failure modes, targets and scaling
- Target RTOHours. Queued events are retained
- Target RPONear zero for queued events. Reconciliation catches the rest
- Scaling and limitsDesigned for tens to thousands of invoices a day. Both APIs apply rate limits, so check them for your plan.
| Failure mode | Mitigation |
|---|---|
| Refresh token revoked or expired | Alert on auth failures and document the reauthorisation step. |
| Duplicate invoices | Idempotency through deal reference and ID map. |
| Rate limit or API outage | Queue with exponential backoff and DLQ replay. |
| Wrong tax code | Mapping tests and a review report for new products. |
Observability and runbooks
- Dashboard of invoices created, failed and pending.
- Daily reconciliation report to finance.
- Alerts on auth failures and DLQ depth.
Cost drivers and levers
Runtime, iPaaS licences if used and accounting API plan limits.
- Serverless runtime for low volume.
- Batch non-urgent updates.
- Avoid polling where webhooks exist.
Implementation and fit
Phased approach
- Agree the system of record and tax mapping with finance.
- Build one-way deal to invoice with idempotency.
- Add payment status back to the CRM.
- Add reconciliation and exception handling.
Anti-patterns to avoid
- Two-way sync of the same field.
- Matching customers by name.
- Calculating GST in the CRM.
- Storing tokens in code.
When to use it
- Businesses quoting in a CRM and invoicing in Xero or MYOB.
- Teams re-keying invoices today.
When not to
- Complex multi-entity consolidation that needs an ERP.
- No agreement on who owns customer records.
More in crm and business systems
Data platform
Customer 360 platform joining CRM, support, billing and analytics
One governed customer profile built from the systems you already have: identity resolution, consent-aware activation and privacy controls, with a clear line between what is analysed and what is acted on.
Zendesk and ServiceNow
Service desk with chatbot deflection and a knowledge base RAG
Zendesk or ServiceNow as the system of record for tickets, a chatbot that answers from approved knowledge with citations, and a clean hand-over to a person with full context when it cannot.
Entra ID and Okta
Identity and single sign-on across CRM and business apps
One identity provider for staff, partners and customers: SAML and OIDC federation, SCIM provisioning, Conditional Access, role mapping and a leaver process that really removes access.
Related insights
Discuss this architecture
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.