Blog › ICP guides

NetSuite consultant on retainer: SuiteScript 2.0, SuiteFlow, multi-subsidiary configuration, and ERP advisory on monthly retainer

August 7, 2026 · ~20 min read

A 150-person software company with operations in three countries and four subsidiaries closes its books monthly using NetSuite OneWorld. The Controller reports three recurring problems: the intercompany elimination journal entries for intercompany receivables and payables between the US parent and the UK and Canadian subsidiaries require 6 to 8 hours of manual reconciliation each close cycle because the intercompany AR and AP accounts are not in balance by the time the consolidation reports run; the revenue recognition schedules for multi-element SaaS contracts were configured by a consultant two years ago and produce allocation amounts that the accounting team cannot reconcile to the standalone selling price methodology required under ASC 606; and the purchase order approval workflow stops routing approvals for POs above $50,000 when the approver is out of the office, with no delegation fallback, leaving high-value vendor commitments in pending status for days at a time. The company engages a fractional NetSuite consultant on monthly retainer to resolve the intercompany configuration, correct the revenue recognition setup, and redesign the PO approval workflow.

In month one: an intercompany configuration audit that traces the reconciliation gap to two specific problems — the intercompany clearing account used by the UK subsidiary for intercompany AP transactions is mapped to a different account than the intercompany clearing account the US parent uses for the corresponding intercompany AR transactions, producing a mismatch that accumulates to a $48,000 gap at consolidation; and the intercompany elimination rules are configured to eliminate by account pairing, but because the account numbers differ between subsidiaries, the elimination engine cannot match the transactions and passes them through to the consolidated balance sheet as uneliminated intercompany balances. The Controller sees the audit findings in a two-paragraph email. The 14 hours of subsidiary account mapping, consolidation rule tracing, and elimination engine testing behind the two identified problems are not in the email.

NetSuite consultants, NetSuite developers, and NetSuite administrators on monthly retainer — independent ERP consultants, fractional NetSuite architects, and Oracle NetSuite Alliance Partner firms — perform their highest-value work in the SuiteScript development, SuiteFlow workflow design, financial module configuration, and integration architecture that keeps the ERP platform aligned with the organization’s evolving business processes. This guide covers NetSuite administration and configuration, SuiteScript 2.0 development, SuiteFlow workflow design, financial modules and multi-subsidiary configuration, and NetSuite integration architecture — and how to structure a NetSuite retainer that makes the hours behind each ERP advisory function visible.

NetSuite administration and configuration advisory

NetSuite administration advisory covers the configuration layer of the ERP platform: saved searches and reports, roles and permissions architecture, custom record types and custom field schema, custom forms, and the data model design that determines how well the NetSuite instance supports the organization’s financial reporting, operational workflows, and compliance requirements. The advisory function is not configuration execution — it is the architectural analysis that identifies where the current configuration produces incorrect or incomplete data, where it will break as the organization adds subsidiaries, currencies, or transaction volume, and what specific configuration changes will resolve the identified gaps.

Saved search and KPI dashboard design

NetSuite saved searches are the primary data retrieval tool for operational reporting, workflow conditions, and SuiteScript data inputs. Saved search design requires understanding the NetSuite record join structure (a Transaction search can join to Transaction Lines, Items, Customers, Vendors, Employees, Projects, Subsidiaries, and custom records via relationship fields), the formula language (NetSuite saved search formulas use SQL-style syntax: DECODE({status}, 'pendingApproval', 'Needs Review', 'approved', 'OK', 'Other'); CASE WHEN {amount} > 10000 THEN 'High Value' WHEN {amount} > 1000 THEN 'Medium' ELSE 'Low' END; NVL({custbody_custom_field}, 'Not Set') for null handling; ROUND({amount} / {quantity}, 2) for calculated unit costs; TO_CHAR({trandate}, 'YYYY-MM') for period grouping), and aggregate function availability in summary searches (SUM, COUNT, MINIMUM, MAXIMUM, AVG with GROUP BY on non-formula fields).

