MYOB and Rippling integration
MYOB runs accounting and AR/AP for SMBs across ANZ. Rippling runs payroll, HR, and employee records. Connecting the two keeps your workforce master data and your chart of accounts in agreement. New hires and terminations in Rippling populate as contacts in MYOB, and department changes align with cost centers so payroll allocations reference valid GL dimensions. ml-connector handles the different authentication flows on each side and moves data on a schedule you control.
What moves between them
The main flow is Rippling into MYOB. ml-connector polls Rippling's employees endpoint on a weekly or bi-weekly schedule and maps each employee to a contact in MYOB, using the employee ID as the external reference. When an employee is terminated in Rippling, their contact in MYOB is marked inactive. Departments in Rippling are mapped to categories or cost center references in MYOB so that GL journal lines written during payroll processing can allocate to the correct ledger dimension. The sync runs one-directional because MYOB has no employee lifecycle events and Rippling has no accounting APIs.
How ml-connector handles it
ml-connector stores the OAuth token from each system encrypted and manages MYOB's 20-minute token refresh automatically to avoid 401 errors mid-flow. On the Rippling side, it presents either the API key or a fresh OAuth token on each call depending on the credential type provided. It polls Rippling using the updated_at timestamp filter to find employees added or changed since the last sync, and cross-references the external_id field in Rippling against the employee ID stored in MYOB to avoid duplicates. When an employee is updated, ml-connector fetches the current record from Rippling, maps the full name and department to MYOB contact fields, and issues a PATCH to MYOB with the required RowVersion field to prevent conflicts. MYOB's rate limit of 8 requests per second is respected with queuing, and 429 responses trigger exponential backoff. Because MYOB has no native idempotency key header, ml-connector uses BullMQ job deduplication to ensure the same employee sync is never posted twice, and the audit trail logs both the Rippling source record and the resulting MYOB contact state for reconciliation.
A real-world example
A mid-sized marketing and professional services firm uses Rippling for payroll and employee records across two offices and uses MYOB for accounting and AR. When new employees are hired or move departments in Rippling, the finance team manually adds them as contacts in MYOB to ensure they are available as payee dimensions for timekeeping and cost allocation. With Rippling and MYOB connected, each week's batch of new hires and department transfers flows into MYOB automatically, keyed by employee ID so there is no duplicate entry or re-keying. Year-end close is simpler because the employee roster in MYOB always matches the active payroll in Rippling.
What you can do
- Sync active employees from Rippling into MYOB as contacts with full names and employee IDs to prevent duplicates.
- Mark employee contacts as inactive in MYOB when they are terminated in Rippling.
- Map Rippling departments to cost centers or categories in MYOB so payroll allocations land on valid GL dimensions.
- Manage MYOB's 20-minute OAuth token refresh and Rippling API key credentials transparently on every call.
- Poll Rippling on a weekly schedule with retries and a full audit trail on every employee record change.
Questions
- Which direction does data flow between Rippling and MYOB?
- The flow is primarily Rippling into MYOB. Employees and departments from Rippling are synced into MYOB as contacts and cost center references. MYOB does not publish employee events, so ml-connector polls Rippling on a schedule rather than waiting for a push. There is no sync of MYOB data back into Rippling.
- How does ml-connector prevent duplicate employee entries in MYOB?
- ml-connector stores the Rippling employee ID on the MYOB contact record as an external identifier. On each sync, it queries MYOB using that ID to find the existing contact and updates it rather than creating a new one. BullMQ job deduplication ensures the same sync is never processed twice if retried.
- What happens to MYOB contacts when an employee is terminated in Rippling?
- ml-connector detects the termination status on the Rippling employee record and marks the corresponding MYOB contact as inactive, preserving it in the historical ledger without removing it. This keeps GL transactions linked to the former employee intact while preventing them from appearing in active contact lists.
Related integrations
More MYOB integrations
Other systems that connect to Rippling
Connect MYOB and Rippling
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started