Internal audit · NetSuite TD3016323
Six months of posting transactions screened for amount, timing, journal, duplicate, and threshold exceptions, with the two categories the account's audit trail cannot support called out first.
1,932 posting transactions were reviewed for the six months to 2026-09-23 across six exception categories. Two of the six could not be tested: the account records a creator on only 49 of the 1,932 transactions (2.5%) and an approval status on vendor bills alone, so user-activity and self-approval exceptions are not observable in this data. The four testable categories produced 83 amount outliers, 515 weekend-dated documents, 8 same-vendor same-amount pairs within a week, and a journal population that needs explaining before anything else.
The findings that matter are few and specific. A single vendor payment of $341,743 on 2026-09-07 is 97 standard deviations above the prior year's mean for payments and carries a card number as its memo. Twelve journals labeled "Beg Balance Entries", worth $5,993,437, were all created on 2026-09-10 and backdated to the first of each month from April to September; they post most of the account's revenue. Three of the largest open customer invoices carry memos that read "TEST" and "Invoices > 30 Days > 50000". And one vendor was billed $33,700 three times in a day. Each is flagged for human review; none has been concluded on here.
createdby and an approver field. In this account createdby is empty on 97.5% of transactions, the approver custom field the prompt references does not exist, and createddate is clustered on a few recent days for most records, which is consistent with a bulk data load rather than day-to-day entry. Those are findings about the audit trail, and they come before any finding about the transactions: an account that cannot say who entered a document cannot support a segregation-of-duties test.| Category | Exceptions found | High risk | Medium risk | Low risk | Total value |
|---|---|---|---|---|---|
| Amount | 83 | 8 | 59 | 16 | $2,036,555 |
| Timing (weekend-dated) | 515 | 0 | 0 | 515 | $1,333,700 |
| Journals (backdated or unlabeled) | 25 | 12 | 13 | 0 | $6,665,437 |
| Duplicates (same vendor, amount, within 7 days) | 8 | 1 | 0 | 7 | $73,674 |
| Approval and user activity | n/a | not testable, see below |
Risk based on: the prompt's classification. Critical is multiple red flags at high value; high is a single major flag; medium is a statistical outlier alone; low is a minor policy exception. Amount outliers are measured against the mean and standard deviation of the same transaction type over the twelve months before the review window.
| ID | Category | Transaction | Amount | Exception | Risk | Action |
|---|---|---|---|---|---|---|
| E-001 | Amount | Vendor payment, 2026-09-07 | $341,743 | 97 standard deviations above the prior-year mean for payments; memo is a card number | Critical | Investigate |
| E-002 | Amount | Vendor bill, 2026-09-03 (Davidson Leasing) | $120,000 | 25 s.d.; new vendor, single bill, no PO, posted to prepaid expenses | High | Investigate |
| E-003 | Amount | VB08 and VB07, same memo, May and April | $110,300 and $69,699 | 23 and 14 s.d.; two large bills sharing one memo reference | High | Priority review |
| E-004 | Amount | INV774, INV783, INV759 | $97,942, $86,007, $53,424 | Invoice memos read 'TEST' and 'Invoices > 30 Days > 50000'; all three unpaid | High | Priority review: planted or test records in a production ledger |
| E-005 | Duplicate | Generation N, three bills of $33,700 within one day | $101,100 | VB05 plus two bills with system-generated document numbers | High | Investigate before payment |
| E-006 | Journal | 12 'Beg Balance Entries' journals dated April to September, all created 2026-09-10 | $5,993,437 | Backdated up to five months; post revenue and balances every month | High | Characterize; decide the reporting basis |
| E-007 | Journal | JE154 to JE158 'Negative Cash Flow', JE160 to JE162 unlabeled | $410,000 and $262,000 | Round amounts, three with no memo | Medium | Document purpose and approver |
| E-008 | Timing | 165 vendor bills and payments dated on weekends | see dashboard | Cash sales on weekends are normal for retail; supplier documents are not | Medium | Scheduled review |
| E-009 | Amount | 18 bills and payments between $9,000 and $9,999 | Against an assumed $10,000 approval threshold; nine are bill and payment pairs for the same amount | Low | Confirm the real threshold |
83 transactions exceed three standard deviations for their type. Most are the large customer invoices and inventory bills that go with a business growing at 20% a year, and the threshold is doing what it should: surfacing the biggest documents for a look. The critical item is E-001, which stands out even among outliers. The duplicate pattern at Generation N (E-005) shows three bills for the same amount in one day, two of them with system-generated document numbers, which is the signature of a re-entered bill; the payment records should be checked to see whether it was paid more than once.
27% of documents are dated on a Saturday or Sunday. For a retailer with point-of-sale, weekend cash sales and fulfillments are expected, and 86 cash sales and 53 shipments account for part of it. Weekend-dated vendor bills (85) and vendor payments (80) are the part to review; supplier documents entered on weekends either reflect a real weekend operation or a back-dating convention. Round-number analysis found 14 of 635 bills and payments over $1,000 at exact thousands (2.2%), under the prompt's 5% low-risk mark.
42 journals posted in the window, $6,684,633 of debits. Twelve are the "Beg Balance Entries" series: two per month, one per subsidiary, each about 62 lines, all created on the same day in September and dated back to the first of the month. They are the account's largest recurring entry and they post revenue, which is why the same series appears as a finding in the period comparison, the flux analysis, and the working capital review of this account. Five journals labeled "Negative Cash Flow" total $410,000 in round amounts, and three of the largest journals have no memo at all. The prompt requires all journal conclusions to go to a person; the recommendation is limited to: explain the series, name an approver, and require a memo.
No approval threshold is recorded in the account, so $10,000 was assumed. Eighteen bills and payments fall between $9,000 and $9,999, nine of them bill-and-payment pairs for the same amount, which is what a real threshold would produce if bills were being split. With the threshold unknown this is documented, not concluded.
| ID | Type | Name | Handle | Scope | Used for | Complete |
|---|---|---|---|---|---|---|
| DL-001 | SuiteQL | Transactions, six months | transaction (posting) with createdby, approvalstatus, day of week | 1,932 rows | All categories | Yes; creator missing on most |
| DL-002 | SuiteQL | Baseline amounts, prior twelve months | transaction (posting) | 4,141 rows | Outlier thresholds | Yes |
| DL-003 | SuiteQL | Vendor bills and payments | transaction (VendBill, VendPymt) | 12 months, 1,087 rows | Duplicates, round numbers, threshold | Yes |
| DL-004 | SuiteQL | Journals with debit totals | transaction join transactionaccountingline, accountingperiod | 6 months, 42 journals | Journal patterns | Yes |
| DL-005 | SuiteQL | Created date vs period end | transaction join accountingperiod | 6 months | Late entries (not usable) | Yes; created dates reflect a bulk load |
Adaptations from the prompt's templates: STDDEV and the correlated subqueries in the templates are not supported in this account's SuiteQL, so baseline statistics were computed in code from raw amounts; the approver field custbody_approver does not exist, and approvalstatus was used where present; journal amounts are null on the header, so debits were summed from accounting lines; transaction.subsidiary is not exposed and no subsidiary filter was applied. The user-activity query was run but every row has a null user.
SELECT t.id, t.tranid, t.type, t.trandate, TO_CHAR(t.trandate, 'DY'), t.createddate, ABS(t.foreigntotal), t.entity,
BUILTIN.DF(t.createdby), BUILTIN.DF(t.approvalstatus), t.memo
FROM transaction t WHERE t.posting = 'T' AND t.trandate > ADD_MONTHS(TRUNC(SYSDATE), -6) AND t.trandate <= TRUNC(SYSDATE)
SELECT t.id, t.type, t.trandate, ABS(t.foreigntotal) FROM transaction t
WHERE t.posting = 'T' AND t.trandate > ADD_MONTHS(TRUNC(SYSDATE), -18) AND t.foreigntotal IS NOT NULL
SELECT t.id, t.tranid, t.trandate, t.createddate, t.memo, ap.periodname, SUM(CASE WHEN tal.amount > 0 THEN tal.amount ELSE 0 END), COUNT(*)
FROM transaction t JOIN transactionaccountingline tal ON tal.transaction = t.id JOIN accountingperiod ap ON ap.id = t.postingperiod
WHERE t.type = 'Journal' AND tal.posting = 'T' AND t.trandate > ADD_MONTHS(TRUNC(SYSDATE), -6) GROUP BY ...| Assumption | Value | Rationale | Impact if wrong |
|---|---|---|---|
| Outlier = more than 3 standard deviations above the prior-year mean for the type | Prompt template | Statistical convention | Count of amount exceptions |
| Approval threshold | $10,000, assumed | None recorded | Just-below-threshold list |
| Duplicate = same vendor, same amount, within 7 days | Prompt threshold (high risk under 7 days) | Standard | Duplicate list |
| Weekend = Saturday or Sunday transaction date | Prompt template | Standard | Timing count |
| Backdated journal = created more than 30 days after its date | Analyst | Conservative | Journal count |
| Test | Objective | Result |
|---|---|---|
| G1-001 | Population complete | Pass all posting types in the window |
| G1-002 | Baseline statistics valid | Pass computed per type from 4,141 prior transactions; types with fewer than 5 skipped |
| G1-003 | User fields populated | Fail creator on 2.5%; approval status on bills only |
| G2-001 | Outlier arithmetic | Pass computed in code; top item verified by hand |
| G2-002 | Duplicate matching | Pass exact amount and vendor, date gap computed |
Confidence: high on the amount, duplicate, and journal findings as descriptions of the records; not applicable on approval and user findings; low on the late-entry test because created dates reflect a data load. Every critical and high item, every user-specific conclusion, and every investigation recommendation is flagged for human review per the prompt.