The saved search design challenge is that NetSuite’s formula evaluator does not expose error messages at design time: a formula with a syntax error returns no results and no error indicator, requiring iterative testing to isolate the problematic expression. NetSuite-specific formula limitations compound the challenge: the {field} reference syntax for joined record fields (a Transaction search referencing Customer fields uses {customer.email}; a Transaction Line search referencing Item fields uses {item.weight}); the difference between Summary and Detail formula columns (Summary columns can reference aggregate functions and GROUP BY groupings; Detail columns cannot use aggregate functions); and the transaction line vs. transaction header join scope (a search on the Transaction record type that adds Transaction Line columns produces one result row per transaction line, not one row per transaction, which inflates transaction-level reports unless the correct Summary Type is selected).

Roles, permissions, and data access design

NetSuite access control is configured through a role-permission matrix where each role specifies the permission level (None, View, Create, Edit, Full) for each record type and the subsidiary and department restrictions that scope the role to specific organizational units. Role design requires mapping each user persona (Accounts Payable Clerk, Controller, Sales Representative, Project Manager, IT Administrator) to the minimum permission set required to perform their job functions, then validating that the role configuration does not expose sensitive data (payroll amounts, intercompany transactions, consolidated financial statements) to users outside the authorized finance team.

NetSuite's Custom Employee Center roles allow end users (employees who are not accounting or operations staff) to access NetSuite for specific functions — expense report submission, time entry, purchase requisition — without access to financial records. The custom employee center role design challenge: the default Employee Center role provides access to a fixed set of record types; extending it to include custom records or non-standard transaction types requires cloning the default role and adding specific permissions, which then requires maintenance when NetSuite updates the default Employee Center role definition. The NetSuite consultant designs the permission inheritance strategy (custom roles that extend the minimum required base and add specific permissions) that balances access control with maintenance overhead.

SuiteScript 2.0 development

SuiteScript 2.0 is NetSuite’s JavaScript-based scripting framework that executes on the NetSuite server within a governance unit (GU) framework that limits the number of operations each script execution can perform. Governance units are consumed by NetSuite API calls: each record load (record.load()) costs 10 GUs; each record save (record.save()) costs 20 GUs; each search result retrieval costs 10 GUs; each external HTTP call costs 10 GUs. Each SuiteScript execution context has a governance unit limit (1,000 GUs for User Event and Client scripts; 5,000 GUs for Scheduled and Map/Reduce scripts per chunk; 10,000 GUs for RESTlets), and a script that exhausts its GU limit throws a SSS_GOVERNANCE_UNIT_EXHAUSTION error and halts execution without completing its work.

SuiteScript 2.0 script types and execution contexts

The seven primary SuiteScript 2.0 script types and their execution contexts:

User Event scripts execute in response to record create, edit, delete, and view operations. The three entry points: beforeLoad(context) executes before a record form is loaded (used to modify the form: hide fields, change field labels, add custom buttons, set default field values based on user context or URL parameters); beforeSubmit(context) executes before the record is saved to the database (used to validate field values, set computed field values, and reject saves that violate business rules by throwing an error); afterSubmit(context) executes after the record is saved (used to trigger secondary operations: create related records, send notifications, update related records based on the saved values). User Event scripts have a 1,000 GU limit per execution; scripts that approach this limit use the runtime.getCurrentScript().getRemainingUsage() defensive check to log governance warnings before exhaustion.

Client scripts execute in the user’s browser when they interact with a NetSuite record form. Entry points: pageInit(scriptContext) (page load); fieldChanged(scriptContext) (field value change, for cross-field calculations and conditional field visibility); validateField(scriptContext) (returning false cancels the field change); saveRecord(scriptContext) (returning false cancels the record save with a user-facing validation message). Client scripts have no governance unit limit but have a 5-second timeout for synchronous API calls; long-running lookups should use the search.lookupFields() lightweight API rather than record.load().

