Beyond Native ERP Reporting: A Strategy for Local Government

If you work for a local government that uses a modern ERP, such as Oracle Fusion, to run its business, you know how large it can loom in your day-to-day work.

Enter your timecard? Use the ERP.

Post a manual accounting journal entry? Use the ERP.

Create a purchase order? Pay an invoice? Submit an expense report? ERP, ERP, ERP.

Begin a recruitment? Create a budget transfer? It is ERP all the way down.

What were once separate workflows, manually stitched together through hand-keyed information or custom integrations built by IT, can now converge in one enterprise platform. That is one of the great advantages of a modern ERP. It gives local governments a more consistent and controlled way to execute much of their work.

With one major exception: reporting.

Modern ERPs have dramatically improved transactional processing and workflow management. Yet, many local governments still find themselves extracting reports, combining files, creating lookups, and rebuilding the context required to answer relatively ordinary questions.

This is not a criticism of modern ERP products or the people who create them. The cause of this uneven progress is structural.

Speed and control are not free. Delivering them requires an underlying data architecture that is both siloed and atomized: activity broken into discrete transactions and held inside the module that owns them. That is what makes the ERP fast and reliable, and it is exactly what native ERP reporting inherits. Useful reporting needs the opposite. It is comprehensive and contextualized, not narrow and isolated.

A modern ERP is designed to record transactions quickly, apply controls reliably, and move work through defined processes. Useful reporting asks the data to perform a different job. It must combine related activity, preserve business context, compare periods, cross organizational boundaries, and sometimes draw from systems outside the ERP altogether.

The issue is not that the ERP cannot produce reports. It can. The issue is that the report a local government needs often exists between modules, systems, fiscal years, security roles and even generations of technology.

When the reporting environment does not bring those pieces together centrally, the work does not disappear. It moves out to users.

Someone exports the actuals. Someone else sends the budget. A third person combines the files, adds lookups, and builds a pivot table. Another department creates its own version. Soon, the organization has dozens of slightly different answers to what appeared to be one question.

The lookup-filled workbook is a visible symptom of reporting logic being pushed out to individual users. In practice, this structural mismatch appears whenever a reporting question crosses one of five boundaries: systems, time, access, technology lifecycle, or the limits of the user workflow.

The Problem Is Not Native Reporting. It Is Asking Native Reporting to Do Every Job

Native ERP reporting plays an important role. Local government employees need real-time operational information from the systems in which they work. They need to see transactions, monitor workflows, run statutory reports, and check the current state of a process.

But operational reporting and enterprise analysis are not the same workload.

Oracle's own technical guidance makes this distinction. It describes embedded Fusion reporting tools as appropriate for day-to-day operational and statutory reporting. For cross-application, longitudinal, historical, and externally blended analysis, it points to separate analytical environments. Oracle also advises against using OTBI and BI Publisher for historical data analysis.

The Government Finance Officers Association makes a related point about ERP implementations more broadly. Governments should think beyond the software application and include the business processes, policies, and people that make the system work.

Reporting requires the same systems thinking.

The question is not, "Can the ERP generate a report?" Ask instead: Can this reporting environment answer the organization's real questions without manual assembly, incomplete context or permanent dependence on specialists?

The following five tests help answer that question.

Five Tests for Your ERP Reporting Strategy

These five tests translate the structural difference between transaction processing and reporting into a practical decision framework. Each asks whether the data can remain within its original transactional context or must be combined, reorganized or governed differently to answer the real business question.

1. Does the Answer Need to Cross a System Boundary?

Transaction processing follows the boundaries of the application. Reporting follows the boundaries of the question.

Those are not always the same.

Even in an Oracle-centered environment, related parts of a business process may live in separate applications. At one county that worked with SplashBI, operating budgets lived in Oracle EPM while actuals lived in the ERP. Divisions across the county had to pull reports and perform manual calculations to compare the two.

Each application held a valid part of the answer. Neither held the complete answer.

The county used SplashBI to create one dataset spanning the two environments. A pivot-based budget variance report could then calculate and present the comparison without requiring every division to recreate it independently.

This is the first sign that the ERP is not the reporting strategy. Transaction-oriented systems can manage their respective parts of a process correctly while leaving users to assemble the complete picture.

A broader reporting layer must do more than connect the applications. It must reconcile their levels of detail, align definitions, establish refresh expectations, and present the combined data in a form people can actually use.

2. Does the Answer Need to Cross a Time Boundary?

An ERP records each transaction within a specific period. Useful reporting often needs to remove those period-by-period boundaries and show what happened over time.

A city government panelist at Data Splash described a budgetary control balance review covering fiscal years 2013 through 2026. The native process required the user to run the report separately for each fiscal year, export the results, combine the data in Excel, and then create the required calculations and pivot tables.

The information was in the ERP. The longitudinal view was not.

A custom SplashBI report allowed the city to run the years together and return the information needed to review budget amounts, usage and remaining balances.

This is an important distinction. Storing years of transactions does not automatically make those years available as one analytical view. If users must extract each period separately and reconstruct the timeline themselves, the reporting environment is passing the work of contextualizing time back to them.

Oracle's technical guidance recognizes this difference. It describes embedded Fusion tools as appropriate for real-time operational reporting and recommends a separate analytical approach for longitudinal and historical analysis.

3. Does the Question Need More Context Than Transactional Access Provides?

Transactional security is designed to control what a person may see and do while performing a role. Comprehensive reporting may require a broader view of the same activity without giving that person broader authority to transact.

Another county encountered this distinction in small-purchase reporting. The county monitored whether annual purchasing for a commodity code had reached a $25,000 threshold that would require an annual bid.

