Sage 100 and Rippling integration

What moves between them

The main flow runs from Sage 100 into Rippling. AP vendors and GL accounts are read from Sage 100 via the local agent and mapped to Rippling accounting dimensions, so payroll cost allocations land on valid GL accounts. Department and cost center records are aligned in both directions to keep payroll GL impacts traceable. Sage 100 GL journals created by payroll adjustments are read back from Rippling and posted into Sage 100's GL if needed. Data moves on a polling schedule you control, typically every 15 minutes for AP and GL changes and daily for vendors and chart-of-accounts updates.

How ml-connector handles it

ml-connector deploys a local Windows agent on your Sage 100 server with credentials to call the BOI COM layer directly; no SOAP calls are needed because the agent wraps the full AP/GL/PO surface. The agent polls Sage 100 at intervals you set, reads vendors, GL accounts, and GL journal entries, and pushes them to ml-connector's queue. On the Rippling side, ml-connector authenticates with OAuth or API key and polls the employee, department, and accounting-dimension endpoints using the updated_at filter to only fetch changes. Sage 100 GL accounts use multi-segment format (e.g. 4000-01-00); ml-connector normalizes them to flat strings and maps them to Rippling's accounting dimensions on initial setup. Sage 100 has no idempotency keys and uses COM record locking, so ml-connector checks for existing records before inserting and retries with exponential backoff on lock conflicts. Department and cost center names are synchronized in both directions, so downstream payroll journals in Sage 100 reference departments that exist in Rippling. Every record carries a full audit trail and can be replayed if a downstream system call fails.

A real-world example

A mid-market manufacturing company runs Sage 100 on-premises for AP, GL, inventory, and PO, and uses Rippling for payroll, HR, and benefits across three departments. Before the integration, the accounting team exported AP vendor lists and GL charts from Sage 100 monthly, then manually updated Rippling's accounting dimensions and cost centers to match. Payroll was run in Rippling, but the GL impact - labor cost distribution by department - was re-entered by hand into Sage 100's GL, creating reconciliation delays during month-end close. With Sage 100 and Rippling connected, vendor and GL changes from Sage 100 flow into Rippling automatically, department definitions stay in sync, and the accountant can see payroll's GL impact in Rippling before posting it to Sage 100, eliminating manual re-keying and closing faster.

What you can do

• •Sync AP vendors and GL accounts from Sage 100 to Rippling accounting dimensions so payroll allocations are always valid.
• •Map Sage 100's multi-segment GL account format to flat Rippling accounting dimensions and maintain the mapping across updates.
• •Align department and cost center definitions in both directions so Rippling payroll journals and Sage 100 GL line up by department.
• •Deploy a local Windows agent on your Sage 100 server to call the BOI COM layer directly, bypassing SOAP's AR-only limitation and accessing the full AP, GL, and PO surface.
• •Poll on your schedule with retries and a full audit trail on every vendor, account, and journal record so reconciliation and replay are straightforward.

Questions

Why does ml-connector need a local agent on the Sage 100 server?

Sage 100's SOAP eBusiness Web Services only covers Sales Orders and Customers (AR only). AP, GL, PO, and vendor data require the full BOI COM layer, which can only be called locally from the Sage 100 server. ml-connector's local Windows agent wraps the BOI calls, polls on your schedule, and pushes the data to ml-connector's queue for processing.

How does ml-connector handle Sage 100's multi-segment GL account format?

Sage 100 GL accounts use a multi-segment format like 4000-01-00, and the exact format varies by customer configuration. ml-connector reads the full segments during initial setup, normalizes them to flat strings for storage and matching, and maps them to Rippling accounting dimensions. The mapping is maintained in ml-connector's audit log so changes can be audited and replayed.

Can payroll GL journals from Rippling post back into Sage 100?

Yes. ml-connector polls Rippling for GL journals created by payroll runs, maps the cost allocations back to Sage 100's GL accounts and cost centers, and posts the journals into Sage 100's GL if your workflow requires it. This keeps Sage 100's labor cost accounts in agreement with Rippling's payroll run totals.