Integration Services
We connect NetSuite to the systems around it, in an account that has already been customised for years.
NetSuite is usually the centre of the business by the time anyone asks for an integration, which means it is also heavily customised. Custom records, custom fields and custom forms mean the account in front of us is not the one in the documentation. We start by reading yours, then build the link between it and whatever sits around it.
Most of this work arrives as part of a wider build, so if the system on the other side does not exist yet, we write that too. That side of it is covered on our CRM and ERP development page.
They arrive somewhere else, a website, a marketplace or a portal, and a person types them in again.
What the website promises and what NetSuite holds are different numbers for most of the day.
Getting a straight answer out of the system means raising a ticket and waiting.
An earlier job ran fine until it hit a limit nobody knew about and stopped, without telling anyone.
| Record | Direction | How It Is Handled |
|---|---|---|
| Customers | Both ways | Matched on the internal id we store, with the right subsidiary attached so the record lands in the correct books. |
| Sales orders | Your system to NetSuite | Created with the item, price level and location the mapping specifies, not whatever the sending system happened to call them. |
| Items and pricing | NetSuite to your system | NetSuite stays the master. Your other systems follow it, so a price is changed in one place. |
| Inventory levels | NetSuite to your system | By location, because a single stock number is meaningless once there is more than one warehouse. |
| Invoices and credits | Both ways, by agreement | Depending on whether NetSuite raises them or receives them, which is settled during scoping. |
| Payments | Both ways | Applied against the right invoice rather than posted as unallocated cash. |
| Custom records | By agreement | Most accounts have them and most integrations need them. They are read from your account rather than assumed. |
This is the starting point rather than a fixed list. The final version is agreed with you and written into the scope before the build begins.
NetSuite gives a script a budget and charges each operation against it. Run out and the job stops where it stands, often halfway through a batch. Integrations that were never designed around this work on day one and fail once volume arrives. We budget the units the same way we budget time.
NetSuite uses token based authentication with signed requests and your account id built into the address. It is not the standard flow most libraries expect, and it is a common reason a proof of concept never reaches production.
REST, SuiteTalk and SuiteQL each cover different ground, and the one that is easiest to start with is often the one that cannot do what you need later. Choosing before the scope is understood usually means rewriting.
Custom fields, custom records, custom forms and workflows built up over years mean your NetSuite is unique. A mapping done against a clean demo account will not survive contact with yours, which is why we read the real one first.
In a multi-subsidiary account, a record posted without the right subsidiary goes somewhere, just not where it belongs. Nothing errors. It is found weeks later during a review, and by then there is a lot of it.
Custom fields, custom records, subsidiaries, locations and the workflows already running. The mapping is written against what you actually have.
REST, SuiteTalk or SuiteQL, picked for what the scope needs rather than what is quickest to demonstrate.
Development runs in a NetSuite sandbox, and the governance cost of each job is measured there before it ever touches production.
Failures are retried, limits are monitored, and a job that stops raises an alert rather than waiting to be noticed at month end.
Yes, and it is worth having one anyway. Building against production in a system this central is not something we are willing to do.
That is the normal case. Custom records and fields are read from your account and mapped explicitly, rather than being worked around.
Usually governance. NetSuite budgets what a script may do and stops it at the limit, and an integration that was not designed around that will run for a while and then fail as data grows. It is fixable, and it is one of the first things we look at.
Yes, and it is the part we treat most carefully. Posting to the wrong subsidiary does not raise an error, so the mapping has to be right rather than hopeful.
Scope decides it, and NetSuite accounts vary more than most. We read your account, settle what will be built, then put your own schedule in writing with start and delivery dates.
You own the source code. Once payment is complete, everything produced for the project passes into your company’s ownership. That is written into the agreement before work starts, alongside the scope and the price.
Invoices, contacts and payments between Xero and the system you run on.
Invoices, customers, payments and items between QuickBooks and your own system.
Invoices, contacts and payments between Sage and the system you run on.
Zoho Books, CRM and Inventory joined to each other and to your own system.
Payments, subscriptions, refunds and payouts between Stripe and your own system.
Card payments, refunds and settlement between PayTabs and your own system.
Send us the system on the other side and what should move between them. We read your account first, then give you a written scope with the mapping, the timeline and the price.
Average Response Time: 15 Minutes