A procurement user could run the report and see purchasing across the county. A Parks and Recreation user looking to buy shirts for a summer camp could see only the department's own spending. Its view might show $4,000 and appear unremarkable, even when countywide purchasing for that commodity code had crossed the threshold.

The report was applying the user's transactional permissions correctly. It was still unable to provide the context required for the countywide compliance question.

But does this mean giving every employee unrestricted access? Far from it. Financial, HR and payroll information carry different risks. What a solid ERP reporting strategy does instead is to design analytical security around the purpose of the question, the sensitivity of the data, and the responsibilities of the user.

4. Does the Reporting Obligation Outlive the Transaction System?

An ERP has a lifecycle. Government reporting obligations do not necessarily end with it.

A local government may implement a new ERP, retire the old application and still need to answer questions about transactions recorded years earlier.

A county discussed plans to retain access to seven years of Oracle E-Business Suite data while moving to Fusion. Historical reports would still need to be available after the new system went live.

The local government took a different architectural approach after moving from EBS to Fusion. It retained the EBS database in Oracle Cloud Infrastructure without maintaining the old application front end. The database became a static reporting and archival environment, with SplashBI continuing to retrieve historical financial and HR information.

That access mattered when the city received public records requests. Authorized staff still needed to locate and report on information from the retired application.

Retention requirements vary by jurisdiction and record type. The Florida Department of State, for example, states that the minimum retention period for a public record depends on its nature, content and purpose.

A transaction-oriented strategy can end at system retirement. A reporting strategy must account for what happens next.

It must determine where historical data will live, how its meaning will be preserved, who may access it and how authorized users will retrieve evidence after the original application is gone.

5. Does Self-Service Still Require Users to Rebuild the Context?

An ERP can standardize transactional workflows because those workflows are defined in advance. Reporting questions are less predictable. One answer often produces another question.

This is where the difference between access to a reporting tool and access to an answer becomes especially important.

After several years with Fusion, one county panelist said only one person outside IT had created an OTBI report, and it did not provide what the user needed. Creating the view was difficult. The available data depended on predefined structures and role-based access. Each new variation could bring the user back to IT.

The county saw much stronger demand for Excel-based reporting because people could work in a familiar environment. Its developers also used SQL Connect to investigate Fusion data, understand how different pieces fit together, and troubleshoot reporting issues.

Useful SQL did not have to remain with the developer who wrote it. The team could turn the SQL into a SplashBI data source, build a reusable report over it, and allow business users to run it themselves.

That is genuine self-service. It does not ask every user to reconstruct joins, definitions, security rules and calculations. It centralizes that analytical context, then gives authorized users the flexibility to explore it and ask follow-up questions.

The goal is not to decentralize the technical work of building reports. It is to decentralize the ability to use trusted reporting.

What a Broader Reporting Strategy Must Decide

A reporting strategy centralizes decisions that employees would otherwise make repeatedly and inconsistently in individual reports and spreadsheets.

Strategy Decision	Question to Resolve
Business purpose	Which operational, management, audit and public questions must be answered?
Data scope	Which systems, entities, periods and levels of detail are required?
Definitions	Who owns the meaning of budget, actual, vacancy, headcount or committed spend?
Freshness	Which decisions need live data, and which can use scheduled refreshes?
Security	Should analytical access mirror transactional roles or use a separate governed model?
Delivery	Do users need dashboards, Excel, scheduled reports, SQL access, or natural-language analysis?
Continuity	How will reports, definitions, and historical evidence survive the next migration?
Ownership	Who maintains data models, validates outputs and retires obsolete reports?

Native ERP reporting remains valuable when the question sits naturally inside the ERP process. A broader layer becomes necessary when the question crosses a boundary.

Without that layer, the organization does not avoid integration work. It simply distributes the work across finance teams, analysts, departments, and spreadsheets.

That is why reporting must be planned as part of government modernization, not postponed until after go-live as a cleanup project.

Build the Reporting Foundation Before You Add AI

Conversational AI does not make the structural reporting problem disappear. It makes the quality of the underlying reporting foundation even more important.

A natural-language interface cannot reconstruct history that was not retained. It cannot reconcile incompatible definitions that were never governed. It cannot supply countywide context when the data available to it contains only one department. It cannot turn a collection of disconnected extracts into a reliable answer simply because the question was asked conversationally.

The work still has to happen in the right order.

SplashBI's AI x BI Flywheel follows that sequence:

• CONNECT: Bring Oracle Fusion, EBS, EPM, UKG and other enterprise data into a governed reporting foundation using capabilities such SplashBI Data Pipeline.
• UNLOCK: Give finance, IT and operational teams the right way to work with that data through dashboards, governed reports, GL Connect, Excel-based analysis and SQL Connect.
• ASK: Allow authorized users to ask contextual questions in natural language through SplashAI, embedded within the SplashBI platform at no extra cost.

BI supplies the governed data, definitions, history and security. AI reduces the effort required to explore them.

The purpose of this broader layer is not simply to add another tool. It is to stop every user and department from having to reconstruct the same analytical context independently.

Measure ERP Success by the Questions People Can Answer

For local government employees, it may feel like ERP all the way down. That does not mean it should be ERP-only all the way out to every answer.

A successful ERP go-live proves that the system can process the organization's work. It does not prove that the organization can explain that work across departments, systems and years.

Before calling the reporting work complete, ask:

• Can finance compare budgets and actuals without manually assembling files?
• Can a department see the full scope required for a decision without receiving inappropriate access?
• Can analysts examine several fiscal years in one governed view?
• Can authorized staff answer historical and public records questions after the old ERP is retired?
• Can users investigate a follow-up question without creating another permanent IT task?

If the answer to any of these is no, the ERP may be working exactly as intended. The reporting strategy is what still needs attention.

Talk to a SplashBI public-sector expert about building a reporting layer across current, cloud and legacy systems.