A SuiteScript 2.1 upgrade is no longer optional. Oracle's guide to transitioning to SuiteScript 2.1 says support for SuiteScript 1.0, SuiteScript 2.0, and scripts annotated @NApiVersion 2.0 or @NApiVersion 2.x, is expected to be removed in NetSuite 2028.2. Before that, from 2027.1, SuiteScript 1.0 support covers critical issues only.

The short answer to "what do I rewrite first?" is this: find every legacy script, delete the ones nobody uses, then rewrite your SuiteScript 1.0 scripts in order of business risk. Scheduled scripts that yield, RESTlets used by integrations, and scripts that touch postings or approvals go to the top. Most SuiteScript 2.0 scripts are a smaller job and can come later.

I write all new NetSuite customisation in SuiteScript 2.1, and I maintain and upgrade older 1.0 code for clients. This is the plan I follow.

The SuiteScript 2.1 timeline Oracle has published

Oracle's transition guide sets out four releases:

• 2026.2: SuiteScript 2.1 becomes the standard scripting model for new and existing scripts.
• 2027.1: SuiteScript 1.0 enters end-of-life support, covering critical issues only. For other problems, Oracle will ask you to convert the script to 2.1 first.
• 2028.1: SuiteScript 1.0 scripts can no longer be deployed in new accounts. They remain deployable in existing accounts. SuiteScript 2.0 and 2.x scripts run as 2.1 by default.
• 2028.2: all new and existing scripts must use SuiteScript 2.1.

Release plans can move, so check Oracle's page before you fix dates in a project plan. The practical point is that 2027.1 matters more than 2028.2. After 2027.1, a SuiteScript 1.0 script that breaks in a way Oracle doesn't class as critical may have to be converted before anyone will look at it. That is a poor time to start a rewrite.

The same releases bring the authentication changes I covered in NetSuite TBA to OAuth 2.0 and SOAP to REST. If you have RESTlets or integrations to rework anyway, plan both changes as one project.

Step 1: Build an inventory of legacy scripts

Oracle's guide suggests three ways to find scripts not on 2.1. The quickest is the script list:

1. Go to Customization > Scripting > Scripts.
2. Use the API Version filter to show 1.0, then 2.0, then 2.x.

For something you can share and sort, create a saved search on script records with the criterion API Version is not 2.1, and show Name, ID, Script Type, API Version, Owner and Description. A SuiteAnalytics workbook grouped by API Version or Script Type works too.

Then add the columns that drive the plan. For each script, note:

• What it does, in one line a finance user would understand.
• Whether it still runs. Check its deployments and execution logs. A script with no recent activity is a candidate for retirement, not conversion.
• Who owns it. Some scripts belong to a SuiteApp or a third-party bundle. Those are the vendor's job to upgrade, so ask each vendor for their plan and date.
• What it touches: transactions, approvals, tax, payments, integrations or just a UI field.
• Dependencies: libraries it loads, other scripts on the same record, workflows that call it.

Step 2: Retire before you rewrite

Most accounts that have been live for several years carry scripts nobody remembers writing. Oracle's guidance is to evaluate inactive or obsolete scripts for retirement instead of migration. Every script you remove is one less to convert, test and support.

Be careful with the word "inactive". A script that runs once a year at year-end, or only when a particular subsidiary posts an intercompany journal, can look unused. Confirm with the process owner before you undeploy anything, and keep a copy of the file.

Step 3: Decide what to rewrite first

Oracle recommends starting with scripts that support critical business processes, high-usage scripts, integrations and scripts with complex dependencies. Within that, this is the order I use.

1. Scheduled scripts that yield or set recovery points

SuiteScript 2.1 scheduled scripts have no equivalent of nlapiYieldScript() or nlapiSetRecoveryPoint(). Oracle's script type differences say 2.1 scheduled scripts don't support manual yielding, and a restarted script begins again from the start. For work that needs yielding, Oracle points you to a Map/Reduce script.

That means these scripts aren't a line-by-line conversion. They are a redesign: split the work into stages, make each record safe to process twice, and decide how errors are reported. They take longest, so start them first.

2. RESTlets and integration scripts

RESTlets sit between NetSuite and other systems, so a failure stops data moving. If the integration also uses TBA or NLAuth, the authentication needs to change too. I built the Cape.io integration between NetSuite and Fortnox in native SuiteScript 2.1, and the lesson carries over: integration code needs proper logging, retries and a test plan agreed with finance. See the Cape.io case study for how that looked across eight subsidiaries.

3. Finance-critical user event and workflow action scripts

Next come scripts on transactions: GL impact, approval routing, vendor bank detail controls, tax fields, intercompany logic. A subtle change here may not throw an error. It may just post a different amount.

4. Client scripts, Suitelets and portlets

These affect what users see. Errors are usually obvious and quick to spot in testing, so they can follow the server-side work.

5. SuiteScript 2.0 and 2.x scripts

These come last because there is a shortcut for many of them. Under Setup > Company > Preferences > General Preferences, Oracle provides two account-level preferences: Execute SuiteScript 2.0 Server Scripts as 2.1 and Execute SuiteScript 2.x Server Scripts as 2.1. They run server scripts on the 2.1 runtime without changing the file, and you can switch them back at any time. Use them in sandbox to see which scripts work unchanged, then update the annotation.

Two limits apply. The preferences cover server scripts only, and there is no equivalent for SuiteScript 1.0. And SuiteScript 2.1 runs on a different engine, so some behaviour changes. Oracle lists differences between 2.0 and 2.1 including error object properties, parseInt, date formatting, strict mode and RESTlet return types.

What changes when you convert SuiteScript 1.0

A SuiteScript 1.0 script can't be fixed by changing a tag. NetSuite doesn't support calling SuiteScript 1.0 APIs from a 2.x script, so every nlapi function and nlobj object has to be replaced with the matching N/ module. Oracle's SuiteScript 1.0 to 2.1 API map is the reference. Expect these changes:

• Structure. Global functions become an AMD module with define, and each entry point receives a single context object.
• Arguments. 2.1 methods take one options object, and parameter names sometimes differ.
• Subrecords. Addresses and other subrecords work differently. You don't save them separately; NetSuite saves them with the parent record.
• APIs with no direct equivalent. Oracle lists some, such as the date-time value functions (use N/format) and nlapiAddDays (use standard JavaScript dates).
• Reserved names. log and util are reserved in 2.1. Oracle notes that a 1.0 variable with either name causes an error if 1.0 and 2.1 scripts run on the same record. That matters during a phased upgrade, when old and new scripts sit side by side.

Using AI to convert scripts, safely

Oracle now publishes a SuiteScript upgrade agent skill, netsuite-suitescript-upgrade, that can analyse, convert, explain and validate legacy scripts. It's a useful first draft and a good way to size the work.

Oracle's own warnings are worth repeating. Validation is a static check, not a substitute for functional testing. Review entry points, dependencies, script IDs and deployment behaviour, and don't change production behaviour just because a conversion completed without errors. Oracle flags date, time zone, subrecord, search, error handling and sublist indexing as areas to check by hand.

Test and release in batches

For each converted script, run it in sandbox against the same records as the original and compare the results: field values, GL lines, emails sent, records created. Then release a few scripts at a time, outside month-end, and watch the execution logs before the next batch. Oracle recommends the same phased approach.

After go-live, make sure each release is tested too. A release readiness check runs your scripts against the release preview before each upgrade, which matters more as 2028 approaches.

If you would rather hand over the inventory and rewrite, my NetSuite customisation and SuiteScript development service covers it, or you can book a call to talk it through.

