This article is written for CFOs, Controllers, and solution architects seeking ways to produce parallel financial and non-financial reporting with control and structure.
TL;DR Summary
Businesses often need two views of their results: GAAP or IFRS financials for compliance and a parallel management, cost, or cash-basis view for decision-making. SuiteQL and AI make that second view fast to build, but accountants hesitate to rely on query-only reporting for anything that drives decisions, because it is hard to audit and slows as the reporting view logic grows.
NetSuite’s multi-book feature and its lighter-weight adjustment-only book offer a path to balance automation and efficiency with structure and control. Posting the parallel view as book-specific entries that tie back to source transactions yields reporting that is deterministic, repeatable, and auditable to the entry, presented through native financial statements with no separate tool. SuiteQL and AI still do the analytical work; the secondary book gives that logic a controlled place to land. Our cash-basis client implementation illustrates the pattern in practice.
Introduction: Fitting Customizations with Native Building Blocks Unlocks NetSuite’s Power
In a recent conversation with a client about options for an upcoming implementation, the client’s CTO shared an insight I found valuable: While NetSuite’s platform is highly adaptable, it is unwise to change the core definitions of business records. In other words, let a customer record express a customer, a vendor record express a vendor, and so on. When key record definitions are repurposed, it increases the risk that future NetSuite enhancements will interfere with how records were customized. In other words, when enhancing NetSuite to fit unique business needs, design the system to complement native structures rather than overwrite their meaning.
That principle sits behind the approach I want to share here. When we need NetSuite to produce a second, parallel view of the business, whether for management accounting, cost accounting, or cash basis, the instinct is often to reach straight for a custom reporting layer built on SuiteQL or, increasingly, AI. Those tools are powerful, and my team and I use them daily. But core financial reporting carries a higher bar than ad hoc analysis, and a pure query layer struggles to clear it. This article makes the case that one of NetSuite’s own building blocks, the secondary book, can serve as the anchor that gives parallel reporting the determinism, repeatability, and auditability accountants require, while still leaving room for SuiteQL and AI to do what they do best on top of it.
The Challenge: Producing Alternate but Parallel Views for Financial and Management Accounting in NetSuite
Most businesses don’t measure results with one yardstick. While financial reporting under established accounting standards such as GAAP and IFRS provides broadly recognized definitions, management often wants to see the business through an alternative lens. One simple example is Project Accounting, which seeks to assess a project’s profitability across accounting periods. Another common reporting need is Cost Accounting, a non-GAAP measurement system used in manufacturing that allocates overhead and indirect costs to products, providing business insights and decision support that financial accounting does not. Even GAAP/IFRS standards themselves allow for more than one valid approach to measuring certain events, such as inventory costing and depreciation. Another common but challenging use case is producing Cash Basis reporting in NetSuite. [Although NetSuite provides a limited Cash Basis Income Statement, it does not offer a Cash Basis Balance Sheet or Trial Balance.]
The general approach companies take to give stakeholders the business insights they need is to create custom reports to satisfy parallel business reporting objectives, while the core accounting setup adheres to recognized accounting standards.
Evolution of Reporting Tools: SuiteQL and AI
The introduction of SuiteQL reporting a number of years ago has given analysts breadth and depth, allowing them to create reporting that can formulaically provide alternative views for management reporting. Nascent AI tools such as NetSuite’s MCP connector further expand the ability to work with NetSuite data and shape reporting to suit varying needs. Further, AI development tools such as Claude Code, working with a CLI (command line interface) connected to NetSuite, have reduced the time needed to create custom portlets and dashboards, providing a layer of powerful visualizations driven by custom analytic tools.
AI and SuiteQL Provide Powerful Logic Tools, but Accountants Are Reluctant
Yet, with all the expanded capacities described above, accountants like me find ourselves slower to fully adopt AI in crucial financial reporting. Ad hoc queries are one thing, but core reporting that is relied on for decision-making needs to be deterministic and repeatable. SuiteQL reports within NetSuite do provide deterministic and reliable results, but there is often another reason for reticence in relying on custom SuiteQL-driven reporting: a lack of auditable records to support complex reporting, especially when the SQL logic is complicated and includes formulas that modify the standard GL-posting transaction layer in NetSuite.
To summarize: Accountants want 1) deterministic, 2) repeatable, and 3) auditable reporting.
Great strides have been made using context, skills, and other guardrails that insert themselves into the reasoning layer of AI to produce reliability and consistency, which helps close the gap on the first two concerns. Yet, even the best-crafted boundaries to create deterministic results don’t surmount the third problem: auditability, which usually requires records that demonstrate how financial data has been acted on, categorized, or finessed to produce a reporting result that, by design, differs from financial reporting to produce management reporting.
To be clear, we may not need to satisfy a financial or tax auditor when producing “management” (non-GAAP) reporting, but decision-makers need confidence that the business insights generated by custom reporting are grounded.
Additionally, as the logic complexity increases to produce the desired perspectives, so does the time to run SQL-based reporting. Multiple joins and Common Table Expressions (a.k.a. “CTEs,” which are embedded subqueries that act as temporary tables within a larger query) can, over time, make reports performance-heavy and difficult to work with.
The Other Extreme: NetSuite’s Multi-Book Overview
One of NetSuite’s more advanced offerings is “Multi-book.” Multi-book is a system for parallel General Ledgers that can be used to present a different view of a company’s financial activity and results. Common use cases that Multi-book is used to solve include:
- Multi-Currency concerns: Companies that want to measure their financials in different currencies but want to avoid traditional currency translation challenges during consolidation.
- Statutory Books: When local statutory accounting rules differ from those to which a corporate parent entity is subject.
The key functionality of multi-book is that it provides two (or more, depending on the number of “books”) sets of GL impacts for each transaction, and it also includes “Book-Specific Entries”, which are transaction types that can be used for top-side adjustments to only one book. Even with multi-book, there is very limited ability to manually change each book’s GL impacts on source transactions, but custom GL plugins can be crafted to add GL logic that targets individual books. Alternatively, Book-Specific entries can be used to handle specific convergences from GAAP (IFRS) to management accounting via top-side adjustments that only impact the specified book.
Despite its limitations, Multi-Book could, in theory, serve as a parallel measuring system for non-GAAP (or non-IFRS) reporting. The “Primary Book” would be used as expected, with transactions and processes designed to ensure proper financial accounting. “Secondary Books” can be used to modify or craft parallel GL impacts that are only meaningful in the relevant Book.
Using a Secondary Book to record a parallel view of the world, with the goal of creating non-GAAP reporting, represents the polar opposite of SuiteQL, AI-driven reporting. It lends itself to deliberate, formalized “posting” of economic narratives, therefore allowing native reporting to be completely deterministic and auditable, down to the individual transaction level.
While this may sound good in theory, the difficulties in setting up this type of model are many. As mentioned, impacts to the secondary books cannot be modified in the UI on standard transactions. The definitions and requirements for any non-GAAP reporting would need to be scripted with custom GL plugins to shape and modify GL lines. Otherwise, “Book-Specific” entries could be used, but, absent custom scripting, would be highly manual.
Given the above factors and the feature cost, implementation cost, and implementation effort, most companies would opt for a custom reporting solution rather than consider multibook.
NetSuite’s “Adjustment Only” Book Offers a Low-Cost Option for Alternative Financial and Managerial Narratives
There is a lightweight option that NetSuite has included in all OneWorld accounts since 2018: “Adjustment Only Books,” which provides functionality similar to the full Multi-Book features but in a scaled-down form. The main difference between “adjustment-only books” and “multibook” is that in the adjustment-only book feature, all transactions impact both books identically, except that the “book-specific journal entry” transaction is available to adjust amounts in a secondary book where the impact differs from the Primary Book. In other words, the expected use of the secondary book is to enter delta amounts only where the required impact on a secondary book differs from that on the primary book. This can provide a cost-effective path to achieve what I will describe in the remainder of this article.
Use Case: Automated Cash Basis Reporting in NetSuite
A client of ours wanted full Cash Basis reporting, which was something they required as standard in their industry. We had solved the Cash Basis reporting challenge in the past using a SuiteQL approach to back into Cash Basis reporting from the native Accrual-oriented transactions: Closer Inspection: NetSuite Cash Basis Reporting Challenges. For example, to determine the cash-basis impact of a customer payment, the query finds the invoices that the payment is applied to, calculates the prorated amount applicable to each invoice line (in case of partial payments), and displays the revenue account attributable to the invoice.
While the query worked well at producing the right numbers, it was difficult to audit the source transactions, and it didn’t produce the standard formatting used in the core NetSuite financial statements. While there are many ways to solve either problem (see Marty Zigman’s article on a version of a Cash Basis solution that includes records that store the narratives here, and see the following article on the Content Renderer, one of many: Learn the Framework to Extend NetSuite Content Generation), it occurred to me that by activating Adjustment-only Multibook, and using the cash basis query to automatically create Book Specific Journal entries, we could effectively produce a per-transaction narrative that would be more easily auditable, and naturally result in the out-of-the-box Cash Basis reporting that could be viewed side-by-side against Accrual reporting using the native multibook reporting.
The solution contains the following elements:
- The SQL logic stored in an app setting: This holds the logic needed to convert accrual to cash basis
- A user event script to generate book-specific entries and cross-link them to the source transactions
The really nice thing about this solution is that it combines advanced SQL logic with core native building blocks to get the best of both worlds: multidimensional reporting with traceable records, offering an audit narrative. No special reporting tool was required once we had the logic in place to inform financial shaping.
NetSuite’s Multi-Book Provides a Framework for Automation, Control, and AI Insights
Taking a step back, the secondary book gives us something more useful than a fix for one reporting problem. It gives us a place to stand.
Think of the model in three layers. At the top is the logic layer, where SuiteQL and AI tools do the analytical work: interpreting transactions, applying allocation rules, backing into a cash basis figure, or shaping a cost view. This is where modern tooling is strongest and where it should stay. At the bottom is the reporting layer, NetSuite’s native financial statements, which most accountants already trust and know how to read.
The “Record Structure” layer is what holds the whole thing together. Rather than letting the logic layer feed a report directly, we have it post the result as book-specific entries in a secondary book. Those entries are durable records. They carry a date, an account, an amount, and a link back to the source transaction, and they can be inspected, reconciled, and explained long after the query that produced them has run. The logic can change, and the AI prompt can be refined, but the posted record remains as evidence of what was booked and why.
This is the piece that answers the accountant’s three concerns at once. Determinism and repeatability come from posting to the ledger rather than recomputing on every report run. Auditability comes from the records themselves. And because the output draws on native financial statements, it looks like the financials the organization already relies on, with no separate report writer to maintain.
A chain is only as strong as its weakest link, as the adage goes, so, obviously, records such as multi-book transactions can only be as sound as the logic that created them. We can’t do away with thoughtful architecture and a human who can assess and validate any AI-produced query or script. What the record structure affords us is something we can touch and feel, and use to demonstrate what the logic layer actually produced.
Prolecto’s Accomplishments Provide a Solid Foundation for Multi-Layered Reporting
Every tool referenced in this article came out of solving a real client problem, and each one now sits ready to serve the next. The reporting patterns described here draw on years of Prolecto investment in getting NetSuite to produce financial and management views that are both flexible and controlled: SuiteQL query tooling for the logic layer, content generation for formatted output, and a library of financial saved searches and queries refined across hundreds of engagements. We give these to our clients license-free, because the value is in the practice of applying them to your specific reporting requirements, not in the tools themselves. What follows is a sample of the accelerators and prior work that make the multi-layered approach practical to stand up.
For those interested in previous articles on these concepts, see the following:
- 2025: Solving NetSuite’s Inherent 1099 Cash Basis Reporting Challenge
- 2022: Learn the Framework to Extend NetSuite Content Generation
- 2021: Closer Inspection: NetSuite Cash Basis Reporting Challenges
Bring the Same Control to Your Own Reporting
The pattern in this article is not unique to cash basis reporting considerations. Any time you need NetSuite to produce a second, parallel view of the business, whether for management accounting, cost allocation, or a board-ready presentation that native reporting cannot quite reach, the secondary book can serve as the anchor that keeps that view deterministic, repeatable, and auditable.
The work is in mapping your specific reporting requirement to the right layer: what logic belongs in SuiteQL or AI, what should post as book-specific entries, and what the native financials should surface. If this article resonates, consider subscribing to receive notifications for new posts. And if you are ready to bring this kind of structure and control to your own financial and management reporting in NetSuite, let’s have a conversation.
