The gap between knowing what you spent and what remains available

Spending history and available money are related, but they are not the same view.

A transaction list describes activity already recorded by the bank. A category total summarises part of that history. Neither automatically accounts for payments due later, pending card activity, budget amounts still reserved or the date the current period ends.

The gap between those views is where much of budgeting software lives.

Past spending is a record

Completed transactions answer concrete questions. What amount left the account? When was it booked? Which description did the bank provide? Which account was used?

The product can organise those records by merchant or category, but the source remains historical. Even a transaction from this morning describes an event that has already entered the feed.

History is useful for recognising patterns and checking automatic categories. It cannot contain a bill that has not been collected or a cash purchase that was never recorded in a connected account.

A balance is another snapshot

The latest connected balance describes the account at the bank's most recent update. It includes the effects of completed activity and, depending on the balance type, may reflect some pending authorisations.

It does not label part of itself as rent, a subscription or next week's transport. Those meanings exist in the user's commitments and budget, not inside the balance field.

The same balance can therefore mean different things at different points in a period. Timing supplies context that the number alone does not carry.

Known future commitments create the gap

Recurring payments and bills can be visible before they leave the account. The product can identify a repeated transaction pattern or use a commitment entered by the user.

That information changes a budgeting estimate without changing the bank balance. A payment expected inside the current period can be reserved in the view even though the bank has not yet completed it.

Detection remains uncertain. An amount can change. A service can be cancelled outside the app. A new commitment has no history. The interface needs to show the list of assumptions so a user can correct them.

A budget reserves money without moving it

A category plan is not a separate pot at the bank. It is a rule in the budgeting product.

If part of a category remains unused, that amount can stay reserved in the active plan. As transactions are assigned to the category, they consume the reservation. The system has to avoid subtracting the plan and the same spending twice.

This distinction is why a budget view can differ from both the statement and the balance while still using them as inputs.

Pending transactions sit between past and present

A pending card payment has been authorised but has not completed settlement. It may already affect the bank's available balance. Its final description, amount or date can change.

For a budgeting view, pending activity is important because ignoring it can overstate what remains unallocated. Counting both pending and completed versions can understate it.

Reconciliation is therefore part of the calculation. The product matches a completed record to its earlier pending version where the data allows. Ambiguous cases remain a limitation rather than an opportunity to invent certainty.

The period gives every input a boundary

An estimate needs to know whether it covers the rest of a calendar month, the time to the next payday or another selected range. A commitment outside that range does not belong in the same subtraction.

The chosen period also affects category reservations. A monthly plan does not become a weekly plan merely because the interface divides a remainder by days.

Showing the period beside the figure prevents the number from being read as a permanent statement.

Why the product keeps the views separate

Combining everything into one total can look simple, but it hides the route back to the source. A person needs to be able to move from the estimate to the commitment list, from the commitment to the original transaction pattern and from the category total to individual records.

The transaction view answers what the bank recorded. The budget view answers how the user arranged the period. The safe-to-spend view combines selected inputs into an estimate. They are connected without being interchangeable.

What remains unknowable

Software cannot account for information it has not received. Cash activity, an unconnected account, a new bill, delayed bank data or a personal plan that was never entered can all sit outside the model.

The estimate also cannot decide whether using the remaining amount is appropriate. It provides information, not financial advice.

This is the real gap between knowing what was spent and knowing what remains available in a budget. The second question needs history, balance, timing, commitments and user choices. It produces a derived view whose usefulness depends on making every input and limitation visible.

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