Wave Accounting and Rippling integration

What moves between them

The main flow runs from Wave into Rippling. When customers are created or updated in Wave, ml-connector syncs them into Rippling as accounting dimension references. When invoices are created, updated, or paid in Wave, ml-connector pushes them to Rippling so payroll and expense allocations can reference the correct customer. Updates trigger immediately via Wave webhooks, avoiding polling delays. Rippling accounting dimensions are aligned with Wave customers so every payroll line or expense entry can land on the correct customer allocation. No data flows from Rippling back to Wave, since Wave invoices are created in the accounting platform and Rippling consumes them downstream.

How ml-connector handles it

ml-connector listens on a webhook endpoint registered in Wave and validates each incoming event with the HMAC-SHA256 signature and replay window. When a customer or invoice event arrives, ml-connector refreshes its Wave OAuth token if needed and queries the GraphQL endpoint for the full entity. For Rippling, ml-connector can use either OAuth 2.0 (if App Shop integrated) or direct API key authentication (simpler for integrations that do not require webhook delivery from Rippling). Customer data maps to Rippling accounting dimensions by customer ID, so every invoice reference can be traced back to a customer. If a Wave refresh token expires, ml-connector detects the 401 response and prompts for re-authentication. If an invoice event arrives for a customer not yet synced to Rippling, ml-connector queues the invoice and retries after the customer dimension is created. Every record carries full audit and can be replayed if a downstream Rippling call fails.

A real-world example

A small professional services firm uses Wave Accounting to track customer invoices and expenses. They use Rippling for employee payroll and time tracking. Before the integration, they manually entered customer references into Rippling's time and expense sheets by hand, and project allocations in payroll did not match the invoice customers in Wave. With Wave and Rippling connected, each new customer added to Wave flows into Rippling as an accounting dimension, time entries and expense codes align automatically, and the finance team can reconcile customer revenue in Wave against labor costs in Rippling by customer without manual rekeying.

What you can do

• •Sync Wave customers into Rippling as accounting dimension references so payroll and expenses align with billing.
• •Push Wave invoice events (created, updated, paid) to Rippling in real time via webhooks.
• •Validate Wave webhook signatures using HMAC-SHA256 and enforce the 5-minute replay window.
• •Map Wave invoice and customer data to Rippling accounting dimensions and company metadata.
• •Handle Wave OAuth token refresh and Rippling API key or OAuth authentication with automatic retries and a full audit trail.

Questions

Why does Wave and Rippling integration use webhooks instead of polling?

Wave pushes invoice and customer events via webhooks, so ml-connector receives updates immediately as they happen. This avoids the delay and cost of polling the GraphQL endpoint. ml-connector listens on a registered webhook URL, validates each event with the HMAC-SHA256 signature, and syncs the entity to Rippling right away.

What happens if a Wave invoice references a customer that has not yet been synced to Rippling?

ml-connector queues the invoice event and retries it after the customer dimension is created in Rippling. This ensures every invoice reference has a valid customer dimension to land on. If the retry fails, the event is logged in the audit trail and can be manually replayed.

Can data flow from Rippling back to Wave?

No. Wave invoices are the source of truth and are created in the accounting platform. Rippling consumes customer and invoice data downstream for payroll and expense allocation. ml-connector does not write back to Wave, keeping the flow unidirectional and avoiding conflicts.