SYSPRO and ServiceNow integration

What moves between them

Invoice and supplier records flow from SYSPRO into ServiceNow APO staging tables on a regular schedule. SYSPRO general ledger account master records and cost center definitions flow into ServiceNow's itfm_gl_accounts and cmn_cost_center tables so APO invoice lines land on valid dimensions. General ledger posting records from SYSPRO flow into staging for downstream reconciliation. The flow is primarily one-way, from SYSPRO into ServiceNow, with reference data (cost centers, GL accounts) synced bidirectionally to keep both systems aligned.

How ml-connector handles it

ml-connector stores both credential sets encrypted and uses HTTP Basic Auth to poll SYSPRO OData on a schedule you define, filtering by PostDate and InvoiceDate to retrieve only new or changed financial records. On the ServiceNow side it refreshes the OAuth 2.0 bearer token on every request, since tokens expire after 30 minutes, and places invoice and supplier records into the APO inbound staging table (sn_apo_invoice and proc_po families) for downstream processing. SYSPRO session tokens are cached and refreshed on timeout. Cost centers and GL accounts are mapped first so invoice lines reference valid ServiceNow dimensions. Because both systems are polling-only with no webhooks, ml-connector runs on a fixed schedule (typically hourly for invoices, daily for reference data) and tracks which records have already been synced to avoid duplicates. Every record carries a full audit trail and can be replayed if a downstream ServiceNow workflow fails.

A real-world example

A mid-sized discrete manufacturer runs SYSPRO for ERP and operations and uses ServiceNow for IT and finance automation through the APO module. Before the integration, the accounts payable team received supplier invoices from SYSPRO, printed or manually exported them, and re-keyed the invoice lines into ServiceNow staging tables, which then fed into ServiceNow procurement workflows. This process was slow, error-prone, and created reconciliation gaps between SYSPRO and ServiceNow during month-end close. With SYSPRO and ServiceNow connected, each new SYSPRO invoice is synced automatically into ServiceNow staging on a schedule tied to invoice receipt, supplier records stay aligned, and GL accounts match between systems. The AP team now starts their workflow with clean data already loaded and verified, and close cycles complete faster with fewer reconciliation exceptions.

What you can do

• •Sync SYSPRO supplier and invoice records into ServiceNow APO staging tables on a schedule you control.
• •Map SYSPRO cost centers and general ledger accounts to ServiceNow dimensions so invoice lines post to valid accounts.
• •Authenticate SYSPRO with e.net Business Objects session tokens and ServiceNow with OAuth 2.0 Client Credentials, managing token refresh and session timeout.
• •Poll SYSPRO OData on a fixed schedule, filtering by timestamp to retrieve only new or changed records.
• •Track synced records and retry failed inserts into ServiceNow with a full audit trail.

Questions

Which records flow from SYSPRO into ServiceNow and in which direction?

Invoices, suppliers, purchase orders, and general ledger records flow from SYSPRO into ServiceNow APO staging tables. Cost centers and GL accounts flow in both directions to keep reference data aligned. The primary direction is SYSPRO into ServiceNow; ml-connector does not write back to SYSPRO general ledger.

How does the integration handle SYSPRO's polling-only model and ServiceNow's OAuth token expiry?

ml-connector polls SYSPRO OData on a fixed schedule (typically hourly for invoices) filtering by PostDate and InvoiceDate to retrieve only new records. ServiceNow OAuth tokens expire after 30 minutes, so ml-connector refreshes the bearer token on every request and handles 401 responses by re-authenticating before retrying the insert.

What happens if an invoice fails to insert into ServiceNow staging?

ml-connector tracks the failed record and retries on the next sync cycle with exponential backoff. The full audit trail shows which records succeeded, which failed, and why, so you can investigate downstream workflow failures or missing data without re-keying.