Halaxy Reporting: Native Reports or a Custom Dashboard?

Halaxy already provides reporting. Its reporting guide describes categories including finance, appointments, patients and communications. Begin with the report that most closely matches the question, and check its filters with the person who knows how the practice records its work.

The Practice Dashboard includes revenue, outstanding balances, session value, attendance and practitioner performance, with location, practitioner and date filters. Review the definitions before using a figure in another report. For example, its revenue measure includes processing fees and deposits, while its session-value measure includes paid and unpaid appointment invoices.

That detail matters when two reports appear to disagree. Before building a new calculation, establish whether the existing figures use the same date range, records and definition. A different total can be the result of a different question.

If the recurring task is running the same report, check Halaxy's recurring-report feature. It can run a saved report on a schedule and refresh its results. The documentation notes that each run overwrites the previous version, so retaining historical snapshots is a separate requirement.

Run the native option through a normal reporting cycle before deciding it is insufficient. Ask the person who prepares the report what work remains: joining another source, checking exceptions, applying a calculation, or distributing information to a particular audience.

Write down that remaining work. It gives a custom project a testable purpose and makes it possible to check whether the work was actually removed after delivery.

A useful brief names the decision, the person making it and the information required. For example: an owner wants to review practice activity beside costs held outside Halaxy before a weekly operations meeting. The brief needs to explain how that combined information changes the meeting's decisions.

List the source for each measure. Agree which date determines inclusion, how cancelled or reversed records are treated, and whether a payment date or service date answers the question. Keep a link or reference back to the records so a surprising total can be checked.

Start with a small view containing only the measures needed for the first decision. Show when each source last updated. If one connection fails, preserve its last successful result and make the stale state clear. Missing information should remain unknown rather than becoming a zero.

Give a total a route back to its contributing records. For a combined view, show which source supplied each part. This lets the team distinguish a changed business result from a failed import or a different calculation.

Where a calculation differs from Halaxy's own definition, name and explain it. A custom figure should not reuse a familiar report label while quietly changing what is counted. Agree the definition with the people who will rely on it.

Check the proposed fields against the current API access table and the intended account's permissions. The presence of information on a screen does not establish that a separate application can retrieve the same fields.

Choose a complete reporting period and compare the proposed view with the records the team already trusts. Keep a record of every difference and its explanation. Repeat the comparison after a source record changes and after an import is deliberately repeated.

Ask the intended reader to use the view in the real meeting or review it was designed for. Can they answer the original question? Can they find the records behind an exception? Does someone know what to do if a source stops updating?

A custom dashboard earns its place when it supports that defined job and can be maintained. If the native report provides the answer, keep using it. If a connection is needed, the Halaxy integration checklist covers access and failure handling; the Xero sync guide covers an existing connection to check first.