Verity reads the stock database you already have and shows you where your capital is sitting still. Report definitions are data — JSON, not code — and an engine compiles them to SQL.
Which means the guarantee runs deeper than a style guide. A report that would produce a wrong number is not a report Verity can express.
One real dataset, one question — how much capital is trapped in dead stock? A naive join answers it one way. Verity answers it another. Only one of them is right, and the wrong one never says so.
€1,276,727
reported as dead stock
Rows fan out across a to-many join and the same stock is summed once per matching child row. No error is raised. No warning appears. The figure is plausible, it balances against nothing, and it is wrong by three quarters of itself.
€327,056
actually trapped in dead stock
The to-many side is pre-aggregated before it is joined, so each unit of stock can be counted exactly once. This is not a setting you remembered to switch on. It is the only shape the engine can compile.
Both bars are drawn on one shared scale, 0 to €1,276,727.
of stock that was never there — almost four times the real figure, returned without a single error message. That is the gap a plausible-looking number hides, and the reason a tool that merely lets you be careful is not enough.
| Measure | Naive join | Verity |
|---|---|---|
| Dead stock reported | €1,276,727 | €327,056 |
| Difference from the correct figure | +€949,671 | €0 |
| Share of the shared scale | 100% | 25.6% |
| Error surfaced to the user | None | None needed |
Every tool a small business can actually buy sits at one end of this trade-off. Both ends fail, and they fail in opposite directions.
Metabase · Tableau · Cin7
They will let you build anything. That includes the wrong thing. Cross a to-many join and your totals quietly multiply; divide by a column that contains a zero and you get an exception, or worse, a number. Nothing in the tool knows the difference between a report and a mistake.
The tool trusts you completely, and never tells you when that trust was misplaced.
Sortly · Zoho Inventory
They will not let you build anything at all. You get a fixed set of templates, and the question you actually have — which of my stock has not moved, and what is it costing me — is never one of them. Safety by amputation.
Nothing wrong ever comes out, because nothing much comes out.
Not "flexible with guardrails", and not "safe because it is limited". The rules that produce wrong numbers are removed from the grammar the report engine can express. If a definition can be built, it can be trusted — and if it cannot be trusted, it cannot be built.
These are not validations bolted on after the fact. They are properties of the compiler, which is why there is no "advanced mode" that turns them off.
The many-side is collapsed to one row before it ever reaches the join. Double counting is not caught — it has nowhere to happen.
Divide by zero or by nothing and you get NULL, rendered as "no value". The engine will not invent a number to fill a gap in your data.
A report definition is checked before a single row is read. An invalid definition fails loudly at the door instead of returning a confident wrong answer.
The field picker shows you a field only when a genuine foreign-key path connects it to what you are measuring. Unrelated tables never appear together.
Verity reads the stock database you already run. Nothing is re-keyed, and nothing moves.
Your existing stock and inventory tables, in place. No import, no parallel copy to keep in sync.
A report is a JSON definition, not a script. It can be read, reviewed and diffed by someone who does not write SQL.
The definition is validated, then compiled to SQL — with the pre-aggregation and the null-safe arithmetic built into the output.
The same definitions render in English, Romanian and Hungarian. One source of truth, three readings of it.
Point Verity at your stock database and read the figure you can defend — not the one that merely looks plausible. If a report can be built, it can be trusted.