Want a ranked list of your legacy scripts and a fixed price to upgrade them? The SuiteScript 2.1 and OAuth 2.0 Upgrade starts with a free inventory.

Originally published at suiteheroes.com.

Good NetSuite support after go-live is not a help desk that closes tickets. It is a clear split of who answers what, a quick route to a fix when something breaks, and someone who finds out why it broke so it doesn't happen again. Most businesses handle simple questions in-house. What they lack is the second and third levels: someone senior who can read a script log, trace a failed integration record, or work out why a journal posted to the wrong period.

I've provided L2/L3 support and administration to NetSuite customers for years. Most of them came to me after going live with someone else. This is what I think good support looks like, and how to tell whether you have it.

What L1, L2 and L3 NetSuite support mean

Oracle doesn't define these levels for you. They are a common way to divide the work, and this is how I use them:

• L1: how-to and access. Password resets, "where do I find this report", a user who can't see a field. Usually handled by a key user or your NetSuite administrator.
• L2: diagnosis and configuration. Something is wrong and needs investigating. A saved search returns the wrong totals, an approval workflow stalls, a tax code posts to the wrong account, a CSV import fails. L2 fixes configuration, roles, forms, searches and data.
• L3: technical and design. The cause sits in SuiteScript, a workflow, an integration or the way the account was designed. L3 reads code and logs, fixes or rewrites scripts, and changes the design where it's wrong.

The test of a good set-up is that each request reaches the right level quickly. An L3 problem that sits with L1 for two weeks costs more than the fix.

Where Oracle NetSuite Customer Support fits

Oracle's own support is part of the picture, but it covers the product, not your configuration. The defects it tracks are cases "when a feature doesn't work as intended" (Oracle: NetSuite issue resolution). Your custom scripts, workflows, saved searches and third-party integrations are yours to support, or your partner's.

What you can do through Oracle depends on your support level. Oracle's help on creating support cases says:

• On Basic Support, you go to the Support tab, select Go to SuiteAnswers, then Contact Support. You start with the Virtual Support Assistant, and you can submit only critical problems that affect business operations. Other questions go to the NetSuite Support Community.
• On Premium Support, you go to Contact Support > Create Support Case, choose a case type and set a severity. For a C1 case you tick the 24 x 7 availability box.

Only authorised support contacts can report problems and manage cases with Oracle on your behalf. The limit is two contacts on Basic Support and four on Premium. You manage them from the Support tab, in NetSuite 360 > Authorized Support Contacts (Oracle: adding authorised support contacts). When an administrator leaves, check this list straight away, so you aren't left without a valid contact when you need to raise an urgent case.

A good L2/L3 partner knows when an issue is a genuine product defect and writes the case for you: steps to reproduce, the record IDs, the role used, screenshots and the business impact. Oracle says the more case questions you answer, the faster the response. If you have access to NetSuite 360, you can follow defects linked to your cases under See Support Issues.

What good L2/L3 NetSuite support looks like

1. A clear way in, and agreed response times

One channel for requests, whether that's email, Teams or Slack, and a written response time. Everyone should know what counts as urgent. A blocked payment run or failed month-end close is urgent. A new column on a report is not.

2. Triage that starts with evidence

Good support asks for the record, the user, the role and the time, and then looks at the evidence NetSuite already keeps:

• System notes on the record show who changed what and when, with the old and new values (Oracle: system notes).
• Script execution logs, at Customization > Scripting > Script Execution Logs, show script errors across all scripts. Oracle purges user-generated logs after 30 days and system error logs after 60 days, and the log subtab on a script can lose entries sooner when log volume is high (Oracle: governance on script logging). If an error happened six weeks ago, the log may be gone, so act on errors promptly.
• Application Performance Management (APM), a SuiteApp from Oracle, shows which scripts and workflows slow down pages and processes (Oracle: APM for the SuiteCloud platform).
• Integration error queues in Celigo, Boomi or your own logs.

This is the difference between L2 and guesswork. Many "NetSuite is broken" reports come down to a changed role, an edited form or a closed period, and the system notes show that quickly.

3. Fix the cause, not the symptom

Re-running a failed integration record clears today's error. Fixing the missing mapping stops tomorrow's. When the same ticket comes back each month, treat it as a design problem, not a support problem. On the Jockey Club's Coupa integration, finance and support see every flow's health and every error, with a suggested fix, in a control centre built inside NetSuite (case study).

4. Changes made safely

Even small changes should be made in a sandbox first, where you have one, then moved to production with a note of what changed and why. Script and workflow changes need a quick regression test of the process they touch. This is where many support arrangements fall down: a quick fix in production that breaks a scheduled script nobody remembered.

5. A log of every request

Each request should be recorded: what was asked, what was found, what was done and how long it took. The log is how you spot patterns, such as one integration that causes half the tickets. It also means the next person who supports your account doesn't start from nothing.

6. Release readiness twice a year

NetSuite is upgraded twice a year. Before each release, you can request a Release Preview account, which lets you test your daily business processes against the new version (Oracle: the Release Preview account). Good support uses that window to test scripts, workflows, integrations and key reports, and fixes problems before they reach production. I cover this as part of support, or as a fixed NetSuite Release Readiness check.

7. Steady improvement

Support should leave the account better each month: a saved search tidied up, a manual step automated, a role tightened, a user trained. If your support provider only ever reacts, you are paying for the same problems twice.

Warning signs your NetSuite support isn't working

• The same errors appear every month-end.
• Nobody can say which scripts or integrations run in your account, or who owns them.
• Small changes wait weeks because the implementation partner is busy or expensive.
• Fixes are made directly in production with no record.
• Your only NetSuite expert has left, and the authorised support contact list still has their name on it.

If several of these sound familiar, start with a review of the account. My NetSuite health check checklist covers the areas I look at first.

In-house, partner or independent support

There's no single right model. A strong in-house administrator handles L1 and much of L2, and brings in senior help for L3 and design questions. Smaller teams often have no administrator at all, and need someone to cover all three levels for a set number of hours a month. Either way, the person helping should know your account before something breaks, not learn it during an outage.

My NetSuite support and administration service covers L2/L3 support, administration, performance tuning and release reviews, for accounts I implemented and accounts set up by other partners. If you want a set number of hours each month with agreed response times, a support log and a monthly summary, see the NetSuite Support Retainer. If your integrations generate most of your tickets, read how I plan and test NetSuite integration projects so errors are designed out from the start.

Need senior NetSuite support after go-live, or a second pair of hands for your administrator? Book a call and we can talk through what you need.

Originally published at suiteheroes.com.

A NetSuite integration rarely fails because the API call didn't work. It fails because nobody agreed which system owns the customer record, a field was mapped by guesswork, or an error sat unnoticed in a log until month-end. Those are project problems, not coding problems. They are solved by four pieces of work: scoping, mapping, error handling and sign-off.

I've led integrations on Celigo, Dell Boomi and native SuiteScript 2.1, with Coupa, Salesforce, HubSpot, Shopify, Stripe, Fortnox and others. This is the plan I follow, whichever tool carries the data. If you're still choosing the tool, I've covered that separately in native SuiteScript vs iPaaS.

Step 1: Scope the NetSuite integration flow by flow

"Integrate Salesforce with NetSuite" is not a scope. It is a dozen separate flows, each with its own rules. Break the integration into flows and write a short specification for each one. For every flow, answer these questions:

• Which records? For example, customers, sales orders, invoices, payments or vendor bills.
• Which system is the source of truth? One system owns each record type, or even each field. If both systems can edit the same field, decide which wins.
• Which direction? One way, or both. Two-way sync needs protection against echo loops, where an update in one system triggers an update back, and so on forever.
• What triggers it? Real time on save, a schedule, or a manual run.
• How many, and how often? Daily and peak volumes, and the busiest day of the month.
• What happens to history? Whether open or historical records are loaded at go-live, and how.
• Who owns errors? A named person or team, not "IT".

