From ERP Searches to Board Packs

The question is why a weekly finance sync should spend time on reporting automation when there are open ERP tickets, renewal dates, billing questions, and a new prepaid amortization requirement to handle.

The answer is that reporting is not a side process. It is one of the ways a finance team proves control. When a board pack or management workbook is built through manual exports, copied tabs, broken formulas, and late reconciliations, the risk is not only wasted time. What is at stake is trust in the operating system of finance.

At first principles, a reporting pack should be a repeatable view of live business records. It should not depend on one person remembering the right sequence of clicks. It should not require a weekend of cleanup before every management meeting. It should turn the ERP into a reliable source of structured insight.

The weekly sync as a control point

A weekly sync is often treated as a status meeting. Tickets are reviewed. Owners are assigned. Dates are confirmed. Questions are parked or escalated. That is useful, but the better version of the meeting is a control point for the finance system itself.

In this case, the consultant and client team used the call to cover several active workstreams:

ERP ticket updates and outstanding configuration items
A new requirement for prepaid amortization reporting
Upcoming contract renewal timing
Billing and invoicing questions tied to the renewal
A demonstration of an AI-built reporting workbook connected to ERP saved searches

On the surface, these topics look separate. In practice, they are connected. Prepaids affect management reporting. Billing logic affects revenue visibility. Contract timing affects forecast assumptions. ERP tickets affect the reliability of the underlying data.

The sync became more than a checklist. It became a way to ask whether the finance team had a repeatable system for turning transactional data into reporting outputs.

The failure mode of manual reporting

Many finance teams inherit reporting packs that work only because someone has learned their fragility.

The pattern is familiar:

Export trial balance, transaction detail, prepaid schedules, revenue reports, and departmental spend
Paste each export into a workbook
Rename tabs and adjust date ranges
Refresh formulas and repair references
Reconcile totals back to the ERP
Add commentary for management or the board
Save a new version and hope no linked file breaks

This process may be acceptable when the company is small. It becomes a constraint as complexity grows. More entities, more departments, more subscriptions, more prepaids, more revenue rules, and more stakeholders all increase the number of places where the pack can drift from source data.

The hidden cost is not just hours. It is the narrowing of attention. Finance spends its best thinking time checking whether numbers moved correctly between systems instead of explaining why the business moved.

Saved searches are the foundation

The practical breakthrough was not the AI tool by itself. It was the decision to use ERP saved searches as the source layer.

A saved search is a defined, repeatable query. It captures logic that should not be recreated manually each week or month. For example:

Open prepaid balances by vendor, period, and amortization schedule
Bills pending approval or payment
Revenue and billing records by customer and contract
Department-level expense activity
Balance sheet and income statement detail by period
Exceptions such as missing classifications or incomplete records

When saved searches are designed well, they become finance data products. They are not one-off exports. They are reusable feeds with known fields, known filters, and known owners.

This matters because automation needs stable inputs. If the source files change shape every week, the workbook will remain fragile. If the ERP searches are standardized, the workbook can be rebuilt consistently from live data.

What the AI-built workbook changed

During the call, the consultant demonstrated how an AI tool could generate and refresh a complex financial reporting package directly from ERP data.

The important shift was procedural. Instead of asking a person to assemble the workbook manually, the team defined the desired reporting structure and connected it to saved search outputs. The tool could then build the workbook logic around the data model.

That included:

Pulling the relevant ERP search outputs into a structured workbook
Creating tabs for management reporting, variance views, prepaid detail, and supporting schedules
Mapping fields consistently across reports
Applying formulas and rollups based on defined reporting rules
Supporting repeatable refreshes as ERP data changed
Making exceptions easier to identify before the pack was distributed

This does not remove finance judgment. It moves judgment to the right place.

The team still needs to decide what belongs in the board pack, how prepaids should be presented, which billing questions require follow-up, and what commentary management needs. But the team should not have to rebuild the same mechanical structure every cycle.

Prepaid amortization as a useful test case

The new prepaid amortization reporting requirement was a good test of the system.

Prepaids often look simple until reporting needs expand. A team may start with a basic schedule. Then management asks for monthly rollforwards. Auditors ask for support by vendor. Department leaders ask where costs are landing. The board wants to understand cash paid versus expense recognized.

A manual schedule can handle this for a while. But it usually has weak points:

Start and end dates are entered inconsistently
Amortization logic differs by preparer
Vendor names do not match ERP records
Department or class coding is missing
The balance sheet does not reconcile cleanly to the schedule
New bills are added late or missed entirely

By tying prepaid reporting to ERP saved searches, the team can separate source data from reporting presentation. The ERP holds the transactions and classifications. The saved search exposes the fields needed for reporting. The workbook turns those fields into rollforwards, summaries, and exception views.

This is a better control design. It lets finance see both the answer and the evidence behind the answer.

Renewal and billing questions belong in the same system

The call also covered contract renewal and billing questions. These may seem operational compared with board reporting, but they carry the same systems issue.

If renewal dates, billing terms, invoice timing, and contract metadata are not visible in a structured way, finance ends up managing them through messages and memory. That creates avoidable risk:

Missed renewal deadlines
Incorrect billing start dates
Confusion over contract term changes
Manual revenue or deferred revenue adjustments
Late answers to management questions

The reporting workbook does not need to become a contract system. But it can surface the financial consequences of contract data. For example, it can show customers with upcoming renewals, billing records that do not match expected terms, or revenue activity that needs review.

This is where a weekly sync becomes useful. The team can connect the operational question to the reporting impact. A billing issue is no longer just a ticket. It is a potential variance, forecast change, or cash timing issue.

A practical method for finance teams

The lesson is not to automate everything at once. The better path is controlled and incremental.

1. Define the recurring pack

Start with the reports that are actually used. Board materials, management reporting, prepaid schedules, billing summaries, variance analysis, and close support schedules should each have a clear owner and purpose.

If a tab is not used, remove it. If a stakeholder needs a decision, define the metric that supports it.

2. Identify the source of truth

For each report, identify the ERP object or saved search that should feed it. Avoid relying on offline files unless there is no system source available.

The question should be simple: where does this number come from, and can we retrieve it the same way next time?

3. Standardize the saved searches

Saved searches should have stable names, filters, fields, and documentation. They should be reviewed like any other finance control.

A small change to a filter can change a board number. That change should not happen casually.

4. Build the workbook around the data model

The workbook should be generated from structured inputs, not from copied tabs. Formulas, rollups, and exception checks should be part of the design.

This is where AI can help. It can accelerate workbook creation, mapping, documentation, and refresh logic. But it needs a clear target architecture.

5. Review exceptions, not mechanics

Once the pack is repeatable, the weekly or monthly review can focus on exceptions:

Missing coding
Unexpected balance changes
Unbilled activity
Prepaids without schedules
Contract records with unclear renewal terms
Variances that need management commentary

That is a higher-value meeting. The team is no longer asking whether the workbook was assembled correctly. It is asking what the data says about the business.

The role of AI in finance operations

AI is most useful here when it is treated as a system builder, not a replacement for finance ownership.