1 — Source data — live NetSuite tables, no ETL
NetSuite SuiteQL — read-only, no data movement
PostingAccountActivity
transactionLine
transaction
AccountingPeriod
Queries execute directly against NetSuite's analytical tables via SuiteQL. No data warehouse, no ETL pipeline, no replication lag. The number Tessera shows is computed from the same records NetSuite uses for its own reports — same period boundaries, same subsidiary hierarchy, same posting rules.
There is no copy of your data. Tessera reads NetSuite directly. The numbers can never drift from your ledger.
how are those tables queried?
2 — The queries behind each component
Template: Running Balance · Source: PostingAccountActivity
SELECT SUM(apa.amount)
FROM PostingAccountActivity paa
WHERE paa.account IN (1100, 1105, 1110)
AND apa.subsidiary = 1
AND ap.enddate <= '2026-03-31'
GL: 1100, 1105, 1110
Subsidiary: Main Co.
As of: 2026-03-31
Template: Ratio: Trailing Days · Source: transactionLine
SELECT SUM(CASE
WHEN t.type = 'invoice' THEN tl.netAmount
WHEN t.type = 'creditMemo' THEN -tl.netAmount
END) AS credit_sales
FROM transactionLine tl ...
WHERE t.trandate BETWEEN '2026-01-01' AND '2026-03-31'
Accounts: 4000–4100
Types: invoice, creditMemo
Posted only
Excl. intercompany
No query executed. Value 90 read directly from the Query Component record. Stored in the metric definition at sign-off. Part of the immutable record — changing to 60 days requires a new version and re-approval.
Every scope condition is a stored Filter/Scope record — not a buried parameter inside query code. The Controller reviewed these conditions in plain English before signing off.
who defined these queries, and when?
3 — Controller sign-off (the definition is immutable from this point)
| Status | Approved & Active |
| Effective from | 2026-04-15 |
| Effective to | null (currently active) |
| Formula Pattern | Ratio: Trailing Days → (A / B) × C |
| Approval Domain | Finance Operations — Main Company |
✓ Signed off by Controller, J. Morrow · 2026-04-15 14:23 PDT
"DSO measures how long on average the company takes to collect payment after a credit sale. Numerator is the AR trade balance at period-end across accounts 1100–1110, Main Company subsidiary. Denominator is net credit sales (invoices minus credit memos, excluding intercompany) over the same 90-day trailing window. Result is multiplied by 90 to express in days."
Sign-off locks the definition. The formula, queries, and scope filters cannot change without creating a new version — which requires a new sign-off. The number you see today can always be tied back to this exact moment of approval.
what did that definition produce?
4 — The result record (permanent, linked to this exact version)
Component A
AR Balance
,847,320
Component B
Credit Sales
4,623,450
Component C
Window Days
90 (constant)
Component values are stored alongside the result. You can always reconstruct how any number was reached — not just the answer, but every input that produced it.
which version of the definition is the portlet using?
5 — Which version is shown, and why
| Displayed definition | DSO v2 — approved 2026-04-15 |
| How selected | Directly assigned at portlet placement (Resolution Policy: v2) |
| Override? | No — system recommendation accepted |
| Policy scope | Main Company · All subsidiaries · Finance role |
Tessera always knows which definition produced a number and whether it was the system-recommended one. If you override, you write a reason. That reason is permanently on record.
and what does the CFO actually see?
6 — What appears on your dashboard
Days Sales Outstanding
17.52 days
Computed 2 hrs ago · Main Company · Q1 FY2026 · Trailing 90 days
↓ 3.1 days vs prior quarter
▬▬▬▬▬▬ trend
Every Tessera number shows its age. Cache age is always visible — there is no such thing as a silently stale result.
