ml-connector
Oracle NetSuiteZuora

Oracle NetSuite and Zuora integration

Oracle NetSuite runs your ERP and financial records. Zuora manages subscriptions, recurring billing, and revenue recognition. Connecting them keeps your billing facts aligned with your source of truth and eliminates manual invoice re-keying. Subscription amendments in Zuora can flow back to NetSuite to update revenue schedules, and NetSuite customers automatically create corresponding Zuora accounts so billing records exist for everyone in your ERP.

How Oracle NetSuite works

Oracle NetSuite exposes customers, invoices, sales orders, vendors, and general ledger accounts through SuiteTalk REST Web Services. Authentication uses OAuth 2.0 with an M2M certificate or Token-Based Authentication. NetSuite publishes event subscriptions (push webhooks) for invoices, sales orders, and customer records, with no native HMAC signature; instead use IP allowlist and a shared secret. For bulk or historical reads, SuiteQL provides query access. NetSuite's webhook retry mechanism uses exponential backoff, and OAuth tokens valid for 60 minutes are per-request.

How Zuora works

Zuora is a subscription billing and revenue recognition platform with order-to-cash capabilities. It exposes accounts, subscriptions, invoices, payments, orders, and refunds through REST APIs secured by OAuth 2.0 Client Credentials. Tokens expire in 1 hour and must be reused across requests. Zuora sends Callout Notifications (webhooks) for billing events (invoices posted, payments processed), subscription lifecycle changes (renewed, cancelled), and account updates, with configurable HMAC-SHA256 signatures. Webhook payloads are minimal; the receiver must call back to fetch full records. Multi-region endpoints require capturing the tenant base URL at setup. Rate limits are 50,000 requests per minute in production, and batch operations are limited to 50 records per call.

What moves between them

The primary flow is NetSuite into Zuora. When a customer is created or updated in NetSuite, ml-connector pushes the account details to Zuora so a corresponding account and subscription framework exist. Invoices created in NetSuite flow into Zuora as invoice records mapped to the correct Zuora account. Subscription lifecycle events (new subscriptions, cancellations, amendments) are triggered in Zuora and can flow back to NetSuite as custom records to update revenue schedules and GL accounts. Payment events in Zuora are read but not written back, since NetSuite owns accounts receivable and payment posting.

How ml-connector handles it

ml-connector stores both OAuth 2.0 credential sets and handles the 60-minute NetSuite token refresh separately from Zuora's 1-hour token expiry, caching each to avoid redundant calls. NetSuite event subscriptions arrive as push webhooks; ml-connector validates them with the shared secret (not HMAC signature, which NetSuite does not support natively) and queues them for processing. When processing a NetSuite invoice, ml-connector looks up the Zuora account by matching the NetSuite customer ID, then calls Zuora's invoice creation endpoint with the line items, amounts, and GL account codes mapped to Zuora product identifiers. Subscription changes in Zuora arrive via Callout Notifications with HMAC-SHA256 validation, and ml-connector creates NetSuite custom records with the subscription details so accounting can adjust revenue GL entries. Zuora's multi-region base URL is captured at setup and used for all requests. Rate limits from both sides (NetSuite SuiteScript governance units, Zuora 50k RPM) are respected with exponential backoff and jitter. Every record carries audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-market SaaS company runs Oracle NetSuite for finance and ERP and uses Zuora for recurring billing and revenue recognition. Before the integration, the billing team exported invoices from NetSuite, manually created matching invoices in Zuora, and handled subscription amendments by copying details between systems. Reconciliation took days because customer records, invoice counts, and amounts could drift between the two systems. After connecting NetSuite and Zuora, customers created in NetSuite automatically appear in Zuora, invoices sync immediately, and subscription changes in Zuora create audit records in NetSuite so the revenue and accounts receivable teams stay aligned. Month-end close is faster because billing data is already reconciled, and the manual re-entry step is eliminated.

What you can do

  • Sync Oracle NetSuite customers to Zuora accounts so every customer in ERP has a billing record ready.
  • Push NetSuite invoices to Zuora mapped to the correct Zuora accounts and subscription contracts.
  • Validate NetSuite event subscriptions with shared-secret verification since NetSuite does not support native HMAC signatures.
  • Receive Zuora subscription lifecycle events and create NetSuite custom records for revenue accounting and GL mapping.
  • Handle OAuth 2.0 token expiry and refresh independently for NetSuite (60 minutes) and Zuora (1 hour), with exponential backoff and audit trail on every record.

Questions

Which records move from NetSuite to Zuora, and in which direction?
Customers and invoices flow from NetSuite into Zuora. Subscription events (new subscriptions, cancellations, amendments) originate in Zuora and create custom records in NetSuite for revenue accounting. Payments are read from Zuora but not written back to NetSuite, since NetSuite owns the accounts receivable ledger.
How does ml-connector handle NetSuite's lack of native HMAC signatures on event subscriptions?
ml-connector validates NetSuite event subscriptions using a shared secret appended to the webhook URL, the same mechanism NetSuite recommends in its best practices. IP allowlisting and the secret-in-URL pattern protect against spoofing while keeping the integration straightforward without requiring custom SuiteScript code.
What happens when Zuora rate limits are hit, or token refresh fails?
ml-connector implements exponential backoff with jitter when either system returns a rate-limit (429) or token endpoint response. Every outbound call is tracked with a full audit trail, so if a downstream write fails, the job can be retried without duplicate posting. Token refresh failures are surfaced in the audit log so the operations team can investigate credential rotation or rate-limit exhaustion.

Related integrations

Connect Oracle NetSuite and Zuora

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started