NetSuite ERP Consultant common mistakes
NetSuite ERP Consultant · Understand the traps and how to avoid them.
Treating a transaction's posting period as determined by its transaction date, and assuming changing the date moves the GL impact.
Candidates learn that transactions post to the period containing the date, then forget that NetSuite defaults the posting period from the date but allows it to be overridden, and that period-close locking and the 'Allow Non-GL Changes to Closed Periods' preference change what is even possible. Exam items probe the gap between date and period.
What to do instead
For every accounting-impact question, explicitly identify three things: transaction date, posting period field value, and whether the period is closed or locked (A/R and A/P lock, all-areas lock). Practice by taking one invoice, setting the period to a different period than the date, and observing the GL Impact page and the period-close checklist behaviour.
Assuming a journal entry or transaction can always be edited or deleted after approval, rather than reasoning about the specific blocking mechanism.
The UI hides or greys out actions without explaining why. The real causes are distinct: period closed or locked, transaction approved and the 'Restrict' preferences enabled, transaction has applied payments or is in a closed accounting cycle, or the record is a system-generated reversal. Candidates conflate all of these into 'it's locked'.
What to do instead
Memorize the separate levers: Accounting Preferences restrictions on editing/deleting approved transactions, period lock types, and the reversal/void mechanics. For each practice scenario, state which single lever blocks the action and what the supported workaround is (void, reversal, or adjustment in an open period).
Mixing up item types and their inventory/COGS behaviour, for example expecting a Non-Inventory for Sale item to affect quantity on hand or a Service item to create a fulfillment.
Item type names are intuitive-sounding but the accounting and fulfillment behaviour differs in ways not visible on the item record. Candidates pick the type by name rather than by the downstream transactions it generates (fulfillment, receipt, COGS posting, asset account).
What to do instead
Build a one-page matrix of item types (Inventory, Non-Inventory for Sale/Resale, Service, Kit/Package, Assembly, Group) against: tracks quantity, requires fulfillment, posts COGS, uses asset account, appears on purchase orders. Rehearse which transactions each type permits before answering.
Confusing the fulfillment/receipt/billing sequence and guessing which transaction moves inventory and which moves the GL revenue or expense.
Order-to-cash and procure-to-pay involve several records, and the GL impact is split: item fulfillment posts COGS and relieves inventory, while the invoice posts revenue and A/R. Candidates assume the sales order or the invoice alone drives inventory.
What to do instead
Trace both flows end to end on paper: Sales Order → Item Fulfillment (inventory out, COGS) → Invoice (revenue, A/R); Purchase Order → Item Receipt (inventory in, accrued receipt) → Vendor Bill (A/P, accrual reversal). For each step, write the debit and credit accounts from memory, then verify in a sandbox.
Answering procurement questions as if a purchase order commits inventory or creates a payable.
A PO is a commitment, not a posting event. Candidates who have seen the PO screen but not the receipt/bill chain assume approval of a PO affects stock or the GL. Related trap: expecting a Vendor Bill to be required before inventory is received.
What to do instead
State explicitly for each procurement document what it does and does not post: PO (no GL, no quantity on hand), Item Receipt (inventory in, accrued liability), Vendor Bill (A/P, expense or accrual clearing). Also learn the 'Bill in Advance of Receipt' and 'Receive in Advance of Bill' variants and how they change the accounts.
Assuming a custom field, custom record, or workflow is automatically available everywhere, ignoring role permissions, form assignment, and subsidiary or department restrictions.
SuiteBuilder makes creation easy, so candidates assume global visibility. In practice the field must be added to the form, the role needs permission to the record and field, and restrictions (subsidiary, department, class) can hide it. Exam items test why a user cannot see a field that 'exists'.
What to do instead
For any customization question, run a checklist: is the field on the specific form used by that role, does the role have the record-level and field-level permission, and is the record or field restricted by subsidiary or other classification? Learn the difference between 'Display Type' (normal, disabled, hidden, inline) and actual permission-based invisibility.
Writing or reasoning about SuiteScript as if client scripts can load records server-side or as if user event scripts run on every trigger indiscriminately.
Candidates blur the execution contexts. Client scripts run in the browser and cannot use server-only modules; User Event scripts fire on create/edit/delete (and approve, depending on configuration) and must return true from beforeSubmit or the write is aborted. Governance limits also differ by context.
What to do instead
Memorize the script-type table: Client (browser, no N/record server modules, fieldChanged/saveRecord entry points), User Event (server, beforeLoad/beforeSubmit/afterSubmit, must return true), Scheduled, Map/Reduce, RESTlet, Suitelet, Workflow Action. For each, note governance units and whether it can call record.load. Practice one small script per type.
Treating integration as a single mechanism and not distinguishing SuiteTalk (SOAP/REST web services), RESTlets, CSV import, and SuiteCloud Connect/SFTP flows when answering 'how should this integrate' questions.
All four 'move data in and out', so candidates default to the one they have heard of. The correct answer depends on volume, real-time vs batch, authentication model (token-based auth, OAuth 2.0), and whether the source system can speak SOAP/REST.
What to do instead
Build a decision table: real-time record CRUD from an external app (SuiteTalk REST/SOAP with token-based auth or OAuth 2.0), custom endpoint logic (RESTlet), bulk scheduled data (CSV import or SFTP with a scheduled script), and file-based partner exchange. Learn which supports asynchronous processing and which is subject to governance and concurrency limits.
Confusing saved searches, reports, and SuiteAnalytics Workbook capabilities, and choosing a tool that cannot do the requested grouping, formula, or charting.
The three overlap, and the UI has moved features between them over releases. Candidates pick saved searches for things needing multi-level pivots or pick workbooks for things needing a custom formula field, or forget that summary searches need the right summary type.
What to do instead
Learn the boundaries: saved searches for record-level filters, formula fields, and reusable lists; reports for formatted financial statements and standard layouts; workbooks for pivots, charts, and multi-dataset analysis. Practice building the same metric three ways and note where each fails, especially around formula (numeric/currency/date) fields and summary types.
Answering multi-subsidiary and multi-currency questions as if all records, accounts, and transactions behave the same across subsidiaries.
Candidates study on a single-subsidiary account and never internalize that accounts, items, and even some preferences are subsidiary-restricted, that intercompany transactions need elimination, and that currency conversion uses the exchange rate on the transaction date with base-currency translation for reporting.
What to do instead
For every financial or customization question, ask: is this account/item/record restricted to one subsidiary? Does the transaction cross subsidiaries (intercompany) and require an elimination? Which currency is the transaction in versus the base currency, and which rate applies? Rehearse the OneWorld settings (subsidiary hierarchy, intercompany preferences, currency exchange rate types) before answering.