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, and billing and revenue scripts like those in the multi-cloud billing case study. 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, as the Pink Group Salesforce integration showed. 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. You can try a similar screen in the Integration Control Tower demo.
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. The E-Invoicing Control Centre demo shows what that looks like in practice.

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. My NetSuite data migration service covers mapping, trial loads and reconciliation sign-off.

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 longer engagement, see NetSuite project recovery. 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. Sales orders fulfilled but never billed are often a sign of wider revenue leakage, which a revenue leakage audit traces from contract to invoice.

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. The same rule applies if you connect AI agents such as Claude to NetSuite through MCP, as in my NetSuite AI integration work and the agentic AI case study.

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.

The native SuiteScript vs iPaaS question comes up on almost every NetSuite integration I scope. The first instinct is usually to reach for a third-party integration platform, such as Celigo, Dell Boomi, Workato or Make. They are capable tools, and for some jobs they are 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.

My short answer: for integrations that touch the general ledger, tax or statutory reporting, a native SuiteScript 2.1 build is usually cheaper over its life and easier to defend in an audit. For connecting many SaaS tools with strong pre-built connectors, an iPaaS often wins. I've delivered both, natively for Cape.io and on Celigo for The Jockey Club, so this is not a religious position.

What each option means

Native SuiteScript means the integration lives inside NetSuite. Each script type does the job it suits: Map/Reduce for bulk syncs, Scheduled scripts for pollers, User Event scripts for create and update triggers, RESTlets for inbound webhooks, and a Suitelet for an admin console. Outbound calls use the N/https module, and credentials sit under Setup > Company > Preferences > API Secrets (Oracle: secrets management).

An iPaaS is a separate platform that sits between NetSuite and the other system. It reads from and writes to NetSuite through SOAP or REST web services or RESTlets, and runs its own mappings, schedules and error queues.

The hidden costs of an iPaaS

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

• Licence creep. iPaaS pricing is usually tied to endpoints, flows or volume, which are exactly the things that grow as your business grows. Ask the vendor what drives the price before you sign.
• Opaque error handling. When a sync fails at month-end, you're debugging someone else's platform, often through a support queue.
• Limited control over mapping. Audit-grade requirements, such as line-by-line VAT reconciliation or explicit chart-of-accounts mapping, can be awkward to express cleanly in a connector.
• A data-residency question. Your transactions pass through a third party's infrastructure, which procurement and compliance will rightly ask about.

NetSuite concurrency limits

There is a NetSuite-side cost too. Requests an iPaaS sends to NetSuite through web services and RESTlets count towards your account's concurrency limit. Oracle sets the base limit by service tier, and each SuiteCloud Plus licence adds 10 (Oracle: concurrency governance). The limit covers web services and RESTlet requests combined (Oracle), so several busy connectors can compete with each other. Your current limit is shown on the Integration Governance page. If you plan to add integrations, check it before you buy another connector.

Where native SuiteScript wins

Building natively 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 platform fee, no extra vendor in the data path, and no translation layer between what finance needs and what the connector can express.

The platform also does some heavy lifting for you. A Map/Reduce script yields and reschedules its work automatically when it hits certain governance limits. Oracle sets a soft limit of 10,000 usage units per map and reduce job, and a Yield After Minutes setting on the deployment that defaults to 60 (Oracle: map/reduce governance). Long runs show on Customization > Scripting > Map/Reduce Script Status (Oracle).

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.

The Cape.io case study is a good example. It's a native SuiteScript 2.1 integration between NetSuite and Fortnox across eight OneWorld subsidiaries, covering six record types in both directions, with audit-grade COA and VAT mapping and an admin Suitelet the finance team operates themselves. I describe the approach in NetSuite Fortnox integration.

What native SuiteScript costs you

Native has its own costs, and they should be on the table:

• You own the code. Someone has to maintain it, fix it and understand it after the original developer has gone. Document it, and keep it in version control.
• Platform changes land on you. Oracle expects to remove SuiteScript 1.0 and 2.0 support in 2028.2, and authentication is moving from TBA to OAuth 2.0. See my SuiteScript 2.1 upgrade plan and TBA to OAuth 2.0 guide.
• Monitoring has to be built. An iPaaS gives you a dashboard on day one. A native build needs its own logging, alerting and reprocessing, which is why I always include an admin console.
• Release testing. Scripts need checking against each NetSuite release preview, like any customisation.

Where an iPaaS still earns its keep

An iPaaS is a sensible choice when:

