"Trip to Rome" is not a category
It always arrives at the same moment. You get back from a trip, sit down to bring your accounts up to date, and think: I'll make a category called "Trip to Rome" so I can see what it cost.
It is a reasonable idea and it is a mistake, and it is worth understanding why — because this isn't about naming. It's structural.
The rule, in one line
A transaction has one category. And as many tags as you like.
Everything else follows from that.
Why categories have to be few and mutually exclusive
A category answers a single question: what was this money for? Food. Transport. Lodging. Health. Housing.
Because every expense falls into one and only one, the set of categories is a complete division of what you spend. That has a practical consequence which is the entire point of the exercise: the month's breakdown adds up to the total, and this month can be set beside the same month last year with the comparison actually meaning something.
That property is fragile. It breaks the moment a category stops being a "what for" and becomes an "on account of what".
What "Trip to Rome" actually is
The trip is not a what-for. It's a reason that gathers up spending from several what-fors: the flights are transport, the hotel is lodging, the dinners are food.
Turn it into a category and, during the trip, it seems to work: you get your total and you're pleased. The damage shows up afterwards, and it shows up quietly.
That €600 of restaurant meals has left "food". Your October food spending looks artificially low, and not because you ate less. The comparison with last October is no longer comparing two years; it's comparing two filing criteria. And because the symptom is a number that looks good, nobody investigates it.
Multiply that by a year of trips, moves, building work and birthdays and you end up with thirty categories, half of them finished projects, and a monthly breakdown that resembles last year's in no way at all.
This is what tags are for
A tag is a free label you can put on many transactions, and a transaction can carry several. It doesn't compete with the category — it sits on top of it.
That dinner in Rome is, at the same time:
- category: food — what kind of spending it is;
- tag: rome-trip — why it happened.
Both questions get answered at once and neither spoils the other. Your food spending stays true, and so does the trip's total.
The usual candidates for a tag are exactly the things people try to file as categories: a trip, a kitchen renovation, a child's school year, a freelance project, a wedding.
What abacova adds on top
Three things that turn this from a tidy convention into something useful.
Tags nest. A tag can live inside another, and the parent totals everything filed under its children. "Travel" above "Rome" and "Lisbon" answers both "what did Rome cost me?" and "what do I spend on travelling?" without recording anything twice. Tags have their own screen, on the web and on the phone.
Reports and filters understand the hierarchy. You can filter by a tag with or without its subtags — which is the difference between one specific trip and the spending category "travel" that you built yourself.
They can be budgeted and automated. A budget in abacova doesn't have to sit on a category: it can sit on a tag, which is how you cap a project rather than a type of spending. And a rule can apply tags on its own, just as it applies categories, so you don't have to remember for the three weeks the trip lasts.
The quick test
When you're unsure, ask the category question out loud:
What was this money for?
If the natural answer is "to eat", "to get around", "to sleep" — that's a category.
If the natural answer is "for the trip", "for the renovation", "for my daughter's school" — that isn't a what-for, it's a why. It's a tag.
Deciding it correctly takes five seconds, and it saves reorganising a year of transactions when you notice your categories have turned into a list of old projects.