Every system ships with reports, and every organisation eventually needs one that was not shipped. The question is what happens then: whether someone can build it in an afternoon, or whether it becomes a change request with a quote attached.
Pre-built reports cover the statutory and the routine — the trial balance, the ageing, the stock valuation, the headcount by department. They should be there and they should be correct. But the questions that actually drive a decision tend to be specific to one organisation and one week, and no catalogue anticipates them.
So look for three things.
**A builder, not a request form.** Someone in the business should be able to choose a source, pick the dimensions and measures, filter, group, and run it — then save it so it is there next month, and schedule it so it arrives without being asked for.
**Reports that respect permissions.** A report builder that ignores row-level access is a data breach with a friendly interface. The same scoping that governs the screens has to govern the query, so a department manager building their own report sees exactly the rows they would see anywhere else.
**A builder that cannot be turned into an injection surface.** This is the part that goes wrong quietly. A builder assembles a query from user input, which is precisely the shape of an SQL injection vulnerability. The safe construction allowlists every identifier — sources, dimensions, measures, operators — and passes values only as parameters, never as text spliced into a query. Ours does that, and there are tests whose only job is to fail if a future change lets user input reach SQL as an identifier.
Ask any vendor how their builder composes its query. The answer tells you how seriously they take the rest of the system.