Divine Charles · Fullstack Product EngineerLoading
000%
Getting things ready…

(W/01 · F/03) · Case study

Transaction recognition

Label bank payments in the app: sales, bills, vendors, and splits for money in and money out.

01

The problem

When a merchant linked a bank, payments showed up as raw lines. Nobody knew which were sales, which were bills, or which vendor got paid. People copied everything into spreadsheets and labeled it outside FloatMerchant.

02

The story

A bank feed without labels is only a list of amounts. Finance still did the real sorting in spreadsheets, and support kept hearing “what was this payment?” Recognition exists so merchants can finish that job inside FloatMerchant for both income and spend.

03

What changed

There are two familiar areas: money coming in and money going out. You open a payment, choose what it is, and save. One payment can be split across categories. If the bank line is missing or wrong, you can enter it by hand. Spend can filter by vendor. The product also warns when a payment looks like a duplicate.

04

How it was built

Inflow and outflow were designed to work the same way on purpose, so learning one side teaches the other. The focus was finishing the label while you still have the payment open: category, customer or vendor, proof, and a check for doubles, instead of sending people back to a spreadsheet later.

05

Outcome

  • Income and spend get labeled in the product, not only in a spreadsheet.
  • Once you learn money in, money out feels familiar.
  • Duplicates and missing proof show up while you are still reviewing the payment.