Two NetSuite limits belong in scope. First, every account has a concurrency limit on web services and RESTlet requests, which depends on your service tier and SuiteCloud Plus licences. Oracle documents that requests over the limit are rejected, and you can reserve part of the limit for a single integration at Setup > Integration > Integration Management > Integration Governance (Oracle: concurrency limit per integration). If three integrations all run at 2am, they compete for the same pool.

Second, give each application its own integration record. In Oracle's model each application can have its own record, listed at Setup > Integration > Manage Integrations. That lets you see each application's own execution log and block one application without touching the others (Oracle: integration record overview). Pair it with a dedicated integration role that has only the permissions the flow needs.

Then write down what is out of scope. Exclusions agreed early are far cheaper than exclusions argued about in UAT.

Step 2: Map identifiers first, then fields

Before you map a single amount, decide how each system will recognise a record it has seen before.

In NetSuite the usual answer is the external ID. You store the other system's ID on the NetSuite record, and the integration looks records up by it. NetSuite's REST web services support an upsert operation that uses it: a PUT request with the external ID in the URL creates the record if it doesn't exist and updates it if it does (Oracle: using the upsert operation). That is what makes a retry safe. Without it, a timeout followed by a retry gives you two invoices.

Write the other system's reference back as well, so a user in either system can trace a record to its partner. On the Cape.io Fortnox integration, the Fortnox document number was stamped back on every NetSuite transaction for exactly that reason.

Then map fields, and be explicit about the awkward ones:

• Subsidiary, currency and tax code. In OneWorld, a record in the wrong subsidiary is a consolidation problem, not a typo.
• GL accounts, departments, classes and locations. Map each value. Don't let an unmapped value fall back to a default account. In the Cape.io build, unmapped accounts fail loudly by design, so the statutory accounts still reconcile line by line.
• Items. Decide what happens when a line has no matching item. On the Jockey Club's Coupa integration, a line with no item match posts as an expense line coded from the billing string, rather than stopping the whole invoice.
• Dates, rounding and line order. Small differences here cause most reconciliation breaks.

Keep crosswalks, such as entity to subsidiary or tax code to tax code, as data the business can maintain, in a custom record or a lookup table. Hard-coded lists in scripts become a change request every time finance adds a code.

Step 3: Design NetSuite integration error handling before you build

Every integration will fail sometimes: an inactive supplier, a closed period, a blank mandatory field. What matters is what happens next. Agree these rules in design, not after the first bad month-end:

1. Classify errors. Separate temporary errors (timeouts, concurrency rejections, an unavailable endpoint) from data errors (a missing vendor, a closed period). Temporary errors can retry automatically with a growing delay between attempts. Data errors need a person, and retrying them only fills the log.
2. Make every write safe to repeat. Use upserts or a lookup on the external ID, and decide the order of writes. On the Jockey Club build, NetSuite IDs are written back to Coupa first and the exported flag second, because Coupa locks exported invoices.
3. Log in one place, with context. Each error should record the flow, the source record, the message and a suggested fix. On that project, finance and support see every flow's health and every error in an integration control centre built as a Suitelet inside NetSuite, without logging in to Celigo.
4. Alert the owner. Send failures to the named owner from Step 1, and alert on silence too. A flow that hasn't run for a day is often a bigger problem than one that failed once.
5. Guard against bad runs. Before a large run, check a known record first. The Jockey Club chart-of-accounts flow checks a "golden record" combination before it starts, so a change to the segment order stops the run before it can do damage.
6. Write the runbook. For each common error: what it means, who fixes it, and how to re-run.

Step 4: Test like finance will use it

Build and test in a sandbox, and plan for refreshes. Oracle notes that a sandbox refresh deletes the token key and token secret, so they have to be regenerated, and it recommends separate integration records in each account so sandbox changes can't break production (Oracle: TBA credentials and accounts). If your integration still uses token-based authentication, read my note on the move from TBA to OAuth 2.0 before you build.

Test in three layers:

• Unit tests of each mapping, run by the developer.
• System integration tests (SIT) end to end across both systems, with scripted cases for creates, updates, cancellations, credits, partial payments and each error you designed for in Step 3.
• User acceptance tests (UAT) run by the people who will live with it, using real scenarios from a recent month.

Test volume, too. Run a realistic month-end batch, not ten records. And if you're loading history, load it through the same flows and rules as live data. On the Jockey Club project, a 777-invoice backlog was re-imported through the live rules, and every remaining error was traced to a named data fix.

Step 5: Sign off against evidence

Sign-off is where projects either end cleanly or drift. Agree the criteria at the start, and make them measurable:

• Every SIT and UAT script passed, or has an agreed workaround and an owner.
• A reconciliation report that ties the count and value of records in both systems for a test period, by subsidiary.
• The runbook, mapping document and support contacts handed over.
• Alerts tested, by forcing a failure and checking the right person was told.
• A go-live plan: cut-off times, who switches each flow on, and how to roll back.

Signatures should come from the finance owner and the business owner of each flow, not just the developer. The first two or three month-ends after go-live are the real test, so agree who is on hand for them. Ongoing NetSuite support after that can be in-house or a retainer, but someone must own the error queue.

When an integration is already live and failing

If an existing NetSuite integration keeps breaking, work the same steps in reverse: list the flows, rebuild the mapping from what the integration actually does, then add the missing error handling. My fixed-price NetSuite Integration Rescue Sprint does that for Celigo, Boomi and SuiteScript integrations.

For a new project, my NetSuite integration services cover scoping, mapping, build, testing and sign-off. You can see how a 24-flow, nine-entity build came together in the Jockey Club case study.

Planning a NetSuite integration, or living with one that keeps failing? Book a call and I'll walk through your flows with you.

Originally published at suiteheroes.com.

If you're looking for a NetSuite consultant in the UK, the hard part isn't finding one. It's telling apart the consultant who will deliver your project from the one who will learn on it. The quickest way to do that is to ask the same ten questions of everyone on your shortlist, and listen to how specific the answers are.

I've seen this from both sides. I was a Senior NetSuite Consultant at RSM US, a NetSuite partner, and I now run SuiteHeroes, an independent NetSuite consultancy in London. I've also been brought in to rescue stalled implementations, and most of them went wrong in ways these questions would have exposed before anyone signed.

10 questions to ask a NetSuite consultant in the UK

1. Who will actually do the work?

This matters more than anything else on the list. The person who runs the sales meeting is not always the person who configures your account. Ask for the names of the people who will lead design, build any scripts and run data migration, and ask to meet them.

Then ask how much of their time you get. A consultant spread across six clients will be slow to answer when your month-end breaks. A good answer names people and gives a realistic commitment, such as days per week during build.

2. Have you done projects like ours?

"Yes, we've done lots of NetSuite implementations" isn't an answer. Ask about projects with the same shape as yours: the same number of entities, the same modules, the same systems to integrate, the same source system you're leaving.

If you're a UK group with overseas subsidiaries, ask about OneWorld, multi-currency and intercompany. If you're moving from Xero or Sage, ask how they handled opening balances and history. If you sell subscriptions, ask about revenue recognition. Then ask for a reference you can call, not just a logo. A short conversation with a finance director who has been through it tells you more than any proposal.

3. Can you verify your NetSuite certifications?

