Financial transparency portals have been widely adopted and unevenly used. The common pattern is an initial launch with substantial visibility, followed by declining traffic, followed by a dataset that stops being refreshed. The projects that avoid this share a small number of design decisions made early.
Decision one: who is this for?
Three audiences want different things and cannot be served by one interface.
- Residents want a small number of answers: where does my money go, how much do we spend on the service I care about, how does that compare to last year. They want a page, not a query tool.
- Journalists, researchers and advocacy organisations want the underlying records in bulk, with documentation. They will not use a dashboard; they will download a file.
- Internal users and other agencies want reliable structured access, usually an API or a scheduled extract.
Serving all three is straightforward provided each is served in its own form. Attempting to serve all three with a single configurable visualisation tool serves none of them well, and it is the most common design.
Publish the bulk file first
If resources permit only one thing, publish a documented, complete extract of transaction-level expenditure on a fixed schedule. It is the cheapest artefact to produce, the most useful to the audience most likely to do something with it, and the least likely to break. Visualisation can follow.
Decision two: what granularity
Transaction-level detail is more useful than aggregated summaries and raises real questions that should be settled in advance: payments to individuals, sensitive law enforcement expenditure, information subject to statutory confidentiality, and vendor information that may be commercially sensitive. Establishing a redaction policy before publication — with categories, criteria, and a named approver — prevents both over-redaction and the far worse outcome of publishing something that should have been withheld.
Publish the redaction policy alongside the data. Unexplained gaps generate more suspicion than explained ones.
Decision three: how it stays current
A portal refreshed manually will eventually stop being refreshed. Automation is not optional for sustainability. The pipeline should run on a schedule, validate before publishing, publish a timestamp of the last successful refresh, and alert an owner on failure. The visible timestamp matters: users encountering data of unknown vintage discount it entirely.
Refresh frequency should match the underlying process. Expenditure detail monthly after close is honest. Advertising real-time data that is in fact monthly damages credibility more than a stated monthly cadence.
Decision four: context
Raw figures without context produce predictable misreadings. Four inexpensive additions prevent most of them:
- A plain-language explanation of fund accounting, and why total spending across all funds is not comparable to the general fund budget.
- Definitions of every field, and a note on what the dataset excludes — payroll detail, interfund transfers, capitalised items, and encumbrances are common exclusions that materially change totals.
- Prior-year comparatives.
- A stated reconciliation to the audited financial statements, or a clear statement that the data are unaudited and why they will differ.
The last is the item that most often causes trouble. A portal total that does not tie to the annual report generates an accusation of concealment, and the explanation — different basis, different scope, different timing — is entirely legitimate but arrives too late if it is not published up front.
Formats and access
CSV for bulk download, with a stable schema and a documented dictionary. JSON via API where an API is offered. Avoid publishing analysis-ready data solely inside a proprietary visualisation product, which makes the entity's transparency dependent on a vendor relationship. Where a dashboard product is used, the underlying extract should be downloadable independently.
Measuring whether it worked
Downloads and API calls, not page views. Page views measure launch publicity. Repeat downloads of bulk files measure whether anyone is actually building on the data — and a portal with modest traffic and a handful of consistent bulk users is doing more good than one with high traffic and no downloads.
This publication is general information and is not legal, accounting, audit or financial advice. See our Disclaimer. Found an error? Write to [email protected] — we correct in place and note what changed.