• You're connecting many SaaS systems that already have strong pre-built connectors.
• You have no in-house scripting capability to maintain a native build, and don't want to retain one.
• Time to live matters more than long-run control, and the data is low-stakes, such as marketing events rather than the GL.

The honest test is whether the connector is doing real, ongoing work that justifies its seat in your architecture.

A hybrid often works best. On The Jockey Club Coupa integration, Celigo carries the data across 24 flows and nine group entities, while ten SuiteScript 2.1 scripts and a set of custom records in NetSuite hold the controls, logs and operating console. The platform moves data; NetSuite holds the rules.

Comparing the cost over the life of the integration

Most comparisons look at year one: the iPaaS subscription against the cost of a native build. That flatters whichever option is cheaper to start. A fairer comparison covers three to five years and includes:

• For an iPaaS: the subscription at the volume you expect in year three, any extra connectors or environments, the build itself (someone still has to design the mappings), and the time your team spends working through its error queues.
• For native SuiteScript: the build, documentation, the support arrangement after go-live, and an allowance for platform changes such as the SuiteScript 2.1 and OAuth 2.0 deadlines.
• For both: the cost of a failed month-end sync. If a broken integration delays the close or the VAT return, that cost usually dwarfs the licence.

Put the numbers side by side, and the right answer is often obvious for each flow.

Native SuiteScript vs iPaaS: a simple way to decide

Ask three questions about each integration:

1. Does it touch the ledger, tax, or anything an auditor will examine?
2. Will its volume, and therefore its licence and its concurrency use, grow with the business?
3. Do you have, or can you retain, the capability to maintain a native build?

The more "yes" answers to the first two, and the stronger your answer to the third, the stronger the case for native SuiteScript.

Checklist before you commit

• List every system you need to connect now and in the next two years.
• Mark each flow as finance-critical or not.
• Check which systems have a mature connector, and what it doesn't cover.
• Check your NetSuite concurrency limit and current usage.
• Get the iPaaS price for year three, not just year one.
• Decide who will support the integration after go-live, and how they'll see failures.
• Agree error handling, retries and reconciliation with finance before the build starts.

You can see what good monitoring looks like, native or not, in the Integration Control Tower demo.

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.

My NetSuite integration services cover native SuiteScript, Celigo and Dell Boomi, so the recommendation follows the integration, not the tool I happen to sell.

Weighing up native SuiteScript against an iPaaS for a new integration? Book a free call and we'll talk it through, with 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.

NetSuite for schools and nurseries usually enters the conversation at a particular moment. The billing system that got the group 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 and claimed completely? NetSuite answers those questions by becoming the group ledger, while the settings keep the systems they already know.

I've connected iSAMS and Famly to NetSuite OneWorld, and this article sets out the architecture I use, the finance rules that shape it, and how to roll it out without disrupting the settings.

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 setting level. What they are 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. Finance ends up exporting from each system every month and rekeying into the ledger. Nobody can see enrolment and billing side by side, so pupils who are enrolled but never invoiced go unnoticed.

What NetSuite brings to schools and nurseries

NetSuite OneWorld gives a school or nursery group one general ledger across every entity, with consolidation, intercompany handling and a single view of receivables. Each setting, or each legal entity, becomes a subsidiary under Setup > Company > Subsidiaries. Departments or classes can then carry year groups, rooms or sites for reporting.

The framing stays commercial: profit and loss, fee debtors, debtor days. A commercially run group shouldn't be forced into charity-specific vocabulary that doesn't fit. Design the chart of accounts for how the group is managed and reported.

If you are planning a new NetSuite implementation for an education group, my NetSuite for schools and nurseries page covers the sector in more detail.

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. NetSuite is 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 can be reconciled from the board pack to the source record.

The parts that matter most:

• One identity per payer. A parent who pays for two children in two settings should be one customer, with each child as a sub-customer. A cross-reference record stops duplicates.
• External IDs everywhere. Store each source record's ID as the NetSuite external ID. NetSuite's REST web services can then upsert on it: create the record if it's new, update it if it exists (Oracle: using the upsert operation). A re-run never duplicates an invoice.
• A fee-code map. Each source fee code, such as tuition, lunch, trips or wraparound care, maps to a NetSuite item, GL account and tax code. An unmapped code should stop the record with a clear error, not post to a default.
• Staging and a retry queue. Raw data lands in a staging record first, then posts once it validates. Failed records wait in a queue for review and one-click reprocessing.
• A sync frequency per record type. Payers, invoices and payments usually need to arrive within the day so receivables stay current. Occupancy can often be a daily snapshot. Agree each one with finance rather than syncing everything as often as possible.

