Oracle NetSuite and Cleo integration

What moves between them

Vendor invoices and purchase orders flow in both directions. Outbound: purchase orders in NetSuite are polled via SuiteQL, mapped to EDI 850 format, and written to Cleo folders for transmission to suppliers. Inbound: incoming EDI 810 invoices and 855 purchase order acknowledgments arrive in Cleo, are mapped back to NetSuite schema, and written as vendor bills and purchase order receipts. Reference data such as vendors, items, and GL accounts are aligned in both directions. The flow runs on a schedule you define, typically daily or weekly depending on your trading partner cadence.

How ml-connector handles it

ml-connector stores NetSuite OAuth credentials encrypted and refreshes the Bearer token every 59 minutes to stay ahead of the 60-minute expiry. On each poll cycle it queries NetSuite via SuiteQL for new or updated purchase orders and vendor invoices, retrieves the full record details including item detail and expense account allocations via REST, and maps them to canonical EDI transaction formats. For Cleo, ml-connector authenticates via password grant, reads folders for incoming EDI files, parses them to extract vendor, item, quantity, and amount data, maps them back to NetSuite GL accounts and inventory items, and writes vendor bills via NetSuite's REST create endpoint. Because NetSuite Event Subscriptions lack native HMAC signatures, ml-connector validates webhook endpoints via IP allowlist if used, and relies on polling via SuiteQL for reliability. Cleo outbound delivery requires CIC Studio configuration per trading partner, so ml-connector coordinates folder drops with that system. All records carry a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized discrete manufacturer runs Oracle NetSuite for procurement and GL accounting, and partners with 15 to 20 suppliers who exchange orders and invoices via EDI. Before the integration, the procurement team generated purchase orders in NetSuite, exported them as CSV files, manually converted them to EDI 850 format, and uploaded them to a shared Cleo folder. Incoming supplier invoices arrived as EDI 810 files in Cleo, were manually parsed, and re-entered into NetSuite as vendor bills. With Oracle NetSuite and Cleo connected, each new purchase order in NetSuite is automatically formatted and delivered to Cleo, flowing to suppliers within minutes. Incoming invoices from suppliers arrive in Cleo as EDI 810, are automatically mapped to matching purchase orders, and land in NetSuite as three-way-matched vendor bills ready for payment. The manual file conversion step is gone, and suppliers see PO changes within hours instead of days.

What you can do

• •Query Oracle NetSuite purchase orders via SuiteQL and map them to EDI 850 format for Cleo delivery to suppliers.
• •Receive incoming EDI 810 invoices from Cleo, validate against matching NetSuite purchase orders, and create vendor bills in the GL.
• •Align vendor master data, item codes, and GL account mappings between NetSuite and Cleo so transactions land on valid accounts.
• •Refresh Oracle NetSuite OAuth tokens every 59 minutes and handle Cleo password-grant session management transparently.
• •Poll both systems on a schedule you control, with transaction-level audit trails and replay capability for any failed downstream call.

Questions

Which direction does data move between Oracle NetSuite and Cleo?

Both directions. Purchase orders flow outbound from NetSuite to Cleo for transmission to suppliers in EDI format. Incoming invoices flow inbound from Cleo into NetSuite as vendor bills. Vendor master data and GL accounts are aligned in both directions to ensure all transactions map to valid accounts.

How does the integration handle Oracle NetSuite's 60-minute OAuth token expiry?

ml-connector caches the OAuth Bearer token and automatically refreshes it every 59 minutes before expiry, staying ahead of the 60-minute window. This prevents auth failures mid-transaction and eliminates the need to manually restart the connector or manage token lifecycle.

Why does the integration use polling instead of relying on Oracle NetSuite Event Subscriptions?

NetSuite Event Subscriptions lack native HMAC signatures, requiring IP allowlist validation or shared secrets in URLs for security, which adds operational complexity. ml-connector uses polling via SuiteQL for all purchase orders and invoices, ensuring reliable delivery and a full audit trail, and can also consume NetSuite Event Subscriptions where you have already configured them.