The category taxonomy is the foundation of every spending insight feature in a personal finance app. But most taxonomies are built by engineers or accountants working from a data classification perspective rather than from a user mental model perspective. The result is a schema that is internally consistent and machine-friendly but confusing to users and poorly suited to the spending patterns of modern consumer life.
When we designed the Openaggr taxonomy, we started from a different question: not "how can we classify all transactions accurately" but "what categories make sense to someone trying to understand where their money goes." These are related questions but not identical, and the gap between them is where most taxonomy design decisions live.
The Accounting Schema Problem
The canonical reference for financial categorization is the IRS Schedule C for business expenses, or Chart of Accounts structures from accounting software like QuickBooks. These schemas are logically rigorous: every expense has exactly one home, the categories are exhaustive, and the definitions are precise enough for tax and audit purposes.
They are also completely wrong for consumer PFM.
An accounting schema puts "meals and entertainment" together as a category because they share a tax treatment (50% deductible for business purposes). But for a consumer building a personal budget, dinner at a restaurant and a concert ticket are completely different types of spending with different behavioral patterns, different budget implications, and different emotional weight. Lumping them together because they share a depreciation rule is a category design decision that makes sense for a tax preparer and makes no sense for a user trying to understand their spending.
Similarly, accounting schemas often have an "other" or "miscellaneous" bucket that can absorb anything that does not fit cleanly. This is a reasonable escape valve for accounting completeness but terrible for PFM. Miscellaneous is the category that destroys user trust: if 15% of transactions land in "Other," the user concludes the system cannot categorize their spending and stops paying attention.
What a User-First Taxonomy Needs
A consumer-oriented taxonomy should meet several criteria that accounting schemas typically do not prioritize.
First, category names should match user vocabulary, not industry vocabulary. Users think "coffee" not "food service, limited service, beverage establishment." They think "gas" not "petroleum retail, automotive fuel distribution." The labels on categories determine whether users trust the categorization or second-guess it.
Second, the category tree should reflect spending frequency, not conceptual purity. Categories that appear in 25% of user transactions deserve a top-level slot and recognizable icon. Categories that appear in 0.1% of transactions can live two levels deep. An accounting schema gives equal weight to every leaf node; a PFM schema should surface the ones users actually encounter.
Third, the top-level categories should be few enough to scan visually on a mobile screen. Eight to twelve top-level categories is the right range. More than that and the spending breakdown becomes a wall of small numbers. Fewer than eight and categories are too broad to be useful.
Fourth, the schema should handle modern spending patterns that did not exist when most financial taxonomies were designed. Streaming subscriptions, digital goods, in-app purchases, cryptocurrency exchange fees, BNPL installment payments, and peer-to-peer transfers all appear in modern transaction feeds and need a coherent home in the taxonomy.
Openaggr's Taxonomy Structure
Our taxonomy has two levels: primary categories (12 top-level) and subcategories (the 1,200+ leaf nodes). The top-level categories are:
- Food and Drink (restaurants, coffee shops, groceries, delivery, bars)
- Transport (rideshare, public transit, fuel, parking, tolls, car rental)
- Shopping (general retail, clothing, electronics, books, sporting goods)
- Entertainment (streaming, live events, gaming, movies, hobbies)
- Health (pharmacy, fitness, medical services, dental, vision)
- Home (utilities, rent and mortgage, home improvement, furniture)
- Travel (flights, hotels, vacation packages, travel agencies)
- Financial (bank fees, investment services, insurance, BNPL payments)
- Education (tuition, books and supplies, online courses, tutoring)
- Personal Services (haircuts, spa, laundry, pet care)
- Transfers (P2P payments, bank transfers, wire transfers)
- Income (payroll, freelance deposits, refunds, government payments)
Several design decisions in this list are deliberate and worth explaining.
Groceries is under Food and Drink rather than a separate top-level category. This is controversial among taxonomy designers. The argument for separating groceries is that it represents a fundamentally different type of purchase (household necessity, often weekly, predictable amount). The argument against is that most users mentally group all food spending together when thinking about budget, and separating groceries creates friction when users try to answer "how much did I spend on food." We tested both approaches and users had better intuition about Food and Drink as a unified category.
Travel is separate from Transport. A flight to see family is categorically different from a daily commute, even though both involve movement. Travel implies discretionary spending, planning horizon, and a different budget mental model. The category split matches how users think about budgeting travel versus commuting.
Financial is a top-level category rather than being folded into Banking or Other. BNPL installment payments, brokerage transfers, and insurance premiums are a growing and significant portion of consumer spending. Treating them as an afterthought understates their importance in the spending breakdown.
The Hard Cases: Ambiguous Merchants
Category taxonomy design has to contend with merchants that genuinely span multiple categories. A few patterns come up repeatedly.
Big-box stores (Target, Walmart, Costco) sell everything. The MCC code for these merchants is typically general merchandise retail, which maps to Shopping. But a Costco run for household supplies plus a rotisserie chicken and a pharmacy prescription is really Shopping plus Groceries plus Health. Without item-level data (which most transaction feeds do not provide), the best you can do is assign the most probable single category based on the merchant type. For Costco, we assign Shopping at the primary level. For Walmart Neighborhood Market (which is grocery-focused), we assign Groceries. The distinction is based on merchant variant, not purchase content.
Online marketplaces (Amazon, eBay, Etsy) have similar challenges. Amazon sells groceries, electronics, household goods, books, and clothing. The transaction string alone is AMZN*MKTP US AMZN234 with no item information. We categorize these as Shopping / Online Marketplace and flag them as high-ambiguity transactions in the confidence score. Some teams choose to surface these differently in their UI: showing "Amazon" without a specific subcategory rather than confidently labeling it "Electronics" when it might be anything.
Pharmacies present the health versus personal care split that we discussed in the ground-truth post. Our approach: chain pharmacies (CVS, Walgreens, Rite Aid) are assigned Health / Pharmacy as the default. Amounts under $15 are more likely to be personal care purchases and get a slight confidence adjustment toward Personal Services / Personal Care. This is a heuristic, not a reliable rule, and the confidence score reflects that uncertainty.
The Custom Taxonomy Option
Standard taxonomy works well for most consumer applications. But some PFM products serve user populations with distinctive spending patterns that the standard taxonomy does not serve well.
A finance app built for healthcare workers might want a detailed taxonomy for medical professional expenses: scrubs, certification fees, continuing education, malpractice insurance. These exist in the standard taxonomy but are scattered across several categories without the specific granularity that matters to that user population.
A finance app for freelancers might want a taxonomy that prominently surfaces business expense categories alongside personal ones, with specific subcategories for common independent contractor expenses: home office supplies, professional subscriptions, client-facing meals.
For these cases, the standard taxonomy is a starting point, not a constraint. The enrichment API returns category codes that map to our standard taxonomy by default. The custom taxonomy feature (available on the Scale tier) lets you define a mapping from our standard codes to your own code namespace, along with additional rules that reclassify specific merchant types differently from the standard assignment.
We are not saying every app needs a custom taxonomy. For most neobanks and general PFM apps, the standard taxonomy covers the cases well. Custom taxonomy is for teams whose user base has genuinely distinctive spending patterns that warrant the additional design investment.
Testing Taxonomy Fit With Your User Base
The best way to validate whether a taxonomy fits your users is to run a labeling exercise with a small sample of real transactions from your user population. Give 20 to 50 transactions to a handful of representative users (no UI, just raw merchant names and amounts) and ask them to sort them into categories. The categories they naturally create, and the ones they debate, reveal where your taxonomy design will create friction.
Pay attention especially to the items they put in an "Other" pile. Those are the taxonomy gaps. If users consistently cannot find a home for a transaction type, that transaction type either needs its own subcategory or it needs to be mapped more clearly to an existing one.
Taxonomy design is an ongoing process, not a one-time decision. Spending patterns change, new merchant types emerge, and user expectations evolve. The taxonomy that fit a 2022 user population may not fit a 2025 one: streaming services alone have diversified enough to warrant a much more granular subcategory tree than existed a few years ago.
Getting the taxonomy right is worth the design time. It is the invisible foundation of every spending insight feature your users actually use.