> ## Documentation Index > Fetch the complete documentation index at: https://docs.dualentry.com/llms.txt > Use this file to discover all available pages before exploring further. # Connect Rippling payroll and post journal entries > Connect Rippling to DualEntry, map worker types and pay statement items to GL accounts, and post each pay run as journal entries by company and currency. Connect [Rippling](https://www.rippling.com/) to DualEntry so each finalized pay run posts to your ledger as journal entries, split by the worker types you choose to sync: W-2 employees, 1099 contractors, and workers employed through an employer of record (EOR) or a professional employer organization (PEO). DualEntry reads Rippling's V2 REST API directly over OAuth. Data flows one way, from Rippling into DualEntry, and DualEntry never writes back to Rippling. The integration also reconciles Rippling's user provisioning group into DualEntry seats, so the people your Rippling admin provisions get DualEntry access without a separate invite. The Rippling integration is in beta. Setup takes more configuration than most connectors, so read [Current limitations](#current-limitations) before you commit a close cycle to it. Contact DualEntry support if you want help with the first connection. ## Prerequisites Confirm all of the following before you start. The first two are the ones that most often block a connection on the day. * **The Rippling App Management package.** Your organization must have purchased it. If you do not have it, contact your Rippling Account Manager to add it. Without the package, the install does not work. * **Rippling admin permissions for whoever runs the install.** Your organization may need to grant these internally first, so confirm them before you start rather than partway through. * Permission in DualEntry to create and configure integrations. * A vendor record in DualEntry to act as the payroll vendor, stamped on the journal entries the integration writes. * GL accounts in your [chart of accounts](../core-financials/general-ledger/chart-of-accounts) for payroll expense, employer tax expense, employer benefit contributions, withholding liabilities, and an accrued payroll or clearing account to use as the offset. * A DualEntry company for each Rippling legal entity you intend to post to. Every legal entity has to be mapped before setup counts as complete. * Optionally, a classification such as **Department** in DualEntry if you want journal entry lines split by Rippling department. ## How to connect Connecting redirects the browser to Rippling's install screen, where a Rippling admin authorizes DualEntry. The authorization code comes back to DualEntry, which exchanges it for tokens and immediately runs a metadata sync so there is something to map. 1. Confirm both Rippling prerequisites above. 2. Sign in to DualEntry as the person who holds Rippling admin permissions, since the same session authorizes both sides. 3. Go to **Company → Integrations → Rippling**. 4. Choose **Connect**. DualEntry sends the browser to the Rippling install screen for the DualEntry app. 5. Authorize DualEntry from that screen. Rippling returns to DualEntry, which stores the tokens and marks the app installed on Rippling's side. 6. Confirm the connection shows as active. 7. Complete the mapping described in the next sections, then run the first sync and check the entries it produces before you rely on the daily schedule. DualEntry requests read scopes covering payroll runs, worker payroll records, earning types, workers, users, companies, legal entities, departments, employment types, work locations, job functions, and supergroups. The payroll scopes are private scopes that Rippling approves per app; the rest are self-serve. Alongside those scopes, the DualEntry app listing in Rippling carries an IAM package: the permission set Rippling attaches to an installed app to decide what company data it may read. A scope can be granted while the IAM package still withholds the underlying data, which is why a connection can look correctly authorized and still return nothing for a step. A connection succeeds even when some of those scopes are missing. DualEntry records the steps that were refused and surfaces them as warnings rather than failing the install, so a partially scoped connection still gives you something to work with. Reconnect after the Rippling admin grants the missing scopes and the warnings clear on the next clean run. ## What syncs The first sync after connecting pulls reference data only, so you can finish mapping before any journal entry is written. Pay statements post once the required mappings are complete. The following table maps each kind of Rippling data to the DualEntry record it becomes: | Rippling data | DualEntry record | Notes | | --------------------------- | -------------------------- | ------------------------------------------------------------------------------------------- | | Legal entities | `company` mapping | One row per Rippling legal entity. Each must map to a DualEntry company. | | Payroll vendor | `vendor` mapping | One vendor stamped on every payroll journal entry. | | Departments | `classification` line | Mapped to the classification you name in settings, used to split journal entry lines. | | Workers | `individual` mapping | Employees and contractors, resolved to a worker type on import. | | Employees to companies | `employee_company_mapping` | Auto-matched from each worker's legal entity, and resolvable by hand where the match fails. | | Provisioning group members | DualEntry seats | Members of Rippling's **PROVISIONING** supergroup become organization users. | | Pay statement item catalogs | `account` mapping | Three fixed catalogs, one per worker type. Every item needs a GL account. | | Pay runs | `vendor payment` reference | Finalized runs inside the history window. | | Worker payroll records | Journal entries | Gross-to-net detail per worker, rolled into the journal entries described below. | Only pay runs in an **APPROVED** or **PAID** state sync. Runs in any other state are skipped until they are finalized. ## Choose which worker types to sync Rippling covers three kinds of worker, and each posts differently. Turn on only the ones you actually pay through Rippling, because each one you enable adds its own required mappings before setup counts as complete. The terms come from Rippling and from US payroll practice rather than from DualEntry: * **W-2 employee.** A direct employee of one of your legal entities, named for the US wage and tax statement filed for them. Payroll taxes are withheld and remitted on their behalf. * **1099 contractor.** A self-employed worker paid without withholding, named for the US information return filed for them. * **EOR, employer of record.** A third party that legally employs a worker on your behalf, typically in a country where you have no legal entity. You direct the work; the EOR runs the employment. * **PEO, professional employer organization.** A co-employment arrangement in which a third party handles payroll, taxes, and benefits for workers at your own entity. DualEntry posts EOR and PEO the same way, as a consolidated invoice total rather than a gross-to-net breakdown, because the amount you owe is an invoice from the provider rather than wages you paid. Open the integration's configuration drawer and choose **Rippling Settings**: * **Sync W-2 Employees.** Posts payroll journal entries for W-2 employees. Requires the W-2 pay statement item catalog to be fully mapped and a **Default Offset Account (W-2)**. * **Sync 1099 Contractors.** Posts journal entries for contractors. Requires the contractor catalog and a **Contractor Offset Account**. * **Sync EOR/PEO.** Posts EOR and PEO payroll as a consolidated invoice-total journal entry. Requires the EOR catalog, an **EOR Offset Account** (the payable to Rippling) and an **EOR Employment Expense** account. Worker type is resolved from Rippling rather than chosen in DualEntry. A worker whose legal entity carries a management type of PEO or EOR is treated as an EOR worker, whatever their employment type says. Everyone else resolves from their employment type: EMPLOYEE becomes W-2, CONTRACTOR becomes a contractor. A worker who matches neither is reported as an error rather than guessed at. Two more settings affect scope rather than posting. **Include Terminated Employees** brings terminated workers into the sync, which you want when a final paycheck lands after termination. **Department Classification Name** picks the DualEntry classification that Rippling departments map onto. If you enable a worker type and leave its offset account empty, that worker type is blocked at posting time with an explicit error and the rest of the run still posts. ## Set the accounting basis The **Accounting Basis** setting decides how many journal entries a W-2 pay run produces and what they are dated. Set it once, before the first sync, because it changes the shape of every entry the integration writes. On **Accrual**, a W-2 pay run produces two journal entries: an accrual entry dated the end of the pay period, and a payment entry dated the check date. The payment entry is only written when the two dates differ, so a run whose period ends on the check date produces a single entry. On **Cash**, a W-2 pay run produces one journal entry dated the check date. Contractor and EOR entries follow the same basis, and settle differently depending on one more setting. Leave **Cash / Bank Account** empty to post the accrual and settle the payable through Accounts Payable. Set it, and the cash or bank account is credited when a contractor or EOR payable is settled on a later payment date. Changing the basis does not restate journal entries that already posted. Set it before the first sync and treat a later change as a decision that applies from that point forward. ## Map your Rippling data After connecting, DualEntry shows you what needs mapping. Until every required mapping is filled in, the integration reports itself as not yet set up and no pay statement posts. Setup is complete when all of this is true: every Rippling legal entity maps to a DualEntry company, the payroll vendor is mapped, the pay statement item catalog for each enabled worker type is fully mapped, and every employee resolves to a company. ### Map legal entities and the payroll vendor Map each Rippling legal entity to the DualEntry company its payroll should post to. This mapping decides where the journal entries land, and unlike some payroll connectors, Rippling supports more than one entity: each legal entity gets its own row and its own company. Map the payroll vendor to your DualEntry vendor record. That vendor is stamped on every payroll journal entry the integration writes, which is what makes the entries traceable back to the connector during close. ### Map pay statement items to GL accounts Rippling pay data maps onto three fixed catalogs rather than a list of earning codes built from your own payroll configuration, so the mapping work is bounded and the same for every organization. The W-2 catalog holds fifteen items: regular pay, overtime, bonus, commission, reimbursement, employer payroll taxes, employer benefit contributions, payroll tax withholding, benefits withholding, 401(k) withholding, deductions, accrued payroll (net pay), employer payroll taxes payable, employer contributions payable, and garnishments payable. The contractor catalog holds contract labor and reimbursement. The EOR catalog holds a single EOR payroll expense item. Each item carries a fixed debit or credit direction, so you choose the account and the integration decides the side. Assign a GL account to every item in each catalog you enabled. At posting time, DualEntry routes each line from Rippling by its earning code, tax code and payer, deduction code, or garnishment code. Codes that do not match the catalog directly fall back to keyword classification: | Keywords in the Rippling code | Routes to | | ------------------------------------------- | -------------------- | | reimbursement, mileage, per diem, allowance | Reimbursement | | overtime, double time | Overtime | | bonus, incentive, spiff | Bonus | | commission | Commission | | 401k, 403b, retirement, pension | 401(k) withholding | | health, medical, dental, vision, HSA, FSA | Benefits withholding | ### Map departments to classifications Rippling departments are matched against the classification you named in settings and applied to the journal entry lines. This step is optional, and a department with no matching classification line is left off the entry rather than treated as an error. ## How pay runs become journal entries Once setup is complete, each finalized pay run becomes journal entries grouped by worker type, not one entry per employee. W-2 payroll produces one set of entries per company and currency, so a pay run covering three legal entities produces three sets. Contractor payroll produces one journal entry per contractor, in that contractor's own currency. EOR and PEO payroll produces one consolidated invoice-total entry for the whole run. Tax lines are consolidated by target account by default, which keeps an entry compact when several tax types share an account. Turn **Consolidate Payroll Taxes** off to get one line per tax type instead, for tax-type-level reporting. Every entry is checked for balance before it is written. Sub-cent drift across many workers is absorbed by a rounding adjustment line, tolerated at one cent per line with a five-cent floor. An entry that is out of balance by more than that is reported as an error rather than posted, so an unbalanced entry never reaches your ledger. Review the resulting entries in [Journal Entries](../core-financials/general-ledger/journal-entries). ## Provision DualEntry users from Rippling DualEntry reconciles Rippling's provisioning group into DualEntry seats, so the people your Rippling admin provisions get DualEntry access without a separate invite. This is what the App Management package buys you, and the reason it is a prerequisite rather than a nice-to-have. DualEntry reads the members of the Rippling supergroup named **PROVISIONING** and reconciles them into DualEntry seats. A member who has no DualEntry user gets one created with the view-only role, which an admin can then raise. Members are matched by work email. Rippling then keeps the two in step. DualEntry receives webhooks when an employee is created, updated, deleted, hired, or terminated, and when a group is created, updated, or deleted, and re-runs the reconciliation shortly afterwards rather than waiting for the daily sync. Users the integration created are marked as Rippling-managed. An admin who changes one by hand in DualEntry marks it as a manual override, which the reconciliation then leaves alone. If the connection was authorized without the supergroups scope, provisioning is skipped quietly and the rest of the integration runs normally. The connection shows a warning to that effect, and reconnecting with the scope granted turns provisioning on. Signing in to DualEntry through Rippling is a separate capability, and an optional one. You can skip it when you connect the app, and the payroll integration works either way. Setting it up is not self-service, because it needs SAML details exchanged between the two sides: you configure Rippling, DualEntry configures its identity provider. Contact DualEntry to start that exchange rather than expecting the connect flow to cover it. Once SSO is configured for your email domain, people sign in at the Rippling sign-in page, which asks for a work email and sends them to Rippling to authenticate. ## Sync cadence and history The integration syncs once a day. You can also run it by hand from the integration page when you need a pay run in the ledger sooner. On the first sync, DualEntry imports pay runs whose period ended within the last twelve months. Setting a cutoff date on the integration reaches further back than that, and the earlier of the two dates wins. Later syncs do less work. A **PAID** run whose journal entries all posted cleanly is skipped, so sync cost tracks new activity rather than the age of the connection. An **APPROVED** run is always re-checked, because it can still change before it is paid, and any run with a posting error is retried. ## Current limitations The Rippling integration is in beta and has the following limitations today: * **Setup takes longer than most connectors.** The scope, IAM package, and mapping requirements mean the first connection is a working session rather than a few-minute install. * **No retroactive remapping.** Journal entries that already posted do not change when you later remap a pay statement item or change the accounting basis. Resync the affected runs to apply new mappings. * **Departments match by name.** A Rippling department whose name does not match a classification line is omitted from the entry, with no fallback and no auto-create. * **Read-only toward Rippling.** DualEntry pulls payroll and worker data and does not push your chart of accounts, journal entries, or vendor records back. * **Only finalized runs sync.** Draft and in-progress pay runs are invisible to DualEntry until they reach APPROVED or PAID. ## Troubleshoot sync errors Failed records appear in the **Integration Errors** log on the integration page. Rippling's own status is at [status.rippling.com](https://status.rippling.com/). The following table maps each error you might see on a Rippling integration to its cause and fix: | Error | Cause | Resolution | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Missing IAM package at connect | The DualEntry app listing lacks the IAM package, the permission set Rippling attaches to an installed app, that the OAuth exchange requires. Usually this means App Management was not purchased. | Confirm the App Management package with your Rippling Account Manager, then reconnect. | | Rippling denied access (403) | The connection is missing an API scope, or the app's IAM package withholds that data. Affected steps are skipped, not failed. | Grant the missing scopes or permission set on the Rippling side, then reconnect to re-consent. | | Rippling rejected the access token (401) | The stored token is dead and refreshing it did not help. | Reconnect the integration. | | Rate limit persisted (429) | Rippling throttled the sync after several backoff retries. | Wait and let the next scheduled sync pick it up. | | A pay statement line has no mapped account | An item in an enabled catalog has no GL account assigned. | Assign the account and resync the affected runs. | | A worker type's offset account is not configured | A worker type is enabled but its offset account is empty. | Set the offset account for that worker type. Other worker types keep posting meanwhile. | | A worker's type cannot be resolved | The worker is not EOR or PEO and their employment type is missing or unrecognized in Rippling. | Fix the worker's employment type in Rippling and resync. | | Journal entry is out of balance | Debits and credits differ by more than the rounding tolerance. | Compare the run against Rippling's payroll register and raise it with support. The entry is held back rather than posted. | | Provisioning did nothing | The connection was authorized without the supergroups scope, or the **PROVISIONING** supergroup does not exist in Rippling. | Create the supergroup, grant the scope, and reconnect. | ## Result After completing these steps, every finalized Rippling pay run posts to DualEntry as journal entries per company, currency, and worker type, with departments applied and rounding absorbed. For other payroll providers, see the [Gusto integration](./gusto), the [Justworks integration](./justworks), or the [Deel integration](./deel) for contractor-heavy workforces. For the sync actions you use across every connector, see [Retry, resync, and archive](./managing-syncs). To connect additional systems, return to [Integrations](./index).