Two different operations often confused as one
In conversations with banking product teams, the terms "enrichment" and "reclassification" are often used interchangeably, as if they refer to the same thing. They don't. They are distinct operations on transaction data, they solve different problems, and for SMB cash-flow features, understanding the distinction matters because doing enrichment without reclassification — which is the common case — still leaves you with wrong categories.
The short version: enrichment adds information to a transaction record. Reclassification corrects the category label when the original category is wrong. Both are valuable, but they operate on different parts of the problem. For SMB banking features that depend on accurate categories, reclassification is the prerequisite and enrichment is the enhancement. Getting this order backwards is a common reason why "enriched" transaction data still produces bad cash-flow forecasts.
What enrichment does
Transaction enrichment takes a raw transaction record and appends additional metadata: a cleaned merchant name, a merchant logo URL, geographic coordinates of the merchant location, a canonical merchant identifier, the ISO 8583 MCC code if not already present, and sometimes a category label. Enrichment vendors like Ntropy, Heron Data, and the enrichment layers built into aggregators like Plaid and MX all do this work to varying degrees.
A raw transaction that arrives as:
{
"merchant": "SQ *JIMS LANDSCAPING SVC 704",
"amount": -247.00,
"date": "2025-05-14",
"category": "SERVICE"
}After enrichment might look like:
{
"merchant_raw": "SQ *JIMS LANDSCAPING SVC 704",
"merchant_canonical": "Jim's Landscaping Services",
"merchant_logo": "https://cdn.logos.example/jims-landscaping.png",
"mcc_code": "0780",
"mcc_label": "Horticultural Services",
"amount": -247.00,
"date": "2025-05-14",
"category": "SERVICE"
}Notice what changed: the merchant name is cleaner, a logo and canonical ID are appended, and the MCC code is resolved. What didn't change: the category is still SERVICE. If SERVICE is wrong for this transaction — which it is, for an SMB that operates a landscaping business and needs this categorized as Subcontractor or Landscaping Services to make sense in their expense breakdown — enrichment didn't fix the problem. The metadata is better. The category is still wrong.
What reclassification does
Reclassification takes the transaction record — raw or enriched — and evaluates whether the existing category label is correct. If it isn't, reclassification replaces it with the correct label. Crucially, reclassification for SMB accounts needs to operate with business context: what industry does this account operate in, what does this merchant relationship look like in the context of this specific business, is this a recurring vendor payment or a one-time purchase?
The same transaction after reclassification:
{
"merchant_canonical": "Jim's Landscaping Services",
"amount": -247.00,
"date": "2025-05-14",
"original_category": "SERVICE",
"corrected_category": "Subcontractor Labor",
"confidence_score": 0.91,
"classification_basis": "recurring_vendor_pattern + mcc_horticultural + account_industry_construction"
}Now the category is a business-meaningful label that maps to how an accountant or bookkeeper would categorize this expense. The confidence score tells the downstream system how certain the classification is. The classification basis gives an audit trail for why this category was assigned. That's the output that powers reliable cash-flow features.
Why the ordering matters: enrichment before reclassification
The reason to think of enrichment and reclassification as a sequence rather than alternatives is that enrichment produces better inputs for reclassification. A merchant name normalization step — part of enrichment — resolves the noisy raw descriptor to a canonical form that the reclassification engine can match to a known merchant more reliably. An MCC code resolved during enrichment provides an additional classification signal. Geographic data can help disambiguate merchants with common names across different industries.
In practice, enrichment and reclassification often happen together in a single pipeline pass — the distinction is conceptual, not necessarily a requirement for two separate API calls. A classification API that takes a raw transaction and returns both enriched metadata and a corrected category is doing both operations internally in sequence. What matters from the consuming application's perspective is that you get back clean metadata and a correct category, not how the vendor structures their internal pipeline.
The SMB-specific dimension that consumer enrichment misses
General-purpose enrichment APIs are built around a broad merchant database and a consumer-oriented category taxonomy. For most personal finance use cases, this is sufficient — a restaurant is a restaurant, and whether it's categorized as Dining or Food and Drink is a naming difference, not an accuracy problem.
For SMB banking, the category label carries business meaning that consumer categories don't. The difference between Office Supplies and Cost of Goods Sold is the difference between a deductible business expense in one accounting category and a deductible business expense in another — wrong categorization affects P&L line items, tax preparation accuracy, and cash-flow waterfall construction. A restaurant owner's purchase at a commercial food supply wholesaler (MCC 5141, Groceries, Wholesale) is not the same as a personal grocery purchase, even though both involve the same MCC code from a general enrichment taxonomy perspective.
This is where SMB-specific reclassification adds value that general enrichment does not: it applies business context — account industry, merchant relationship history, transaction pattern — to assign categories that are meaningful for business accounting and cash-flow analysis, not just for consumer spending behavior understanding.
Practical implications for banking product teams
If you've already integrated a general enrichment API and are seeing category quality issues in your SMB accounts, the enrichment is doing its job (cleaner merchant names, logos, MCC resolution) but the categorization layer it includes isn't built for the business use case. You don't necessarily need to replace your enrichment vendor — you can insert a reclassification step downstream that takes the enriched record and corrects the category for SMB-specific accuracy.
We're not saying enrichment is unnecessary — it's valuable, and having cleaned merchant names and resolved MCC codes as inputs to reclassification makes the reclassification more accurate. We're saying enrichment is not a substitute for reclassification when the existing category is wrong. If you're measuring categorization accuracy on your SMB customer population and finding rates in the 60-75% range, a richer merchant logo and a cleaner merchant name won't move that number. Reclassification with business context will.
The question for your next sprint planning: is the category data your cash-flow features are built on correct, or is it just better-labeled incorrect data? The distinction is the difference between enrichment and reclassification, and it's worth being precise about which problem you've solved.