Live Excel Reporting Add-in

The problem

Finance works in Excel. That is not a failure of NetSuite — it is where the models, the allocations, the board schedules and the twenty years of institutional formula logic live. So every reporting cycle follows the same shape: run the saved search, export CSV, open it, paste into the tab, check the row count did not change, repair the broken references, repeat for the next six searches.

The cost is not the export. It is that the workbook is stale the moment it is built, that nobody trusts a number without knowing when it was pulled, and that a single added column upstream silently breaks a VLOOKUP three tabs away. Reconciliation becomes archaeology.

What finance actually wants is unglamorous: the same saved search they already trust, appearing in a workbook, refreshing on demand, with the columns landing in the same place every time.

What ECOSIRE builds

This is a build-to-order engagement. There is no product to download and no trial account — we build the connectivity layer for your NetSuite account and your specific reports.

Authenticated data endpoints

The core is a set of RESTlet scripts written in SuiteScript 2.1. Each endpoint accepts parameters — date range, subsidiary, department, saved search id, custom segment values — validates them, executes the query, and returns a flat tabular payload shaped for a spreadsheet rather than a nested object graph an analyst would have to unpick.

Authentication uses token-based authentication with OAuth 1.0 signing, so each user connects with their own token issued against their own NetSuite role. Nothing runs under a shared service account, which means permission and subsidiary restrictions apply per user, and access is revoked simply by revoking their token.

Query layer

Two strategies, chosen per report. Existing saved searches are executed by internal id through N/search, so the definition your team already maintains in NetSuite stays the single source of truth — edit the search, and the workbook column set follows. For reports needing joins, unions or window functions that saved searches cannot express, we write SuiteQL executed through the N/query module. Both return through the same endpoint contract, so the Excel side does not care which was used.

Large result sets are paged. The RESTlet returns a page plus a continuation marker, and the workbook query loops until exhausted, so a fifty-thousand-line transaction pull completes without hitting governance limits or a timeout.

Workbook layer

On the Excel side we build Power Query connections against those endpoints, with parameters surfaced as workbook cells rather than buried in query code. A user changes the period in a cell, hits Refresh, and every dependent query re-runs. Query output lands in named tables with a stable column order, so downstream formulas, PivotTables and charts keep working when the underlying data changes shape. Where your team prefers it, we deliver an Office Scripts or VBA refresh helper that drives the sequence and reports errors clearly instead of failing silently.

Every refreshed table carries a timestamp and the parameters used, so any figure in the pack can be traced back to when and how it was pulled.

Scheduled distribution

Where reports need to arrive rather than be pulled, we add a Scheduled or Map/Reduce script that runs the same queries server-side, writes the output to the File Cabinet, and emails it to a distribution list. The logic is shared with the interactive path, so the scheduled pack and the on-demand refresh cannot drift apart.

Governance and logging

RESTlet execution is logged to a custom record — which endpoint, which user, which parameters, row count, duration. Administrators can see who is pulling what and how often, and diagnose a slow refresh without guesswork. Endpoints are deployed with an audience restricted to the roles that should reach them.

Who this is for

Finance and operations teams already on NetSuite whose reporting cycle depends on repeated manual exports. It fits best where the reports are well understood and stable — a monthly pack, a weekly flash, a reconciliation set — and the pain is refresh effort and trust in data recency, not report design. If your team needs entirely new analysis rather than live delivery of existing analysis, say so in scoping and we will scope it honestly.

How delivery works

1. Scoping call. We inventory the reports you want live: which saved searches, which SuiteQL joins, which parameters need to be user-driven, expected row volumes, and how users are licensed for Excel. We also review your token-based authentication setup, role structure and OneWorld subsidiary layout.

2. Fixed quote. A written scope listing every endpoint, every workbook query, every parameter and the delivery method, at a fixed price. Nothing starts until you approve.

3. Build. Developed against your sandbox account as an SDF project, delivered to you at handover.

4. Install in test. RESTlets deploy to sandbox as an unmanaged bundle or SDF deployment. Your team connects real workbooks with real tokens and refreshes against sandbox data. This is where row counts get reconciled against known-good exports and where column expectations get settled.

5. Install in production. After sandbox sign-off, endpoints deploy to production in an agreed window, production tokens are issued per user, and we validate a live refresh end to end.

6. Support window. Two weeks after go-live for defects and calibration. You own the SDF project and the workbook queries afterwards.

Honest constraints

This reads NetSuite data into Excel. It is not a write-back tool — nothing in the workbook edits a NetSuite record, by design, because a spreadsheet is a poor transaction boundary. Refresh speed depends on result size and account load; a pull returning hundreds of thousands of rows is better served by a scheduled server-side extract than an interactive refresh, and we will tell you which of your reports fall on which side of that line during scoping.

Lead time

Typically one working week from approved quote to production deployment, depending on endpoint count and how much SuiteQL is needed versus reusing existing saved searches.