RESTlets provide custom REST API endpoints within NetSuite, accessible via OAuth 1.0a token-based authentication or NLAuth header authentication. RESTlet entry points correspond to HTTP methods: get(requestParams), post(requestBody), put(requestBody), delete(requestParams). RESTlets are the correct integration pattern for external systems that need to query or write NetSuite records with custom business logic (field validation, related record creation, workflow triggering) that the standard SuiteTalk SOAP API or REST Record API does not support natively.

Map/Reduce script design for bulk processing

The Map/Reduce script type is the correct pattern for processing large record sets that exceed the 5,000 GU per-chunk limit of a Scheduled script. The Map/Reduce framework divides work into four phases executed in sequence: getInputData() returns the input data set (a saved search result, a custom array, or a file Cabinet CSV); the framework distributes the input rows to map(context) invocations, each receiving one input row with a key-value pair; the framework groups map output by key and passes all values for each key to a single reduce(context) invocation; summarize(context) receives the aggregated results and handles error reporting.

The Map/Reduce governance unit strategy: each map() invocation receives 5,000 GUs; each reduce() invocation receives 5,000 GUs per key. The data segmentation decision in getInputData() — what field to use as the map key — determines the work distribution. For a vendor bill approval routing job processing 2,400 bills: using the approver employee ID as the map key groups all bills for each approver into a single reduce() call, which then loads and updates each bill in that approver group; if any single approver has more than 100 bills (loading 100 records at 10 GUs each = 1,000 GUs, plus saving 100 records at 20 GUs each = 2,000 GUs, total 3,000 GUs out of 5,000), the governance budget is sufficient. When approver groups exceed the governance budget, the design adds a secondary segmentation (approver ID + date range) to split large groups across multiple reduce() calls.

The summarize(context) error handling pattern: context.mapSummary.errors.iterator() and context.reduceSummary.errors.iterator() enumerate any records that failed during map or reduce phases; the summarize() implementation logs each error to a custom record or sends an email notification with the failed record IDs, providing the operational visibility to identify and manually resolve the subset of records the automated job could not process.

SuiteFlow workflow design

SuiteFlow (NetSuite’s graphical workflow builder) enables non-developer configuration of multi-step business process automation: approval routing, status progression, notification triggers, and scheduled data updates. SuiteFlow workflows are configured per record type and execution context, with states representing workflow positions and transitions representing the conditions that move a record from one state to the next.

Approval workflow architecture with delegation and escalation

A purchase order approval workflow that routes by amount threshold requires: States representing each approval stage (Pending Manager Approval, Pending Director Approval, Pending VP Approval, Approved, Rejected); Transitions with conditions that check the PO Amount field against threshold values and the approver’s availability (a condition using {approver.isinactive} = false AND {approver.hasonlyleaveapproval} = false evaluates approver availability); Wait states that pause the workflow until the approver acts or a timeout expires; and Escalation paths that transition to the next-level approver when the wait state timeout fires.

The delegation fallback pattern: a custom field custentity_approval_delegate on the Employee record designates the employee who should receive approvals when the primary approver is unavailable; the workflow transition condition checks {approver.isinactive} = true OR {approver.hasonlyleaveapproval} = true and routes to the delegate employee when the condition is met. The wait state timeout configuration: a Scheduled workflow that runs every 4 hours checks open POs in the Pending Approval states and fires the Send Reminder Action for POs that have been pending for more than 24 hours; fires the Set Field Value Action to update the approver to the delegate for POs pending more than 48 hours.

Custom workflow actions via SuiteScript integration

SuiteFlow’s built-in workflow actions (Set Field Value, Send Email, Create Record, Lock/Unlock Record) cover the majority of workflow automation requirements. When a workflow requires logic that SuiteFlow’s action library cannot express — multi-table lookups, conditional record creation based on complex field combinations, external API calls during workflow execution — the Custom Action Script action invokes a Workflow Action SuiteScript that receives the workflow context (the triggering record ID and the workflow instance state) and executes arbitrary SuiteScript logic. The Workflow Action script type receives 5,000 GUs per execution, enabling lookups, record creation, and API calls that the built-in workflow actions cannot perform.

