Acumatica and ServiceNow integration

What moves between them

The main flow runs from Acumatica into ServiceNow. ml-connector reads vendors, purchase orders, AP bills, payments, GL accounts, and cost centers from Acumatica and loads them into the ServiceNow Source-to-Pay staging tables, where a transform map promotes them to the operational supplier, purchase order, and invoice tables. GL accounts and cost centers are synced first so each line resolves to a valid ServiceNow dimension. The return path is narrower: procurement requests approved in ServiceNow are read back and created as Acumatica purchase orders. Acumatica stays the financial system of record, so ml-connector never writes posted ledger entries from ServiceNow back into the ERP.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Acumatica side it requests an OAuth2 token from the tenant identity server, refreshes it with the offline_access refresh token, and pins the exact endpoint version per customer so a version mismatch never silently breaks a sync. On the ServiceNow side it requests a client-credentials bearer token and re-authenticates before the 30-minute expiry, falling back to basic auth where the inbound client-credentials grant is not enabled. Because neither side has a reliable registerable webhook, the default is polling: Acumatica is read with a LastModifiedDateTime filter and top and skip offset paging, and a high-water mark is stored after each run. Writes into ServiceNow go through the Import Set API with a coalesce field set to the Acumatica reference, so re-reading the same vendor or bill updates the existing row instead of creating a duplicate, which matters because ServiceNow has no idempotency-key header. Acumatica field values are unwrapped from their value objects on read and wrapped again on write, and GL accounts and cost centers are mapped on both sides so postings land on dimensions that exist in each system. Both APIs return HTTP 429 under load, so ml-connector honors the Retry-After header where present and backs off with jitter, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized building products distributor runs Acumatica for AP, purchasing, and the general ledger, and runs ServiceNow for IT and shared services across three branches. Procurement and AP staff already live in ServiceNow all day, so they kept a side spreadsheet of approved vendors and open purchase orders copied out of Acumatica, which drifted out of date and led to bills entered against the wrong GL account. With Acumatica and ServiceNow connected, vendors, purchase orders, AP bills, GL accounts, and cost centers land in the ServiceNow Source-to-Pay tables on a schedule, and a request approved in ServiceNow becomes an Acumatica purchase order automatically. The duplicate spreadsheet is gone and the two systems show the same numbers.

What you can do

• •Load Acumatica vendors, purchase orders, AP bills, and payments into the ServiceNow Source-to-Pay staging tables.
• •Sync Acumatica GL accounts and cost centers first so every ServiceNow line resolves to a valid dimension.
• •Create approved ServiceNow procurement requests as Acumatica purchase orders on the return path.
• •Bridge Acumatica OAuth2 to ServiceNow client-credentials auth across two instance-specific URLs.
• •Upsert by coalescing on the Acumatica reference, with retries and a full audit trail on every record.

Questions

Which direction does data move between Acumatica and ServiceNow?

The main flow is Acumatica into ServiceNow. Vendors, purchase orders, AP bills, payments, GL accounts, and cost centers move from Acumatica into the ServiceNow Source-to-Pay staging tables. The narrower return path turns approved ServiceNow procurement requests into Acumatica purchase orders. Acumatica stays the financial system of record, so posted ledger entries are never written back from ServiceNow.

How does the integration avoid duplicate records in ServiceNow?

ServiceNow has no idempotency-key header, so posting the same record twice would create two rows. ml-connector writes through the Import Set API with a coalesce field set to the Acumatica reference, so a re-read vendor or bill updates the existing row instead of inserting a new one. It also dedupes on that reference before each write.

Do Acumatica or ServiceNow webhooks drive the sync, or is it polling?

Polling is the default because neither side offers a connector-registerable webhook. ml-connector reads Acumatica with a LastModifiedDateTime filter and offset paging and stores a high-water mark each run. A ServiceNow admin can optionally wire a Business Rule and Outbound REST Message, and Acumatica push notifications can act as a trigger, but both are treated as optional accelerators on top of the scheduled poll.