NetSuite GL Audit Numbering: Permanent vs Repeatable

Executive Summary

NetSuite GL audit numbering has two sequence types, permanent and repeatable. The choice should be approved before the first production run. A permanent run fixes the audit number assigned to a posting transaction, even if that transaction is later deleted. A repeatable run can be executed again to address gaps, but a rerun renumbers transactions and can change numbers already cited in a close package. These are documented system behaviors, not judgments about which type satisfies a jurisdiction's rules. ^{[1] [2] [3] [4]}

The first question is whether a law, statutory filing, auditor instruction, or adopted internal policy calls for sequential numbers on general ledger posting transactions. An invoice-number requirement is a different question. European Commission guidance describes a unique sequential invoice number and also points to national invoicing rules; the UK's VAT guide likewise addresses a number identifying the invoice document. Neither statement, by itself, establishes that a NetSuite GL audit sequence is required for a particular entity. Qualified local advisers should determine the obligation and the required scope. ^[5] (Source: taxation-customs.ec.europa.eu) ^[6] NetSuite's GL audit numbers are independent of ordinary auto-generated transaction numbering.

The configuration decision has several axes. NetSuite offers base accounting period, quarter, or year timing, and in OneWorld and Multi-Book Accounting a sequence can be scoped by subsidiary and book. A permanent sequence excludes future-dated transactions at its run date, while a repeatable rerun includes future-dated transactions in its sequence. Approval is another boundary: transactions subject to an approval process do not receive GL audit numbers until approved or reviewed. The preflight therefore has to compare the intended population with the Review page, approval queue, period and book, not merely check whether a run button is available. ^{[7] [8] [9]}

The practical control is a documented decision and an evidence-bearing run. Record the requirement, sequence type, period, subsidiary, accounting book, ordering, eligible population, unapproved items, run operator, validation result, reviewer, and treatment of any exception. The GL Audit Numbering report and run status provide the system-side evidence; a separate sign-off record preserves the business decision. ^{[10] [11]} Audit guidance on completeness testing and identifying review dates supports this design as a control principle, without turning vendor behavior into legal advice. ^{[7] [12]}

Introduction and Background

General ledger (GL) audit numbering is NetSuite's mechanism for applying gapless sequences to GL posting transactions. It is a period-close control when the feature is enabled, and the task appears in the final month of the configured period. Administrators can also set up and run sequences on demand. The important decision is not the screen navigation. It is whether an organization needs fixed identifiers after issue, or a sequence that can be regenerated after adjustments, and whether the chosen unit of account matches the requirement. ^{[13] [14]}

Transaction numbers, document numbers, and GL audit numbers serve different purposes. NetSuite's auto-generated internal transaction numbers are assigned when records are saved; document numbers can be external references such as vendor bill numbers. GL audit numbering is independent of those numbering schemes and targets transactions that post to the ledger. A sales order can have a document or transaction number without being a numbered GL posting transaction. The UK invoice rule is a useful illustration of why a document sequence must not be confused with a ledger sequence. ^[6]

The decision is especially consequential for a company with multiple subsidiaries, accounting books, approval workflows, or late adjustments. The finance team should obtain a written statement of the required numbering population and whether changes to an assigned number are permissible. Local statutory and tax treatment depends on the jurisdiction and facts; this report describes the NetSuite mechanics and an implementation control, not a universal compliance determination. (Source: taxation-customs.ec.europa.eu) The European Commission notes that national rules supplement its invoicing framework, while Microsoft advises consulting an auditor or accounting manager before allowing gaps in a number series. Those sources concern different products and obligations, but they reinforce the need to resolve the policy first. (Source: taxation-customs.ec.europa.eu) ^[5]

Houseblend offers NetSuite implementation work spanning process design, roles, permissions, workflow setup, testing, and launch support. That makes a written sequence specification and a sandbox test natural implementation deliverables; ^[15] the choice of sequence type remains an accounting and local-adviser decision. ^[16]

Permanent GL Audit Numbering

Capabilities

Permanent numbering assigns a GL audit number that cannot be changed after the run. Oracle explicitly states that this remains true even if the underlying transaction is deleted. The transaction's details can still be modified, so a fixed audit number is not the same thing as a locked GL impact. If the separate GL Impact Locking feature is enabled, changes to relevant fields on a numbered transaction generate copy and reversal transactions. The numbering sequence must have run before that edit for the adjustment behavior to apply. ^{[3] [17]}

