Integrate Oracle NetSuite with Perk for expenses

The Perk integration for Oracle NetSuite connects Perk to a company's NetSuite ERP system so spend data moves between the two automatically. This article explains what the integration does, how data maps and flows between Perk and NetSuite, and how each type of record — from employees to company cards — behaves once it's connected. Read it to understand the concepts behind the integration.

Overview

The Perk integration for Oracle NetSuite automates spend management by connecting Perk with a company's NetSuite ERP system. It removes manual data entry, keeps financial tracking accurate, and makes expense processing smoother across the business. The integration supports zero-touch processing of travel-and-expense workflows, and it's built as a managed, scalable solution: it automatically syncs spend into NetSuite's native finance and payroll ledgers and can handle complex requirements and use cases.

The integration gives companies several concrete benefits:

  • No manual data entry for expenses.
  • Master data — employees, categories, tax codes, and other reference data — stays consistent across both systems automatically.
  • Approval workflows run in Perk and sync automatically, so approvals never get duplicated in NetSuite.
  • Real-time data exchange keeps both systems consistent and accurate.
  • Support for multiple NetSuite subsidiaries through multi-entity (OneWorld) support.
  • Support for multiple currencies with automatic exchange rates.
  • Support for both Legacy Tax and SuiteTax configurations.

What data moves between Perk and NetSuite

Data moves between Perk and NetSuite in both directions, and the timing depends on the record type — some data syncs in real time, some on a schedule, and some only when someone triggers it manually.

NetSuite sends this master data into Perk: employees, expense categories, cost objects (built from NetSuite classifications such as departments, classes, locations, custom segments, projects, or customers), custom fields and tags (extra classification dimensions, built the same way as cost objects), tax codes, and company cards created in NetSuite.

Perk sends this transactional data into NetSuite: approved expenses (company-paid, privately paid, and travel expenses), and company cards created in Perk.

The two systems exchange this data over secure REST API endpoints, using OAuth 1.0 token-based authentication to keep the connection secure.

How Perk and NetSuite data map to each other

Each NetSuite object has a matching object in Perk, and understanding this mapping makes it easier to follow how a record moves between the two systems.

NetSuite object Perk object What it's used for
Employee User Managing users
Classification (department, class, location, custom segment, project, or customer) Cost object Managing cost objects and cost allocation
Classification (department, class, location, custom segment, project, or customer) Custom field Managing secondary classification and dimensions
Company card Company card Managing company cards
Tax code Tax rate Managing tax rates
Expense category Expense category Managing expense categories

Managing employees and other master data

Master data forms the foundation the integration runs on: employees, categories, cost objects, tax rates, company cards, and custom fields each sync between Perk and NetSuite in their own way.

Employees

A user needs to sync before their expenses can export from Perk to NetSuite. The integration syncs each employee to the same Perk legal entity as the subsidiary they belong to in NetSuite, and it stores NetSuite's internal ID for the employee in Perk's "Account (ERP)" field on the user. Each user's email must be unique in both systems, since email is the matching key — email addresses that use plus-addressing (for example, name+tag@example.com) aren't supported. Only employees who belong to subsidiaries connected to Perk — that is, subsidiaries with a legal entity ID already set up — are eligible to sync.

Which sync strategy a company uses depends on how it provisions users in Perk:

  • Push employee: for companies where NetSuite creates and manages employees, and those employees need provisioning into Perk. NetSuite pushes the employee data, and Perk returns the new Perk user ID back to NetSuite.
  • Pull Perk ID by email: for companies where users already exist in Perk — for example, provisioned through SCIM or created manually — and need linking to their NetSuite employee record. Matching happens by email address.
  • Pull Perk ID by employee ID: the same use case as pulling by email, but matching happens by NetSuite employee ID instead.

Sync can run per record in real time, or in bulk through a CSV import in NetSuite.

Categories

In Perk, categories are the accounts used to book expenses, and each one links to a general ledger account in NetSuite. Categories sync individually and in real time. A category enabled for only one NetSuite subsidiary syncs only to that subsidiary's Perk legal entity.

Cost objects

Cost objects in Perk are hierarchical structures that assign costs to dimensions like departments, projects, or customers. The integration lets a company choose which NetSuite classification serves as its cost object — departments, classes, locations, custom segments, projects, or customers — and it automatically creates a dedicated cost object table linked to that classification.

The integration creates and manages cost objects per legal entity, and it automatically limits them to the subsidiaries where the chosen classification is enabled. Parent-child relationships, especially department hierarchies, carry over from NetSuite into Perk's cost object structure. A company can set approvers and approval limits on each cost object in NetSuite, but the approver must already sync to Perk before anyone can select them.

Cost objects sync in two steps: first NetSuite creates them from the chosen classification, then they sync to Perk.

Tax rates

