Your sales manager opens the CRM and sees a strong month. Finance opens the invoicing system and sees a different result. The dashboard displays a third number. Before anyone buys another reporting tool, ask whether those screens are measuring the same business event.
For an Australian SME, this can affect hiring, stock orders and cash planning. A beautifully presented chart is not useful if “sales” means accepted orders to one team, issued invoices to another and money received to the owner. Adding an AI summary can make the disagreement sound more convincing without resolving it.
One customer order can belong to different months
Consider an illustrative example: a customer accepts a quote near the end of October, the business delivers and invoices in November, and payment arrives in December. An orders report, an invoiced-sales report and a receipts report can legitimately show the transaction in different months. None should silently be presented as the other.
This is a reporting-design question, not a recommendation about when to recognise revenue for tax or accounting purposes. Ask your accountant to confirm those requirements. The technology task is to preserve the relevant dates and make the chosen reporting basis explicit.
Microsoft’s Power BI modelling guidance describes this distinction through date roles: a sales event can be analysed by order date, shipping date or delivery date. The choice of relationship determines which question a report answers. A generic filter labelled “Date” can hide an important business decision.
Write a definition that fits under the chart
Pick one important measure, such as monthly invoiced sales. Have the business owner and finance lead agree a short definition before the developer changes the dashboard. For example: issued invoices, excluding GST, less applicable credit notes, grouped by invoice date in the agreed business timezone. Confirm how your own systems represent those items rather than assuming that this example matches them.
That definition should also settle whether drafts, cancelled documents, deposits, freight and multiple currencies are included. If the dashboard reports accepted orders instead, name it “Accepted order value” and define its status rules separately. Do not use one reassuring “Revenue” label for several incompatible measures.
Put the definition, reporting timezone and data-through time within reach of the viewer. A short description beside a chart is more useful than a technical document nobody opens during the Monday meeting.
A correct invoice can still be counted twice
Dates are only part of the problem. An invoice may contain several line items and several payments. If an integration joins each invoice line to every payment and then sums the repeated invoice total, the dashboard can overstate sales even though every source document is genuine.
Ask the developer a plain question: what does one row in this reporting table represent? It might be one invoice, one invoice line or one payment, but those are not interchangeable. Microsoft’s star-schema guidance recommends a consistent level of detail for fact tables and appropriate relationships between tables.
Keep stable source identifiers through the integration. An invoice number may need a source-system or company identifier to be unique. Treat retrying an import as an update to the same source record, not permission to append another sale. Where operationally useful, report excluded or unmatched records separately instead of quietly dropping them.
“Refreshed” needs a precise meaning too
A report can reload successfully while its underlying imported data is still old. Microsoft distinguishes refreshing report visuals from refreshing the imported semantic model. Refreshing a browser page is not proof that today’s transactions have been imported.
Show the last successful source-data refresh and its coverage, not just the time someone opened the report. If CRM data is current but invoice data failed overnight, make that partial state visible. Assign someone to receive and investigate refresh failures.
A live connection can reduce some freshness delays, but it adds source-system load and does not fix inconsistent definitions. For a small business, a dependable daily import with a clear cutoff may be a better fit than a more complex near-real-time design. Choose the frequency around the decision being made.
Prove one reporting period before expanding the dashboard
Use a small, controlled sample in a test environment: an ordinary invoice, a multi-line invoice, a credit note, a cancellation, a part-payment and a transaction close to month-end. Compare the source records with the dashboard using exactly the same dates, statuses and tax basis.
Then re-run the import, change one permitted source record and simulate an upstream refresh failure. Confirm that the second import does not duplicate sales, the change is traceable and the failed refresh does not leave an apparently current report. Keep a record of the agreed expected outcomes and have the business measure owner approve them.
Finally, reconcile a complete period to the corresponding source report. Document any legitimate differences. A stable reconciliation is a stronger acceptance test than matching a screenshot once. When definitions change later, record the change and explain whether earlier periods are being restated or preserved.
If you add an AI assistant to explain the results, give it the approved measure definitions and freshness information. Require its answers to identify the measure and period used. It should flag missing or stale data, not invent an explanation for a number that has not been reconciled.
Xpansion Technologies can help Australian businesses connect reporting data, define consistent measures and test dashboard integrations. Start with one disputed number, its source records and the decision it is meant to support. That gives the project a clear business outcome before more charts or AI features are added.
Sources
- Microsoft Learn: Star schema design, consistent data grain, measures and date roles
- Microsoft Learn: Data refresh in Power BI, refresh types and operational considerations
Leave a comment