Xero and Rippling integration

What moves between them

Employee records and payroll dimensions flow from Rippling into Xero. When employees are created, updated, terminated, or rehired in Rippling, their records sync into Xero's contact list. Departments, cost centers, and job codes from Rippling map to Xero's tracking categories and custom accounts so payroll GL allocations carry the correct dimensions. Payroll runs and compensation data are read from Rippling on a schedule aligned to your payroll calendar, then translated into manual journal entries in Xero. The flow is primarily one-way: Rippling to Xero, with reference dimensions aligned bidirectionally.

How ml-connector handles it

ml-connector uses OAuth2 on both sides: an authorization code flow for Xero (storing the refresh token securely) and either OAuth2 or an API key for Rippling depending on the integration type. For webhook-based Rippling instances, employee lifecycle events trigger a pull of the full employee record from the Rippling API. For API-key integrations without webhook support, ml-connector polls Rippling's employee and activity endpoints using the updated_at filter or the company activity log. On the Xero side, it constructs manual journal entries from payroll data and posts them with the appropriate GL account and tracking category codes. Because Xero rate-limits at 5 concurrent calls and 60 per minute per tenant, ml-connector queues requests and backs off on 429 responses. Deleted employees in Rippling are soft-deleted in Xero by toggling the contact status. Every record carries audit trail metadata so failed posts can be replayed.

A real-world example

A mid-market services firm uses Xero for accounting and Rippling for payroll across three offices. Before integration, payroll was processed in Rippling monthly, then the finance team manually entered labor cost journals and headcount changes into Xero, taking days to reconcile. With Rippling and Xero connected, each payroll run automatically posts journal entries to Xero allocated to the cost center for each office, and employee changes in Rippling immediately update the corresponding Xero contact records. Month-end close starts with labor accounts already balanced and headcount aligned.

What you can do

• •Sync employee records from Rippling into Xero contacts and maintain name, email, department, and job title in lockstep.
• •Map Rippling departments and cost centers to Xero tracking categories so payroll allocations land on the correct GL accounts.
• •Post payroll GL entries from Rippling into Xero's general ledger on a schedule tied to your payroll calendar.
• •Authenticate Rippling via OAuth2 or API key and Xero via OAuth2 refresh token, refreshing both credential sets automatically.
• •Poll Rippling for employee lifecycle changes via webhooks or activity logs, with retries and full audit trail on every sync.

Questions

Does ml-connector receive Rippling webhooks or poll the API?

If your Rippling integration is an App Shop application with webhook permissions, ml-connector listens for employee lifecycle events and pulls the full record on demand. If you use a direct API key integration without webhook support, ml-connector polls the Rippling employee and activity endpoints on a schedule you define, using the updated_at filter or company activity log.

How are Rippling departments and cost centers mapped to Xero accounts?

You define a mapping during setup that links Rippling departments, teams, and job codes to Xero's tracking categories and GL accounts. When a payroll journal is posted, ml-connector looks up the employee's department and applies the matching account code. If a mapping is missing, the sync halts and logs the discrepancy so you can add it without data loss.

What happens if the Xero rate limit is hit or a manual journal post fails?

ml-connector queues outbound requests and backs off on HTTP 429 rate-limit responses, respecting the 60-per-minute limit. If a journal post fails due to an invalid GL account or tracking category code, the job is retried up to three times with exponential backoff; if it still fails, the record is logged as failed in the audit trail and can be replayed once you fix the underlying issue.