Financial modules and multi-subsidiary configuration

NetSuite’s financial module configuration — multi-subsidiary consolidation with OneWorld, revenue recognition under ASC 606, and advanced financial workflows — is the advisory function where configuration errors produce the most significant business impact: financial statements that misstate intercompany balances, revenue recognition schedules that violate accounting standards, and approval routing gaps that expose the organization to unauthorized vendor commitments.

Multi-subsidiary configuration with NetSuite OneWorld

NetSuite OneWorld extends the base NetSuite financial module to support multiple legal entities within a single NetSuite account, each with its own chart of accounts, currency, tax jurisdiction, and audit trail. Multi-subsidiary configuration involves:

Intercompany transaction routing: NetSuite records intercompany transactions (an intercompany purchase from a subsidiary, an intercompany expense recharge between entities) as paired entries in the source and destination subsidiary ledgers. The intercompany transaction routing configuration specifies the intercompany AR account on the selling subsidiary and the intercompany AP account on the buying subsidiary; these accounts must be mapped to the same consolidation elimination account in the intercompany elimination rules, or the consolidation will carry intercompany balances through to the consolidated statements as uneliminated amounts.

Currency revaluation: subsidiaries that transact in a currency different from the parent’s functional currency carry monetary asset and liability balances that must be revalued at the closing exchange rate each period. NetSuite’s Currency Revaluation process generates revaluation journal entries for open AR, AP, bank account balances, and intercompany loan balances; the revaluation configuration specifies the revaluation date, the exchange rate source (from the NetSuite exchange rate table or a manually entered rate), and the revaluation gain/loss account. Configuring currency revaluation for a multi-subsidiary org requires mapping each monetary account to the correct gain/loss account by subsidiary and verifying that the revaluation process selects the correct exchange rate for each currency pair.

Consolidated reporting: the Consolidated Balance Sheet and Consolidated P&L in NetSuite OneWorld aggregate all subsidiary ledger balances into a single consolidated report, with intercompany eliminations applied based on the elimination rules configuration. Validating consolidated report accuracy requires: confirming that intercompany receivables and payables net to zero in the consolidated statement (any residual balance indicates an uneliminated intercompany transaction); confirming that subsidiary-to-subsidiary investment account balances are eliminated against the corresponding subsidiary equity account; and confirming that intercompany revenue and expense transactions are eliminated from the consolidated P&L.

Revenue recognition under ASC 606

NetSuite Revenue Management implements ASC 606 (Revenue from Contracts with Customers) within the ERP: the consultant configures revenue elements, recognition plans, and allocation rules that determine how contract revenue is recognized over time or at specific performance obligation completion milestones.

Revenue element configuration: each product or service sold is mapped to a revenue element that specifies the recognition method (Straight Line for subscription revenue recognized ratably over the subscription period; Event-Based for one-time implementation fees recognized at project completion; Percent Complete for professional services recognized based on hours delivered vs. total estimated hours) and the deferred revenue and recognized revenue accounts. For multi-element arrangements where a single contract bundles SaaS subscription, implementation services, and training — each with a different recognition pattern — the revenue element configuration must support separate recognition schedules per contract line item.

Standalone selling price (SSP) allocation under ASC 606: when a multi-element contract is sold at a total contract price that differs from the sum of the individual element SSPs, ASC 606 requires allocating the total transaction price to each performance obligation in proportion to its SSP. NetSuite Revenue Management implements this allocation through revenue arrangement templates that specify the SSP for each element type and apply the proportionate allocation formula when a contract contains multiple elements. Configuring and validating this allocation requires the NetSuite consultant to: define the SSP for each element type (typically derived from standalone sale analysis of historical transactions); configure the allocation method (relative standalone selling price); create test arrangements with multiple elements and verify that the allocated amounts match the expected SSP-proportionate calculation; and validate that the recognition schedules generate journal entries that agree to the allocated amounts over the recognition period.

