QuickBooks Desktop and Rippling integration

What moves between them

Rippling employees flow into QuickBooks Desktop as new or updated Employee records, aligned by email or external ID to prevent duplicates. Payroll GL entries from Rippling payroll runs are mapped to JournalEntry objects, with each line item allocated to the matching QuickBooks Account and cost center. The flow is Rippling-to-QuickBooks-Desktop only; QuickBooks is the system of record for accounting and does not send employee or payroll changes back to Rippling. Polling occurs on a cadence tied to your payroll calendar, typically once per pay cycle, so payroll entries post into QuickBooks a few hours after Rippling marks the run closed.

How ml-connector handles it

ml-connector stores your Rippling OAuth token or API key encrypted and refreshes it before expiry. On the QuickBooks side, it accepts the SOAP endpoint URL and QBWC credentials you provide, calls authenticate() at the start of each polling cycle to obtain a session token, and uses that token for all QBXML requests in that cycle. Before updating an existing Employee or JournalEntry record, ml-connector queries it fresh to retrieve the current EditSequence version number, re-sends the update with the correct EditSequence, and retries if the version has changed in the meantime (indicating a concurrent edit). For payroll GL entries, ml-connector reads Rippling compensation or payroll-run summaries, matches cost centers and departments to QuickBooks Accounts, and builds JournalEntry objects with debit and credit lines. If a SOAP request times out or returns an EditSequence conflict, ml-connector backs off and retries on the next polling cycle without duplicating prior entries. Every transaction carries an audit trail and can be replayed if a downstream QuickBooks job fails.

A real-world example

A mid-sized services firm runs Rippling for employee onboarding, payroll, and expense management, and uses QuickBooks Desktop as their accounting system. Before the integration, the finance team exported payroll summaries from Rippling monthly and manually entered labor costs into QuickBooks, often introducing typos and misaligned cost center allocations. New employees added in Rippling were entered by hand into QuickBooks after a week-long lag, and terminated employees left ghost records that had to be cleaned up during month-end. With Rippling and QuickBooks Desktop connected via ml-connector, each employee change flows into QuickBooks within minutes, and payroll GL entries post automatically on payday, already allocated to the correct cost centers. Month-end close is now a verification step instead of a re-keying marathon, and the finance team has reclaimed hours of manual work per pay cycle.

What you can do

• •Sync Rippling employees into QuickBooks Desktop as Employee records, with change detection via the updated_at filter to avoid re-entering unchanged records.
• •Post payroll GL entries from Rippling payroll runs into QuickBooks Desktop as JournalEntry objects, allocated to the correct cost centers and accounts.
• •Authenticate QuickBooks Desktop via the SOAP session-token handshake and manage EditSequence versioning on all updates to prevent version conflicts.
• •Handle QuickBooks QBWC polling cycles with retry-safe transaction processing and duplicate detection across multiple polling intervals.
• •Maintain a full audit trail of every employee and payroll record synced, with the ability to replay failed entries when downstream jobs recover.

Questions

Which direction does data move between Rippling and QuickBooks Desktop?

Data flows one way: from Rippling into QuickBooks Desktop. Rippling employees and payroll GL entries are read from Rippling, transformed into QuickBooks objects, and written into QuickBooks. QuickBooks does not send employee or payroll changes back to Rippling, making QuickBooks the system of record for accounting.

How does ml-connector handle QuickBooks Desktop's EditSequence versioning and SOAP session tokens?

ml-connector calls the SOAP authenticate() method at the start of each QBWC polling cycle to obtain a session token, valid for all requests in that cycle. Before updating an existing record (Employee or JournalEntry), ml-connector queries it fresh to retrieve the current EditSequence, re-sends the update with that version number, and retries if the version has changed due to a concurrent edit.

Why does QuickBooks Desktop require the QBWC agent to be running on premises?

QuickBooks Desktop is a locally-installed application; the QBWC agent bridges between the customer's premises and ml-connector. QBWC must be running on a Windows machine with QuickBooks logged in to an open company file. ml-connector provides a SOAP endpoint that QBWC calls on a configurable interval (typically every 5-15 minutes) to fetch and execute Rippling-to-QuickBooks requests.