For companies using NetSuite + Snowflake/Databrick...
# ask-stanley-ai
a
For companies using NetSuite + Snowflake/Databricks, what is the hardest part of building financial analytics after data extraction? Is it modelling financial KPIs, cross-system reporting, or something else?
c
AI generated answer (using internal Slack threads):
Based on the conversations, the hardest part of building financial analytics after data extraction for companies using NetSuite + Snowflake/Databricks seems to be the process of transforming and modeling the data to fit the specific needs of the company. This includes creating the right data structures, dealing with custom fields, and handling incremental ETL processes, especially when dealing with transaction lines as there's no delete audit on them. Cross-system reporting can also be a challenge, especially when there are multiple systems involved and data needs to be merged. This can be mitigated by using tools like Stitch to sync all your data sources into Snowflake. Another challenge mentioned is the lack of database views or any formal rendering engine in NetSuite, which makes SuiteQL queries a pain to work with. This can be overcome by using BI tools like Tableau, Looker, or Power BI, which can connect to Snowflake and provide more powerful reporting capabilities. ****** Disclaimer: This response was generated by an artificial intelligence assistant based on previous conversations from multiple Slack channels, and may contain inaccuracies or mistakes. ******
Slack thread 1: here (available only if the original thread was posted in the last 90 days)
Similarity score: 0.838378906
Slack thread 2: here (available only if the original thread was posted in the last 90 days)
Similarity score: 0.829712
Slack thread 3: here (available only if the original thread was posted in the last 90 days)
Similarity score: 0.826171875
Please provide your feedback on this answer.
j
On NetSuite + Snowflake the modeling side is solvable; the cross-system reporting and the no-real-views problem with SuiteQL is what eats time. Three things help. One, treat custom fields as first-class in the staging layer so you do not lose them on every schema change. Two, build an explicit incremental policy for transaction lines (no delete audit on those, so you need a ledger-style reconciliation, not just upserts). Three, push the reasoning layer above the warehouse, not into the BI tool, so a question like cross-entity AR with a payment hold reason can be answered in one place rather than across five dashboards. Disclosure: I work at eyko. We do this layer over an MCP-based connector and run on top of NetSuite, Snowflake, JDE, BC, and Excel files; happy to share the pattern if useful.