The engine reads your business, not your chart of accounts.

Two businesses. The same event. Filed in different places.

One books a processing fee as a cost of sale, another as an operating expense. One nets refunds against revenue, another files them as a separate line. A vendor rebate lands in "other income" here and reduces cost of goods there. Every one of these choices is defensible for accounting purposes, and every one of them breaks a diagnostic that reads categories at face value.

A category total cannot tell you what to fix.

This is why generic reporting tools stall at the category level. "Cost of goods sold went up" is a category total. It cannot tell you whether a supplier raised prices, your product mix shifted, or a fee was misfiled: three different problems with three different fixes.

Once everything is resolved, the real questions become answerable.

Before Helcyon diagnoses anything, every transaction is resolved into a canonical model of what it economically is: the parties involved, the obligation it settles, the product or service it touches, and the direction the money actually moved. The bookkeeper's filing choice is noted, not obeyed.

The causal tracing in every Helcyon brief, the part that names the vendor and prices the impact, is only possible because the ontology resolved what everything is first.

It keeps the baseline honest.

Every vital sign Helcyon monitors is judged against the range that is normal for your specific business. If the same economic event drifts between categories from month to month, a new bookkeeper, a new rule in the accounting software, a one-off correction, a category-reading tool sees a phantom change. The ontology sees the same event in the same place, so when Helcyon flags a deviation, it is a deviation in the business, not in the filing.