Building an ERP-Aware Finance Assistant

The question is why a finance team needs another dashboard when most teams already have too many. The answer is not presentation. It is operating speed. When revenue, project margin, billable utilization, and cash timing live in separate reports, the organization spends its attention reconciling the picture instead of acting on it.

What’s at stake is not whether AI can generate a chart. It is whether a team can ask better questions of its financial system without creating a parallel universe of unofficial numbers. From first principles, an AI financial dashboard should not be a novelty layer. It should be a controlled way to retrieve, interpret, and explain the data the business already runs on.

The 07-30 work session focused on that practical problem: building a Claude-connected financial assistant that uses NetSuite as the operational source of truth, supports project profitability analysis, and creates dashboards that a team can share without losing trust in the underlying numbers.

Start With the System of Record

The first design choice is simple: do not make the AI assistant the source of truth.

NetSuite already contains the financial objects that matter: customers, projects, invoices, bills, revenue, expenses, time, departments, classes, subsidiaries, and accounting periods. The assistant should operate as an interpreter and workflow layer on top of those records.

That means the work begins with boundaries:

Which NetSuite records can the assistant read?
Which saved searches or SuiteQL queries are approved?
Which users can access which entities, departments, or subsidiaries?
Which metrics are calculated inside NetSuite versus calculated in the assistant layer?
Which outputs are allowed to be shared with the team?

These questions are not administrative overhead. They are the foundation of useful AI work. If the assistant can answer quickly but inconsistently, it will reduce confidence. If it can answer more slowly but traceably, it can become part of daily operations.

The Core Use Case: Operational Finance Questions

The session centered on a practical set of questions that come up in operating reviews:

Which projects are profitable this month?
Which projects are profitable over their full lifecycle?
Where are margins changing, and why?
Which clients have strong revenue but weak contribution margin?
Which teams are carrying delivery costs that are not visible in standard revenue reports?
What changed since last week?

These are not complex questions conceptually. They become hard because each answer depends on definitions.

Project profitability can mean recognized revenue less vendor costs. It can include labor cost, estimated labor cost, or only posted payroll allocations. It can be measured by accounting period, project phase, customer, practice, or delivery lead. It can include only posted transactions or also committed but unbilled costs.

A useful assistant has to make these assumptions visible. It should not simply return a margin percentage. It should explain the metric path:

Revenue source
Cost source
Period filter
Project filter
Exclusions
Last refresh time
Known gaps

This is where AI becomes valuable. Not by replacing the financial model, but by making the model easier to interrogate.

A Practical Architecture for the Build

The build pattern used in the session followed a simple architecture.

1. NetSuite connection layer

The assistant connects to approved NetSuite data through a controlled method. Depending on the environment, this may use SuiteAnalytics, SuiteQL, saved searches, RESTlets, or an intermediate warehouse.

The important point is not the connector brand. It is that the access pattern is explicit. The team should know which tables, searches, or datasets are available and which are excluded.

For a first version, the connection layer should be narrow. A useful starting scope might include:

Projects and customers
Transactions by accounting period
Revenue and expense categories
Time entries or labor allocations
Invoices and billable status
Project manager or delivery owner fields

A narrow connection makes validation possible. A broad connection creates the illusion of completeness before the team has earned it.

2. Metric definition layer

The second layer defines the measures that the assistant can use. This is where many AI dashboard efforts fail. They connect the data and then let the model improvise the business logic.

Instead, the session treated metrics as governed objects. For example:

Project gross margin = recognized project revenue minus direct project costs, divided by recognized project revenue.

Delivery contribution = recognized project revenue minus direct costs minus allocated labor cost.

At-risk project = project with margin below threshold, negative trend over two periods, or unbilled cost above agreed limit.

These definitions do not need to be perfect at first. They need to be named, documented, and testable.

3. Assistant reasoning layer

Claude’s role is to translate user questions into approved queries and summarize the results. The assistant should be able to answer questions such as:

Show me the five lowest-margin active projects this month.
Explain why Project A’s margin changed from June to July.
Compare profitability by delivery lead for the current quarter.
Identify clients with revenue growth but declining margin.
Create a weekly finance summary for the leadership team.

The assistant should also know when not to answer. If the user asks for a metric that has not been defined, it should state that and offer a nearby approved metric. If the data is missing labor allocations, it should say so before making a profitability claim.

4. Shared dashboard layer

The final layer is the team-facing output. This may be a dashboard, a recurring summary, a Slack or Teams update, or a finance review packet.

The key is that shared views should be generated from the same metric definitions used in the assistant. Otherwise, the organization ends up with two systems: one for conversational answers and one for official reporting.

A good shared dashboard for this use case might include:

Project margin leaderboard
At-risk projects
Margin movement by week or period
Revenue and cost breakdown by project
Unbilled work or cost exposure
Client profitability view
Notes generated from the assistant with links back to source views

The dashboard should not try to show everything. Its job is to focus attention.

What the Assistant Should Do During Review

A strong finance assistant is most useful in the meeting, not only before it.

Imagine a weekly operating review. The dashboard shows three projects with declining margin. A delivery leader asks whether the issue is lower revenue, higher subcontractor cost, or internal labor overrun. Instead of pausing the meeting for manual analysis, the team asks the assistant to break down the movement.

The assistant returns:

Revenue was flat versus prior period.
Direct vendor costs increased by a specific amount.
Internal time entries increased in the final week of the period.
Two invoices are pending approval and not yet recognized.
Margin would improve by a stated amount if the pending invoices post in the current period.

This does not replace the controller or finance lead. It gives them a faster way to test the explanation. The human still decides whether the issue is timing, pricing, scope, delivery execution, or data quality.

Controls Matter More Than Interface Polish

The temptation in a session like this is to focus on the visible result: the clean dashboard, the natural language prompt, the concise summary. Those matter. But the more important work is control design.

A finance assistant connected to an ERP needs guardrails:

Role-based access aligned to financial permissions
Read-only access by default
Query logs for auditability
Approved metric definitions
Clear refresh timing
Source links or query references where possible
Exception handling for missing or incomplete data
Separation between draft commentary and official reporting

These controls are what make the assistant usable beyond a demo. Executives do not need another interesting prototype. They need a system that can be trusted enough to influence decisions.