There's no need to re-platform what the settings already do well. You connect it. My iSAMS and Famly case study shows how I structure this across 40 subsidiaries, with the record mappings in full.

VAT: schools and nurseries are now treated differently

This is where many education groups need to revisit their setup. Since 1 January 2025, education and boarding services provided by a private school for a charge are subject to VAT at the standard rate of 20% (HMRC VAT Notice 701/30). Before that date they were exempt.

Nursery classes, meaning classes made up wholly or almost wholly of children below compulsory school age, are still VAT exempt under the same guidance. A mixed group can therefore have standard-rated school fees and exempt nursery fees in the same consolidated ledger.

In NetSuite, that means separate tax codes, and a fee-code map that applies the right one to each fee type and setting. Extras such as trips, uniform or lunches may each have their own treatment. The rules have detail and exceptions, so confirm the VAT treatment of each fee type with your tax adviser and let the integration apply it consistently.

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. Once enrolment and billing sit side by side, a report can flag every child enrolled but not invoiced.

The second is funded-hours reconciliation. In England, eligible working parents can get 30 hours of funded childcare a week, for 38 weeks of the year, for children from 9 months old to school age, and every 3 and 4 year old can get 15 hours (GOV.UK). The funding comes from the local authority, not the parent, so the nursery has to track hours expected, claimed and paid.

A practical way to model this in NetSuite is to treat each local authority as a customer and post funded hours as a separate item. Expected, claimed and received amounts then reconcile per setting like any other receivable. A finance dashboard that pulls occupancy and billing together makes both numbers visible, often for the first time. You can explore one in the schools and nurseries finance dashboard demo, and a revenue leakage audit puts a figure on the gap.

Recognising termly fees properly

Fees billed termly in advance are not all revenue on the day you bill them. They belong to the months the term covers. Posting them as revenue when invoiced overstates income at the start of each term and understates it later.

NetSuite's Advanced Revenue Management automates deferral and recognition. It is enabled at Setup > Company > Enable Features, on the Accounting subtab, as Advanced Revenue Management (Essentials). Oracle notes that you must enable Accounting Periods first, and that once enabled the feature can't be disabled (Oracle: advanced accounting features). Plan the recognition rules with your auditors before you switch it on. Term dates from the source system can then drive each schedule.

A checklist for school and nursery groups

1. List every setting and legal entity, and decide the subsidiary structure before anything else.
2. Agree a single customer identity per bill payer, with children as sub-customers.
3. Build the fee-code map: every code to an item, GL account and tax code.
4. Confirm the VAT treatment of school fees, nursery fees and extras with your adviser.
5. Model local-authority funding as a receivable you can reconcile per setting.
6. Decide how termly fees are recognised, and test it in sandbox across a full term.
7. Pilot one or two settings, reconcile the first month-end line by line, then roll out.

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.

My NetSuite implementation services cover the full roll-out, and my NetSuite integration services cover the iSAMS and Famly connection on its own. For why I build finance-critical integrations like this natively, see native SuiteScript vs iPaaS.

Running a group of schools or nurseries and outgrowing spreadsheets? Book a free call and we'll talk it through, with no obligation.

Originally published at suiteheroes.com.

German e-invoicing in NetSuite is one of the larger compliance changes for any group with a German entity this decade. The first date has already passed: since 1 January 2025 every German business must be able to receive a structured electronic invoice. The obligation to issue them is phased in from 1 January 2027. If you run a German subsidiary on NetSuite, the practical question is whether you can receive, validate and post e-invoices today, and issue them in time for your deadline.

I've worked on German NetSuite localisation covering SKR03, DATEV, XRechnung and ZUGFeRD. This is what matters, with the official sources so you can check each point.

What is changing, and when

Germany introduced mandatory B2B e-invoicing through the Growth Opportunities Act (Wachstumschancengesetz) of 27 March 2024, which reformed §14 UStG. The Bavarian State Tax Office sets out the phases clearly (LfSt Bayern):

• From 1 January 2025: every domestic business must be able to receive e-invoices for domestic B2B supplies. Issuing them was allowed from the same date, without the recipient's consent.
• From 1 January 2027: businesses whose total turnover in 2026 was more than €800,000 must issue e-invoices for domestic B2B supplies.
• From 1 January 2028: all domestic businesses must issue them.

