From spreadsheets to Power BI: a data and reporting guide for SA councils and small organisations

Most South Australian councils, not-for-profits and small businesses already hold the data they need to run better. It sits in the finance system, the CRM, the asset register, the rostering tool, the customer request system and a long tail of spreadsheets. The problem is rarely a lack of data. It is that every monthly report is rebuilt by hand, two teams quote different numbers for the same measure, and nobody quite trusts the dashboard the last consultant left behind. This guide explains how to move from spreadsheet reporting to a reporting platform people actually use: which option fits your size, how to design it so the numbers stay trustworthy, the governance and privacy controls to build in, and what to ask before you engage anyone. It is general guidance, not legal advice.

Start with decisions, not dashboards

A dashboard is only worth building if it changes a decision. Before choosing any tool, list the five to ten decisions your executive, council or board makes regularly and the measures that inform each one. For a council that might be capital works delivery against the annual business plan, customer request response times, or asset renewal against the asset management plan. For a not-for-profit it might be program outcomes, funder reporting and volunteer hours. For a small business it might be margin by product, debtor days and pipeline conversion.

For each measure, write a one-line definition, the system it comes from, how often it needs refreshing and who owns it. That page becomes your metric register, and it prevents the most common failure in reporting projects: a technically sound platform that shows numbers nobody agrees on.

Four stages of reporting maturity

Organisations rarely need to jump straight to an enterprise data platform. Most progress through four stages, and the right next step depends on where you are today.

1. Spreadsheet reporting. Exports are pasted into workbooks each month. It works until the person who built the workbook is on leave, or a formula silently breaks.
2. Connected self-service BI. A tool such as Microsoft Power BI connects directly to source systems and refreshes on a schedule. This removes the copy-paste and suits most small organisations with a handful of sources.
3. A shared semantic model. Measures are defined once, in one governed model, and reused by every report. This is the stage where two teams stop arguing about whose number is right.
4. A managed data platform. Data from many systems lands in a central store (a lakehouse or warehouse on Microsoft Fabric, Azure or AWS), is cleaned and joined, and keeps history that source systems overwrite. This suits larger councils, agencies and organisations combining many sources, long histories or analytics beyond standard reports.

Each stage builds on the last. If you skip the metric register and the shared model, a bigger platform simply produces inconsistent numbers faster.

Choosing a platform that fits your size

For most Microsoft 365 organisations, Power BI is the natural starting point: staff already sign in with the same accounts, it connects to common finance, CRM and SharePoint sources, and licensing can start small. As data volumes and the number of report readers grow, Microsoft Fabric capacity or a dedicated warehouse becomes worth evaluating. Organisations already invested in AWS can use Amazon QuickSight with S3 and Athena in the Sydney region. The data lake and BI reference architecture in our Learn section shows how those layers fit together.

Whichever product you choose, compare options on the same criteria:

• Total cost of ownership. Licences per creator and per reader, capacity costs, the effort to maintain refreshes, and the internal time to keep definitions current. Check current vendor pricing at the time you decide, because it changes.
• Connectivity. Whether it connects to your actual systems, including on-premises databases, which usually need a secure gateway.
• Security and access. Single sign-on, multi-factor authentication, and row-level security so a manager sees only their area.
• Data residency. Where data and backups are stored. Australian regions are available for the major platforms, but confirm it for each component, including any AI features.
• Exit. Whether your models and data can be exported if you change platforms later.

Design principles that keep the numbers trustworthy

• One definition per measure. Put calculations in the shared model, not in individual report pages, so a change is made once.
• Keep raw, cleaned and reporting layers separate. Raw extracts are kept unchanged for audit, cleaned data fixes known issues, and the reporting layer is shaped for the questions people ask. When a number looks wrong, you can trace it back.
• Automate refresh and alert on failure. A dashboard that quietly shows last month’s data is worse than none. Monitor refreshes and tell the owner when one fails.
• Show data freshness on every page. A simple “data as at” timestamp prevents decisions being made on stale figures.
• Design for the reader. Lead with the three or four measures that matter, use plain labels, and test reports for accessibility (colour contrast, keyboard use and screen reader text) so every staff member and councillor can use them.
• Version control the model. Treat the semantic model like software, with source control, a test copy and a review step before changes reach production reports.

Governance, privacy and security

Reporting platforms concentrate data from many systems, which makes them valuable and also a privacy risk. Build the controls in from the first release:

• Collect only what reporting needs. Most dashboards need counts and trends, not names and addresses. Aggregate or de-identify personal information before it reaches the reporting layer wherever you can.
• Know which privacy rules apply. SA Government agencies work under the Information Privacy Principles Instruction, councils under their own privacy policies and legislative obligations, and many businesses and not-for-profits under the Privacy Act 1988. Check which apply to you and to each data source.
• Least-privilege access. Use groups rather than individual sharing, apply row-level security for sensitive areas, and review access when people change roles.
• Control exports. Decide whether reports may be exported to spreadsheets or shared externally, and log it.
• Classify and label. Agencies should align data handling with the South Australian Information Classification System and their security framework obligations (see our guide to the ISMF for ICT suppliers); other organisations benefit from a simple sensitivity scheme.
• Keep data onshore. See our guide to Australian data residency for SA Government ICT for what to check in contracts and configuration.

Where AI fits

Modern BI tools increasingly offer natural-language questions and AI-generated summaries. These can help, but only on top of a well-defined model: an AI assistant asked about “overdue requests” will give a confident answer whether or not the organisation has agreed what overdue means. Get the metric register and shared model right first, confirm where any AI feature processes data, and apply the same responsible AI practices you would to any other AI use.

A practical first 90 days

1. Weeks 1 to 3: discovery. Agree the priority decisions and measures, build the metric register, map source systems and check data quality on a sample.
2. Weeks 4 to 8: first release. Connect two or three sources, build the shared model for the agreed measures, and release one executive or board dashboard with automated refresh and access controls.
3. Weeks 9 to 12: adopt and extend. Train report owners, retire the spreadsheets the dashboard replaces, set up refresh monitoring, and prioritise the next set of measures.

Retiring the old spreadsheets is the step most often skipped, and it is the one that proves the new platform is trusted.

Questions to ask before you engage anyone

1. Will you start from our decisions and a metric register, or from a dashboard template?
2. Where will each measure be defined, and how do we change a definition later?
3. How will refresh failures be detected and reported, and to whom?
4. How is personal information minimised, and how is row-level security tested?
5. Where is every component hosted, including backups and any AI features?
6. What will it cost per year in licences, capacity and support after launch?
7. Will our team be able to maintain and extend the model without you?

This article reflects common practice as at late 2026. Product features, licensing and privacy obligations change, so confirm current details with vendors and your advisers before committing.

Talk to an Adelaide team

If you want reporting your executive, council or board can trust, talk to us about a reporting discovery or call 0402 401 584. We can start with a short, fixed-price discovery that produces a metric register and a costed plan you can use with any supplier. You can also read about our data and analytics services, cloud and DevOps and managed services.