Pending card transactions, and why amounts move before they settle

A card payment can affect an account before it becomes a completed transaction. The period in between is the pending state.

Pending does not mean the bank has lost track of the money. It usually means a merchant has received authorisation but the final payment record has not yet completed settlement. That distinction explains many apparent mismatches between an available balance and a list of completed transactions.

Authorisation comes first

When a card is used, the merchant asks the card issuer whether the payment can proceed. The issuer checks the account and other controls, then approves or declines the request.

An approval can create a hold. The bank reserves the authorised amount so it is not treated as fully available for another transaction. The merchant has not necessarily received final settlement at that moment.

The bank may expose this as a pending transaction, an adjusted available balance or both. The exact presentation varies.

Settlement creates the completed record

The merchant later submits the transaction for completion through the card system. The bank books the final entry and removes or replaces the earlier hold.

The completed transaction can have a different date or description from the authorisation. The amount can also differ in legitimate cases. The pending record and the completed record are stages of one payment, not always two separate payments.

A budgeting product tries to match them using available identifiers, amount, merchant information and timing. Bank feeds do not always provide a perfect shared identifier, so matching includes uncertainty.

Why the amount can change

Some merchants authorise an estimate before the final amount is known. Hotels, vehicle hire, transport and unattended terminals can place a temporary hold. Hospitality payments can be adjusted when the final total is completed.

A small verification authorisation can also appear and later disappear. Currency conversion can produce a final amount that differs from the initial display.

The product should not rewrite the pending record to make it look settled. It can show the status and later reconcile the final transaction when it arrives.

Why a pending item can disappear

An authorisation has a limited life. If the merchant does not complete it, the bank can release the hold. The pending entry then disappears and the available balance changes again.

That can happen after a cancelled order or a failed checkout, but disappearance alone does not describe the merchant's reason. In some cases the completed transaction arrives separately after the pending display has gone.

The feed reflects the stages published by the bank. The budgeting app cannot force a merchant to settle or a bank to retain a particular pending record.

Why duplicates appear

During the handover from pending to completed, both records can briefly be visible. If software treats each one as independent spending, category totals and budgeting estimates are understated.

Matching on amount alone is unsafe because two genuine purchases can share the same value. Matching on description alone is also weak because a merchant label can change at settlement.

The product combines signals and removes the pending effect when a likely completed counterpart appears. Ambiguous cases may remain visible until the feed provides more information. A correction path is needed when an automatic match is wrong.

How pending activity affects a budget

Ignoring a known hold can make an available-to-spend estimate look higher than the latest bank information supports. Counting it twice has the opposite effect.

The calculation therefore treats unresolved pending activity as a separate input. When the completed record arrives, that record replaces the pending effect rather than adding a second deduction.

If the bank does not expose pending information, the product cannot recreate it reliably from completed transactions. The timestamp and connection state help explain the boundary.

Dates describe different events

A transaction can have an authorisation date, booking date and value date. A weekend or bank processing cycle can place those dates apart.

For a category chart, the product needs a consistent rule about which date determines the period. For a live budgeting estimate, current status can matter more than the final booking date. These views can legitimately organise the same payment differently while it is pending.

The interface needs stable labels so the user can tell whether a date means when the card was used or when the bank completed the entry.

Pending is not a final promise

A pending amount is useful information, but it is not a final receipt. It can change, disappear or be replaced. A merchant dispute or cancellation follows separate processes outside the budgeting product.

The app provides a read-only view. It cannot cancel the authorisation, release a hold or complete the payment. Those actions sit with the bank, merchant and card system.

The best the product can do is preserve status, avoid obvious double counting and update the view when the bank feed changes. Pending transactions are a reminder that money movement is a process, while a transaction list makes it look like a single event.

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