NetSuite integration architecture

NetSuite integrates with external systems through four primary API patterns, each suited to a different data volume, latency, and integration direction requirement.

SuiteTalk REST Record API and SuiteQL

The NetSuite REST Record API (available from NetSuite 2020.1) provides resource-oriented JSON access to standard and custom records: GET /services/rest/record/v1/salesOrder/{id} retrieves a sales order; POST /services/rest/record/v1/salesOrder/ creates an order; PATCH /services/rest/record/v1/salesOrder/{id} updates specific fields. The REST Record API supports bulk upsert operations (PUT /services/rest/record/v1/salesOrder?replace={fields}) and sublist operations (adding line items to an order in the same request as the order header). Authentication uses OAuth 2.0 machine-to-machine (M2M) client credentials flow for server-to-server integration, replacing the legacy NLAuth and OAuth 1.0a patterns.

SuiteQL is an SQL-like query language for NetSuite that provides more powerful record querying than saved searches: standard SQL syntax (SELECT t.id, t.trandate, t.entity, tl.item, tl.quantity, tl.amount FROM transaction t JOIN transactionLine tl ON t.id = tl.transaction WHERE t.type = 'SalesOrd' AND t.trandate >= '2026-01-01'); JOINs across record types (Transaction, TransactionLine, Item, Customer, Vendor, Employee, Project); aggregate functions and GROUP BY for summary reporting; pagination via offset and limit parameters for large result sets. The SuiteQL API endpoint (POST /services/rest/query/v1/suiteql) is the correct pattern for data warehouse synchronization queries, financial data extracts, and reporting integrations where saved searches would require multiple separate queries to produce the same result set.

Third-party integration platform architecture (Celigo and Boomi)

For integrations between NetSuite and other enterprise systems — Salesforce, Shopify, Workday, Avalara, ShipStation, custom EDI trading partners — integration platform as a service (iPaaS) connectors reduce development time compared to building direct API integrations. Celigo (the most widely used NetSuite iPaaS connector) provides pre-built integration templates for common NetSuite integration patterns (Salesforce ↔ NetSuite customer/order sync; Shopify ↔ NetSuite order/fulfillment sync); a visual flow builder for mapping source fields to NetSuite record fields; and a NetSuite-native adapter that uses SuiteScript RESTlets for operations that the SuiteTalk API does not support directly. The NetSuite consultant’s advisory role in an iPaaS integration engagement: defining the data mapping requirements (which Salesforce Opportunity fields map to which NetSuite Sales Order fields; how product catalog differences are resolved between the two systems); designing the error handling strategy (which integration errors require manual intervention vs. automatic retry; how conflicting updates from both systems are resolved); and validating the integration in a sandbox before production cutover.

HourTab for NetSuite retainers

NetSuite retainer work produces ERP reliability, financial close speed, and process automation — the intercompany eliminations that balance correctly at consolidation, the revenue recognition schedules that comply with ASC 606 without manual adjustment, the purchase order approval workflow that routes correctly even when approvers are on leave. The hours behind each outcome — the subsidiary account mapping audit behind the intercompany balance correction, the SSP allocation configuration and validation behind the revenue recognition accuracy, the delegation logic design behind the approval workflow robustness — are not visible to the Controller, the Finance Director, or the IT Manager without a work log that connects each hour block to the specific ERP function performed.

HourTab gives NetSuite consultants a retainer dashboard that their Finance Directors and IT Managers can bookmark without creating an account: the month’s committed hours, the hours consumed to date, and the work log entries that connect each hour block to the intercompany reconciliation advisory, the SuiteScript development, the SuiteFlow workflow design, or the revenue recognition configuration being worked on. When the Controller can see that 14 of the month’s 50 retainer hours went to intercompany elimination rule configuration and 12 went to revenue arrangement template design and validation, the retainer renewal conversation is grounded in the actual distribution of ERP advisory work rather than an abstract sense of whether the NetSuite investment was worth the fee.

