Oracle NetSuite and Airbase integration

What moves between them

The main flow runs from Airbase into Oracle NetSuite. ml-connector reads approved Airbase bills, paid expense reimbursements, and card transactions and posts them into NetSuite as vendor bills and vendor payments, each mapped to the matching NetSuite GL account, department, class, location, and subsidiary. Reference data flows the other direction: the NetSuite vendor master and chart of accounts are pushed into Airbase so spend is always coded against vendors and accounts that exist in the ledger. Card transactions are read-only in Airbase, and GL accounts are read-only there as well, so ml-connector treats NetSuite as the system of record for the chart of accounts and never lets Airbase overwrite it. Cadence follows your close calendar, with a poll between runs to pick up newly approved items.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Oracle NetSuite it signs a JWT with the customer's private key, exchanges it for a 60-minute bearer token, and refreshes when a call returns 401, and it accepts the full account-specific URL since NetSuite has no shared host. For Airbase it sends the portal bearer token on the tenant base URL and tracks the token's age because it does not auto-rotate. Vendors and GL accounts are aligned first, so every Airbase bill line maps to a real NetSuite account and dimension before any document is created. Because an Airbase bill is not payable until it clears its approval chain, ml-connector reads status fields and only books items that show as approved. Each Airbase record is posted to NetSuite with a stable externalId, so the upsert pattern means re-running a sync never books the same bill twice. NetSuite returns HTTP 429 when its concurrency or frequency caps are hit, and Airbase returns 429 with a Retry-After header, so ml-connector backs off with jitter and retries. Multi-subsidiary NetSuite accounts require a subsidiary on every transaction, so it is mapped per Airbase entity to avoid a 400. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized software company with about 250 employees runs Oracle NetSuite for accounting across two subsidiaries and uses Airbase for corporate cards, vendor bills, and employee reimbursements. Before the integration, the accounting team exported card and bill activity from Airbase at month-end and keyed the totals into NetSuite as vendor bills and journal entries, guessing at GL codes and chasing the ones that did not match a real account. With Oracle NetSuite and Airbase connected, each approved bill, reimbursement, and card transaction posts into NetSuite already coded to the right account, department, and subsidiary, and the vendor list and chart of accounts pushed into Airbase mean coders pick from valid values up front. Close starts with spend already booked and reconciled instead of a week of manual entry.

What you can do

• •Post approved Airbase bills and expense reimbursements into Oracle NetSuite as vendor bills coded to the correct GL accounts and dimensions.
• •Record Airbase card transactions and payments in NetSuite against the right accounts, departments, and subsidiaries.
• •Push the NetSuite vendor master and chart of accounts into Airbase so spend is coded against values that exist in the ledger.
• •Authenticate NetSuite with its certificate-based JWT client credentials flow and Airbase with its portal bearer token.
• •Deduplicate with externalId upserts and replay any failed post, with a full audit trail on every record.

Questions

Which direction does data move between Oracle NetSuite and Airbase?

The main flow is Airbase into NetSuite. Approved bills, paid reimbursements, and card transactions move from Airbase into NetSuite as vendor bills and payments. Reference data moves the other way: the NetSuite vendor master and chart of accounts are pushed into Airbase. GL accounts are read-only in Airbase, so NetSuite stays the system of record for the chart of accounts.

How does the integration avoid booking the same Airbase transaction twice in NetSuite?

Each Airbase record is posted to NetSuite with a stable externalId. NetSuite upserts on that externalId, so re-running a sync or processing a retry updates the existing record instead of creating a duplicate. Combined with the audit trail, this lets a failed post be replayed safely.

Does the integration wait for Airbase approvals before posting to NetSuite?

Yes. Bills, POs, and reimbursements in Airbase run through configurable approval chains, and a created record is not payable until it clears them. ml-connector reads the status fields and only books items into NetSuite that show as approved, so unapproved or rejected spend never reaches the ledger.