Oracle NetSuite and Procurify integration

What moves between them

The main flow is Oracle NetSuite into Procurify. Vendor master records, approved purchase orders, and vendor bills flow from NetSuite into Procurify via the vendors and bills endpoints. GL account and department mappings ensure every bill posted in Procurify references valid cost centers and GL accounts from NetSuite. Requisitions in Procurify remain read-only; NetSuite is the source of truth for approved POs and posted bills. The sync cadence can be event-driven using NetSuite Event Subscriptions for real-time create-edit-delete, or polling-based using SuiteQL for batch synchronization on a schedule.

How ml-connector handles it

ml-connector stores both OAuth credential sets encrypted and refreshes the NetSuite token every 60 minutes to avoid expiry mid-request; Procurify tokens are refreshed every 20 hours. It receives vendor and bill events from NetSuite via the Event Subscriptions listener when available, or polls SuiteQL on a configurable schedule if events are unavailable. For each vendor record, ml-connector maps NetSuite's vendor ID and name to Procurify's vendor slug and validates that any parent GL account or department exists in Procurify first. For each bill, it posts the bill date, amount, vendor reference, and GL account coding to Procurify's bills endpoint, and retries with exponential backoff if Procurify returns a rate limit or timeout. NetSuite's 60-minute token window is tracked and refreshed proactively to prevent mid-flow failures. Every record carries a full audit trail, and failed bills can be manually replayed after corrections are made in either system.

A real-world example

A mid-market manufacturing company runs Oracle NetSuite for general ledger and accounts payable across three plants. The procurement team uses Procurify for purchase order workflow and spend analytics. Before the integration, Procurify's bill records and vendor master often drifted from NetSuite - new vendors added in NetSuite took days to appear in Procurify, and bills approved in Procurify that landed in NetSuite sometimes ended up on incorrect GL accounts or cost centers. Month-end close required manual reconciliation of bill totals and GL coding between the two systems. With Oracle NetSuite and Procurify connected, each new vendor and approved bill flows automatically from NetSuite into Procurify, and all GL account and department mappings are validated before the bill is written. The procurement team now sees accurate spend against the actual GL accounts NetSuite uses, and month-end close begins with bills and vendors already reconciled.

What you can do

• •Sync vendor master records from Oracle NetSuite into Procurify, keeping vendor names and payment terms aligned.
• •Post vendor bills from Oracle NetSuite to Procurify with correct GL account and department coding.
• •Map NetSuite GL accounts and cost centers to Procurify account codes so bills land on valid dimensions.
• •Receive real-time vendor and bill events from NetSuite via Event Subscriptions, or poll SuiteQL on a schedule.
• •Manage OAuth 2.0 token expiry on both sides, retry on rate limits, and maintain a full audit trail for every record.

Questions

Which direction does data move between Oracle NetSuite and Procurify?

The main flow is from Oracle NetSuite into Procurify. Vendor records, purchase orders, and vendor bills move from NetSuite into Procurify so the procurement team sees accurate vendor and bill data that matches the GL. Requisitions in Procurify remain local; NetSuite is the source of truth for approved orders and posted bills.

Does the integration use events or polling?

It can use both. If Oracle NetSuite Event Subscriptions are enabled on your tenant, ml-connector listens for vendor and bill create-edit-delete events and syncs in near real-time. If events are unavailable, it falls back to polling NetSuite via SuiteQL on a configurable schedule. Both methods maintain the same audit trail and can be combined for different record types.

How does the integration handle GL account and department coding?

ml-connector maps each NetSuite GL account and department to Procurify account codes before writing a bill. If a bill references a GL account that does not exist in Procurify, the mapping is flagged for manual review, and the bill is not written until the account is set up in Procurify. This prevents bills from landing on incorrect cost centers.