Oracle runs NetSuite certifications, including SuiteFoundation and the ERP Consultant exam. You don't have to take a badge on a website at face value. Oracle's certification portal, CertView, lets a candidate publish their credentials to a third party: you receive a link and a password by email, and they're only valid for a limited time (Oracle CertView FAQ). Oracle says it won't verify a certification for an employer without the candidate starting the request, so ask them to send it.

Treat certification as a floor, not proof. It shows someone has passed an exam. Questions 1 and 2 tell you whether they've delivered.

4. Do you understand our finance processes, or just the system?

NetSuite is an accounting system first. A consultant who knows every setting but not why a controller locks a period, how VAT is reported, or what IFRS 15 asks of revenue recognition will build something that works on screen and fails at month-end.

Ask them to walk you through how they would set up your close, or your approval for supplier bank detail changes. This is where my CIMA qualification earns its keep: on one project I helped take a monthly close from 12 days to 2.5 days, and the work was as much finance process as system configuration.

5. How do you build, test and document customisation?

Scripts and workflows are where long-term cost hides. Ask:

• Do you write new scripts in SuiteScript 2.1?
• Where is the code kept, and do we get a copy?
• What documentation do we receive at the end?
• How do you test before NetSuite's twice-yearly upgrades?

On the last point, Oracle provides a Release Preview account before each release so you can check that your existing business processes still work. A consultant who has never mentioned it is unlikely to plan for it. The same goes for integrations: ask how errors are logged, who is alerted and how failed records are retried. I've written about the choice of tool in native SuiteScript vs iPaaS.

6. How did you arrive at this estimate, and what's excluded?

A credible estimate shows days by workstream (design, configuration, data migration, integrations, testing, training and go-live support), with assumptions and exclusions written down. A single total with no breakdown can't be compared with anything.

Look hardest at the exclusions. A low fixed price with a long list of them is often how a cheap project becomes an expensive one. I cover what drives the number in NetSuite implementation cost in the UK.

7. How do you handle change and open decisions?

Scope will change. That's normal. What you want to know is how: who raises a change request, how it's priced, and who signs it off. Ask also how they keep design decisions from sitting open. In my experience, many troubled projects didn't fail on technology. They ran over because decisions waited weeks for an answer.

8. How will you access our NetSuite account?

Each consultant should have their own named login, with a role that gives them what they need and no more, and two-factor authentication. Shared logins wreck the audit trail and make it impossible to remove one person's access cleanly. Ask also what happens at the end: who removes their access, and how integration credentials are handed over.

9. What happens after go-live?

The first two or three month-ends usually need hands-on help. After that, someone has to fix issues, make small changes and test each release. Ask whether the consultant offers support, how fast they respond, and whether the person answering will know your account. A NetSuite support retainer is one option. Training an internal NetSuite administrator is another. Either way, agree it before go-live, not after the first problem.

10. Are the contract basics in place?

These are dull questions, but they protect you:

• The company. Check the business on Companies House. Know who you're contracting with.
• Insurance. Ask whether they hold professional indemnity insurance, and for what cover.
• Data protection. Your consultant will see customer, supplier and employee data. Expect clear data processing terms in the contract.
• IR35. If you're a medium or large business and you hire an individual who works through their own limited company, the off-payroll working rules make you responsible for deciding their employment status. HMRC's guidance says this has applied to private sector clients since 6 April 2021. Whether the rules apply to your engagement depends on the facts, so check with your accountant or tax adviser.

Red flags to watch for

• They propose a solution before asking about your processes.
• They can't name the people who'll do the work.
• Every requirement gets "yes, NetSuite does that", with no trade-offs.
• They have no references from a project of similar size and shape.
• They want to customise heavily where standard NetSuite would do.
• There's no plan for testing, training or support after go-live.

Partner, independent or both?

You can choose a NetSuite partner, an independent NetSuite consultancy, or a mix, such as a partner for licences and an independent consultant for design and delivery. Each has strengths. A larger firm offers more people and cover. An independent consultant usually means the senior person you met is the one doing the work. Ask all ten questions either way.

If you're planning a new project, my NetSuite implementation services cover requirements and design through to data migration, integrations and go-live. You can see how a multi-entity integration project ran in the Jockey Club case study. If you already have NetSuite and want an independent view of how well it's set up, a NetSuite health check is a sensible place to start.

Shortlisting NetSuite consultants? Book a call and put these ten questions to me. I'll answer them straight, including when I'm not the right fit.

Originally published at suiteheroes.com.

E-invoicing is no longer something a few countries do. On 1 January 2027 new NetSuite e-invoicing obligations start in Germany, the UAE, Norway and Croatia, with France, Spain and the rest of the UAE following during 2027. For many NetSuite customers the question isn't whether to comply, but how: switch on a prebuilt add-on, or build a native localisation inside NetSuite that you control.

There's no single right answer. This article sets out the deadlines, where prebuilt add-ons work well, where they start to hold a growing business back, and what a custom native solution gives you in return.

The NetSuite e-invoicing deadlines to plan for

These are the dates that affect most of the groups we work with. Each was checked against tax authority or official sources in November 2026:

• 31 December 2026, Philippines: structured e-invoicing under the EOPT Act for large taxpayers, e-commerce sellers and businesses using computerised accounting systems.
• 1 January 2027, Germany: issuing structured e-invoices becomes mandatory where prior-year turnover was above €800,000. Everyone else follows on 1 January 2028.
• 1 January 2027, UAE: businesses with revenue of AED 50m or more go live through an Accredited Service Provider, under Ministerial Decision 244 of 2025. Smaller businesses follow on 1 July 2027.
• 1 January 2027, Norway: businesses must send EHF or Peppol e-invoices to other businesses.
• 1 September 2027, France: SMEs and micro-businesses must issue e-invoices and e-report through an approved platform, a year after large companies (official timetable).
• 6 October 2027, Spain: B2B e-invoicing for businesses above €8m, including reporting payment status.

Our country-by-country guide covers 38 countries, including the statutory reports that sit alongside each mandate.

What NetSuite gives you out of the box

Oracle's starting point is the Electronic Invoicing SuiteApp. It's a framework for creating, sending and receiving XML or JSON e-documents. Oracle's documentation says it's free for one country and needs a licence for more. On top of it, Oracle offers country SuiteApps for places such as Belgium, France, Germany and Spain (Veri*Factu), as well as Brazil, Mexico, Chile, India, Saudi Arabia, the UAE, Israel and Malaysia. Several of these route documents through Oracle Business Network and Avalara.

Third-party add-ons fill many of the gaps, from Italian SDI connectors to Argentine localisations. For a single subsidiary with a standard sales process, one of these is often the quickest way to comply. We recommend them where they fit.

Where prebuilt add-ons start to hurt as the business changes

The trouble usually starts a year or two after go-live, when the business no longer looks like it did on the day the add-on was installed. These are the issues we see most often.

You depend on someone else's roadmap

Mandates change often. Germany's tax ministry issued new guidance in October 2026, Malaysia changed its exemption threshold in August 2026, and Spain has announced but not yet enacted a delay to Veri*Factu. When a rule changes, you wait for the vendor's next release. If that release lands after your deadline, or doesn't cover your edge case, you have no way to fix it yourself.

Locked records, fields and scripts

Most add-ons ship as locked bundles. You can't change their custom records, add a field the authority now wants, or alter the script logic. When your process needs something slightly different, such as a self-billing flow, a marketplace channel or a new document type, you end up building workarounds around a black box.

Costs and coverage that grow with every country

Each new subsidiary can mean another licence, another vendor or another connector. A group in five countries can easily end up with three different e-invoicing products, three support contracts and three ways of handling rejections. Finance teams then have to learn a different process for each entity.

Your data leaves NetSuite for someone else's cloud

