Level up your business with Advanced NetSuite Modules! Explore their powerful features tailored to streamline your operations after go live.
Most NetSuite implementations go live with the core in place and the interesting parts deferred. That is usually the right decision, because a project that tries to do everything at once tends to do none of it well, and because you cannot sensibly design a module you have never used the platform to run.
The problem is what happens next, which in most businesses is nothing. The deferred list becomes a document nobody opens, and two years later the business is running on the same core it went live with while paying for a platform that could do considerably more.
This article covers the modules and capabilities most worth revisiting after go live, what problem each solves, and how to work out which are worth it for your business.
Before considering any specific capability, it is worth being clear about the method, because the businesses that get this wrong buy modules they do not need.
The useful starting point is the manual work that survived your implementation. What is still done in a spreadsheet. What gets rekeyed between screens. What takes a person a day every month that a system should handle.
That list, ranked by hours consumed, tells you which capability to look at. Working the other way round, starting from what is available and asking whether you want it, produces expensive shelfware.
It also gives you a business case, because the hours saved are countable and the person who currently spends them can tell you exactly what they would rather be doing with that time.
Most implementations go live with basic approval routing or with approvals happening outside the system entirely, by email.
The cost of that is invisible until you look for it. Approvals sit in inboxes, nobody can tell you what is waiting on whom, and the audit trail is a collection of forwarded messages that somebody has to assemble when asked.
Proper workflow moves the routing into the system, with rules based on amount, department, category or any other field, escalation when something sits too long, and a record of who approved what and when.
This is usually one of the cheapest improvements available, because it is configuration rather than customisation, and one of the most visible, because everybody involved in an approval notices the difference immediately.
The fixed asset register is one of the most common survivors of an implementation, usually as a spreadsheet maintained by one person who understands how it is built.
That works until it does not. Depreciation runs are manual, the register drifts from the ledger, disposals get handled inconsistently, and the whole thing depends on somebody remembering the logic.
An on platform register calculates depreciation, posts directly to the ledger, handles disposals and revaluations, and carries the same dimensional coding as everything else so asset cost by location or department is available without an export.
The case is strongest for businesses with a meaningful asset base, frequent additions and disposals, or a statutory audit, since the audit effort on a spreadsheet register is materially higher. Our piece on managing fixed assets on platform covers this in more depth.
AASB 16 put almost every lease on the balance sheet, and most businesses handle the resulting schedules in a workbook.
The initial calculation is straightforward. What breaks spreadsheets is everything afterwards, since leases get modified, indexed, extended and terminated, and each of those requires a remeasurement with treatment that depends on the type of change.
A native lease application maintains the register, calculates and maintains the schedules, generates the journals, handles remeasurements consistently, and produces the disclosure information that otherwise gets assembled by hand at year end.
Worth considering once the lease population is more than a handful, and worth considering urgently if the population changes frequently. Our piece on NetLease in NetSuite covers what that looks like.
Payroll running outside the ERP is the single largest source of routine reconciliation work in most finance functions, and almost nobody counts it.
Every cycle, somebody posts a journal, reconciles a clearing account and investigates the differences. Every month end, the same. And labour cost, usually the largest cost in the business, arrives in the ledger as a summary rather than as coded transactions.
Bringing payroll onto the platform removes the reconciliation entirely, because the pay run posts directly, and makes labour cost available by department, project or location at transaction level.
The migration is a real project rather than a switch, and for businesses with dimensional reporting requirements it is frequently the highest return move available. Our piece on on platform payroll covers the argument.
Businesses holding stock frequently go live with basic inventory and defer everything that makes it genuinely useful.
Landed cost is usually the first gap that matters, since freight, duty and handling belong in the value of the stock rather than in overheads, and getting it wrong misstates margin on every item you sell.
Serial and lot tracking is the second, required in regulated industries and useful anywhere recall or warranty matters.
Demand planning and replenishment is the third, replacing the judgement of whoever currently decides what to reorder with something that considers lead time, seasonality and existing commitments.
Each of these is a distinct decision and the sequence should follow the size of the problem rather than the order they appear in a feature list.
Services businesses commonly go live without proper project accounting and manage it in a spreadsheet alongside.
The consequence is that project profitability is estimated rather than known, because the labour cost is allocated rather than posted, and because the spreadsheet is updated whenever somebody has time.
Proper project costing captures time and expense against the project, applies real cost rates, and produces margin by project as a report rather than an exercise.
Where revenue recognition rules apply, the same records drive the recognition schedule, which removes another manual process and a common source of audit questions.
Most implementations handle the accounts payable end of the process and leave the front end informal.
The symptom is that spend is visible only after it is committed, since the first record in the system is an invoice rather than a request or an order.
Adding requisitions and purchase orders moves the control point earlier, so that spend is approved before it happens rather than reported after it did.
It also enables three way matching, which removes a substantial amount of manual checking in accounts payable and catches supplier errors that otherwise get paid without question.
The case is strongest where the business has grown past the point of one person knowing about every commitment, which happens earlier than most owners expect.
Almost every implementation leaves reporting incomplete, and it is the capability most worth revisiting first because it is cheap and it improves every subsequent decision.
Beyond the standard reports, the platform supports saved searches with formula fields, dashboards built per role, scheduled distribution, and reporting that reads live data rather than a periodic extract.
The gap is usually not capability but knowledge. Most organisations have one or two people who can build a report and everybody else requests one, which means most questions never get asked.
Investing in reporting capability, both the reports themselves and the ability to build them, changes the culture around information more than any individual module. Our report writing service exists for this gap.
The close is where the surviving manual work concentrates, and it is measurable, which makes it a good target.
The candidates are recognisable. Recurring journals entered by hand. Reconciliations performed in a spreadsheet and evidenced by a signature. Checklists tracked outside the system. Intercompany eliminations calculated manually.
Close management capability moves the checklist into the system, tracks who has done what, automates the recurring entries and holds the reconciliation evidence against the account.
The benefit is fewer days to close and, more usefully, a close that does not depend on one person's memory of the sequence.
Sometimes the answer is not a NetSuite module but a connection to something that already exists.
Where a specialist system genuinely serves a function better, integrating it removes the rekeying without forcing the business into a compromise it does not want.
The decision between integrating and replacing usually turns on how much the specialist system does that NetSuite would not, and on how much ongoing maintenance the integration will require.
Integrations are not free. They fail, they fail quietly, and somebody has to own them. That cost belongs in the comparison. Our guide to NetSuite integration covers the approach.
A short discipline before any addition prevents most of the disappointment that follows one.
Confirm the problem is real by measuring the current effort rather than estimating it. Ask the person who does the work how long it takes and how often.
Confirm that standard functionality does not already cover it, since a surprising proportion of gaps turn out to be configuration nobody switched on.
Confirm the data will support it, because a module fed by unreliable data produces unreliable output faster.
And confirm who will own it after go live, because a capability nobody owns degrades within a year and becomes another thing people work around.
Doing one thing properly beats doing three partially, and the order matters more than the list.
Take the largest source of manual hours first, regardless of how unglamorous it is, because that is where the return is and because it buys the capacity for everything after it.
Then take anything that is a compliance or audit exposure, since the cost of getting those wrong is not proportional to the effort of fixing them.
Then take the capability that unlocks a decision the business currently cannot make, which is usually reporting or costing depth.
And leave anything that is merely interesting until the list above is empty, which for most businesses means never, and that is the correct outcome.
Post implementation improvements compete for budget against everything else and they are frequently harder to fund than the original project.
The reason is that the original project had a clear narrative and a visible deadline, while an incremental improvement has neither.
What works is a business case built on hours, since hours are countable and everybody understands them. Four hours a month returned to a management accountant is a number a board can evaluate.
Where the case rests on risk rather than hours, name the exposure specifically. A spreadsheet based asset register with a single person who understands it is a concrete risk rather than a general concern.
And set aside a small annual allowance for improvement rather than seeking approval each time, since the administrative cost of approving a two day change frequently exceeds the change itself.
Every addition increases the amount of system there is to understand, which raises a question most businesses answer by accident.
Somebody internal needs to understand the configuration well enough to make routine changes and to judge when outside help is needed. Without that, each addition increases dependency rather than capability.
That person does not need to be technical. They need context, access and enough time to keep up with what the platform does.
Building that alongside the additions rather than afterwards is what separates businesses whose systems keep improving from those whose systems slowly stop fitting. Our guidance for system administrators covers the role.
The practical next step is not to evaluate a module. It is to spend an hour listing the manual work that survived your implementation and how long each item takes.
That list will point at two or three obvious candidates, with a business case already attached, and it will usually include at least one thing that turns out to be configuration rather than a purchase.
Our pieces on post implementation strategy and features you probably are not using cover related ground, and our managed services arrangement exists to keep this moving rather than leaving it to whoever has time.
If you would like help working out what is worth adding to your NetSuite environment, get in touch.