Some invoices are excluded: small invoices up to €250, travel tickets, invoices from small businesses under §19 UStG, and certain tax-exempt supplies. B2C sales and B2B supplies that aren't between German businesses are not currently covered.

The receiving rule applies to every business, whatever its size. If your German entity cannot accept an e-invoice, the supplier is not obliged to send you something else instead.

Germany's Federal Ministry of Finance (BMF) has published guidance letters on 15 October 2024, 15 October 2025 and 15 October 2026, covering format, validation, corrections and retention. The BMF FAQ on e-invoicing is a good starting point. Rules can change, so confirm your position with your Steuerberater.

What counts as an e-invoice

Under §14(1) UStG, an e-invoice is issued, sent and received in a structured electronic format that allows electronic processing. The format must meet the European standard EN 16931, or allow the required details to be extracted into a format that does.

Two formats dominate in Germany:

• XRechnung is a pure XML invoice. It has been used for public-sector invoicing for years.
• ZUGFeRD, from version 2.0.1, is a hybrid: a readable PDF with the structured XML embedded inside it.

Other EN 16931 formats, such as Factur-X, are also allowed. A plain PDF, image or Word file is not an e-invoice, even if it is sent by email. Because the XML is hard to read by eye, the tax authority offers a free ELSTER e-invoice viewer for XRechnung files.

What NetSuite provides for German e-invoicing

Oracle's European Union Electronic Invoicing SuiteApp includes Germany-specific features for inbound and outbound transactions using the PEPPOL and ZUGFeRD standards. The documented setup for PEPPOL in Germany looks like this (Oracle: Germany PEPPOL transactions):

1. Fill in the Legal Name on the German subsidiary at Setup > Company > Subsidiaries.
2. Enter the subsidiary's PEPPOL ID at Setup > E-Documents > Electronic Invoicing Preferences.
3. On each customer and vendor, at Lists > Relationships > Customers or Vendors, set the PEPPOL ID and the Germany e-document package on the E-Document subtab.
4. Assign the German subsidiary to the invoice and credit memo templates at Setup > E-Documents > E-Document Templates.
5. Set the EI PEPPOL Tax Category on every tax code, at Setup > Tax > Tax Codes in SuiteTax accounts.

Oracle recommends creating your own EI PEPPOL tax categories rather than editing the defaults, because exemption reasons set on the defaults are removed when the SuiteApp updates. Categories such as exempt, reverse charge and intra-community supply also need an exemption reason and code.

Inbound documents are converted into inbound e-document records by a scheduled Map/Reduce script that runs every 15 minutes. Someone then reviews each one and converts it into a NetSuite transaction.

Read the known limitations before you commit. Germany XRechnung inbound transactions appear on that list. Test your real supplier invoices in sandbox, not only the samples. Where the SuiteApp doesn't fit your flows, a custom native localisation can fill the gap; I compare the two routes in prebuilt e-invoicing add-ons or a custom native localisation.

Receiving: the job to get right first

Receiving has been mandatory since 2025, so start here. A sound receive pipeline does four things:

• Extracts the XML from inbound XRechnung and ZUGFeRD invoices.
• Validates it against EN 16931 before anything posts.
• Maps it cleanly onto NetSuite vendor bills: vendor, items or expense accounts, tax codes and amounts.
• Rejects non-conformant documents loudly, with a reason the AP team can act on, rather than failing silently.

Decide who owns the inbound queue. With the SuiteApp, converted documents wait for someone to review and convert them, so name the person in AP who checks it daily, and agree what happens when a document fails validation. Clean master data helps too: for PEPPOL, each German customer and vendor needs its PEPPOL ID and e-document package set on the E-Document subtab.

Watch for a common gap: suppliers who still email a PDF. From 2027, larger suppliers must send a real e-invoice, so AP needs a clear process for asking for one.

Issuing: numbering and content

The content rules for invoices haven't changed. Each invoice still needs a sequential number that identifies it uniquely, as §14(4) UStG requires. In NetSuite, check that the German subsidiary uses its own numbering and that manual overrides are locked down.

Find out which formats your German customers can receive. Many will accept XRechnung or ZUGFeRD by email; some will expect PEPPOL. Your output has to match what they can process.

Tax codes, DATEV and archiving

Tax. SuiteTax codes should cover the 19% and 7% rates under §12 UStG, EU intra-community supplies and §13b reverse charge, each posting to the correct control account. Map the chart of accounts, SKR03 or SKR04, cleanly. The e-invoice simply carries what your tax setup produces, so errors there show up on every document.

