The trap of pre-set "intelligent tools"

Most management apps sell "intelligent matching". In reality, it's:

  • A list of hardcoded patterns (URSSAF, HMRC, Stripe, common SaaS)
  • A text-similarity score between labels
  • That's it

It works for 60-70% of your transactions. The remaining 30%, you classify by hand every month. No learning.

The difference: persisted rules + evolving confidence

In Freelance Budget, each time you validate or create a classification, the app generates or updates a ReconciliationRule:

  • Pattern (substring or regex) of the bank label
  • Target match (mission, expense, salary, other income)
  • Confidence score: 0-100, rises with each validation, drops if you reject

Concrete example:

  1. Month 1: First debit from OVH SAS. You classify it as "Web hosting". A rule is created: pattern: "OVH SAS" → expense: "OVH Hosting", confidence 50.

  2. Month 2: New OVH SAS debit. The engine applies the rule automatically. You validate the auto-match. Confidence rises to 65.

  3. Month 3: Confidence 80. The engine auto-applies without even asking.

  4. Month 6: Confidence 95. The engine applies silently. You just see "9 transactions auto-matched" at the top of the dashboard.

A system that gets smarter over time

Here's what actually happens for an active freelancer after 3-6 months of use:

| Month | Manual classification % | Time spent | |---|---|---| | Month 1 | 95% of statement | 1h30 | | Month 3 | 35% of statement | 30 min | | Month 6 | 12% of statement | 10 min | | Month 12+ | 5-8% of statement | 5 min |

Those remaining 5-8% are typically:

  • A unique transaction (exceptional purchase, new client wire)
  • An unusual variation (usual debit but different amount)
  • A pattern deletion (you canceled a subscription, the pattern is obsolete)

The regex vs substring mechanism

Rules support two modes:

  • Substring (default): matches if the label contains the pattern. Simple, handles 80% of cases.
  • Regex: for tricky cases. Example: ^STRIPE.*ACME captures all Stripe payouts for client Acme specifically.

Regex modes are earned automatically when you correct a false match repeatedly. If you reject "STRIPE — Acme Consulting" matched to "STRIPE — Other Client", the app hardens the rule with a more specific regex.

Confidence also goes down

If you reject or modify a classification, confidence drops. Essential — prevents the app from getting stuck on an error.

Example: you classified "STRIPE PAYOUT" as "Other income". But actually you have 2 Stripe sources: your shop (revenue) and your Pro app (rebillings). When you reject 3 times, the rule loses confidence and the app asks again.

Why few SaaS tools do this

Building an evolving, behavior-adaptive learning engine requires:

  • A ReconciliationRule table with a rich schema (confidence, regex flag, applied/confirmed counts)
  • A matching engine that queries these rules before hardcoded patterns
  • A UI making correction explicit (not just an "x" that erases the suggestion)

It's invisible product engineering — the average freelancer doesn't explicitly ask for "persisted rules with confidence". But after 3 months, they see the effect: their monthly statement classifies itself.

The moment you notice

Typical month 4: you upload your April statement. The app shows "47 transactions, 44 auto-matched using 31 learned rules, 3 to classify".

You classify the 3 in 1 minute. Done.

You remember spending 1h30 in month 1. You realize you just saved 15-20 hours per year on bank reconciliation alone.

That's exactly the benefit you can't see in a 5-minute demo — but that becomes obvious after 90 days of regular use.