Many connectors copy invoice data to the vendor's platform before it reaches the authority. Sometimes the law requires an intermediary anyway, such as approved platforms in France, Accredited Service Providers in the UAE, PACs in Mexico and Peppol access points elsewhere. But adding a second, optional copy outside NetSuite means more contracts to review and more places where data is kept.

Reporting that doesn't reconcile

When e-invoices live in one product and VAT returns, SAF-T files and ledgers are built somewhere else, the figures drift apart. The authority then sees invoice data that doesn't match the return you filed.

What a custom native localisation gives you

A native build lives entirely inside your NetSuite account, written in SuiteScript 2.1 and using records you own:

• Records and fields: custom records for each e-document, its status history, the country profile and your code mappings, with fields on the transaction that your team can see, report on and change.
• Scripts: one engine that builds XML (UBL, CII, FatturaPA, CFDI) or JSON, checks it against the official schema, signs it with your certificate and sends it. Adding a country means adding a format, not a new product.
• Workflows: approvals, blocks on editing cleared invoices and rejection handling that match how your finance team actually works.
• Security: credentials in NetSuite API Secrets, documents sent from NetSuite straight to the authority wherever its API allows, and no copy held by us or by middleware. The legal archive stays in your account.
• Reporting: VAT returns, SAF-T files and reconciliations built from the same data as the e-invoices, so they agree.

The trade-off is ownership. With a custom build you're responsible for keeping up with rule changes, testing each NetSuite release and keeping the code documented. That's manageable with good tests and a support retainer, but it's a real commitment, and it's one reason we compare options honestly before recommending a build.

Prebuilt, custom or both?

A simple way to decide, entity by entity:

1. One country, a standard process and an Oracle SuiteApp that covers it: start with the SuiteApp.
2. Several countries, non-standard flows or a fast-changing regime: build on Oracle's Electronic Invoicing framework with your own templates and sending plug-ins, or go fully custom.
3. No Oracle SuiteApp, or a requirement that no data leaves NetSuite except to the authority: build natively.

Many groups end up with a mix: Oracle's SuiteApp for Belgium or Germany, and a custom engine for the countries where nothing fits. What matters is one data model, one way of handling rejections and reporting that reconciles across every subsidiary.

Start with the deadlines you can't move

If you have subsidiaries in Germany, the UAE, Norway or Croatia, 1 January 2027 is close. Map each entity to its obligation now, decide the route per country, and leave time to test with the authority's sandbox. Our consultants have delivered NetSuite localisation, e-invoicing and statutory reporting across 38 countries. Our NetSuite e-invoicing and tax reporting service sets out how we get each entity ready.

For a German example in more depth, read German §14 UStG e-invoicing in NetSuite. For the wider build-or-buy question, see native SuiteScript vs third-party iPaaS.

Not sure which route fits your entities and deadlines? Book a call and we'll map each subsidiary to its obligations and the simplest compliant way to meet them.

Originally published at suiteheroes.com.

The honest answer to "how much does a NetSuite implementation cost in the UK?" is that it depends on scope, and anyone who quotes a single number before understanding yours is guessing. What I can do is show you where the money goes and which decisions move the price, so you can build a realistic budget and test the quotes you receive.

I've worked on NetSuite for more than 15 years, as a Senior NetSuite Consultant at RSM US, a NetSuite partner, and now as an independent NetSuite consultancy in London. The same few factors decide the cost of almost every project.

The two bills: subscription and implementation

A NetSuite budget has two separate parts, and it's worth keeping them apart from the start.

The subscription is what you pay Oracle (or a reseller) to use NetSuite. It's normally made up of a base licence, user licences and any add-on modules, such as OneWorld, Advanced Revenue Management, Fixed Assets or Advanced Inventory. Extra sandbox accounts are also licensed separately; Oracle's help says you buy a sandbox through your NetSuite account manager. Oracle doesn't publish a price list, so the only reliable figure is a written quote for your configuration.

The implementation is the work of designing, configuring, migrating, integrating, testing and training. Whether you use Oracle's own services team, a NetSuite partner or an independent consultant, this is priced in consultant days, either as time and materials or as a fixed fee built from an estimate of days.

Published guides on NetSuite implementation cost are mostly written by US partners, priced in dollars, and disagree with each other by a wide margin. That's not because some are wrong. It's because "a NetSuite implementation" can mean anything from one UK company on core financials to a multi-country group with a dozen integrations.

What drives NetSuite implementation cost in the UK

These are the factors I look at first when I estimate a project. Users matter less than most people expect. Adding ten users adds licences and a little training, but adding one subsidiary or one integration can add weeks.

1. Number of entities and countries

A single UK company is the simplest case. A group with subsidiaries needs NetSuite OneWorld, and each subsidiary brings its own base currency, tax set-up, intercompany rules and consolidation. Oracle's help notes that you can't change a subsidiary's base currency once the record is saved, so the hierarchy has to be designed properly up front.

Each overseas country also adds local tax and reporting. Cape.io, for example, runs a OneWorld account with eight subsidiaries across eight countries, and the Fortnox integration I built had to reconcile VAT line by line for Swedish statutory reporting (read the Cape.io case study).

2. Modules and processes in scope

Core financials, order to cash and procure to pay are the base. Each module beyond that, such as revenue recognition, SuiteBilling, projects, inventory, manufacturing or planning and budgeting, needs its own design workshops, configuration and testing. Revenue recognition under IFRS 15 is a common example where the set-up looks small on a feature list but takes careful design.

3. Data migration

Moving from Xero, Sage or QuickBooks is a different job from moving off SAP or a bespoke system. The cost depends on how many years of history you bring across, whether you migrate open transactions only or full detail, and how clean the source data is. Duplicate customers, inconsistent item codes and unreconciled balances all have to be fixed somewhere, and it's cheaper to fix them before the load than after go-live.

4. Integrations

Every system that talks to NetSuite, such as a CRM, e-commerce platform, payment provider, payroll or a hotel PMS, needs mapping, build, error handling and testing. On a Coupa to NetSuite source-to-pay integration I led for The Jockey Club, the build ran to 24 flows across nine entities on Celigo (the Jockey Club case study). That's at the larger end, but it shows how integration scope multiplies.

The tool matters too. An iPaaS such as Celigo or Boomi has its own subscription; native SuiteScript has no extra licence but needs a developer. I've compared the two in native SuiteScript vs iPaaS for NetSuite integrations.

5. Customisation

Every custom field, form and saved search is cheap on its own. Custom workflows and SuiteScript cost more, and they keep costing after go-live, because each one has to be tested before every NetSuite release. The cheapest projects are the ones that adapt the process to standard NetSuite where the business can live with it, and customise only where there's a real reason.

6. UK tax and compliance

UK VAT and Making Tax Digital are well supported. Oracle's UK Localization SuiteApp provides templates for the VAT100 return, EC Sales List and Intrastat, and supports digital submission to HMRC. It still needs installing, configuring and testing against your tax codes, and that time belongs in the estimate. If you have VAT complications such as partial exemption, check the treatment with your tax adviser before design starts.

7. Your own team's time

This is the cost most budgets leave out. Your finance team will spend time in workshops, cleaning data, writing and running user acceptance tests, and learning the system, usually while doing their day jobs. If they can't give that time, the project slows down, and a slower project costs more in consultant days. Some companies backfill roles or bring in temporary help for the busiest months.

Costs that turn up after the quote

A few items are often missing from the first budget:

