Forensic review · NetSuite TD3016323

Audit Trail Investigation

Transaction lineage, user activity, change history, and anomaly screening across twelve months of posting activity, with the one finding that reframes all the others.

Prepared 2026-09-23 · Scope: posting transactions dated after 2025-09-23, system notes and login audit for the same window · Source: NetSuite via SuiteQL · Prompt: Audit Trail Investigator, NetSuite AI Prompt Library v1 · Standard Review depth

Investigation Summary

Scope: Standard Review. Posting transactions dated in the trailing twelve months (3,361 documents), the system notes recorded against transactions in the same window (1,022 notes), the login audit trail (7,042 events), and the employee master. The account holds 2.09 million system notes in total; 1.68 million of them belong to one custom record type and were excluded as out of scope for a transaction investigation.

The investigation produced one finding that governs every other. The entire twelve-month transaction history was entered into the account between September 2 and September 30, 2026: 2,783 of 3,361 documents (83%) were created more than 30 days after their transaction date, the median gap is 125 days, and 172 documents were created before the date they carry. This is a bulk load, not organic activity. Every timing test in the framework, after-hours entry, weekend entry, sequence analysis, must be read in that light: the patterns are real, but they describe the load, not the business.

Two findings survive that caveat. First, 98.3% of transactions carry no creator at all, so user attribution is impossible for the population; the system notes attribute the load to two user identities, both belonging to the account owner, working mostly through a Suitelet. Second, 45 pairs of transactions share a type, a counterparty, an amount, and a date within seven days, and two of them, an invoice pair and a payment pair, are same-day duplicates that deserve a look.

Transaction Timeline

Based on: creation timestamp against transaction date. The transaction dates run from September 2025 to September 2026, one year of business activity. The creation timestamps run from September 2 to September 30, 2026, four weeks. Everything the account shows as a year of trading was keyed in a month.

The lag is consistent across document types, which is what a scripted load looks like. Vendor bills and payments were entered in one pass, customer documents in another, with medians four weeks apart. Journals were entered last, with the shortest lag, and mostly in the first half of September.

User Activity Analysis

The transaction table attributes only 56 of 3,361 documents to a user. The system notes are more complete: 1,022 notes on transactions in the window, 741 by the identity "Timothy Dietrich" and 278 by "Tim Dietrich", both belonging to the account owner. By context, 835 of the notes were written from a Suitelet, 120 from the user interface, and 64 through the REST API. The load was performed by a script, and the script's user is the owner.

Login audit, trailing twelve months. 7,042 events from 116 distinct IP addresses, 63 failures. The account owner accounts for 6,766 of them, and 5,663 of those are calls to the MCP endpoint, which is programmatic access by an AI tool, not a person at a keyboard. Six other named users logged in during the year. The failures are token expiries (18) and a handful of wrong passwords; one wrong second factor. Nothing in the login trail suggests unauthorized access.

Access review. 51 employee records, 20 inactive, 21 with NetSuite access. No inactive employee retains access. However, 13 employees with access have no login event in twelve months. Those are dormant accounts under the prompt's definition and are listed for review: Abby Kwan, Conner Avery, Dean Nolan, Emma Richards, Frank Davenport, Jeff Shipit, Joel Williams, Larry Nelson, Melissa Seaver, Molly Williams, Rick Ventz, Stella James, Sylvia Belanger.

Change Analysis

125 documents were modified on a day after their creation, 3.7% of the population. The system notes on journal entries, the highest-risk document type, total 29 notes across 10 journals, all from May 2026, and all of them creation events through the REST API or a Suitelet. There are no field-level edits to journals in the window. That is either good news or evidence that journals are created complete by script and never touched, which for this account is the same thing.

The prompt's change-analysis block looks for override actions and deletions. The system notes in scope contain no approval overrides, because the account runs no approval workflow on the document types examined, and the deleted-record log was not in scope for this review.

Anomaly Inventory

Timing

1,786 documents (53%) were created outside 08:00 to 18:00, and 1,239 (37%) on a weekend. Under the prompt's thresholds that is "extensive" after-hours activity and would rate high risk. It does not here. The hour histogram below shows the load running in sessions at 03:00 to 07:00 and 15:00 to 17:00, and the weekday chart shows Wednesday and Saturday as the two busiest days. Those are the hours a person ran a loading script, not the hours a business enters invoices.

Round amounts

18 documents (0.5%) are exact multiples of $1,000. That is well under the 5% low-risk threshold. The largest is a $31,000 vendor bill from Generation N; the rest are small vendor bills and payments to Bedline, Crown Equipment, and Flexsteel. None warrants follow-up on amount alone.

