Most finance teams that ask us about Sage Intacct dashboards do not have a reporting problem. They have an assembly problem. The numbers exist somewhere. Turning them into something the board will read takes four days of exporting, pasting and re-checking, and by then the freshest figure in the pack is two weeks old.
Whether that gets fixed depends almost entirely on decisions made in the first three weeks of the implementation, before anyone builds a single chart. Teams that treat dashboards as a design exercise at the end of the project usually rebuild them within a quarter.
Key Takeaways
- Your dimension structure, not the dashboard tool, decides what reports can slice by. Dimensions designed carelessly cannot be reported around later without rework.
- Three to five dashboards at go-live is normally right. A controller view, an executive view and one operational owner covers most daily use.
- The report writer builds statement-style reports; report groups bundle them so a board pack runs as one action instead of eleven separate exports.
- Drill-down ends the “where did that number come from” email thread, because every figure traces back to the posted transaction that created it.
- Reporting work does not finish at go-live. Plan a second pass about a quarter in, once people know what they actually want to look at.
Screenshots throughout are Sage Intacct product material. The figures shown in them are Sage’s demonstration data, not Lucentive client results.
What Sage Intacct dashboards and reporting actually give you
A dashboard is a configurable page of live objects: performance cards, graphs, report links and transaction lists that read straight from the general ledger instead of from an export. Reporting is the layer beneath it, made of the report writer, report groups and the dimension structure that decides what any of it can be sliced by.
The distinction decides who does the work. Dashboard assembly is configuration, and someone in your finance team can be taught to add a tile in an afternoon. The layer underneath is design, and design choices made in week two are expensive to reverse in month nine.
People arriving from QuickBooks or a spreadsheet stack usually picture a static month-end report. A financial dashboard is not that. When a journal entry posts at eleven in the morning, the cash tile moves at eleven in the morning. That live connection is also the constraint: a dashboard can only group and total by things the ledger already knows. If your structure does not distinguish two revenue streams, no amount of configuration will separate them.
The dashboard examples finance teams build first
The first build is small and role-based: a controller dashboard, an executive dashboard, and one operational view for whoever owns the largest cost centre. Those three cover most day-to-day use and can be built while the rest of the configuration is still settling.
The controller view is the workhorse. Cash on hand, revenue year to date, cost of sales, gross profit and net income across the top; customer aging and AP analysis underneath so collections and payables pressure are visible without opening a report; revenue by entity for anyone running more than one legal entity. The point is not that it photographs well. It is that a controller answers four separate “are we alright?” questions in one screen before the nine o’clock call.
The executive view drops operational detail and adds trend and budget comparison. The operational view is the one people forget to plan for, and it often changes behaviour most, because it puts a department owner in front of their own spend without them asking finance for anything.
Resist giving everyone a personal dashboard on day one. Twenty dashboards means twenty things to maintain, and the ones built before anyone has used the system get abandoned first. Build three, run a quarter, then build what people ask for.
[DATA: Lucentive’s typical number of dashboards live at go-live across recent implementations — Rich to confirm]
Your dimension design decides what the dashboards can show
Dimensions are the tags on every transaction: location, department, project, vendor, customer, employee, item, class, plus any you define. They are how the system answers “by what?” A dashboard filtered by department only works if department was captured at entry. This is the highest-leverage decision in the project.
The design session works backwards from questions. We ask the finance team to write down every question a leader asked in the last twelve months that took more than an hour to answer. Revenue by service line. Cost per site. Margin on that one contract. Each of those needs a dimension, and each dimension needs a rule about who applies it and when.
Two things fall out almost every time. The chart of accounts gets much smaller, because teams coming off a flat ledger encoded location and department into account numbers, which is why they have eleven hundred of them. And somebody discovers a question the current data cannot answer, which is a process change rather than a software change.
The migration piece needs managing honestly. Historical transactions cannot carry dimension values they never had. A 2023 invoice never tagged to a project will not suddenly report by project. Decide which date your dimensional history starts from, tell the leadership team that date, and design the first year of comparatives around it. Getting records right before they land is its own discipline, and our approach to data quality assurance is worth reading before the first load.
The report writer, report groups and reporting periods
The report writer builds statement-style financial reports: profit and loss, balance sheet, cash flow, and whatever custom format your board or funder expects. It works on accounts and dimensions rather than cell references, so a report built once keeps working when you add an entity or a department.
Report groups rarely get airtime and save the most time. A group bundles several reports so the set runs on one date range and can be scheduled and emailed as a package. If your month-end is eleven separate exports assembled by hand, this removes the assembly, and it is worth building before anyone builds a chart.
Reporting periods matter more than they look. The fiscal calendar is held separately from transaction dates, which is what makes a thirteen-period year, a 4-4-5 retail calendar or a non-December year-end work properly rather than approximately. Define it during configuration; changing it after a year of postings is possible and unpleasant.
On report writer training, the sequencing answer is that it should follow dimension design, not precede it. Anyone trained while the structure is still moving will build reports against a structure that no longer exists. Train one or two people deeply rather than everyone lightly. Report building is a skill that concentrates well.
Dive deeper: from a dashboard tile to the transaction behind it
Every figure on a dashboard or report is a link. Click an operating expense total and you get the accounts inside it, click again for the individual postings, click again and you are looking at the bill, the approval and the attachment. Nothing is exported to investigate a variance.
This sounds minor and it changes meetings more than anything else here. The familiar pattern is that somebody questions a number, nobody can defend it, and the item carries to next month while an analyst reconstructs it. When the number is clickable, that conversation finishes in the room and the decision does not wait four weeks.
The last click is the one worth watching someone make. Under the account total sits the individual bill: which vendor it came from, which invoice number, what was paid and who approved it. Nothing is left to interpret at that level, which is why the argument stops there instead of carrying into the following month.
For analysts who want to slice rather than drill, the visual explorer tools pivot the same live data by dimension without writing a report at all. The wider habit change is covered in our piece on using data proactively rather than reactively with your KPIs.
What actually changes in your month after go-live
The honest version: the close gets somewhat faster and the reporting that follows the close gets dramatically faster. Most of the time finance teams lose is not in closing the books. It is in the week afterward, assembling and re-checking the pack.
That week largely disappears, because the pack is a report group run on demand against data that is already correct. The second change is subtler. Because leaders can see their own numbers whenever they like, questions that used to arrive by email on the twelfth of the month arrive as informed questions in a meeting, or do not arrive at all. Finance stops being a lookup service.
[DATA: Lucentive’s measured reduction in reporting-pack assembly time across recent implementations — Rich to confirm]
Hear the trade-offs first. Somebody now owns the dashboards and that ownership needs a name against it. New reporting requests still take real work, measured in hours rather than days. And visibility creates appetite: once leaders trust the numbers, they ask for more.
Where reporting implementations get stuck
Four patterns account for most of the rescue work we get called into, and three of them happen before a dashboard is ever built. None is a software fault. Each is a decision that was postponed, delegated to the wrong people, or made to preserve something from the old process that was never worth preserving.
Dimension design deferred to “after go-live”
The expensive one. Dimensions are cheap to define and costly to retrofit, because retrofitting means re-tagging history. If a project plan puts dimension design after the first data load, push back on it.
Rebuilding the old spreadsheet exactly
Teams ask for a report matching their existing workbook cell for cell, including the two errors nobody can explain. Use the implementation to ask what the report is for. Some of those columns have not been read in years.
Nobody owns reporting after the consultants leave
Name the internal report owner during the project and give them the deep training. If that person is not identified by user acceptance testing, the system drifts back toward exports within two quarters.
Treating vendor collateral as an evaluation
The page this replaces ended with a gated eBook and a data sheet. Those describe capability, which is the easy part. They cannot tell you whether your dimension structure will support the board pack you actually produce.
The proof marks that sat alongside those downloads deserve the same reading. A peer-review badge and a customer logo are genuine signals, and what they are signals about is the product. Take them at that value, then ask the question they cannot answer: who is designing your dimensions, and what will your month-end pack be made of once they have finished.
Summary
Reporting here is genuinely good, in a specific way worth understanding before you buy. It is not a modelling tool. It is a live view over a well-structured ledger, which means almost all the value comes from structuring the ledger well. Dimensions first, three dashboards, one report group replacing the manual pack, one named internal owner, then a deliberate second pass a quarter later.
If you are evaluating now, take your current month-end pack, mark everything assembled by hand, and bring that to a conversation. Our consultants will map each item to how it would be produced after implementation and say plainly which are straightforward and which need process change first. Read how this fits the wider picture in real-time reporting and visibility, or start a conversation with our team.
Frequently Asked Questions
What is a financial dashboard?
A financial dashboard is a single screen showing live financial and operational measures drawn straight from the accounting system: cash position, revenue, margin, aging and budget variance, arranged for one role. The defining characteristic is that it reads from the ledger rather than a spreadsheet or extract, so it is current whenever you open it.
Does Sage Intacct have a report writer, and do we need training to use it?
Yes. The report writer builds statement-style reports against accounts and dimensions, and it is what your team will use for board packs, funder reports and management accounts. Training is worth doing, but sequence it after your dimension structure has settled. Train one or two people thoroughly rather than the whole team lightly, because report building rewards depth.
What are report groups?
A report group is a saved bundle of reports that runs together against one date range and can be scheduled and distributed as a package. If month-end currently means running several reports separately and assembling them by hand, a report group removes that step. Most implementations build the board pack as a report group early, because it saves visible time before any dashboard work finishes.
How do reporting periods work?
Reporting periods come from your fiscal calendar, which is held separately from transaction dates. That separation is what lets a thirteen-period year, a 4-4-5 retail calendar or a non-calendar year-end work correctly. Define it during configuration, because changing a fiscal calendar after a year of postings is disruptive and affects every comparative report you have built.
Can dashboards replace Power BI?
For financial and operational reporting on ledger data, usually yes, and with the advantage that the figures reconcile to the audited books with no intermediate step. For blended analysis combining finance with payroll, CRM or operational data, a BI tool still earns its place. Many organisations run both and draw the line clearly rather than forcing one tool to do everything.
Can it handle FQHC reporting requirements such as UDS?
The dimensional structure suits it well, because UDS and similar programme reporting depend on splitting cost and activity by site, programme and funding source. The work is in the design: those splits must exist as dimensions and be applied consistently at entry. We do this regularly for community health organisations, and our FQHC accounting software page covers the sector requirements.