Oracle NetSuite and Chargebee integration

What moves between them

The main flow runs from Chargebee into Oracle NetSuite. As each billing cycle posts, ml-connector reads Chargebee invoices, successful payment transactions, and credit notes and writes the matching accounts receivable entries into NetSuite, mapped to the correct GL accounts and accounting dimensions. Customer records flow the same direction so NetSuite holds a billing entity for every Chargebee customer. Catalog items and plans are aligned so each invoice line maps to a valid NetSuite revenue account. Chargebee is treated as the billing system of record, so ml-connector does not write subscription or pricing changes back into Chargebee.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Chargebee it sends the site API key as HTTP Basic auth with the mandatory empty password and derives the base URL from the account region, since an EU or AU key fails against the US host. For NetSuite it signs a JWT with the stored private key, exchanges it for a bearer token, and re-runs the flow when a call returns 401 because the token expires after 60 minutes with no refresh. Chargebee webhooks trigger work as activity settles, and because they are unsigned, the connector re-fetches each event by id before posting; a scheduled SuiteQL poll backfills anything a webhook missed. Chargebee customers map to NetSuite customers and invoice lines map to GL accounts and dimensions first, so every posted transaction references accounts that already exist. NetSuite writes upsert by externalId to dedupe, and Chargebee rate limits return HTTP 429 with a Retry-After header, so ml-connector backs off and retries.

A real-world example

A mid-sized B2B software company with around 200 employees bills several thousand subscriptions through Chargebee and keeps its books in Oracle NetSuite. Before the integration, the finance team exported invoice and payment registers from Chargebee each month and re-entered the totals into NetSuite by hand, then spent the start of every close reconciling deferred and recognized revenue against the subscription data. With the two systems connected, each Chargebee invoice, payment, and credit note posts into NetSuite automatically, allocated to the right revenue accounts and dimensions, and customer records stay aligned. Month-end close starts with accounts receivable already matching billing, and the manual re-keying step is gone.

What you can do

• •Post Chargebee invoices, payments, and credit notes into Oracle NetSuite as accounts receivable transactions against the correct GL accounts.
• •Keep NetSuite customer records aligned with Chargebee customers as subscriptions are created and changed.
• •Map Chargebee items and plans to NetSuite revenue accounts and accounting dimensions so each invoice line posts where it belongs.
• •Bridge Chargebee Basic-auth keys and the NetSuite signed-JWT token flow, refreshing the NetSuite token when it expires.
• •Run on a schedule with SuiteQL polling, webhook re-fetch, externalId upserts, retries, and a full audit trail on every record.

Questions

Which direction does data move between Oracle NetSuite and Chargebee?

The main flow is Chargebee into NetSuite. Invoices, payment transactions, credit notes, and customer records move from Chargebee into NetSuite, where they post as accounts receivable entries against the matching GL accounts. Chargebee is the billing system of record, so ml-connector does not write subscription or pricing changes back into Chargebee.

How does ml-connector handle the two different authentication methods?

Chargebee uses HTTP Basic auth, where the site API key is the username and the password is empty, and ml-connector preserves that mandatory empty password and selects the correct regional host. Oracle NetSuite uses OAuth 2.0 client credentials, where the connector signs a JWT with a stored private key to obtain a 60-minute bearer token. Because NetSuite issues no refresh token, ml-connector re-runs the token flow whenever a call returns 401.

Are Chargebee webhooks trusted directly, or is there a verification step?

Chargebee webhooks carry no HMAC signature, so ml-connector does not trust the pushed payload on its own. It re-fetches each event by its id through the Chargebee API before posting anything into NetSuite, which guarantees an accurate record. A scheduled SuiteQL poll also backfills any event a webhook may have missed, and the event id is used to deduplicate retries.