For Australian finance, operations and IT leads who want each NetSuite change built once, tested properly and working after every release.
Last reviewed: 12 November 2026. Product details reflect this review date. Availability and behavior can vary by account, role and release.
NetSuite customization in Australia works best when every request passes a short checklist before anyone writes code. Test standard features and the ANZ Localization SuiteApp first. Then scope the script, its owner, its tests and its release plan. A request that clears these checks is cheaper to build and much easier to support.
NetSuite customization is a change to standard records, forms or behavior. This checklist focuses on changes that need SuiteScript, NetSuite's scripting language based on JavaScript. Configuration is different. It means setting up fields, forms, roles, saved searches and workflows with the tools NetSuite already gives you.
The line matters because each side carries a different cost over time. Configuration is maintained by an administrator. A script is maintained by a developer, and it must be tested every release.
| Need | Start with | Move to code when |
|---|---|---|
| Capture extra data | Custom field on the record | The value must be calculated from several records |
| Make a field mandatory | Custom entry form | The rule depends on other values in a way a form cannot express |
| Route an approval | SuiteFlow workflow | Routing needs lookups or loops a workflow cannot do cleanly |
| Report on data | Saved search or SuiteAnalytics workbook | The output is a file in a format NetSuite does not offer |
| Change a document layout | Advanced PDF/HTML template | The document combines data from many unrelated records |
| Talk to another system | A SuiteApp or connector | Standard APIs cannot meet the requirement, so a custom interface is justified |
Australian businesses usually need code for a few things. Pricing rules that read many lines are one. Others are bulk jobs over thousands of records, links to a local system with no connector, and screens built for one team's task. Everything else deserves a hard look at the standard tools first.
Our post on the NetSuite configuration or customization decision covers that choice in more depth.
Many requests we see in Australian accounts ask for something NetSuite already does through the ANZ Localization SuiteApp. Check this list against the request before you scope any work.
Report support depends on whether your account uses SuiteTax. Confirm which reports your setup offers before anyone promises a BAS or TPAR output.
A hypothetical example shows why this step comes first. A Melbourne wholesaler asks for a script that rejects invalid ABNs when users save vendor records. The administrator selects Warn and Block in the ABN Verification Warnings preference. Testing confirms that invalid numbers stop the save.
This closes that specific request without code. Missing ABNs need a separate review because withholding rules and exceptions may apply.
A second request from the same wholesaler does need code. Sales wants a quarterly rebate worked out from every invoice line for 40 customers. The team tests standard searches and workflows against the calculation, then scopes a map/reduce script if those tools fall short. The sales director becomes the owner, and four acceptance tests are written before the build starts.
Run every request through these twelve items in order. If an item fails, stop and fix it before you move on. A request that clears all twelve is ready to build.
Oracle ships two major NetSuite releases each year. Before each upgrade, your administrator can request a Release Preview account at Setup > Company > Release Preview. It runs the new version against a copy of your account, so you can test your scripts before the upgrade reaches production.
A simple routine keeps release weeks calm for an Australian team.
Plan these weeks around your own calendar and time zone. A team in Perth and a team in Sydney may need different test windows. A release that lands near a BAS filing or end of financial year needs testing finished earlier, because finance will have little spare time. Our post on NetSuite optimization in Australia suggests a quarterly review rhythm that fits the same calendar.
Cost depends on the script type, the records it touches and the testing it needs. A fair quote comes after the standard fit test, not before. Ask for each request to be priced on its own with its acceptance tests attached. Then you can weigh code against a workflow or a process change.
You do not always need a developer on staff. They need an administrator who owns configuration and a partner who builds and supports scripts on request. What you do need in house is a business owner for each script and a current inventory. That way the knowledge stays with you if a person or a partner changes.
A workflow is configuration in the sense that an administrator can build it without code, but it still changes how records behave. Treat it like a script for ownership and release testing. Give it an owner, a one line purpose and a test, and add it to the same inventory as your scripts.
Start with ANZ Localization, which supports BAS with SuiteTax and TPAR using vendor and payment fields. Check support for your tax setup first. When a figure looks wrong, inspect the tax codes and reporting flags before changing the output. Fix the data first and confirm the treatment with your BAS agent or tax adviser.
At CuriousRubik, we run the standard fit test with you before any code is quoted. Our NetSuite customization team builds, tests and documents scripts so they survive each release. We work with companies across Australia, from single entity wholesalers to groups running several subsidiaries.
How to decide whether a requirement belongs in configuration or in code.
How to list every script, workflow and custom record with an owner and a purpose.
Why a quarterly review timed to BAS and releases keeps an Australian account healthy.