A permanent run numbers transactions through the run date and does not number future-dated transactions at that point. The team must decide how later eligible postings will be brought into the numbered population, including whether a recurring permanent sequence is suitable. The configured ordering also matters: NetSuite offers transaction date or transaction entry date. A policy that promises chronology by one date cannot silently run by the other. ^{[8] [18]}

Adoption and fit

Permanent is the defensible candidate when the approved requirement calls for a fixed reference to a posted transaction. This is a decision rule, not a claim about the prevalence of permanent sequences or a guarantee of legal compliance. The fit also depends on whether deletion is allowed, whether GL Impact Locking is configured, how the entity handles reversals, and how unresolved exceptions are documented. Zoho Books documents an analogous permanent option that cannot be regenerated, while Odoo describes secured posted entries that can no longer be edited. These comparisons show distinct control designs, not equivalent legal outcomes. ^{[19] [1] [19]}

For NetSuite OneWorld, specify the subsidiary in the decision record. Oracle allows a subsidiary in only one GL audit sequence for a given period; it also documents book-specific sequences under Multi-Book Accounting. An intercompany journal can receive a different GL audit number for each subsidiary represented. This makes a single group-wide count an inadequate substitute for a subsidiary and book reconciliation. ^{[8] [20]}

Strengths and limitations

The main strength is identifier stability: a reviewer can refer to the assigned GL number without planning for a repeatable rerun to move it. The limitation is equally concrete: deletion or a later change in the population may leave an apparent gap that cannot be repaired by changing the permanent numbers. A reviewer should explain such a gap through the applicable audit trail and sequence history; no generic number of acceptable unexplained gaps exists. Infor's separate journal-numbering documentation illustrates why an allocated number and a successfully posted journal need different evidence, since an invalid journal can retain its assigned number. This is a control analogy, not NetSuite behavior. ^{[21] [22]}

• Before selection: document why a fixed number is required and which transactions count.
• Before first run: resolve approvals, date boundaries, exclusions, subsidiary and book scope.
• After run: preserve validation, the numbered report, operator and reviewer sign-off.
• After adjustment: trace the original, reversal, copy, or new posting according to the actual configuration. ^[23]

Repeatable GL Audit Numbering

Capabilities

Repeatable numbering permits rerunning a sequence after ledger adjustments. Oracle says a rerun renumbers included transactions and may give a transaction a number different from its prior number. This is useful when the desired final output is a gapless current sequence, but it changes the audit reference between runs. A report exported before the rerun therefore needs a run timestamp and version context to remain interpretable. Oracle's run page shows the previous last number, run date, operator, and status, which can anchor that context. ^{[23] [4]}

Repeatable reruns include future-dated transactions in the sequence. ^[9] They can also be affected by changes to the GL Audit Numbering Method; Oracle warns that numbers assigned through repeatable sequences may be renumbered when that method changes. A team should test both a late posting and a method change in a sandbox before relying on a production export as a stable reference. Zoho's separate implementation of repeatable audit numbering similarly replaces existing numbers on regeneration, an external reminder that rerun semantics deserve explicit approval. ^{[5] [24] [25]}

Adoption and fit

Repeatable fits an approved policy that values a regenerated final numbering set and permits the references to move. It is a poor fit for a requirement to preserve an originally assigned number permanently. This assessment follows directly from Oracle's documented rerun behavior; it does not infer any particular country's rule. Microsoft Dynamics 365 Finance likewise distinguishes continuous and noncontinuous sequence designs and notes that a continuous ledger-voucher requirement varies by jurisdiction. A requirement statement needs to name the ledger, document, or voucher population before a system design is selected. (Source: taxation-customs.ec.europa.eu) ^[2]

There are no public, comparable adoption or run-time benchmarks in the sources reviewed for the two NetSuite types. The useful comparison is functional. A controller can ask which outcome is required after a deletion, a late journal, or a corrected posting: maintain every originally issued identifier, or regenerate an internally complete current set. The answer governs both the sequence type and the evidence-retention procedure. Tvarana's practitioner guide describes using the status page to reach a completed run report; that report should be retained for each material repeatable run. ^{[12] [26]}

Strengths and limitations

The strength is the ability to rerun after GL changes; the limitation is reference instability. If invoices, workpapers, or statutory exports quote a GL audit number, a repeatable rerun may require reconciliation from the old run to the new one. The team should keep both versions and an explanation of what changed, instead of overwriting the earlier extract. Sage's audit trail documentation shows the general value of retaining action, user, time, and transaction reference; the exact NetSuite evidence should still come from NetSuite's run history and report. ^{[27] [28]}

