NetSuite: Getting the General Ledger Right the First Time

Published on September 20, 2025.

After years of helping organizations implement NetSuite — and stepping into more than a few “rescue projects” — one thing has become crystal clear: the decisions you make about the general ledger (GL) can make or break your implementation.

I’ve seen implementations thrive because the GL was designed thoughtfully. I’ve also seen businesses struggle for years because they simply carried over a legacy chart of accounts “as is” without rethinking it.

Implementation is the perfect time to get this right. It’s your chance to move away from “this is how we’ve always done it” and instead design a model that takes full advantage of what NetSuite offers.

Why the GL Model Matters

In NetSuite, the GL is more than a list of accounts. It’s the backbone of your financial system. Every invoice, bill, payroll run, and inventory adjustment eventually touches the GL.

When the GL model is messy, reporting is messy. When it’s bloated, data entry slows down. When it’s rigid, you end up creating endless new accounts just to answer basic questions.

A well-designed GL delivers:
• Reliable reporting — numbers you can trust, without endless reconciliations.
• Efficiency — users can code transactions quickly and accurately.
• Scalability — your system grows with you instead of collapsing under account sprawl.

Understanding NetSuite’s Foundation: Account Categories and Types

Every account in NetSuite must belong to one of five categories: Assets, Liabilities, Equity, Income, or Expenses.

Within those categories are account types (Bank, Accounts Receivable, Accounts Payable, Other Income, Cost of Goods Sold, etc.). These types aren’t optional — and you can’t create new ones. That’s because they control how accounts behave in the system:
• Bank accounts appear on cash flow statements.
• Accounts Receivable / Accounts Payable link to customer and vendor subledgers.
• Equity accounts roll into retained earnings automatically.

This sometimes frustrates teams migrating from legacy systems, but once you accept the framework, you realize it actually simplifies reporting and ensures consistency.

Building Your Chart of Accounts (COA)

Whether you're building or migrating your COA, here are a few suggestions.

Use numbering. NetSuite doesn’t require it, but a consistent scheme (1xxx = Assets, 2xxx = Liabilities, etc.) helps everyone. NetSuite even supports auto-numbering to enforce consistency.

Avoid bloat. Don’t replicate every account from your legacy system. Merge duplicates, eliminate “miscellaneous” buckets, and re-label cryptic names.

Use parent/child accounts. Parent accounts group children for reporting, but they cannot hold transactions themselves. Think of them as headers, not active accounts.

Think future, not just present. Design a chart that can support acquisitions, new product lines, and growth. Don’t lock yourself into today’s structure.

Dimensions: NetSuite’s Reporting Superpower

In many ERP systems, account numbers (like 4000-10-200) carry meaning. In NetSuite, account numbers are just IDs. The real reporting power comes from dimensions — also called segments — that you tag to each transaction.

NetSuite's standard dimensions include:
• Subsidiary: represents a legal entity. Required in OneWorld.
• Location: usually warehouses, offices, or stores.
• Department: cost centers like Finance, Marketing, or Sales.
• Class: flexible category; often used for product lines, revenue types, or business segments.

This shift is a mindset change: instead of encoding meaning in account numbers, you use dimensions to slice and dice your reporting.

Subsidiaries vs. Classifications: Getting It Straight

This is one of the most common misunderstandings.

Subsidiaries = legal entities. They define fiscal calendars, base currencies, and tax reporting. Intercompany eliminations happen between subsidiaries.

Classifications = reporting categories inside a subsidiary (Departments, Locations, Classes, and custom segments).

If it files taxes separately, it’s a subsidiary. Everything else belongs in classifications.

Departments vs. Classes

A simple rule of thumb:
Departments = Who. Internal cost centers or functions (Engineering, Finance, HR).

Classes = What. Flexible buckets you define (product families, revenue streams, business type).

Both can be hierarchical, both can be required, and both feed directly into reporting. Decide early how you’ll use them — don’t leave it vague.

Custom Segments: Taking Control of Your Own Dimensions

NetSuite’s “big four” dimensions don’t cover everything. That’s where Custom Segments come in.

Custom Segments are dimensions you define yourself. You decide the values, where they appear, whether they hit the GL, and even who can see them.

Here are a few real-world examples of custom segments:
• Product Condition: New vs Refurbished
• Contract ID: for services or SaaS businesses
• Funding Source: common in nonprofits
• Sales Channel: Direct, Distributor, Online

Some of the features of custom segments include:
• GL Impact (single-select only). Tagging affects the GL.
• Line-level or header-level. Perfect for expense allocations or project tracking.
• Hierarchy. Parent/child rollups (Europe → UK → London).
• Filtering. Only show valid values based on other selections.
• Defaulting. Pull values from customers, projects, or other records.
• Permissions. Limit visibility by role for sensitive categories.

And finally, a word of caution: don’t go wild with custom segments. Too many required fields frustrate users and lead to bad data. Start with a handful of segments that truly drive decision-making.

