Spending controls that respect builders

For a long time, corporate spending tools optimized for the wrong customer. They optimized for the finance team’s anxiety. They produced workflows that required four approvers for a fifty-dollar SaaS subscription, prompted in four different inboxes, and routed through a custom app that nobody had asked for.

The result, in practice, was the same in every company we visited: people stopped using the system. Engineers expensed everything personally. Finance lost both the visibility and the controls they had built the system to provide.

We designed Northbank’s spending controls under a different premise: a control that gets bypassed is not a control. The job is to build something that the team being controlled actually agrees to use.

What changed

Three design decisions, each of them slightly counter to industry default.

Defaults that match how teams actually spend

Most spending tools default to deny. Every transaction starts disallowed and has to be argued into allowance. We default to allow within sensible policy. The policy lives in plain language, visible to everyone, and can be edited by finance without an engineering deploy.

This shifts the conversation from can I buy this? to does this fit our policy? — a question the spender can answer without calling anyone.

Approvals that respect calendar reality

A 9 a.m. expense should not require approval at 3 a.m. We sized our approval thresholds against the actual decision speed of the company. A small expense (under a hundred dollars at most companies) does not need approval at all — it just needs to be seen. A medium expense gets one approver, with a default fall-through if not actioned within a business day. A large expense gets two approvers, and a hard block if either disagrees.

Crucially, the thresholds are visible to the spender. Surprises are the enemy of trust.

Policy controls finance can edit

Most enterprise tools require an engineer to change a policy. This is, on examination, indefensible. The finance team is the team that should own the policy. We built the policy editor for them, not for engineers. There is no YAML. There is a sentence-builder UI that produces a policy that the platform enforces.

Engineers can still write policy in code if they want — the API is open. Most of the time, the sentence-builder is faster.

What we hear from customers

The reaction we did not predict: finance teams report less stress, not more. The intuition was that loosening defaults would lead to runaway spending. In practice, the spending pattern stays roughly the same. What changes is the volume of inbound questions to finance — can I buy this, can I expense that — which drops by an order of magnitude.

We think the reason is simple. People asked, at the old companies, because they did not know what was allowed. Once the policy is visible and the defaults are sensible, the questions go away.

What this is not

This is not a libertarian argument against controls. It is, at most, an argument that the form a control takes affects whether it does its job. A control that is loud, friction-heavy, and invisible to the spender is a control that gets routed around. A control that is calm, low-friction, and visible is a control that finance and engineering can both live inside without fighting.

We have spent the last two years moving the product in that direction. The team metrics — questions to finance, percentage of spending on-platform, audit findings — keep improving. We will keep going.