• Approve a rerun trigger: define which adjustments require another run.
• Freeze each extract: label every report with scope, run time, and operator.
• Reconcile references: retain a crosswalk when numbers changed.
• Sign off again: validate the new run and document what happened to open exceptions. ^[29]

Feature Comparison

Table 1 compares the two NetSuite sequence types and the implementation service relevant to putting either into production. The service row is explicitly a delivery option, not a third GL audit sequence type. ^[1]

The table's decisive axis is whether a previously issued reference may change. Permanent is stricter about the reference; repeatable is more flexible about regenerating the sequence. Neither choice removes the need to test approval, posting, subsidiary, book and period boundaries. ^[7] Zoho Books also exposes permanent and repeatable choices, but its country-specific setup should not be imported into a NetSuite configuration. ^[1]

Sequence scope deserves a separate sign-off. Oracle's setup supports base period, quarter or year; transaction or entry date order; subsidiary selection in OneWorld; and book-specific configuration with Multi-Book Accounting. A subsidiary's participation and the actual GL lines in a given book determine which records can receive a number. For a transaction with lines in one book but none in another, Oracle numbers it in the former and ignores it in the latter. ^[30]

The comparison also distinguishes the numbering decision from the locking decision. Permanent audit numbers do not, by themselves, prevent edits to the original transaction. GL Impact Locking is a separate feature dependent on GL Audit Numbering. Odoo's secured-entry model is an example of a different product making edit restrictions explicit; it is useful only as a prompt to verify the control requirement, not as an implementation substitute. ^{[19] [31] [19]}

Performance and Benchmarks

No fetched source supplies a controlled, comparable benchmark for how long permanent versus repeatable NetSuite runs take, how many transactions per minute each processes, or a universal acceptable gap count. Performance claims would therefore be speculative. The observable measures are population completeness, run completion, validation status, exception age, and stability of references after any rerun. NetSuite's Status page reports assigned numbers, percent complete, and records found, while its Validate action tests whether an existing sequence is gapless. ^[32]

For the close team, the strongest benchmark is a reconciled population rather than elapsed minutes. Compare eligible transactions in the Review page with the posting population for the selected period, subsidiary, and book. Then compare the assigned range and record count with the GL Audit Numbering report, excluding known nonposting or intentionally excluded items with documented reasons. The Institute of Internal Auditors frames completeness testing as asking whether all relevant data are included. RSM's practitioner discussion similarly identifies completeness of a posting-transaction listing as a useful audit purpose. ^{[33] [7] [33]}

The NetSuite run itself must finish before sign-off. A displayed Running, Pending, Processing, Retry, or Failed state is not evidence of a completed sequence. The operator should retain the completion status and then validate, or investigate an Invalid or Re-Run indication. Infor's journal-numbering controls provide a useful comparison: its audit table records the assigned number, date and time, operator, and status, and its separate posting report can explain numbers that did not result in posted journals. The principle is to retain the run trail, not merely the latest ledger extract. ^{[21] [21]}

Microsoft Business Central's number-series guidance separates series for different record types and advises auditor or accounting-manager consultation before allowing gaps. That does not set NetSuite rules, but it supports a practical benchmark: a sequence specification must say exactly what population and what kind of gap the reviewer is testing. A missing number in a document series, an unapproved record without a GL number, and a deleted permanently numbered posting are different exceptions. ^{[34] [5]}

Period-End Preflight and Exception Control

Determine the eligible population

Oracle's Review page lists transactions available for a GL audit sequence before numbers are assigned. Transactions under approval do not receive a GL audit number until approved or reviewed. The preflight should reconcile that list to a saved search of expected posting transactions and independently inspect the approval queue. A nonposting transaction is outside the GL posting population even if it has a transaction or document number. ^{[34] [35] [36]}

Table 2 maps common exception classes to a review action. Its outcome column is a proposed control response, not a statement that every listed item is always included in every configuration.

The table should become a saved exception register with record identifiers and decisions, not a fixed list of tolerated gaps. ^[5] Under a company-specific policy, a reviewer may need evidence of a void, deletion, reversal, new approval, or the absence of GL lines in the chosen book. Sage's audit-trail design illustrates the usefulness of recording additions, edits and deletions as separate events; NetSuite's own searches and system notes should supply the actual record-level evidence. ^{[37] [37]}

Run a sequenced preflight