The retainer model works for NetSuite consulting because ERP governance and continuous development are ongoing rather than project-scoped — every NetSuite release introduces new features, module updates, and configuration changes that require evaluation; every business change (new subsidiary, new product line, new currency, new financial reporting requirement) requires NetSuite configuration review and update; every SuiteScript dependency on a deprecated API requires review and migration. A monthly hour commitment provides the NetSuite consultant’s sustained availability across the full ERP maintenance and development calendar.

Frequently asked questions

What does a NetSuite consultant on retainer typically do?

A NetSuite consultant on monthly retainer provides ongoing ERP advisory and development: NetSuite administration and configuration (saved search and report design, roles and permissions architecture, custom record types and custom field schema, custom forms); SuiteScript 2.0 development (User Event scripts, Client scripts, Map/Reduce scripts for bulk processing, RESTlets for external system integration); SuiteFlow workflow design (approval routing, wait states, escalation paths, custom workflow actions via SuiteScript integration); and financial module configuration (multi-subsidiary consolidation with intercompany elimination rules, revenue recognition under ASC 606, multi-currency revaluation). The retainer also covers integration architecture advisory: REST Record API, SuiteQL, and iPaaS connector design for integrations with Salesforce, Shopify, Workday, and other enterprise systems.

What NetSuite work is most commonly underlogged?

The most systematically underlogged categories are saved search formula design (iterative formula debugging in DECODE/CASE WHEN/NVL syntax — typically 3 to 8 hours invisible in the finished search); Map/Reduce architecture design (data segmentation strategy and governance unit budgeting per reduce key — typically 8 to 18 hours invisible in the bulk processing job); intercompany reconciliation (subsidiary account mapping, elimination rule configuration, and consolidated statement validation — typically 15 to 30 hours invisible in the balanced consolidation); and revenue recognition setup (SSP allocation configuration and schedule validation against ASC 606 requirements — typically 20 to 40 hours invisible in the revenue recognition schedule). Detailed work log entries that capture the specific module, configuration decision, and validation outcome make this invisible ERP investment visible.

What should a NetSuite retainer agreement include?

Retainer agreements should specify: scope boundary between administration, SuiteScript development, and financial module configuration; NetSuite account access level required for the scoped work; SuiteScript deployment environment authority (sandbox testing before production deployment); IP ownership for SuiteScript code; and a shared work log documenting each configuration session and SuiteScript deployment. Monthly retainer amounts for NetSuite advisory and development support typically range from $6,000 to $15,000 per month for administrator retainers, increasing to $12,000 to $30,000 per month for full-stack retainers covering SuiteScript development, integration architecture, and financial module configuration.

What are typical retainer rates for NetSuite consultants?

NetSuite administrators and junior consultants with 2 to 4 years of experience typically bill $85 to $150 per hour. Experienced NetSuite developers and functional consultants with 5 to 9 years of experience and ERP Consultant certification typically bill $125 to $225 per hour. Senior NetSuite architects with 10 to 15 years of experience and expertise in multi-subsidiary OneWorld design and advanced financial configuration typically bill $200 to $375 per hour. Oracle NetSuite Alliance Partner firms typically bill $175 to $325 per hour. Monthly retainer amounts range from $6,000 to $15,000 per month for admin retainers, increasing to $15,000 to $35,000 per month for architect-level retainers.

How should NetSuite retainer hours be logged?

Work log entries should capture the advisory category (administration, SuiteScript development, SuiteFlow design, financial module configuration, integration architecture), the specific record type or module, the task, and the finding or deliverable. Example: “SuiteScript Development — Vendor Bill approval Map/Reduce. Designed and deployed bulk approval routing script for 2,400 open vendor bills. getInputData() search segmented by approver ID as map key; reduce() loads and updates bills per approver group with GU checkpoint via getRemainingUsage(); summarize() logs failed bill IDs to custom record. Sandbox test: 50-bill batch, 0 GU errors. Production run: 2,400 bills processed in 14 minutes. 12 hours.”