Oracle NetSuite and Jira integration

What moves between them

Vendor bills and purchase order changes from Oracle NetSuite flow one way into Jira as new or updated issues. When a purchase order is created in NetSuite, ml-connector creates a Jira issue with the PO number, supplier name, and line items as the issue description. When the vendor bill is posted or the PO status changes, the corresponding Jira issue is updated with the new amount, due date, or status label. No data moves from Jira back to NetSuite, since Jira has no financial records to send.

How ml-connector handles it

ml-connector listens to NetSuite Event Subscriptions for purchase order and vendor bill changes, mapping each event to Jira's Issue API. Because NetSuite Event Subscriptions do not support HMAC signatures, ml-connector uses IP allowlisting and a shared secret embedded in the webhook URL to prevent spoofing. On the Jira side, ml-connector stores the OAuth 2.0 credentials and refreshes the webhook registration every 25 days to prevent expiry. Each NetSuite vendor maps to a Jira project or issue label so teams can filter by supplier, and custom fields on the Jira issue capture the PO number, amount, and due date. Because Jira has no account or cost center fields, line items cannot be mapped to GL dimensions; the integration captures the total PO and bill amounts only. NetSuite OAuth tokens expire after 60 minutes, so ml-connector refreshes the token before each API call.

A real-world example

A mid-sized software company uses Oracle NetSuite for finance and procurement and Jira for project management. Their procurement team reviews purchase orders and vendor bills in NetSuite, but the development teams track vendor deliverables in Jira alongside their own work. Before the integration, the procurement team had to manually notify developers when a vendor bill was approved or a PO status changed, and there was no central record of which vendor deliverable corresponded to which Jira task. With Oracle NetSuite and Jira connected, each purchase order automatically creates a Jira issue that tracks the vendor deliverable and ties it to the project timeline. Developers can see the vendor status in their issue workflow, and the procurement team avoids separate notifications.

What you can do

• •Create Jira issues from NetSuite purchase orders with supplier name, PO number, and line items.
• •Update Jira issue status and custom fields when NetSuite vendor bills are posted or PO status changes.
• •Map NetSuite vendors to Jira project labels so teams can organize issues by supplier.
• •Prevent webhook spoofing using IP allowlisting and shared secrets since NetSuite Event Subscriptions do not support HMAC signatures.
• •Maintain OAuth 2.0 token refresh and Jira webhook registration renewal to ensure the connection stays active.

Questions

Why does the integration only move data from NetSuite to Jira, not the other way?

Jira is a project and issue tracking system with no native vendor, invoice, purchase order, or GL account entities. It cannot store or update financial records, so there is no financial data to send back to NetSuite. The integration is designed to keep teams aware of vendor activity alongside their project work, not to manage accounting in Jira.

How does the integration handle NetSuite's lack of HMAC signatures on Event Subscriptions?

NetSuite Event Subscriptions do not support HMAC signature verification like many webhook systems. ml-connector uses IP allowlisting on the NetSuite side and embeds a shared secret in the webhook URL to prevent spoofing. This requires that the ml-connector endpoint IP addresses are whitelisted in NetSuite.

What happens if a Jira webhook expires or the OAuth token is revoked?

Jira webhooks expire after 30 days and must be refreshed via API before they stop receiving events. ml-connector refreshes the webhook registration every 25 days to prevent expiry. NetSuite OAuth tokens are valid for 60 minutes, so ml-connector refreshes the token before each call to keep the connection active.