Budgeting apps sort transactions into categories automatically, and they get a meaningful share of them wrong. The reason lies in what information the app actually receives.
The app only sees a merchant string and a code
A transaction arrives as a short descriptor, an amount, a date and a merchant category code assigned by the payment network. There is no itemized receipt attached.
Descriptors are written for reconciliation rather than for humans, which is why they often contain abbreviations, a corporate entity name and a location fragment.
From that, the app must infer a category. It is inferring purpose from identity, and identity is a poor proxy for purpose.
Merchant category codes describe the business, not the basket
The network code identifies what kind of business the merchant is. A supermarket is coded as a supermarket regardless of what was in the cart.
So a pharmacy run for household cleaning products, a supermarket trip for a gift, and fuel bought at a convenience store all land in the wrong bucket.
Large general retailers make this worse, because a single code covers groceries, clothing, electronics and garden supplies bought in one transaction.
Parent companies obscure what the customer experienced
Payments are often processed under a holding company or a franchise operator whose name the customer has never seen. The descriptor reflects the legal entity, not the storefront.
Payment facilitators compound this. A charge routed through a platform can appear under the platform's name, hiding dozens of unrelated small businesses behind one label.
The app cannot distinguish between them, so it either creates one meaningless category or defaults everything to uncategorized.
The training data is other users' corrections
Most services improve categorization by learning from how users recategorize transactions. That works well for merchants that many people use in the same way.
It works badly for merchants whose customers split evenly between two uses, and badly again for small local businesses that few users have corrected.
The system converges on the majority use, which means a minority use will be reliably wrong and will stay wrong until corrected on that specific account.
Rules beat corrections for recurring merchants
A one-off correction fixes one transaction. Most apps also allow a persistent rule that binds a merchant to a category for every future occurrence.
Setting rules on the handful of merchants that account for the bulk of monthly transactions resolves most of the error with a small amount of work.
The residual errors sit in the long tail of infrequent merchants, where the amounts are usually small enough that the miscategorization does not distort the picture.