Some feature requests spend a while on the backlog — our to-do list of improvements we want to make to CLARIFYProperty. This one was a fairly simple idea: if a transaction already has a suggested transfer pairing, give someone a nudge before they start a separate transfer instead.

With the categorisation guardrails now in place, that request became much easier to implement. We already had a way to recognise a choice worth reviewing, explain it, and let the user confirm that they wanted to continue. This was another useful application of that same infrastructure.

Why a pairing deserves a prompt

When money moves between two bank accounts, the transaction leaving one account and the transaction arriving in the other represent the same transfer. If one side has already been categorised, CLARIFYProperty can suggest pairing the other transaction with it.

Those suggestions were already available in the category list. But having an option in a dropdown does not guarantee that someone will notice it, especially when they are working through a long list of transactions.

The new guardrail appears when someone chooses to start a transfer and suggested pairings already exist. It points them back to the suggestions before they continue. It does not pair anything automatically: they can review the candidates or confirm, “I want to start a separate transfer anyway.”

The benefit of doing the groundwork

From a development perspective, the useful part was how much of the work already had a home.

The existing pairing finder supplies the candidates. The guardrail framework handles the warning and confirmation. The new check connects the two, rather than needing a separate warning mechanism for transfers.

There was still an important detail to handle. Suggested pairings can change between displaying a warning and saving a decision. The confirmation therefore records the pairing context and checks it again before saving. If the candidates have changed and a warning still applies, the user needs to review it again.

That is the kind of work shared infrastructure makes easier: the new feature can use an established confirmation flow while adding the information specific to its own decision. The groundwork has started to pay back in the next feature on the list.

An honest look at the first implementation

We also took the opportunity to tidy up transfer categorisation more broadly.

We had deployed our first implementation, and as more people used it — and other parts of transaction categorisation evolved — we spotted a few issues. In particular, the relationship between transfers and the split editor needed another look.

A split divides a transaction between categories. A transfer connects movement between accounts. Allowing transfer categories within a multi-line split made those two ideas overlap in ways the workflow did not handle well.

The editor also serves another purpose: reviewing categorisation rules. A rule can legitimately propose a single transfer, so simply removing every transfer option from that editor would have been too blunt.

The revised behaviour follows the transaction being proposed. A single line can be a transfer, provided it covers the full transaction amount and uses a different account. With multiple lines, transfer categories are removed. If adding a line clears a transfer selection, the editor explains why.

For an existing transfer, the interface now asks you to uncategorise it before splitting the transaction. That makes changing an established transfer an explicit decision.

Reviewing both UI and UX

This was a useful reminder to review both the UI, or user interface, and the UX, or user experience.

The UI is what someone sees and interacts with: the category dropdown, buttons and warning text. The UX is the wider experience of completing the task: whether the choices make sense, whether the next step is clear, and whether an unexpected change is explained.

Here, that meant looking beyond the new prompt to consider which options should appear, when a selection should be cleared, and how someone gets back to the suggested pairings. The server enforces the same restrictions, so the behaviour also holds if an editor has been left open while the underlying transaction changes.

The original request was small. Implementing it became easier because of the guardrails, while reviewing the surrounding workflow exposed a few things worth improving alongside it. Real usage gives us reasons to revisit earlier decisions, and a better foundation makes those revisions easier to carry through.