• Support after go-live. The first two or three month-ends usually need hands-on help. After that you need someone for fixes, small changes and release testing, whether that's an internal administrator or a NetSuite support retainer.
• Third-party subscriptions. iPaaS tools, tax engines, banking connectors and some SuiteApps carry their own fees.
• Change requests. Anything not in the signed scope will be charged extra. That's fair, but it's where budgets drift.
• Rework. A project that goes live with poor data or untested processes costs more to fix afterwards than it would have cost to do properly.

How to get a quote you can trust

You can't compare quotes unless they describe the same project. Before you ask for one, write down:

1. your entities, countries and currencies
2. the processes and modules in scope, and those out of scope
3. every system that will integrate with NetSuite, with rough volumes
4. what data you'll migrate and how many years of history
5. your target go-live date and any fixed deadlines, such as a year-end.

Then ask each NetSuite partner or consultant to show days by workstream (design, configuration, migration, integrations, testing, training, go-live support), their assumptions and their exclusions. The total cost is simply the days multiplied by the day rate. As an illustration only: if two quotes use similar day rates but one has half the days for data migration, ask what they've left out.

Be wary of a low fixed price with a long list of exclusions. It's often how a project that looks cheap at signing becomes expensive by go-live.

Keeping the cost down without cutting corners

• Phase the scope. Go live on core financials first and add modules or integrations in a second phase, once the team is using the system.
• Clean data before migration, not during it.
• Stay close to standard NetSuite and customise only where it pays back.
• Decide quickly. Many of the stalled implementations I've been asked to rescue didn't fail on technology. They ran over because design decisions sat open for weeks.

If your project is already over budget or behind, the Implementation Rescue Sprint is a fixed-scope way to find out why and get go-live back on track. For a new project, my NetSuite implementation services cover everything from requirements and design through to data migration, integrations and go-live support.

Planning a NetSuite project, or worried one is running over? Book a call and I'll give you an honest view of scope and effort before you commit.

Originally published at suiteheroes.com.

A NetSuite account rarely breaks in one go. It drifts. A preference is changed to get a transaction through at month-end. A leaver keeps access. A script is deployed for a one-off fix and never switched off. Each change is small, but after a few years the account is slower, harder to close and harder to trust.

A health check is a structured look at that drift. You don't need a consultant to start one. This checklist covers 12 areas you can review in your own account, with the menu paths to find each one and what to look for when you get there. You'll need the Administrator role, or a role with view access to setup, for most of it.

Menu paths can vary with your edition, enabled features and role, so treat them as a guide and check Oracle's NetSuite help if something isn't where you expect.

Controls and set-up

1. Enabled features

Go to Setup > Company > Enable Features and work through each subtab. You're looking for two things: features that are switched on but not used, and features you're paying for, or that would solve a known problem, that are switched off.

Features that are on but unused add fields, forms and confusion. Before switching anything off, check with the people who use that area, as some features can't easily be turned off once there's data behind them.

2. Accounting preferences

Go to Setup > Accounting > Accounting Preferences. On the General subtab, check Allow Transaction Date Outside of Posting Period. It has three options: Disallow, Warn and Allow. Allow lets users post outside the period with no warning at all, which is rarely what a finance team wants.

On the same subtab, check whether Require Approvals on Journal Entries is set, unless journal approval runs through a workflow instead. On the Items/Transactions subtab, look at Duplicate Number Warnings.

The Audit Trail under the More menu on this page shows who changed each preference, when, and the values before and after. It's worth a look if a setting surprises you.

3. Accounting periods and locks

Go to Setup > Accounting > Manage G/L > Manage Accounting Periods. Look at how far back periods are open. Old periods left open invite back-dated postings that change figures you've already reported.

The page also shows locks for A/R, A/P, payroll (if used) and all G/L transactions. Oracle's help describes how to lock and unlock periods through the Period Close Checklist. If periods are closed months late, or never locked between month-end and close, that's a finding in itself.

4. Chart of accounts and segments

Review the chart of accounts for duplicate or near-duplicate accounts, accounts with the wrong type, and old accounts that should be inactive. Then look at departments, classes, locations and any custom segments. Ask two questions: is each one used consistently, and is it mandatory where your reporting depends on it? A segment that's optional on half your transactions won't give you a reliable report.

Security and access

5. Roles and permissions

Review who has the Administrator role and how many custom roles carry wide permissions. Look for roles that combine duties that should be separate, such as creating vendors and approving payments to them.

NetSuite requires two-factor authentication for the Administrator and other highly privileged roles, and this can't be removed. Use the Two-Factor Authentication Roles page to see which other roles are flagged, and decide whether any more sensitive roles, such as those that approve payments, should require it too.

6. User access and leavers

Go to Setup > Users/Roles > View Login Audit Trail. It shows login activity by user, role, date and IP address. Compare it with your list of current staff. Anyone who has left should not have access, and anyone with access who hasn't logged in for months may not need it.

This is also a good point to compare active users with the number of licences you pay for.

Data and finance

7. Duplicate customers and vendors

Duplicate records split history, confuse credit control and can hide payment errors. If Duplicate Detection is enabled, its settings are under Setup > Company > Duplicate Detection, and an administrator can review flagged records in bulk at Lists > Mass Update > Entity Duplicate Resolution. Oracle's help on duplicate record detection explains the matching rules and the limits on merging.

For vendors, also check who can change bank details and whether those changes are approved.

8. Bank reconciliation

Check that every bank and credit card account is reconciled up to the last month-end, and how old the oldest unmatched items are.

Oracle now uses the Match Bank Data and Reconcile Account Statement pages (Transactions > Bank > Reconcile Account Statement). The older Reconcile Bank Statement and Reconcile Credit Card Statement pages still work but are no longer supported, according to Oracle's bank data matching and reconciliation help. If your team still uses the old pages, plan the move.

9. Open subledger balances

Run your A/R and A/P ageing reports and look past the totals. Common findings are:

• customer payments and deposits left unapplied
• vendor credits never applied to bills
• sales orders fulfilled but never billed
• purchase orders received but never billed, with no accrual.

Each one means the ledger and the subledger tell slightly different stories. Agree the subledger totals to the balance sheet control accounts as part of the check.

Technical layer

10. Scripts and workflows

Go to Customization > Scripting > Script Deployments. For each deployment, ask whether it's still needed, who owns it and whether it's documented. Clearing the Deployed box stops a deployment running without deleting it, which is a safer first step than removing a script.

Check log levels too. Oracle recommends Debug only while testing, and Audit, Error or Emergency in production. Deployments left on Debug fill the execution log and add overhead. Apply the same questions to workflows: which are active, which still matter and which overlap with scripts on the same record.

11. Integrations

Go to Setup > Integration > Manage Integrations. Tick Show Inactives so you also see blocked records. List each integration, what it does, who owns it and how it authenticates.

This matters now. From 2027.1, Oracle won't allow new integrations that use token-based authentication, and SOAP web services are planned for removal in 2028.2. I've covered the dates and a plan in NetSuite TBA to OAuth 2.0 and SOAP to REST. The Web Services Usage Log (Setup > Integration > Web Services Usage Log) shows which integrations still call SOAP.

12. Performance

Users often say "NetSuite is slow" without being able to say where. Oracle's Application Performance Management (APM) SuiteApp gives you the evidence. It tracks record page performance, splits response time between client, server and network, and monitors user event scripts, workflows, RESTlets, scheduled scripts and Suitelets.

Install it from the SuiteApp Marketplace. Oracle notes that older versions installed from the Search & Install Bundles page stopped working on 7 March 2023, so if you have an old bundle, replace it. Then look at your busiest record pages and the slowest scripts and saved searches behind them.

Turning findings into a plan

A checklist produces a list of findings. To be useful, each one needs an owner, a rating for impact and effort, and a date. I sort findings into three groups:

