AI Reporting on Top of ERP
A project profitability report shows how AI can turn ERP saved searches into a controlled reporting layer, if the data and definitions are ready.
The question is why this kind of build matters. A project profitability report is not just a spreadsheet. It is a test of whether the operating system of the business can explain itself: what was sold, who worked, what it cost, what was billed, and where the margin actually went.
What is at stake is not only faster reporting. It is the reliability of decisions made from that reporting. If project managers, finance leaders, and executives each keep a different version of profitability in separate files, the business spends its time reconciling interpretations instead of improving outcomes.
From first principles, the work is simple to describe: take trusted ERP data, shape it into a repeatable structure, and produce a report that people can use without manual assembly. The difficult part is making the path from source system to final workbook explicit enough that the numbers tie out, the edge cases are visible, and the automation can move from prototype to production.
The prototype as a working system
The team reviewed a working version of a client project profitability report requested the prior week. The prototype was built in the ERP sandbox environment using a sequence of saved searches. Those searches pulled the underlying project, labor, cost, billing, and open-item data needed to assemble the report.
The saved search outputs were downloaded and fed into an AI-assisted reporting project. The AI assistant then generated a formatted Excel workbook with:
- A summary tab across all client projects
- Individual tabs for each project
- Navigation hyperlinks between sections
- Flagged open items requiring review
- Structured calculations for revenue, costs, and margin
- Formatting suitable for operational review
The important detail is that the AI did not invent the data. It shaped data exported from the ERP. All values in the workbook tied back to the saved searches down to the penny. That tie-out is what turned the demo from an interesting automation into a candidate for production use.
This distinction matters. AI is useful here because it reduces the manual work of formatting, structuring, and navigating a complex report. It is not replacing the ERP as the system of record. It is acting as a reporting layer on top of the ERP, with the ERP still responsible for source data and accounting integrity.
Why saved searches are the right control point
A saved search is not glamorous infrastructure, but it is often the right control point for this kind of build. It sits close to the source data, can be reviewed by finance and operations, and can be recreated across environments. It also provides a clear boundary between extraction and transformation.
In this case, the sandbox build used saved searches to isolate each major data category. That made the prototype easier to test. If a margin number was wrong, the team could trace it back to a specific search instead of hunting through a large spreadsheet model.
This approach also creates a better production path. Rather than asking someone to manually run reports, paste values, format sheets, and build formulas each cycle, the future process can become more controlled:
- Run or schedule defined saved searches
- Export or retrieve the results
- Feed the data into the reporting workflow
- Generate the workbook
- Reconcile totals to financial statements
- Review exceptions before distribution
The system is not fully automated until controls and reconciliations are in place. But the operating pattern is clear.
The real work: data completeness
The main tension in the review was not the AI output. It was the condition of the input data.
Several employee records in production were missing billing class assignments. That matters because billing class can drive labor categorization, costing assumptions, or project-level reporting logic. If employees are missing this field, the report may still run, but it will require exceptions, manual mapping, or incomplete cost classification.
This is a common pattern. A report request exposes master data gaps that were previously tolerable because people worked around them manually. Once the process becomes automated, those gaps become visible. The automation does not create the problem. It removes the hiding place.
The agreed cleanup step was straightforward: backfill billing class values on employee records in production before the report is treated as final. This is small operational hygiene with large reporting consequences.
Labor cost rates need history
The team also created a custom ERP record to hold labor cost rates. This is the right pattern when labor cost assumptions must change over time without rewriting history.
A simple static rate on an employee record can work for a small model, but it breaks down when rates change. If an employee cost rate changes in July, the report still needs to know what rate applied to work performed in March. Without effective-date logic, updating the current rate can distort historical profitability.
The custom record solves this by separating rate history from the employee master record. Each rate can have an effective date range, allowing the report to apply the correct cost rate based on the transaction or time entry date.
This is a useful example of designing for auditability. The goal is not only to calculate the right number today. The goal is to preserve the reasoning behind that number when someone asks six months later why a project margin changed.
Contractor costs and the risk of double-counting
Contractor labor introduced another important design issue. Contractor hours and costs can appear in more than one place depending on how the ERP is configured. They may be represented as labor activity, vendor bills, subcontractor costs, or general ledger expense.
If the report pulls contractor labor into the labor section and also pulls the contractor general ledger account into out-of-pocket costs, the same economic cost can be counted twice.
The team identified the likely control: exclude the contractor GL from out-of-pocket cost searches when contractor costs are already captured through labor logic. This is not just a formula adjustment. It is a definition decision.
The business needs to decide where contractor cost belongs in the report. Once that definition is set, the searches should enforce it. That prevents each reporting cycle from becoming a debate about whether the same cost is labor, subcontractor expense, or both.
Reconciliation before production confidence
The prototype tied out to the saved searches, which is necessary but not sufficient. Before go-live, the saved searches themselves need to be reconciled against the financial statements and any existing reports used by finance.
Two areas were called out for additional review: subcontractor costs and travel costs. Another colleague had already created an existing saved search for some of this activity, so the new searches need to be compared against that work. If two searches are intended to answer the same question, they should either match or have a documented reason for the difference.
This is where production readiness differs from prototype success. A prototype proves that the workflow can produce a useful output. Production readiness proves that the output can be trusted repeatedly.
A practical reconciliation path would include:
- Recreating all sandbox saved searches in production
- Confirming permissions and ownership for each search
- Backfilling missing billing class assignments
- Validating labor rates and effective dates
- Excluding contractor GL activity where it would double-count labor
- Comparing subcontractor and travel searches against existing searches
- Reconciling report totals to the financial statements
- Documenting known exclusions, assumptions, and review steps
Only after those checks should the report become part of the operating cadence.
What the AI layer actually changes
The AI layer changes the economics of report production. A person no longer has to spend hours building tabs, links, formulas, summaries, and exception flags by hand. The assistant can assemble the workbook once the data is provided in a consistent structure.
But the AI layer does not remove the need for system design. In fact, it makes system design more important. The saved searches need clear definitions. The custom labor rate record needs effective-date logic. Employee records need complete billing classes. Contractor costs need a single treatment. Reconciliations need to be performed before distribution.
The better framing is not AI replacing finance work. It is AI compressing the mechanical part of finance work so the team can spend more time on definitions, controls, exceptions, and decisions.
This is the pattern worth repeating. Start with a report that consumes too much manual effort. Identify the ERP data needed to produce it. Build saved searches as controlled extraction points. Use automation to assemble the output. Reconcile the result. Then move the process into production only after the master data and edge cases are addressed.
Moving from demo to operating process
The project lead gave the go-ahead to move the build into production. That decision was not based on novelty. It was based on evidence: the prototype worked, the values tied out to the saved searches, and the remaining issues were identifiable cleanup tasks rather than unknown technical blockers.
The next phase is disciplined execution. Recreate the searches in production. Clean the employee records. Confirm the labor rate table. Adjust contractor cost handling. Reconcile to financial statements. Then run the report in a real cycle and review the exceptions with the people who own the numbers.
Ultimately, this is how useful automation enters an organization: not as a broad promise, but as a specific replacement for manual work that is already understood. The report existed as a need before the AI assistant entered the process. The assistant made it possible to produce the report faster and with more structure, but the business logic still had to be made explicit.
What this means for operators and executives is that AI reporting projects should begin with source-of-truth discipline. If the ERP fields are incomplete, the saved searches are ambiguous, or the cost definitions are unstable, the output will reflect that instability. Better automation starts with better operational definitions.
The takeaway is simple. An AI-generated workbook can be impressive, but the durable value is the system behind it: clean master data, controlled searches, effective-dated assumptions, clear cost treatment, and reconciliation before trust. That is what turns a demo into a reporting process.