Statistical Accounts: Beyond Debits and Credits

Not every KPI is a dollar figure. Sometimes you need to track things like headcount, square footage, or number of active subscribers.

That’s where Statistical Accounts come in. They let you book non-monetary values (like “1,000 active customers”) and use them in ratios and KPIs. For example:
• Revenue per employee
• Rent expense per square foot
• Support tickets per active user

They don’t hit the GL in the traditional sense, but they enhance reporting in powerful ways.

Moving Beyond Traditional Subaccounts

Legacy systems often force detail into subaccounts, like:

6400-100 Marketing Travel
6400-200 Engineering Travel
6400-300 Finance Travel

In NetSuite, you don’t need this. One Travel Expense account, tagged with Department, gives you the same breakdown — without account sprawl. Want domestic vs international travel? Add a custom segment.

Multi-Book Accounting: When You Need It

If your business needs to report under multiple accounting standards (say GAAP and IFRS), NetSuite’s Multi-Book Accounting lets you maintain separate books in parallel. Each book can have its own accounting treatments, while transactions are entered once.

Not every company needs this, but if you’re multinational or dealing with statutory requirements, it’s worth planning for during implementation. Retrofitting it later can be painful.

Migration: From Old to New

Most companies that are implementing NetSuite aren’t starting fresh. Migration is about mapping old to new and loading balances.

Here are a few things that I recommend...

Crosswalks. Map legacy accounts to NetSuite accounts.

Opening balances. Load via journal entries.

Don’t replicate blindly. Resist the urge to bring every legacy subaccount forward. Let dimensions handle that complexity.

Test reports early. Validate that balances tie before go-live.

Common Anti-Patterns to Avoid

Over the years, I’ve seen the same GL-related implementation mistakes again and again.

Using Classes as pseudo-subsidiaries. Causes nightmares in consolidation.

Overloading the chart of accounts. Every “what if” request spawns a new account.

Underusing dimensions. Leaving Location or Department optional means inconsistent data.

Ignoring permissions. Letting everyone post everywhere leads to chaos.

Avoid these mistakes, and you’re already ahead of most implementations.

Why Implementations Go Wrong

If NetSuite is so flexible, why do so many companies end up with messy GL designs?

From what I've seen, I think it usually comes down to language and alignment.

Finance says “division,” but Sales says “region.” Operations says “line of business,” and everyone assumes they’re talking about the same thing. Often they’re not.

That’s why I think workshops / working sessions matter. They’re not just technical in nature — they’re about agreeing on definitions, and getting everyone on the same page.

Practical Guidance for Getting the GL Right

Here’s my short list, based on NetSuite implementations that I've worked on, and NetSuite instances that I've worked in.

Keep the COA lean. Don’t create an account for every reporting request.

Leverage dimensions. That’s where the reporting power is.

Define custom segments early. Retrofits are messy.

Plan for growth. Build a structure that can scale with acquisitions or expansion.

Use permissions. Lock down who can post to what.

Standardize language. Make sure everyone agrees on terms.

Get executive sponsorship. GL design cuts across functions — so leadership must back it.

For Accounting and Finance Professionals

If you’re used to segmented account numbers, NetSuite feels different.

In legacy systems, 4000-10-200, might mean: Revenue – East Region – Product Line.

In NetSuite, account numbers don’t carry meaning. Dimensions do.

Here's the mental shift that you need to make:
• Legacy: the COA is the data structure and the reporting structure.
• NetSuite: the COA is the base, and dimensions drive reporting.

Once you internalize that, you’ll see why NetSuite’s approach is cleaner and more scalable.

The Audit and Compliance Angle

Auditors want consistency. NetSuite’s required fields, dimension enforcement, and role-based permissions reduce miscoding risk. Clean design = cleaner audits.

Performance and Reporting Considerations

A quick note: every dimension you add increases complexity in saved searches and reports. For heavy analytics, consider NetSuite Analytics Warehouse (NSAW) instead of pushing everything into saved searches. The right tool for the job matters.

Wrapping Up

Designing the GL in NetSuite isn’t glamorous, and it's often taken for granted. But it’s foundational. Get it right, and you’ll have cleaner data, faster reporting, and a system that scales. Get it wrong, and you’ll spend years untangling the mess.

Implementation is your chance to reset. Don’t waste it.

About Me

Hello, I’m Tim Dietrich. I design and build custom software for businesses running on NetSuite — from mobile apps and Web portals to Web APIs and integrations.

I’ve created several widely used open-source solutions for the NetSuite community, including the SuiteQL Query Tool and SuiteAPI, which help developers and businesses get more out of their systems.

I’m also the founder of SuiteStep, a NetSuite development studio focused on pushing the boundaries of what’s possible on the platform. Through SuiteStep, I deliver custom software and AI-driven solutions that make NetSuite more powerful, accessible, and future-ready.

Copyright © 2025 Tim Dietrich.