• Quick wins: settings and access fixes that take hours, such as tightening a preference or removing a leaver.
• Next 90 days: clean-ups that need some testing, such as merging duplicates or retiring unused scripts.
• Roadmap: larger changes, such as rebuilding an integration or redesigning segments.

Make changes in a sandbox first where you can, and avoid month-end. Keep a short record of what you changed and why, so the next review has a starting point.

Run the check once a year, and again before a large change such as a new subsidiary, module or integration. Each NetSuite upgrade is also a good prompt; a release readiness check tests your scripts and integrations before each release lands.

If you'd rather have someone independent do it, the NetSuite Health Check covers these areas and more, read-only, with a written report and a prioritised plan. Or book a call to talk it through.

Want an independent view? The fixed-price NetSuite Health Check reviews your account read-only and gives you a findings register and a prioritised plan.

Originally published at suiteheroes.com.

Two changes to NetSuite integrations are now on Oracle's published roadmap. From release 2027.1, you can't create new integrations that use token-based authentication (TBA). Then, in 2028.2, Oracle plans to remove SOAP web services completely.

If your NetSuite account talks to a bank, an e-commerce platform, a payroll system, a 3PL or an iPaaS such as Celigo or Dell Boomi, at least one of those connections is probably affected. This article sets out what's changing, why 2027.1 is the date that matters most, and a practical plan to move in good time.

What's changing, and when

These are the dates Oracle has published so far:

• 2025.2: the last planned SOAP web services endpoint.
• 2026.1: no new SOAP endpoints. OAuth 2.0 with REST is the recommended route for new integrations.
• 2027.1: no new integrations using TBA, whether for SOAP, REST web services or RESTlets. New integrations using the OAuth 2.0 authorisation code grant must also send PKCE parameters, and NLAuth authentication for RESTlets is switched off, with limited exceptions.
• 2027.2: the 2025.2 endpoint is the only SOAP endpoint still supported. Older endpoints keep running, but without fixes or support.
• 2028.2: SOAP web services are removed, and existing SOAP integrations stop working. Oracle has tentatively given the same release as the end of support for existing TBA integrations.

Release plans can change, so check Oracle's authentication release notes and SOAP removal FAQ before you finalise a plan.

Why 2027.1 is the date that matters

It's tempting to look at 2028.2 and decide there's plenty of time. Existing TBA integrations do keep working after 2027.1. But from that release, anything new has to use OAuth 2.0: a new integration record, a new connector, a new subsidiary or a new environment that needs fresh TBA credentials.

That catches more than people expect. Developers have pointed out that a refreshed sandbox may not be able to issue new TBA tokens, which would make testing old integrations after a refresh difficult. If you test in sandbox before every release, plan to have OAuth 2.0 working before 2027.1.

SOAP integrations need two changes, not one

OAuth 2.0 can't be used with SOAP web services. It works with REST web services, RESTlets and SuiteAnalytics Connect. That splits your integrations into two groups:

• Integrations on REST or RESTlets with TBA have the smaller job. The endpoints stay the same, and only the authentication changes.
• Integrations on SOAP need a new transport as well, usually REST web services and SuiteQL, or a RESTlet where REST doesn't cover what's needed. Payloads, field mappings and error handling all change, so treat these as small rebuilds and test them properly.

Until a SOAP integration is moved, switching it to the 2025.2 endpoint gives it the longest support window.

Which OAuth 2.0 flow to use

NetSuite offers two OAuth 2.0 flows, and the right one depends on how the integration runs:

• Client credentials (machine to machine): for server-to-server integrations with no user involved, such as nightly syncs, payment files and warehouse feeds. Authentication uses a certificate rather than a user signing in. You set it up under Setup > Integration > Manage Authentication > OAuth 2.0 Client Credentials (M2M) Setup.
• Authorisation code grant: for applications where a user signs in and approves access. From 2027.1, new integrations using this flow must use PKCE.

Most back-office finance integrations suit client credentials. Whichever you choose, give each integration its own role with only the permissions it needs.

A practical six-step plan

1. Take an inventory. List every integration record (Setup > Integration > Manage Integrations) and access token (Setup > Users/Roles > Access Tokens). The web services usage log (Setup > Integration > Web Services Usage Log) shows which integrations still call SOAP.
2. Rank by risk. Note what each integration does, who owns it and what breaks if it stops. Anything touching cash, payroll, tax or customer orders goes to the top.
3. Move SOAP integrations first. They need the most work, so start them early. Move any still on old endpoints to 2025.2 in the meantime.
4. Build OAuth 2.0 in sandbox. Create the new integration records and certificates, update the code or connector settings, and test end to end, including errors and retries.
5. Switch over in batches. Release a few integrations at a time, outside month-end, and keep the old credentials until each one is proven in production.
6. Retire what's left. Revoke old tokens, deactivate unused integration records and remove scripts nobody uses.

Third-party connectors need the same care. Ask each vendor, including your iPaaS, when their NetSuite connector supports OAuth 2.0 and what you need to do to switch.

A good moment to tidy up

An authentication project touches every integration, so it's a good time to deal with other technical debt at the same time: SuiteScript 1.0 RESTlets rewritten in SuiteScript 2.1, hard-coded IDs replaced with parameters, proper logging added and code moved into source control. Doing it in one planned project costs less than doing it twice.

It's also worth checking each release before it lands. A release readiness check tests your scripts and integrations in the release preview account before each upgrade, so 2027.1 doesn't come as a surprise.

Need help planning the move? The fixed-price SuiteScript 2.1 and OAuth 2.0 Upgrade starts with a free inventory of your scripts and integrations.

Originally published at suiteheroes.com.

For most NetSuite integrations, the first instinct is to reach for a third-party integration platform — Celigo, Dell Boomi, Workato, Make. They're capable tools, and for some jobs they're the right call. But the reflex to default to an iPaaS deserves more scrutiny than it usually gets, because the licence is rarely the real cost.

The hidden costs of an iPaaS

An iPaaS adds a permanent third party to your finance architecture. That brings recurring costs that compound over the life of the integration:

• Licence creep. Pricing scales with connections, flows or message volume — exactly the things that grow as your business grows.
• Opaque error handling. When a sync fails at month-end, you're debugging someone else's black box, often through a support queue.
• Limited control over mapping. Audit-grade requirements — line-by-line VAT reconciliation, explicit chart-of-accounts mapping — can be awkward or impossible to express cleanly.
• A data-residency question. Your transactions transit a third party's infrastructure, which procurement and compliance will (rightly) ask about.

Where native SuiteScript wins

Building the integration natively in SuiteScript 2.1 — using the right entry point for each job (Map/Reduce for bulk, Scheduled for pollers, User Event for triggers, RESTlet for inbound webhooks, Suitelet for an admin console) — keeps everything inside NetSuite's own governance and audit trail. You own every mapping, every retry policy, and every log line. There's no monthly fee, no extra vendor in the data path, and no translation layer between what finance needs and what the connector can express.

For integrations that touch the general ledger, tax, and statutory reporting, that control is not a nice-to-have. It's the difference between an integration finance can defend in an audit and one they have to apologise for.

Where an iPaaS still earns its keep

This isn't a religious position. An iPaaS is a sensible choice when you're connecting many SaaS systems that already have strong pre-built connectors, when you have no in-house scripting capability to maintain a native build, or when time-to-live matters more than long-run control and the data is low-stakes (marketing events, for instance, rather than the GL). The honest test is whether the connector is doing real, ongoing work that justifies its seat in your architecture.

A simple way to decide

