Orders, stock
and books that agree
We customize, connect and look after Oracle® NetSuite accounts, from scripts and workflows to integrations and several companies in one account, and try every change in a sandbox first, so every team works from the same numbers.
Thanks, we’ll be in touch soon.
{{ heroStatus }}
You’re in good company
A few of the companies we’ve worked with.
When every partner left something behind
Many companies have run NetSuite for years, and each partner who worked on the account, your company’s NetSuite, added to it: scripts, code that runs inside NetSuite; workflows, steps NetSuite follows on its own when a record such as a sales order changes; and fields on the forms people fill in.
Some of it still matters and some no longer does. But a script or workflow that’s still switched on keeps running, and in many accounts no one is sure which is which.
Meanwhile, many integrations, the connections that pass records between NetSuite and your store, bank or warehouse, were built the older way, on SOAP web services or token-based sign-in. So each release, one of NetSuite’s two updates a year, and each new request carry more risk than they should.
What we build
Scripts, workflows, records and integrations for NetSuite accounts, each with a reason and an owner, and each tried in a sandbox, a copy of your account kept apart for testing, before it reaches production.
Scripts where configuration stops
SuiteScript, NetSuite’s JavaScript-based scripting, for what settings alone can’t do: user event, client, scheduled and map/reduce scripts, and Suitelets, written in SuiteScript 2.1, the version Oracle recommends for new scripts. Each stays within the usage limits NetSuite sets for its kind of script.
Workflows for approvals and routing
SuiteFlow workflows, set up with NetSuite’s point-and-click tools, where a rule doesn’t need code: a purchase sent for approval, a record moved on to its next step, a field set or a message sent as it goes.
Records, fields and forms shaped to how you work
Custom records for what NetSuite doesn’t hold out of the box, custom fields and segments for the details you sort and report by, and forms that show each role, the permissions a job is given, what its work needs.
Several companies in one account
Each company set up as a subsidiary under OneWorld, with its own currency and tax, and sales between them recorded in both companies’ books, so the group’s results can be combined.
Integrations with your product and other systems
REST web services and RESTlets, each integration signing in with OAuth 2.0 under a role of its own, with only the permissions it needs, and planned within the limit NetSuite sets on how many requests an account handles at once.
Older integrations moved to REST and OAuth 2.0
Integrations built on SOAP web services or token-based sign-in, moved in planned steps to REST web services and OAuth 2.0, as Oracle recommends, starting with the ones the business relies on.
Changes moved as projects
Customizations built in a sandbox or development account, kept in source control as SuiteCloud Development Framework projects and deployed from there, so what reaches production is what was tried. Before each release, they’re tried again in the Release Preview account Oracle offers.
Moves onto NetSuite
Data from your current systems brought in with NetSuite’s own import tools, each record matched to its place and checked in a sandbox before anything reaches production.
AI where it helps
AI assistants that reach NetSuite through the NetSuite AI Connector Service, Oracle’s way in for assistants that use the Model Context Protocol. Each person connects under a role with only the permissions for what they do through the assistant, and tools only for the jobs agreed, such as reading records, reports and saved searches.
- Connecting any of your systems:Systems & API Integration
- Automation across your tools:Workflow Automation
- Care once it’s live:Support & Maintenance
- Developers in your own team:Hire developers for Oracle NetSuite
Each company keeps its own books
With OneWorld, one NetSuite account can hold several companies, which NetSuite calls subsidiaries. Each is treated as its own legal entity, with its own tax rules and its own base currency, the currency it keeps its books in.
A sale from one of them to another is an intercompany sale, recorded in both companies’ books: a sale in one, a purchase in the other.
When the group’s results are combined, each company’s figures are converted to the parent company’s currency, and the sales between them are taken out, so the group counts only what it sold outside itself. NetSuite’s Automated Intercompany Management makes those entries at period close; without it, they’re made by hand.
So the companies, their currencies and the rules between them are set up first, and every script and integration respects them.
From one company to another
Harbor Group sells to Harbor Canada: an intercompany sale, in both companies’ books, taken out when the group’s results are combined.
Harbor Group sells to Harbor UK: an intercompany sale, in both companies’ books, taken out when the group’s results are combined.
Harbor Group sells to a customer: a sale in Harbor Group’s books, in US dollars, the currency the group’s results are combined in.
Harbor Canada sells to Harbor Group: an intercompany sale, in both companies’ books, taken out when the group’s results are combined.
Harbor Canada sells to Harbor UK: an intercompany sale, in both companies’ books, taken out when the group’s results are combined.
Harbor Canada sells to a customer: a sale in Harbor Canada’s books, in Canadian dollars, counted in the group’s results in US dollars.
Harbor UK sells to Harbor Group: an intercompany sale, in both companies’ books, taken out when the group’s results are combined.
Harbor UK sells to Harbor Canada: an intercompany sale, in both companies’ books, taken out when the group’s results are combined.
Harbor UK sells to a customer: a sale in Harbor UK’s books, in pounds, counted in the group’s results in US dollars.
Each company keeps its own books, and the group counts only what it sells outside itself.
{{ coStatus }}
A newer way in for integrations
Oracle recommends REST web services with OAuth 2.0 for every integration built from the 2026.1 release on. REST web services are NetSuite’s current way for other systems to read and write its records, and OAuth 2.0 is how they sign in.
From the 2027.1 release, new integrations can’t use token-based authentication, and since SOAP web services require it, no new SOAP integrations can be built. Integrations that already exist carry on, and one that uses REST with token-based sign-in can keep it, though Oracle prefers OAuth 2.0.
For SOAP itself, Oracle’s FAQ sets out the steps after that: from the 2027.2 release only the last SOAP endpoint, 2025.2, the version integrations connect to, is supported, and with the 2028.2 release SOAP web services are removed, so integrations still on them stop working then.
So each integration is listed with how it connects and how it signs in, then moved to REST web services and OAuth 2.0 in planned steps, starting with the ones the business relies on. Where REST web services don’t cover a need, Oracle points to RESTlets, scripts of your own that answer requests.
Start with a review of your account
The review covers your scripts and workflows: what each does, which record it runs on, who added it and whether it’s still in use; your custom records, fields and forms, which are used and which repeat; your companies, currencies and intercompany setup, if you run several; each integration, what it reads and writes, whether it uses SOAP or REST, how it signs in and the role it runs as; your roles, who can do what, and which roles integrations and AI clients use; how changes reach production, from sandboxes and SuiteCloud projects to how each release is tried; and which features need which modules or licenses, as Oracle sets them out.
The first step is one integration the business relies on, moved to REST web services and OAuth 2.0 and tried in a sandbox with real records, so the way is proven before the next one follows.
You get a written review and a proposal for the first step.
Questions worth asking
Oracle is changing how integrations sign in. What does it mean for us?
From the 2026.1 release, Oracle recommends REST web services with OAuth 2.0 for every new integration, and from the 2027.1 release new integrations can’t use token-based authentication. Integrations you already have carry on. Oracle prefers OAuth 2.0 for them too, so we list each integration and how it signs in, and plan any moves, starting with the ones the business relies on.
Will our SOAP integrations stop working?
Oracle’s SOAP Removal Plans FAQ sets out each step. With every release, the oldest SOAP endpoint Oracle no longer supports is switched off, so an integration on an old endpoint needs moving first. From the 2027.1 release no new SOAP integrations can be built, from the 2027.2 release only the last endpoint, 2025.2, is supported, and with the 2028.2 release SOAP web services are removed, when integrations still on them stop working. We check which endpoint each one uses and plan its move to REST web services from there.
How do you make sure a NetSuite release doesn’t break our scripts?
NetSuite has two major releases a year, and accounts are upgraded in phases over a few months. Before your upgrade, you can request a Release Preview account, a copy of your account on the new release, and we try your scripts, workflows and integrations there before the upgrade date.
We run several companies. Can one account keep their books?
With OneWorld, yes: one NetSuite account holds each company as a subsidiary, with its own currency and tax, and combines their results in the parent company’s currency. Moving an account to OneWorld is a one-time upgrade that can’t be reversed, so the companies and the rules between them are planned before it’s made.
Should this be a workflow or a script?
It depends on the rule. A SuiteFlow workflow suits steps a record moves through, such as an approval, set up with point-and-click tools. A SuiteScript script suits logic a workflow can’t express, or work on many records at once. Many accounts use both, and a workflow can call a script for the part that needs code.
Partners have added scripts over the years. Can you sort them out?
Yes. The review lists each script and workflow, what it does, which record it runs on and whether it’s still in use. Then each is kept, fixed or retired on purpose, and changed in a sandbox first, so nothing the business relies on is switched off by accident.
Can AI assistants use our NetSuite data?
Yes, through the NetSuite AI Connector Service, which works with assistants that use the Model Context Protocol. Each person connects under a NetSuite role, and Oracle suggests a separate role with only the permissions for what people do through the assistant. Oracle’s MCP Standard Tools SuiteApp gives tools for records, reports, saved searches and SuiteQL queries, and tools of your own can be built for the jobs you agree.
Can you connect NetSuite to our store, bank or other systems?
Yes, through REST web services or RESTlets, each integration signing in with OAuth 2.0 under a role of its own. We start with the records each side needs and who owns them, then build and try one connection with real records before the next.
Can you build the reports our finance team needs?
Yes: saved searches for the lists people use every day, SuiteAnalytics Workbooks for analysis, and SuiteQL queries where a report needs a query of its own, each built on the records and fields your teams already use.
Can you move us onto NetSuite from our current system?
Yes. Records are matched first: customers, items, open orders and balances, each mapped to its place in NetSuite. Then they’re brought in with NetSuite’s own import tools and checked in a sandbox before anything reaches production.
Do we need more NetSuite modules or licenses for this?
Sometimes. Some features need a particular module or license, or an upgrade such as OneWorld. We say which features the work needs, and what each one needs, before anything is bought.
Can you take over our existing account?
Yes. The review shows what each script, workflow and integration does, who owns it and how changes reach production. Then we keep what works, fix what needs fixing, and look after it from there.
How do you keep our data secure?
Each job gets a role with only the permissions it needs, each integration and AI client works under a role of its own, and integrations sign in with OAuth 2.0. People sign in with two-factor authentication on the roles that need it. Code we add is reviewed before release, so problems are found early.
What does it cost?
It depends on the work: the scripts, workflows, integrations and companies involved, and whether they’re new, moved or rebuilt. Before any work starts, you get a written proposal with the scope, the price or rate, and how you pay.
Can we hire NetSuite developers for our own team?
Yes. Tell us about your account and the work ahead, and within 48 hours we’ll introduce NetSuite developers who fit it, each working in your time zone. You meet them and decide who joins.
Oracle and NetSuite are registered trademarks of Oracle and/or its affiliates, and OneWorld, SuiteAnalytics, SuiteApp, SuiteCloud, SuiteFlow, SuiteQL and SuiteScript are trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Webair is independent of Oracle, and isn’t sponsored by, endorsed by or affiliated with it.
Let’s build it better
Tell us which scripts, workflows and integrations your account relies on, and how they sign in today. A short call is enough to see where to start.
Thanks, we’ll be in touch soon.
{{ ctaStatus }}