Sequential and duplicate patterns

The prompt's sequential test compares each document with the previous one of the same type. Applied as a duplicate screen (same type, same counterparty, same amount, dates within seven days), it returns 45 candidates. Most are retail cash sales for the same customer at the same price a few days apart, which is ordinary repeat purchasing. Two are not ordinary and are listed first below.

• INV762 and INV763, Macgruber Incorporated, $16,884.00, both dated August 27, 2026. Two invoices for the same amount to the same customer on the same day is the classic duplicate-billing pattern. Human review required: confirm whether both represent shipments.
• PYMT01 and PYMT675, Susan Adams, $934.78, both August 31, 2026. A payment recorded twice would leave an unapplied credit. Human review required.

Evidence Documentation

Every figure above is reproducible from the queries in the appendix. Evidence for the bulk-load finding is the distribution of creation timestamps (3,353 in September 2026, 8 in October 2026, none earlier) against transaction dates spanning twelve months. Evidence for the attribution finding is the creator field, null on 3,305 rows, cross-referenced with the system note author on 1,022 notes. Evidence for the duplicate candidates is the document pairs listed, with internal ids retained in the data extract.

30 / 60 / 90 day framing

• Next 30 days. Document the September 2026 load as a control event: who ran it, from what source, under what approval. Resolve the two same-day duplicate pairs. Review the 13 dormant user accounts and remove access where it is not needed.
• 60 days. Establish why the creator field is empty on scripted documents and have loading scripts run under a dedicated integration user, so that attribution is possible in future. Investigate the October creation timestamps.
• 90 days. Once organic activity accumulates, re-run this investigation on the post-load period only. The timing and sequence tests will be meaningful then, and the September baseline will show what "normal" looks like for this account.

Appendix: Data Lineage

Adaptations from the prompt's templates: the modification-history query joins system notes to transactions by recordtypeid = -30 and recordid, because systemnote.record holds a display name rather than an id; the JSON returned for createddate carries the date only, so the hour was fetched with TO_CHAR(createddate, 'HH24:MI'); transaction.subsidiary is not exposed, so no subsidiary filter was applied; employee.lastlogindate is not exposed, so dormancy was measured from the login audit instead; the sequential-analysis window function was replaced by a duplicate screen computed in code.

SELECT t.id, t.type, t.tranid, t.trandate, t.createddate, BUILTIN.DF(t.createdby), t.createdby, t.foreigntotal, BUILTIN.DF(t.entity), t.memo, t.lastmodifieddate
FROM transaction t WHERE t.posting = 'T' AND t.trandate >= ADD_MONTHS(SYSDATE, -12)

SELECT id, type, TO_CHAR(createddate, 'YYYY-MM-DD HH24:MI'), TO_CHAR(lastmodifieddate, 'YYYY-MM-DD HH24:MI'), TO_CHAR(createddate, 'DY')
FROM transaction WHERE type = 'Journal' OR (posting = 'T' AND trandate >= ADD_MONTHS(SYSDATE, -12))

SELECT sn.field, sn.type, sn.context, sn.name, BUILTIN.DF(sn.name), COUNT(*), MIN(sn.date), MAX(sn.date)
FROM systemnote sn WHERE sn.recordtypeid = -30 AND sn.date >= ADD_MONTHS(SYSDATE, -12)
GROUP BY sn.field, sn.type, sn.context, sn.name, BUILTIN.DF(sn.name)

SELECT sn.recordid, sn.record, sn.date, BUILTIN.DF(sn.name), sn.field, sn.oldvalue, sn.newvalue, sn.type, sn.context
FROM systemnote sn WHERE sn.recordtypeid = -30 AND sn.record LIKE 'Journal%' AND sn.date >= ADD_MONTHS(SYSDATE, -12)

SELECT BUILTIN.DF(la.user), la.status, la.detail, la.ipaddress, la.requesturi, COUNT(*), MIN(la.date), MAX(la.date)
FROM loginaudit la WHERE la.date >= ADD_MONTHS(SYSDATE, -12)
GROUP BY BUILTIN.DF(la.user), la.status, la.detail, la.ipaddress, la.requesturi

SELECT e.id, e.entityid, e.isinactive, e.giveaccess, BUILTIN.DF(e.department), e.hiredate, e.releasedate FROM employee e

Appendix: Assumptions and Verification

Confidence: 95% that the twelve-month history was bulk-loaded in September 2026 (timestamp distribution, system note context, uniform lag); 90% that the two same-day pairs are duplicates worth reviewing; low confidence in any conclusion about user behavior, because the population contains almost no organic activity.