An app that sorts spending into categories automatically is convenient and frequently inaccurate. The errors come from the data the categorisation is built on.
The merchant name is not a description
A card transaction carries a merchant identifier and a descriptor string, both set by the merchant's payment processor rather than by any standard describing what was bought.
Descriptors are often truncated, abbreviated or set to a parent company name that bears no resemblance to the shop the customer visited.
Categorisation engines match these strings against reference lists, so an unfamiliar or ambiguous descriptor is assigned by guesswork or left uncategorised.
Small independent businesses suffer most, because their descriptors are unique, unrecognised and often include the name of the payment processor rather than the shop itself.
Merchant category codes are coarse
Payment networks assign each merchant a category code from a fixed list, used mainly for interchange pricing and risk rather than for describing purchases.
A supermarket that sells fuel, clothing and pharmacy items reports everything under a single code, so the split a household actually cares about is unavailable.
Large general retailers present the same problem in reverse, with everything from food to furniture arriving under one label.
Aggregators sit between the bank and the app
Many apps obtain transaction data through intermediaries that connect to banks, and the level of detail varies by institution and by connection method.
Some connections deliver rich data including merchant location and logo; others deliver little more than a date, an amount and a truncated string.
Categorisation quality therefore differs between accounts within the same app, which makes the inconsistency look arbitrary to the user.
Structural cases defeat any engine
Transfers between a person's own accounts appear as an outflow and an inflow, and counting the outflow as spending inflates the totals substantially.
Refunds, cash withdrawals, split bills and payments made on behalf of others all record as ordinary transactions with no marker distinguishing them.
These cases require the user to intervene, which is why a fully automatic budget drifts away from reality even when the category rules are working correctly.
What the tools are actually good for
Automatic categorisation is reliable for direction and magnitude, showing that a category rose or fell, even where individual assignments are imperfect.
Correcting recurring merchants once usually teaches the rule permanently, which fixes most of the persistent errors with modest effort.
Treating the output as a draft to be reviewed rather than a ledger to be trusted gets the benefit of automation without inheriting its blind spots.
The review is also where the useful information sits, since noticing that a category was assigned wrongly usually means noticing the transaction itself.