Ask three questions. Does this integration touch the ledger, tax or anything an auditor will examine? Will its volume — and therefore its licence — grow with the business? Do you have, or can you retain, the capability to maintain a native build? The more “yes” answers, the stronger the case for native SuiteScript.

The bottom line

An iPaaS is a tool, not a default. For finance-critical NetSuite integrations, a well-built native SuiteScript solution is usually cheaper over its life, more transparent when it matters, and fully inside your control. Reach for the platform when it genuinely earns its place — not by reflex.

Working on something similar? Book a free call and we'll talk it through — no obligation.

If an existing integration is already failing, the NetSuite Integration Rescue Sprint fixes the root causes and adds monitoring at a fixed price.

Originally published at suiteheroes.com.

Independent schools and nursery groups reach a point where the billing system that got them started — iSAMS, Famly, or a patchwork of spreadsheets — can no longer answer the questions the board is asking. How much are we actually owed across all settings? Where is revenue leaking? Are funded hours being billed completely? That's usually the moment NetSuite enters the conversation.

Why education groups outgrow their billing system

iSAMS and Famly are excellent at what they do: managing pupils and children, fees, registers and parent communication at the setting level. What they're not built for is consolidated, multi-entity finance — a group P&L, intercompany positions, debtor-day analysis across every school and nursery, and audit-ready statutory reporting. As a group acquires settings, the gap widens.

What NetSuite brings

NetSuite OneWorld gives a multi-academy or nursery group one general ledger across every entity, with consolidation, intercompany handling and a single view of receivables. Crucially, the framing stays commercial — profit and loss, fee debtors, debtor days — rather than being forced into charity-specific vocabulary that doesn't fit a commercially run group.

The integration question

The right architecture keeps iSAMS and Famly as the billing sub-ledger — that's where fees are raised and parents are managed — and treats NetSuite as the group general ledger. A native, bidirectional integration moves invoices, credit notes, payments and bill-payer records into NetSuite, and writes external identifiers back so every transaction is reconcilable end-to-end. There's no need to re-platform what the settings already do well; you connect it.

Funded hours and revenue leakage

Two numbers tend to surprise education groups when they finally get a consolidated view. The first is revenue leakage — sessions delivered but never billed, discounts applied inconsistently, or credits that quietly erode fee income. The second is funded-hours reconciliation: government-funded entitlement hours that have to be tracked against what's actually claimed and delivered. A finance dashboard that pulls occupancy and billing together makes both visible — often for the first time.

Getting started

You don't need a big-bang migration. A sensible first phase connects one or two settings, proves the billing-to-GL flow and the reconciliation reporting, then rolls out across the group. The goal is a finance function that can answer the board's questions on demand — with the settings still running the tools they know.

Working on something similar? Book a free call and we'll talk it through — no obligation.

Originally published at suiteheroes.com.

Germany's move to mandatory business-to-business e-invoicing is one of the larger compliance shifts NetSuite users with a German entity will face this decade. The headline date has passed — from 1 January 2025 every German business must be able to receive a structured electronic invoice — but the phased issuing obligations are still rolling in. If you run a German subsidiary on NetSuite, here's what actually matters.

What is changing, and when

Under the reform of §14 UStG, a compliant e-invoice in Germany is a structured electronic format, not a PDF. The receive capability became mandatory for all domestic B2B from 1 January 2025. Issuing obligations phase in afterwards by company size and turnover over the following years, so the practical priority for most groups right now is being able to receive and process structured invoices correctly.

The formats: XRechnung and ZUGFeRD

Two formats dominate. XRechnung is a pure-XML structured invoice (the standard for public-sector B2G). ZUGFeRD 2.x is a hybrid — a human-readable PDF/A with the structured XML embedded inside it. Both conform to the European semantic standard EN 16931, which is the thing your validation should actually check against.

What it means for NetSuite

NetSuite doesn't do all of this out of the box for Germany, so the work is in configuration and a structured-data pipeline:

• Receiving. Extract the XML from inbound XRechnung and ZUGFeRD 2.x invoices, validate against EN 16931, and map cleanly onto NetSuite vendor bills — rejecting non-conformant documents loudly rather than silently.
• Issuing. Generate structured output for the formats your counterparties require, with gapless invoice numbering as required under §14 UStG and §146 AO.
• Tax. SuiteTax codes covering 19% / 7%, EU intra-community supplies and §13b reverse charge, posting to the correct control accounts.
• Hand-off and archive. DATEV-format export for the external Steuerberater, and GoBD-conformant archiving of every issued and received e-invoice for the full ten-year retention period.

A practical preparation checklist

Confirm your German entity can receive and parse XRechnung and ZUGFeRD 2.x today. Check your chart of accounts (SKR03 or SKR04) and SuiteTax mapping are clean. Make sure invoice numbering is gapless. Agree the DATEV export format with your Steuerberater. And confirm archiving meets GoBD before, not after, an audit asks.

The bottom line

German e-invoicing is a data-quality and configuration exercise as much as a compliance one. Get the receive pipeline, tax mapping and archiving right, and the issuing obligations become a straightforward extension rather than a scramble.

Working on something similar? Book a free call and we'll talk it through — no obligation.

Originally published at suiteheroes.com.

If your group runs NetSuite OneWorld but a Swedish subsidiary keeps its books in Fortnox — Sweden's leading SME accounting platform — you have a classic two-ledger problem. The Swedish entity needs Fortnox for local e-invoicing and Skatteverket reporting; the group needs everything in NetSuite. The answer is a disciplined, bidirectional integration. Here's how to approach it well.

Why this pairing comes up

Fortnox is deeply embedded in Swedish accounting practice and handles local e-invoicing and statutory requirements that a Swedish finance team relies on. Rather than fight that, the pragmatic architecture lets Fortnox stay the local system of record for the Swedish entity while NetSuite remains the group ledger — with a clean, auditable bridge between them.

What to synchronise

A complete integration covers the core entity types in both directions, with full create-update-cancel handling: customers, suppliers, sales invoices, credit memos, journals, and customer and supplier payments. Sales invoices generated in NetSuite can be issued through Fortnox for Swedish e-invoicing compliance, with the Fortnox document number stamped back onto the originating NetSuite transaction for end-to-end traceability.

The mapping discipline that makes finance trust it

The part that separates a robust integration from a fragile one is the mapping layer. Every NetSuite GL account should map explicitly to its Fortnox counterpart — including VAT and tax control accounts — and unmapped accounts should fail loudly with an actionable error rather than silently falling back. That discipline is what lets statutory accounts reconcile line-by-line for Skatteverket. VAT and tax codes need the same treatment so amounts reconcile precisely and post to the correct control accounts on both sides.

Echo-loops and idempotency

Bidirectional syncs have a characteristic failure mode: a record updated on one side is reflected back as a fresh change on the other, and the two systems ping-pong forever. The fix is last-sync hash stamping on every inbound handler, so the integration recognises its own echo and ignores it. Multi-currency handling — setting currency code and exchange rate for non-SEK transactions — and payment-terms alignment across the AR and AP sub-ledgers round out a build finance can rely on.

Native, not iPaaS

This is precisely the kind of finance-critical, audit-exposed integration where a native SuiteScript 2.1 build pays off: full control over mapping and retry behaviour, no licence drag, and every log line inside NetSuite. An admin dashboard — OAuth2 token management, mapping maintenance and run/queue monitoring in one Suitelet — turns it from a script into something a finance team can actually operate.

The outcome

Done properly, the Swedish team keeps the tool they need, the group gets clean consolidated numbers, and every transaction is reconcilable across both systems — with no third-party platform sitting in the middle of your statutory data.

Working on something similar? Book a free call and we'll talk it through — no obligation.

Originally published at suiteheroes.com.