DATEV hand-off. Many German subsidiaries hand their books to an external Steuerberater who works in DATEV. Agree the export format, account mapping and timing with them early.

Archiving. Invoices must be kept for eight years for VAT purposes under §14b UStG. For an e-invoice, at least the structured part must be kept unaltered in its original format, even if you also received a PDF copy (LfSt Bayern). The GoBD rules on electronic records also apply, and the BMF updated them for e-invoices in its letter of 14 July 2025. Check with your adviser how this applies to your records.

German e-invoicing checklist for NetSuite

1. Confirm the German entity can receive, validate and post XRechnung and ZUGFeRD invoices today.
2. Work out which issuing deadline applies, from 2026 turnover: 1 January 2027 or 1 January 2028.
3. Install the European Union Electronic Invoicing SuiteApp in sandbox and test it against real invoices and the known limitations.
4. Clean up SuiteTax codes, EI PEPPOL tax categories and the SKR03 or SKR04 mapping.
5. Check invoice numbering is unique and sequential for the German subsidiary.
6. Ask your main customers which formats and channels they can receive.
7. Agree the DATEV export with your Steuerberater.
8. Confirm the original XML is archived for eight years, and that you can find it.

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 deadline becomes a straightforward extension rather than a scramble.

To see receiving, validation and rejections handled in one place, try the E-Invoicing Control Centre demo or read about my NetSuite e-invoicing and tax reporting service. For the wider German set-up, see NetSuite in Germany, and for other countries' deadlines, NetSuite e-invoicing by country. On a German marketplace launch, the luxury menswear case study shows how German VAT was handled with Avalara.

Need your German entity ready for the 2027 issuing deadline? Book a free call and we'll talk it through, with no obligation.

Originally published at suiteheroes.com.

A NetSuite Fortnox integration solves a common two-ledger problem. Your group runs NetSuite OneWorld, but the Swedish subsidiary keeps its books in Fortnox, a widely used Swedish accounting platform. The Swedish team needs Fortnox for local invoicing and statutory reporting. The group needs everything in NetSuite. The answer is a disciplined, bidirectional integration: Fortnox stays the local system of record, NetSuite stays the group ledger, and every transaction can be traced across both.

I built exactly this for Cape.io, a native SuiteScript 2.1 integration between NetSuite and Fortnox across an eight-subsidiary OneWorld estate. This article sets out how I approach it: what to sync, how to map it, what the Fortnox API expects, and what to check before go-live.

Why a NetSuite Fortnox integration comes up

Fortnox is deeply embedded in Swedish accounting practice. Swedish finance teams, and often their external accountants, know it well. 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.

There is a local reason to keep that bridge tidy. Under the Swedish Bookkeeping Act, accounting records must be kept until the end of the seventh year after the calendar year in which the financial year ended, and kept in Sweden unless specific conditions are met (Bokföringsnämnden on archiving, Bokföringslag 7 kap.). Which system holds which record matters, so agree it with the Swedish team and their adviser at the start.

If the subsidiary sells to the Swedish public sector, e-invoicing is also a requirement. Suppliers must send e-invoices to public bodies for purchases under procurements started from 1 April 2019 (Upphandlingsmyndigheten).

If you are still deciding whether to keep Fortnox at all, my NetSuite in Sweden and the Nordics page covers the wider picture. This article assumes Fortnox stays.

What to synchronise

A complete integration covers six core record types in both directions, with full create, update and cancel handling:

• Customers
• Suppliers
• Sales invoices
• Credit memos
• Journals
• Customer and supplier payments

For each one, decide which system is the master and which direction data flows. On the Cape.io build, the admin console shows this per record type, inbound, outbound or both, so finance can see the rules without reading code.

Sales invoices raised in NetSuite can be issued through Fortnox, with the Fortnox document number stamped back onto the originating NetSuite transaction. That one field gives you end-to-end traceability: from any NetSuite invoice you can find its Fortnox twin, and the reverse.

The mapping discipline that makes finance trust it

The mapping layer is what separates a robust integration from a fragile one. I keep the mappings in custom records, created under Customization > Lists, Records & Fields > Record Types, so finance can maintain them without a developer.

Chart of accounts

Every NetSuite GL account maps explicitly to its Fortnox counterpart, including VAT and tax control accounts. On Cape.io that meant 256 accounts, maintained one by one or by bulk import. Unmapped accounts must fail loudly with an actionable error, never fall back silently to a suspense account. That discipline is what lets the Swedish statutory accounts reconcile line by line for Skatteverket.

VAT and tax codes

