What safe to spend is and how the number is worked out

Safe to spend is a budgeting estimate. It is designed to answer a narrower question than a bank balance: after the commitments and budget reservations currently known to the product, what amount remains unallocated for the period being viewed?

The phrase can sound more certain than the underlying data allows. It is not permission to make a purchase, a guarantee that every future payment has been found or a forecast of a person's financial position. It is a calculation based on the latest information available to the app and the settings supplied by the user.

That limitation belongs beside the number, not hidden in a policy page.

The starting point is the connected balance

The calculation begins with the latest balance returned for the accounts included in the budget. That may be a current or available balance depending on what the bank exposes and how the account is represented.

The timestamp matters. A balance returned earlier in the day can be behind activity that has just happened. A disconnected account or delayed bank feed can make the starting point incomplete. The interface therefore needs to show whether an account is connected and when information was last refreshed.

Money held in an account outside the selected budget is not silently added. Transfers between connected accounts also need to be recognised so the same movement is not treated as new income on one side and spending on the other.

Pending activity changes the picture

A card authorisation can reduce the amount available before it appears as a completed transaction. Where the bank provides useful pending information, the calculation can account for it separately from settled spending.

Pending data has complications. A transaction can disappear before a completed version arrives. A hotel or transport hold can be higher than the final amount. Two records can briefly look like duplicates. The product has to reconcile pending and completed records instead of subtracting both indefinitely.

If pending data is unavailable or ambiguous, the estimate cannot invent it. The displayed number can only reflect activity present in the feed.

Known commitments are then reserved

The next input is money already associated with a known commitment in the active period. That can include upcoming bills and recurring payments identified by the product, together with commitments a user has entered or confirmed.

Detection is evidence, not certainty. A payment that repeated on similar dates may be a subscription, but the next amount can change or the service may already have been cancelled. A new bill has no history to detect. A commitment entered manually can become out of date.

For that reason, the product shows the underlying items rather than presenting a single unexplained deduction. A user can see which payments contributed to the estimate and correct information that no longer matches the plan.

Budget reservations are separate from transactions

A budget can reserve an amount for a category before any transaction happens. That reservation represents the user's plan, not money removed from the bank account.

The calculation treats planned category amounts and completed spending carefully so it does not subtract the same amount twice. As spending appears in a category, it uses part of that category's reservation. The unspent part remains reserved until the period ends or the budget is changed.

This is why safe to spend is not simply the balance minus this month's spending. It includes what has already happened and what the active budget still sets aside.

Time defines the calculation

Every estimate needs a horizon. It may run to the next payday, the end of a monthly budget or another date selected in the product. A bill due after that horizon belongs to a different calculation from one due tomorrow.

Confirmed income already visible in an account can change the starting balance. Expected income that has not arrived is not the same as settled money. If a future-income view is offered, it needs to be labelled separately so an expectation is not presented as a current balance.

The remainder can also be shown as a daily or weekly reference by dividing it across the time left in the period. That does not change the total. It is another view of the same estimate.

A simple conceptual formula

At a high level, the calculation is the latest included balance, less unresolved pending activity where available, less known commitments due inside the period, less the unspent amounts still reserved by the active budget.

Several adjustments sit around that line. Transfers need deduplication. Refunds reverse earlier activity. Shared costs may not belong entirely to one person. Cash spending may not appear in the feed. Bank data can arrive late. User corrections can override an automatic category or recurring-payment guess.

The app keeps those inputs visible because a derived number without an explanation is difficult to trust and difficult to correct.

What the number can and cannot say

Safe to spend describes the product's current view of unallocated money. It can make the difference between a raw balance and known commitments visible in one place.

It cannot know about a payment that has not been entered, a cash purchase outside connected accounts, a bank feed outage or a future change in income. It does not assess whether a purchase is sensible and does not provide financial advice.

The right design standard is therefore not certainty. It is traceability. A person looking at the number needs to be able to see the period, connected accounts, commitments, pending activity and budget reservations that produced it. When one of those inputs changes, the estimate changes too.

For current service details, read the company's open banking explanation and Privacy Policy.