Sage 300 and Rippling integration

What moves between them

The primary flow runs from Rippling into Sage 300. After each payroll cycle, ml-connector reads Rippling payroll accounting records and employee lifecycle events, then posts the corresponding GL journal entries into Sage 300's general ledger, mapped to the GL accounts and accounting dimensions already in Sage 300. Employee records, department assignments, and compensation changes flow from Rippling into Sage 300 to keep headcount and cost allocations aligned. Reference data such as departments and GL dimensions is aligned bidirectionally. Sage 300 GL data is read-only from Rippling's perspective, so no payroll entries are posted back to Rippling.

How ml-connector handles it

ml-connector stores Sage 300 Basic Auth credentials (uppercase username and password) encrypted and encodes them in the Authorization header on every request per the Sage 300 API contract. For Rippling, ml-connector uses OAuth2 bearer token authentication or API Key authentication and refreshes the token on 401 responses. The integration polls Rippling's employees endpoint and payroll activity log on a weekly schedule tied to your payroll calendar, using updated_at filters to capture only new or changed records. Sage 300 IIS configuration requires Anonymous Authentication enabled and Windows Authentication disabled, which ml-connector validates at connection time. Employee records from Rippling are matched to Sage 300 vendors or employee master records by email or ID, and payroll GL entries are posted to the correct GL account and cost dimension before submission. Large poll requests (1500+ calls) can trigger IIS AppPool timeouts, so ml-connector breaks polling into smaller batches and retries with exponential backoff. Every record carries a full audit trail, and failed submissions can be replayed once the underlying Sage 300 issue is fixed.

A real-world example

A mid-sized manufacturing company runs Sage 300 on-premise for accounting and inventory, and uses Rippling for payroll and HR across three locations. Before the integration, the accounting team ran a weekly manual process: extract the payroll register from Rippling, calculate labor cost allocations by department and location, and re-enter those GL entries into Sage 300. New hires in Rippling were not reflected in Sage 300 employee records until the accounting team manually added them. With Sage 300 and Rippling connected, payroll GL entries post automatically every Friday after payroll closes, pre-allocated to the correct GL accounts and locations, and new hires are visible in Sage 300 the same day they are hired in Rippling. Month-end close now starts with labor costs already posted and reconciled.

What you can do

• •Post payroll GL entries from Rippling into Sage 300 on a weekly schedule after each pay period, allocated to the correct GL accounts and cost dimensions.
• •Keep Sage 300 employee records in sync with Rippling hires, transfers, terminations, and rehires.
• •Authenticate Rippling with OAuth2 bearer token or API Key, and Sage 300 with uppercase HTTP Basic Auth credentials.
• •Map Rippling departments and compensation records to Sage 300 GL accounts and dimensions so payroll entries land on valid accounts.
• •Poll Rippling employee and payroll activity on a weekly cadence with retries, full audit trails, and error replay on every record.

Questions

Which direction does data move between Sage 300 and Rippling?

The primary flow is Rippling into Sage 300. Payroll GL entries and employee records move from Rippling into Sage 300, while departments and GL dimensions are aligned in both directions. Sage 300 GL accounts are read-only from the Rippling side, so ml-connector does not write financial entries back into the accounting system.

How does the integration handle Sage 300's uppercase Basic Auth and IIS configuration requirements?

ml-connector stores the Sage 300 API user credentials encrypted and converts the username and password to uppercase before encoding them in the HTTP Basic Auth header on every request. The integration also validates that the Sage 300 IIS server has Anonymous Authentication enabled and Windows Authentication disabled at connection time, which is required for the REST API to function correctly.

What happens if a poll request triggers an IIS AppPool timeout or Rippling rate limit?

ml-connector breaks large polling requests (1500+ calls) into smaller batches to avoid IIS AppPool timeouts, and retries each batch with exponential backoff. If a Rippling API call returns a rate limit or timeout error, ml-connector backs off, retries, and logs the event in the audit trail. If a Sage 300 GL entry fails to post, it is held in the queue and can be replayed once the underlying issue is resolved.