• Confirm authority: capture the approved legal or policy requirement, entity, period, book and intended transaction population. The European Commission and UK sources address invoice numbering, illustrating why a ledger requirement needs its own analysis. (Source: taxation-customs.ec.europa.eu) ^[6]
• Confirm configuration: check that Accounting Periods and GL Audit Numbering are enabled, the method is correct, and the operator has Full Manage Accounting Periods permission for sequence setup and run. ^[38]
• Confirm timing: complete upstream close tasks and review period-end journals, intercompany entries, currency revaluation and any planned adjustments before the run. Oracle places GL Audit Numbering before Close Period; Quick Close does not run closing tasks.
• Confirm approvals: search pending entries, resolve ownership, and check whether approval will change the posting period. This is material because a record can move into a different period on approval.
• Confirm scope: compare the Review page with expected GL postings for each subsidiary and book. Check future dates, entries posted to a closed base period under a quarter or year method, and explicit exclusions.
• Confirm control design: if GL Impact Locking is planned, test its effect on edits after numbering. Do not infer that a permanent GL number alone freezes transaction details.
• Confirm evidence route: identify where the GL Audit Numbering report, sequence history, run status, saved search and reviewer decision will be retained. The IAASB's audit-evidence framework emphasizes judging whether evidence is sufficient and appropriate. ^[39]

Execute, validate and sign off

The operator selects the intended sequence and uses Validate to check its current gapless status, then runs it and waits for a completed state. The report lists GL posting transactions in number order and can be filtered by sequence; it shows the GL number alongside transaction date, record number, type, period, account and amount. The reviewer should verify that report against the approved scope and exception register, then sign the run record. Tvarana's current how-to also points users from the status page to the completed report. ^{[40] [26]}

If the period is already closed and a GL-impacting correction is necessary, NetSuite requires reopening it before that change can post. Reopening can also reopen later closed periods. A repeatable sequence may need another run; a permanent sequence requires analysis of how the new posting receives its own number without rewriting prior numbers. The local policy should define whether prior extracts are supplemented or replaced.

Data Analysis and Evidence

The most useful quantitative evidence available for this decision is configuration and population data from the specific account, not market statistics. Oracle documents three timing choices: Base Accounting Period, Quarter, and Year. ^[41] For a conventional twelve-month calendar, a base-period control offers twelve monthly decision points, a quarterly control four, and a yearly control one. These are simple planning counts, not NetSuite throughput benchmarks, and a nonstandard fiscal calendar changes the schedule. ^[8] The timing choice also determines how much activity can accumulate before numbering.

Table 3 is a hypothetical control-log template. Its fields are placeholders, not an invented run result or an acceptable-gap threshold. ^[7] Each production run should fill the values from NetSuite reports and the exception register.

The log deliberately contains no prefilled number of permitted gaps. A zero in an exception field is meaningful only after the population and exclusions have been reconciled. The Institute of Internal Auditors calls attention to completeness of test data; the PCAOB's audit-documentation standard names reviewer identity and review date as evidence attributes. These are control-design references, not a claim that those standards impose this exact NetSuite template on every company. ^{[10] [11] [7] [12]}

Three test cases should be executed in a sandbox before the first production run. Pending approval: create a GL-impacting entry awaiting approval, inspect its Review-page treatment, approve it, and confirm its period and eligibility. Closed period and late adjustment: close a base period in a test calendar, make the permitted correction path explicit, and assess the sequence outcome. Rerun: export a repeatable report, alter the eligible population, rerun, and compare old and new GL numbers. A fourth test should cover a future-dated posting, because Oracle documents a type-specific difference there. Keep the transaction identifiers, screenshots or extracts, and reviewer result for each test.

Several external systems underline why a general benchmark would be misleading. Infor assigns some journal numbers before posting and can retain a number when posting fails; Odoo's secure-entry model restricts later edits; Microsoft Business Central distinguishes financial transaction series from other record series. Their documentation describes different event timing and controls. NetSuite's permanent-versus-repeatable decision should therefore be evaluated against its own posting and rerun behavior, not against a generic promise of gaplessness. ^{[22] [22] [19] [34]}

Implications and Future Directions

The first implication for a controller is a change-control requirement. Once a permanent run assigns numbers, they cannot be changed. Once a repeatable run is cited in another workpaper, a rerun may require an old-to-new reference reconciliation. The decision memo should state which event is permitted, who authorizes it, and which report version is authoritative for the close. Oracle warns that changing the GL Audit Numbering Method can renumber repeatable assignments, so a preference change also belongs under finance change control.

