Fix NetSuite Reports Showing Wrong Figures
A transdate-within-thismonth search is a moving target; later credit memos shift last month's revenue. Lock accounting periods by subsidiary to freeze reports.

On this page
Your saved search is working as designed. That's the problem.
You built a transaction search with ["transdate","within","thismonth"], which is a moving target. When your manager pulls last month's revenue in week one, they see $100k. By week three, it's $86k. The numbers aren't wrong, they're just picking up transactions entered after the close, like credit memos dated in the prior period.
The fix isn't a better search. It's locking your accounting periods by subsidiary so historical reports stay frozen.
Why Your Numbers Keep Changing
Your current filter uses transdate, which captures the date on the transaction. When someone enters a credit memo on the 5th of the current month but dates it the 28th of last month, that transaction still appears in your "last month" results. The transaction exists, it posts, and your saved search picks it up.
What you actually want is the posting period, not the transaction date. The posting period is the accounting period NetSuite assigns when the transaction posts. Once you close that period, no new transactions can post into it. For more detail on how NetSuite manages period-based posting, the NetSuite Connector documentation explains how transactions link to accounting periods and what happens when a period is closed.
Your three subsidiaries close in sequence: Subsidiary 4 first, then Subsidiary 3 two hours later, then Subsidiary 2 five hours after that. Until all three periods are closed, consolidated reports will shift as each subsidiary finalizes. That's normal.
The issue is that nothing stops someone from posting a June-dated transaction in July if the June period is still open.
Step 1: Close Periods by Subsidiary
Go to Setup > Accounting > Manage G/L > Manage Accounting Periods. You'll see a list of your periods with a status column.
For each subsidiary, you need to close the period in sequence:
- Lock the period when you're done entering transactions but still running adjustments
- Close the period when all postings are complete
- Run the Period Close Checklist to verify everything balanced before finalizing
The control here is the Allow Posting checkbox. When you uncheck it for a period, NetSuite blocks new transactions from posting to that period. Users get an error if they try to enter a June-dated transaction after you've locked June.
For your multi-subsidiary structure, close Subsidiary 4's period first, then Subsidiary 3, then Subsidiary 2. Once all three are closed, consolidated reports for that month become stable. If you use multi-book accounting, note that each book can have its own period closing status, so verify the closing sequence applies across all books you report on. The Multi-Book Accounting Guide covers how closed and locked periods behave differently per book.
Step 2: Fix Your Saved Search Filter
Change your saved search to use the posting period instead of a relative date range.
Replace:
["transdate", "within", "thismonth"]With:
["postingperiod", "anyof", "@LASTCLOSED@"]The @LASTCLOSED@ keyword pulls the most recently closed accounting period. This gives you the actual closed month, not the calendar month relative to today. A credit memo posted in July with a June date won't appear, because the June posting period is closed and no longer accepts new postings.
Your full filter set becomes:
[
["postingperiod", "anyof", "@LASTCLOSED@"],
"AND",
["subsidiary", "anyof", "2"],
"AND",
["posting", "is", "T"],
"AND",
["accounttype", "anyof", "Expense", "Income", "COGS", "OthIncome", "OthExpense"],
"AND",
["formulatext: {account}", "startswith", "4"]
]One caveat: postingperiod with anyof can behave inconsistently in SuiteScript 2.0 searches. If you build this filter in code rather than the saved search UI, test it with a single period value first. In the saved search builder, select the Posting Period field from the filter dropdown and choose the most recently closed period from the list.
Step 3: Set User Preferences for Report by Period
Even with locked periods, you can hit a reporting mismatch if users have the wrong preference set.
Go to Home > Set Preferences > Analytics and find the Report by Period option under the Reporting section. The possible settings are All Reports, Financials Only, and Never. Set this to All Reports (or at minimum Financials Only) rather than leaving it on Never.
Why this matters: If a user has Report by Period set to Never, NetSuite assigns transactions to reporting periods based on the transaction date. A June-dated credit memo posted in July would still show up in June reports for that user, even though the period is closed.
Setting Report by Period to All Reports forces NetSuite to use the posting period for reporting. This aligns what each user sees with what actually closed. Every user must make this change individually, so you'll need to communicate it or have your admin update roles.
Step 4: Handle the Time Zone Variable
Your subsidiaries span three countries in different time zones. NetSuite uses the user's time zone to determine what "this month" means at the moment they run a report.
A user in Subsidiary 2's country running a report at 11:00 PM local time on the last day of the month sees different results than a user in Subsidiary 4's country running the same report 30 minutes later.
This is why relative filters like thismonth and lastmonth are dangerous for multi-country operations. They're evaluated against the individual user's time zone, not a fixed corporate calendar.
The @LASTCLOSED@ keyword solves this too. It references the actual closed period in NetSuite, which is time-zone independent. Once June is closed for all subsidiaries, every user sees the same June results regardless of where they're located or what time they run the report.
What Happens After You Close
Once you close all three subsidiary periods, the numbers are frozen. A credit memo entered in July can't alter June results because June won't accept new postings.
Your saved search with @LASTCLOSED@ will show June's final numbers consistently. The $100k your manager saw in week one becomes the locked figure. The $86k they saw in week three was the moving target, transactions still being entered into an open period.
The one thing to verify: your AP and AR teams need to know the close schedule. If Subsidiary 2 closes five hours after Subsidiary 4, and someone in Subsidiary 2's AP team tries to enter a June bill at 4:00 PM on close day, they'll get rejected if the period is already locked. That's the control working as intended, but it requires communication about cutoff times.
Also note: if you reopen a closed period to process a backdated transaction, you can trigger an inventory cost recalculation. Don't re-close the period until that recalculation completes, or you'll get errors and unpredictable results.
What If You Need to Reopen a Period?
Sometimes an audit adjustment requires reopening a closed period. Go back to Setup > Accounting > Manage G/L > Manage Accounting Periods, select the period, and recheck Allow Posting. Make your adjustment, then re-close the period.
Be aware: reopening a period changes historical reports. Your auditors will want documentation of why you reopened and what changed. Keep a journal entry or saved search snapshot of the original figures before you reopen, so you can show the before-and-after.
For recurring audit adjustments, consider whether they can be posted to the current open period with a memo referencing the prior period. This keeps historical periods stable while still capturing the adjustment in your financial statements.
The Control That Holds It Together
Run the Period Close Checklist for each subsidiary in your defined order. Lock periods when transactions are complete, close them when posting is done, and verify the checklist shows zero open items.
Your saved search should reference @LASTCLOSED@, not thismonth. Your users should have Report by Period set to All Reports. Your periods should be closed by subsidiary in sequence.
If you're still seeing numbers change after all three subsidiaries close, check for transactions posted with a period override. NetSuite allows users with the Override Period Restrictions permission to post into closed periods. Review who has that permission under Setup > Users/Roles > Manage Roles, on the Permissions tab under the Setup subtab, and restrict it to your finance team only. The SuiteTalk REST Web Services Records Guide shows how the accounting period record exposes these controls if you need to audit them programmatically.
Historical reports stay stable when the system prevents changes. The period close is that prevention. Once you enforce it consistently across all three subsidiaries, your month-end reports will show the same numbers every time you run them.