The integration supports both Legacy Tax and SuiteTax. Only tax codes linked to an active tax registration (nexus) for a connected subsidiary are available to sync — tax groups aren't supported, only individual tax codes. Tax codes sync individually and in real time.

Caution: Before syncing a tax code, check that it's enabled only for the subsidiaries where it actually applies. A tax code enabled for the wrong subsidiary — for example, a Swiss tax code left enabled for an Austrian subsidiary — syncs to that subsidiary's Perk legal entity too, and Perk can then apply the wrong country's tax code to an expense, causing export errors.

Company cards

A company card needs mapping from Perk to NetSuite before its transactions can export, and each card needs a cardholder who is an active, Perk-synced employee. Syncing can run manually or on a daily schedule, and the integration automatically detects Perk cards that haven't yet synced to NetSuite. A card transaction can't export until the card's "Creditor number (ERP)" field in Perk holds the matching NetSuite internal ID.

Custom fields

Custom fields in Perk — built from NetSuite classifications the same way cost objects are — add a secondary layer of classification on expenses, giving more granular reporting on top of the primary cost object. A company can use several classifications as custom fields at once. For exports to work, the custom field's code in Perk must match the internal ID of the matching record in NetSuite. Like cost objects, custom fields are created and maintained per legal entity, and the integration automatically limits them to the subsidiaries where the source classification is enabled.

Supported business processes

The integration covers the core spend processes most finance teams need to run day to day.

Business process What it covers
Expense reimbursements Booking and reimbursing employee-paid expenses
GL coding and account allocation Linking expense categories to general ledger accounts
Cost allocation and dimensions Assigning spend to cost objects and custom fields
Credit card transaction management Matching and posting company card transactions
Subscription cards Managing recurring card-based spend
Amortization Spreading costs across periods
VAT handling Applying tax codes and rates through Legacy Tax or SuiteTax

How expenses are posted to NetSuite

Once an item is approved in Perk, it posts to NetSuite in a form that matches how Perk structures the underlying record. One Perk expense report becomes one NetSuite expense report. Perk uses trips as containers for multiple expenses, so when a trip exports, each individual expense inside it becomes its own line — and if a single expense splits across categories or cost objects, that creates multiple lines too.

A travel expense — a booking imported into Perk from a travel integration, already paid, and tracked separately from expense reports — becomes one journal entry per travel expense, again split into multiple lines if it spans several categories or cost objects.

Each company card transaction also becomes a journal entry: the debit line uses the expense account on the transaction, and the credit line uses the card account set up when the card synced to NetSuite. A transaction split across categories or cost objects creates multiple journal entry lines, and credit notes export as negative amounts on those lines.

Expense type NetSuite record How it's structured
Out-of-pocket expenses Expense report One expense-report line per expense, using the category's account; the employee is the creditor
Per diems Expense report One expense-report line per per diem entry, with the amount calculated from the applicable daily rate rather than a receipt
Mileage expenses Expense report One expense-report line per mileage entry, with the amount calculated from the mileage rate
Card expenses Journal entry One debit line per expense, using the category's account, balanced by a credit line to the card's NetSuite account
Travel bookings Journal entry One debit line per expense, using the category's account, balanced by a credit line to the configured travel provider's transfer account
Note: When Perk has already reimbursed an employee directly for an expense, NetSuite creates a Bill Payment alongside the Expense Report to clear it, instead of leaving it payable to the employee. See Set up reimbursement exports to Oracle NetSuite for setup and details.

Architecture and security

The integration connects Perk and NetSuite through secure REST API endpoints, using OAuth 1.0 token-based authentication, so communication stays encrypted using consumer keys and tokens that NetSuite issues. Perk stores these credentials in its integration settings, and a company can revoke or renew them from NetSuite at any time.

Data flows both ways: master data flows from NetSuite to Perk, and transactional data flows from Perk to NetSuite, with syncing that's real-time, scheduled, or manually triggered depending on the record type.

Setting up the integration installs a NetSuite SuiteBundle that includes a custom "Yokoy Integration" role, set up with only the minimum permissions the integration needs — a least-privilege approach. Account admins keep control throughout the process: they can manage NetSuite settings and master data directly from the NetSuite UI, and NetSuite admins choose when to update the integration bundle as new versions become available. Version logs are visible directly in the New Yokoy Configuration App inside NetSuite.

Limitations and customizations

The integration supports standard NetSuite functionality, built the same way for every customer. Custom fields, workflows, or scripts in a company's NetSuite account aren't guaranteed to work with the integration and may need more configuration to coexist with it. Because the integration is a standardized solution, it doesn't include customer-specific deviations from its core functionality — this holds true in both Sandbox and Production, and the setup process is identical in both environments.

Note: If a company's NetSuite account uses custom fields, workflows, or scripts, it's worth reviewing them against the integration before rolling it out. Deviations from standard NetSuite functionality aren't guaranteed to be supported and may need investigation if they cause issues.

Was this article helpful?