The second implication is a scope requirement. OneWorld subsidiary and Multi-Book dimensions make a single entity-wide number count potentially misleading. A controller should sign off the population for each required subsidiary, book and period, including transactions with no GL lines in one book and intercompany journals with separate subsidiary numbers. Microsoft Dynamics 365 Finance also scopes sequences by organizational and fiscal dimensions, which reinforces that sequence boundaries are design choices rather than cosmetic prefixes. ^[8]

The third implication is an evidence requirement. Keep the approved policy, configuration snapshot, Review-page population, approval exceptions, run status, validation, numbered report, and reviewer sign-off together. The run history can be viewed for a period even after it closes, but an exported close package needs its own version label if later activity can change the result. The COSO framework describes using relevant, quality information in internal control, and the Institute of Internal Auditors recommends documenting the process before testing controls. ^{[11] [29]}

Responsibility should be explicit. The controller owns the policy decision and exception acceptance; the NetSuite administrator owns configuration and access; the statutory-reporting lead or local adviser confirms jurisdictional scope; the close operator runs and exports the sequence; an independent reviewer reconciles and signs the evidence. This is a proposed role split, not a NetSuite-mandated role model. Houseblend's published implementation scope includes roles, permissions, workflows and testing, which are the concrete workstreams needed to put that split into operation. ^{[15] [16]}

Frequently Asked Questions (FAQs)

Is GL audit numbering required for every NetSuite account?

No universal requirement follows from the feature's existence. Oracle describes its purpose as numbering GL posting transactions for international compliance needs. The entity must establish its applicable jurisdictional or internal requirement. An invoice-number rule, such as the European Commission's unique sequential invoice identifier, does not alone establish a GL audit-number requirement. (Source: taxation-customs.ec.europa.eu)

Can a permanent GL audit number be changed after a deletion?

Oracle says no: the assigned number cannot be changed even if its transaction is deleted. The appropriate response is to investigate and document the deleted transaction and any resulting gap under the applicable policy, not to assume an acceptable gap count. ^[21] Infor's journal audit example shows why a number's history may matter even when the posting population changes. ^{[3] [21]}

Can a repeatable rerun change old numbers?

Yes. Oracle says a rerun renumbers transactions and may assign a different number. Store the old and new reports and reconcile any references already used outside the current NetSuite view. ^[25] Zoho Books documents a comparable regenerate behavior in its own GL audit-number feature, though its product rules are separate. ^{[4] [25]}

How is a sequence set up and when is it run?

An administrator enables Accounting Periods and GL Audit Numbering, selects a Base Accounting Period, Quarter or Year method, and configures the sequence's type, scope and ordering. The close checklist presents the task in the final month of the chosen period; an on-demand path also exists. Validate and review the eligible population before Run, then retain the completed report and sign-off. ^[26]

What causes missing or unexpected GL audit numbers?

Check whether the transaction posts to the GL in the selected book, is approved, is inside the relevant period and run-date boundary, or is excluded by configuration or script. Then check deletion, reversal and later adjustments. The Review page, saved searches and GL Audit Numbering report answer different parts of that question; a document number alone does not prove GL-number eligibility. ^[34]

Does OneWorld require one sequence for the whole group?

No. Oracle permits subsidiary scoping and book-specific sequences, and it notes that a subsidiary can be in only one sequence for a given period. Intercompany journals can receive separate numbers for the subsidiaries represented. Define the entity and book boundary in the requirement memo. ^[8]

Conclusion

Permanent versus repeatable is a policy and evidence decision. Permanent holds the assigned GL audit number fixed, including after deletion; repeatable can repair a current sequence by rerunning it, but the rerun may change previously assigned references. The finance team should decide which outcome the applicable requirement permits before any production assignment, then record that decision beside the sequence configuration. ^[5]

A sound period-end run starts by defining the eligible population for the chosen period, subsidiary and accounting book. It checks approvals, future dates, late adjustments, nonposting records and explicit exclusions before the operator runs the sequence. The completed run should be validated against the GL Audit Numbering report and retained with its status, run time, reviewer, and exception decisions. This is how the feature becomes a reviewable control rather than a checkbox in the close checklist. ^{[29] [12]}

The legal conclusion remains local. A tax invoice sequence, a GL audit sequence, and an immutable posting record are related but different controls. Qualified advisers should confirm the statutory population and retention requirements; (Source: taxation-customs.ec.europa.eu) the NetSuite administrator and controller should then test the documented behavior in a sandbox and govern every production change to the method, scope or rerun procedure. ^{[29] [11]} (Source: taxation-customs.ec.europa.eu) ^[5]