Fix or reimplement?
Fix NetSuite one area at a time, and reimplement only the areas whose books cannot be proved from source documents.
When a team asks "NetSuite fix or reimplement?", it usually means the whole account. That framing makes the choice harder than it needs to be. A broken accounts receivable (AR) report and a broken item model are different problems, and lumping them together makes everything look like a rebuild.
A full restart is the exception, in VCG's view. It fits when the chart of accounts, the subsidiary structure or the item and unit model cannot carry the business. Everything else is a question about one area at a time.
Three options, not two
Most discussions offer two choices. There are three, and the middle one can be the cheapest path that works.
| Option | What it means | What you keep |
|---|---|---|
| Fix in place | Correct configuration, scripts, workflows and reports in the live account | Everything |
| Targeted rebuild | Tear down and redo one layer, such as items, warehouse apps or revenue recognition | The account, its history and most screens |
| Reimplement | Redesign the account and reload its data, in a fresh account or over the existing one | Very little beyond the data you migrate |
The test in one line
For each area, the general ledger (GL) balance should equal the subledger, plus differences you can explain, plus whatever is left unexplained:
GL = subledger + explained differences + unexplained
A subledger is the detail behind a GL account, such as the list of open invoices behind the AR balance. The rest of this article shows how to run that line for each area and what to do with the answer.
Where the problem sits
Before deciding anything, sort each complaint into software, configuration or code, process, or partner, because each needs different evidence.
Software
Check the requirement against Oracle's Help Center and against what you actually license. If you bought a SuiteSuccess package, compare the requirement with what the package includes. Oracle describes SuiteSuccess as a model with predefined industry and role components, including roles, saved searches, reports, KPI scorecards and the chart of accounts (Oracle: SuiteSuccess).
A real product gap is less common than it feels on a bad month-end.
Configuration or code
Errors that look like "the system is wrong" are often small defects. Three examples, generalised from VCG's work:
- A multi-select field returns comma-separated ids, a lookup compares them with strict equality, every price lookup misses, and a price column stays at zero. The fix is one line.
- One data source returns cost per base unit and another returns it per stock unit. The result is a silent 1000x error in cost or quantity.
- Reports are built on SuiteQL, NetSuite's SQL-style query language, and the queries silently stop at 5,000 rows, so two reports disagree on the same number. Paging the query to the end is a cheap fix that can restore trust quickly.
Process
Some failures live in how people work. If staff still key transactions into the old system, two systems hold half the truth each.
Approvals can reach a record by two routes, such as an emailed link and the record itself. A control built into one route never runs for the other. Count the entry points for each control before you trust it.
Partner
Partner trouble shows up in the evidence, not in the status reports. Ask for the tie-out on one closed period and for an inventory of deployed scripts. If neither can be produced, or the month-end still needs a manual adjusting journal to balance, that is a strong sign the partner cannot show what was built.
Is NetSuite the wrong system?
The implementation, rather than the platform, is often the problem, though that has to be tested rather than assumed. A real platform gap looks like this:
- A regulatory or industry need with no native feature and no SuiteApp path after review
- A process the standard records cannot model, even with configuration
- A volume or structure the account design cannot carry
SmartLam is a published example. NetSuite's standard warehouse apps had no processes for cutting, grading and gluing lumber. SmartLam rebuilt its items and replaced the standard warehouse apps with 17 custom ones, and its finance setup was mostly in place. It went live (SmartLam case study).
Prove each area against the GL
Run the tie-out area by area for a closed period, and let the unexplained amount, and nothing else, decide fix or rebuild.
The areas to test
- Accounts receivable (AR): open invoices against the AR control account
- Accounts payable (AP): open bills against the AP control account
- Inventory: inventory valuation against the inventory asset accounts
- Revenue: deferred and unbilled revenue balances in Advanced Revenue Management (ARM), NetSuite's revenue recognition module, against their GL accounts
- Amortization and prepaid expenses: schedule balances against the prepaid accounts
- Fixed assets: the asset register against the asset and depreciation accounts
- Intercompany: balances between subsidiaries against each other
How to run it
- Pick the last closed period and take the GL balance for each account in the area.
- Total the subledger for the same accounts and the same date.
- Name every difference by class: manual journal, reclass (moving an amount between accounts) or timing. Carry it with its amount.
- Whatever you cannot name is the unexplained amount. Only that amount is a problem.
Decision rules
The answer falls into one of three cases, and each has its own remedy.
| Result | Verdict |
|---|---|
| The area ties | Fix the reports or processes built on top |
| It ties once the differences are named | Fix the named cause in place |
| It cannot be tied from source documents, or its master data is inconsistent | Rebuild that area |
Bad balances are often not bad data
VCG's consultants rebuild open AR and AP from source documents and their application links, the records that show which payment or credit settled which invoice.
In VCG's experience, open lines rebuilt this way often match NetSuite's own unpaid amounts. The transactions were sound, so the problem sat in how the balances were reported or applied, not in the data. That points to a fix, not a clean reload.
Revenue breaks are often a multi-account problem
VCG's consultants often find that revenue which "doesn't tie" is spread across more than one account, and the arrangements themselves are fine.
If an item's deferral account was changed, billing credits one deferred revenue account while recognition debits another. A tie for each account on its own then shows a false break. Tie across the whole deferred and unbilled scope instead, including any long-term deferred revenue held on a different account type.
Stale manual month-end accruals cause a second common break, because they double against ARM's own reclass. The deferred revenue reconciliation guide walks through the tie in detail.
Static residue from an earlier system
Deferred revenue carried over from an acquired company or an earlier system often lived outside ARM, in opening-balance journals or monthly trial-balance uploads. Once that revenue moves into ARM, it can leave a static residue behind.
Look for accounts whose activity stopped on a given date. Plan a named cleanup of that residue. It is not evidence that ARM was set up wrongly.
A worked example
The table below is a fictional distributor. All figures are synthetic.
| Area | GL balance | Subledger | Explained | Unexplained | Verdict |
|---|---|---|---|---|---|
| AR | 4,212,000 | 4,198,500 | 13,500 reclass | 0 | Fix the report |
| AP | 1,870,400 | 1,861,900 | 8,500 timing | 0 | Fix the named cause |
| Inventory | 3,050,000 | 2,610,000 | 120,000 manual journal | 320,000 | Rebuild items |
| Deferred revenue | 940,000 | 1,015,000 | -75,000 second deferred account | 0 | Fix in place |
Three of four areas are fixes. The inventory gap traces to items set up with inconsistent units, so the item master gets rebuilt and the rest of the account stays.
When structure is the problem
Sometimes the tie-out points at the foundation. The chart of accounts, the subsidiaries, or the item and unit master data cannot produce the reporting the business needs. That is the honest case for a deeper rebuild, and it is the only case where a full reimplementation earns its cost.
What is salvageable
Start from what is deployed in the account, then keep what ties and has an owner.
Inventory the live account first
The handover document and the old partner's code repository describe the account someone meant to build. Query the script and script deployment records in the account itself, including scripts installed by bundles and SuiteApps.
The repository can be ahead of production or missing pieces. In one VCG engagement, a shared library had never been deployed, so every script importing it failed. The first two weeks of a rescue covers the read-only inventory method step by step.
Confirm which account you are touching
Before anyone changes anything, confirm which production and sandbox account a project actually points at. An id that looks wrong may be right, and one that looks right may be wrong.
Check the sandbox refresh date too. Rows created after the refresh are test data, and counting them will mis-size a rebuild.
Workflows
VCG's standard for a SuiteFlow workflow (NetSuite's no-code workflow tool) is at most six states, and more than eight means the logic belongs in a script library.
In one account VCG reviewed, an approval workflow had 13 states, each approver and validation step modelled as its own state. VCG's replacement did more with six states by holding the approval chain as data and letting a script advance it. If adding one approver means adding a state, replace that workflow in place. That is a scoped fix.
Controls
Ask which checks run server-side, meaning on NetSuite itself rather than in the user's browser, before the record is saved. A validation in an after-save script (code that runs once the record is stored) prevents nothing, because the record is already saved. A control that trusts a number sent from the screen can be bypassed.
An example from VCG's work, generalised: an over-receipt cap trusted a remaining quantity sent from the screen. The fix was one server-side guard that reloads the purchase order line and caps receipts, shared by desktop and mobile receiving.
What cannot be read
Some parts of a setup cannot be read from outside. In some accounts and roles, amortization schedules, classic revenue recognition schedules and their templates were unreadable, and the template behind an existing schedule could not be recovered.
Role permissions decide this. An honest assessment lists what it could not read and why.
A rule of thumb for scripts
- Keep what ties and has an owner.
- Rewrite what is defective but well placed.
- Retire what nothing calls.
Opening balances and history
Run the same tie-out on opening balances, because a load that reported success can still hide gaps.
Check the clearing accounts
Migrated open items and balances are normally loaded against clearing accounts, temporary holding accounts used during a data load. Those accounts should end at zero. A balance left in a clearing account is a difference you must explain before sign-off.
The load method can hide gaps
VCG's consultants have seen three ways an old load looked fine and was not:
- CSV import skipped mandatory fields; hundreds of imported vendors lacked fields a custom vendor form later required, so those records were rejected.
- Custom segments not applied to a record type were dropped silently.
- Budget loads replaced rows by key, class was part of that key, and the posted currency was ignored.
Problems like these surface only when later automation touches the records, which is often months after go-live.
Audit exposure
Auditors ask how each number was calculated. If finance cannot trace a balance to source documents, that area carries the risk.
Cyderes faced this with revenue numbers finance could not trust and an external audit coming. Its ARM configuration was rebuilt so every recognized amount traced back to its order and invoice, and the revenue numbers held up at audit (Cyderes case study).
This is not legal or audit advice. Talk to your auditor early about any area you plan to rebuild.
Fix versus reimplement cost
Leave out what you have already spent, and compare only the forward cost of each path, area by area.
There is no reliable benchmark
No reliable public benchmark for rescue or reimplementation cost turned up, so none is used here. The only dependable figure is your own forward cost, built area by area.
Sunk cost
What you already paid is gone on either path. It belongs in the lessons learned, not in the decision.
Forward cost of fixing
Count the areas that failed the tie-out and estimate the effort for each. Add testing: Oracle ships two major NetSuite releases a year, and VCG tests each fix in a sandbox before an upgrade.
Forward cost of reimplementing
A reimplementation carries more line items than people expect:
- Design and build services
- Data migration and reconciliation
- Re-testing every integration
- Retraining users
- A period of parallel running
- A second cutover
- The risk of repeating the same load traps
Salvage value
Areas that already tie have value. A full reimplementation throws them away along with the broken ones.
Licences
Your subscription terms come from your contract with Oracle. Whether a new account or extra sandboxes change your fees is a question for your order form and your Oracle account manager. Check these items:
- Contract term and renewal date
- User and module counts
- Sandbox entitlement
- Any clause tied to opening a new account
A worksheet you can copy
One row per area keeps the decision honest. Fill in your own estimates; the blank cells are deliberate.
| Area | Verdict | Fix estimate | Rebuild estimate | Monthly cost of waiting |
|---|---|---|---|---|
| AR | Fix | |||
| AP | Fix | |||
| Inventory | Rebuild items | |||
| Revenue | Fix | |||
| Total |
The cost of standing still
Price the workarounds each month, because waiting has a cost that rarely appears in the decision.
What to count
- Hours of manual reconciliation
- Monthly adjusting journals
- Reports rebuilt in spreadsheets
- Extra close days
- The staff time all of these take, at a loaded hourly rate
A synthetic estimate
Assume 60 hours a month of manual reconciliation, 25 hours rebuilding reports in spreadsheets and 15 hours preparing adjusting journals. At an assumed loaded rate of 85 dollars an hour, those 100 hours cost 8,500 dollars a month, or 102,000 dollars a year. This is an estimate built on those assumptions only.
A synthetic comparison
Take the inventory gap from the worked example. Assume fixing the item master takes 120 hours and a full reimplementation takes 900 hours, both at the same assumed 150 dollars an hour. That is 18,000 dollars against 135,000 dollars. The rebuild also puts AR, AP and revenue, which already tie, back through design and testing. These hours are invented to show the method, not a quote.
What a fix gives back
Cyderes' billing setup went from about an hour per order to about 15 minutes, which returned roughly 2,200 hours of finance time across nearly 3,000 orders (Cyderes case study).
The risk cost
An audit, an acquisition or a new subsidiary can land on numbers nobody can prove. That cost is harder to price, and it tends to arrive at the worst moment.
Timelines and month-end close
The number of areas that fail the tie-out drives the timeline, and each path treats the close differently.
No reliable public benchmark for rescue or reimplementation duration turned up, so treat any universal timeline with suspicion. Ask any partner for a duration per area, not one number for the account.
Fixing keeps the close running
The close keeps running in the same account. Schedule changes between closes and freeze changes during close.
When you replace a workflow, release the new one and inactivate the old one in the same deploy. Leaving both active gives double approvals or conflicting states.
Reimplementing needs parallel running
Plan for a period of parallel running. Decide in advance which system is the book of record for each month, and write it down.
Close effort by path
| Path | Effect on the close |
|---|---|
| Fix in place | Normal close; changes wait until after sign-off |
| Targeted rebuild | Normal close for untouched areas; the rebuilt area is checked by hand once |
| Reimplement | Two books for the parallel period, then a cutover month with extra checking |
Cutover rules that held up
These rules come from VCG's migration work:
- Cut off by posting period, never by transaction date. Source systems hold transactions dated outside their period.
- Check every load file against the target's reference data: missing, inactive, wrong subsidiary or closed period. Refuse to load on any problem.
- Load open items against clearing accounts, and make those accounts end at zero.
- Do not let native loads double balances that history journals already carry. An open invoice on an item with a revenue rule creates new revenue elements.
The double-billing trap
Scope open sales orders by the unbilled remainder on each line, never by order status.
In one migration VCG ran, most "Pending Fulfillment" and "Partially Fulfilled" orders were already fully invoiced. A plan that loads by status would have billed them twice. A partly billed line also needs its billing start set to the first unbilled period, or the periods already billed are charged again.
Partners and second opinions
Change partners when nobody can say what is deployed or why the books do not tie, and keep the evidence either way.
Replacing everyone is one option. Adding an independent lead alongside the current team is another, and sometimes the less disruptive one.
Handover checklist
- Administrator access
- The statement of work and every change order
- The issue log
- The code and the list of deployed scripts
- Integration credentials, moved to your own vault
- Sandbox access
- The test evidence for anything called done
Holding a partner to account
Read the statement of work's acceptance criteria, the change orders and any warranty clause. Keep the tie-out results as evidence. Get legal advice before pursuing any recovery, because the outcome depends on your contract.
What a second opinion should hand over
- Tie-out results for each area
- An inventory of deployed scripts
- A fix or rebuild verdict for each area, with reasons
- A list of what it could not read, and why
Cost and length depend on how many areas and integrations are in scope. Ask for a fixed scope, a pricing basis (fixed fee or per area) and a named list of deliverables. Expect to provide read-only administrator access and one closed period to test.
What users will relearn
Fixing in place keeps the screens people know, a full rebuild retrains everyone, and a targeted rebuild changes one team's tools.
Fixing keeps saved searches and habits intact, and trust returns once the numbers tie. A full rebuild risks the same adoption problem twice.
SmartLam rebuilt its items and replaced the standard warehouse apps; its finance setup was mostly in place.
NetSuite's WMS felt like it was built for a different industry. VCG scrapped it and built us something custom that works the way our lumber business actually runs. Our warehouse team went from fighting the system to trusting it.
Director of Operations, SmartLam
Train on the changed area only. Use real month-end transactions in the sandbox, not demo data.
Quick answers
These are short answers to the questions finance leaders ask most often about a failing implementation.
What percentage of ERP implementations fail?
Gartner predicts that by 2027 more than 70% of recently implemented ERP initiatives will not fully meet their original business goals, and that up to 25% will fail catastrophically (Gartner: What IT Leaders Must Do to Avoid Disappointing ERP Initiatives). That is a prediction, not a measured failure rate.
What are the warning signs of a failing implementation?
The trial balance ties only after a manual adjusting journal each month. Two reports disagree on the same number. Nobody can produce an inventory of deployed scripts.
What is a NetSuite rescue?
A NetSuite rescue is taking over an implementation that went wrong and getting it stable without throwing away what works.
What is a NetSuite reimplementation?
It is redesigning the account and reloading its data, in a fresh account or over the existing one.
How much does reimplementation cost?
It depends on scope, and no published benchmark is reliable. Use the forward-cost worksheet and the synthetic comparison above.
How long does a NetSuite implementation take?
No reliable public benchmark exists. Duration depends on how many areas fail the tie-out.
Can a failed NetSuite implementation be saved?
Often it can. SmartLam went live after a six-month stall by rebuilding its items and its warehouse layer (SmartLam case study).
When should you reimplement an ERP?
Reimplement when an area cannot be tied from source documents, or when the core structure cannot carry the business.
The practical next step
Pick one area, usually AR or revenue, and run the tie-out for last month's close this week.
If it ties, the account is probably fixable, and the job is to list the defects. If it does not tie, name the differences before anyone quotes a rebuild.
If several areas will not tie and nobody can explain why, you can book an assessment and we will run this test across the account.