VAT codes need the same treatment, on both the customer and supplier side, so amounts reconcile precisely and post to the correct control accounts in both systems. Sweden's main rates are 25%, 12% and 6%, plus reverse charge and exports.

Build the VAT mapping with effective dates. Swedish rates do change: Skatteverket confirmed that VAT on food fell from 12% to 6% from 1 April 2026, while restaurant services stayed at 12% (Skatteverket). A mapping table with no dates either breaks or posts the wrong rate when that happens. Agree the VAT treatment itself with your Swedish tax adviser; the integration should only carry it faithfully.

Currency and payment terms

Every inbound and outbound handler should set the currency code and exchange rate explicitly for non-SEK transactions, from a currency mapping record. Payment terms need aligning across the receivables and payables sub-ledgers too, or due dates drift between the systems.

Designing for the Fortnox API

A sound design starts with how Fortnox's API actually behaves. Three points shape the build.

Authentication. Fortnox uses the OAuth 2.0 authorisation code flow. An access token lasts one hour and a refresh token 45 days. Each refresh issues a new refresh token and invalidates the old one, and if the refresh token expires, a user has to authorise the integration again (Fortnox authorisation). In NetSuite, keep the client secret under Setup > Company > Preferences > API Secrets (Oracle: secrets management), let one process own token refresh, and alert someone well before the 45 days run out.

Rate limits. Fortnox allows 300 requests per minute per client ID and tenant, enforced as 25 requests in a sliding five-second window. Over the limit, it returns HTTP 429 (Fortnox rate limits). Bulk syncs and month-end catch-ups need throttling and back-off built in, not added after the first failure.

Change detection. Fortnox offers a WebSocket stream with topics such as invoices and supplier invoices (Fortnox WebSockets). SuiteScript's N/https module makes request-and-response calls rather than holding a connection open, so a native build usually polls Fortnox on a schedule instead. On Cape.io, scheduled scripts poll for changes and Map/Reduce scripts handle bulk syncs.

Echo-loops and idempotency

Bidirectional syncs have a typical failure mode. A record updated on one side is picked up as a fresh change on the other, sent back, and the two systems ping-pong forever.

The fix is last-sync hash stamping on every inbound handler. When the integration writes a record, it stores a hash of what it wrote. When it next sees that record, it compares hashes and ignores its own echo. Combine that with external IDs, so a retried run updates the existing record instead of creating a duplicate.

Native, not iPaaS

This is precisely the kind of finance-critical, audit-exposed integration where a native SuiteScript 2.1 build pays off. You get full control over mapping and retry behaviour, no iPaaS licence fees, and every log line inside NetSuite. I compare the two approaches in native SuiteScript vs iPaaS for NetSuite integrations.

The Cape.io architecture used each script type for its job: Map/Reduce for bulk syncs, Scheduled for pollers, User Event for create and update triggers, RESTlet for inbound calls, Suitelet for the admin dashboard and Client Script for form validation. Long runs show on Customization > Scripting > Map/Reduce Script Status (Oracle).

An admin dashboard turns the integration from a script into something a finance team can operate. On Cape.io, one Suitelet covers OAuth 2.0 token management, COA, currency, VAT and payment-terms mapping, and run and queue monitoring. You can see the idea in the Integration Control Tower demo, and the full build in the Cape.io case study.

Go-live checklist

Before you switch a NetSuite Fortnox integration on in production, check:

1. Every record type has an agreed master system and direction, signed off by group and Swedish finance.
2. Every NetSuite GL account used by the Swedish subsidiary has a Fortnox mapping, and an unmapped account stops the record with a clear error.
3. VAT mappings cover sales and purchases, reverse charge and exports, each with an effective date.
4. Token refresh runs on a schedule, and someone is alerted if it fails.
5. Throttling keeps bulk runs under 25 requests per five seconds, with back-off on HTTP 429.
6. Echo-loop hashes and external IDs are tested by editing the same record on both sides.
7. Opening balances and open items reconcile between the systems before the first live run.
8. Finance can see failed records, the reason, and how to reprocess them, without asking a developer.

For a wider plan covering scoping, testing and sign-off, see running a NetSuite integration project.

The outcome

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

If you need this built, my NetSuite integration services cover design, build and support. If an existing integration is already failing, the Integration Rescue Sprint fixes the causes at a fixed price.

Planning a NetSuite Fortnox integration, or fixing one that keeps failing? Book a free call and we'll talk it through, with no obligation.

Originally published at suiteheroes.com.