Guide

Bank Feed Reconciliation in Cloud Accounting: Matching, Holds, and the Unidentified-Deposit Problem

Bank feed reconciliation is where bookkeeping actually lives. The mechanics look simple — match the feed to an invoice — but the day-to-day reality involves Stripe payouts, PayPal holds, Wise FX gains, refunded card transactions, and unidentified deposits that take a fortnight to chase. This guide is the working manual.

Last reviewed: 14 May 2026 12 min read

For most UK SMEs, bank-feed reconciliation is 60-80% of the monthly bookkeeping workload. The cloud accounting marketing material implies it is mostly automated. The reality is that automation handles the simple cases (a customer pays an invoice with a clean reference, a supplier direct debit hits on schedule) but the bookkeeper's job is the residual: payment processors with delayed payouts, currency movements, refunds, chargebacks, and the steady trickle of unidentified deposits where the customer paid but used a reference that does not match anything in the system.

A working bank-feed reconciliation discipline rests on three things: matching the right transactions automatically, recognising the patterns where automation breaks (Stripe payouts, PayPal holds, Wise FX, card refunds), and investigating unidentified deposits before they accumulate.

Open banking, Yodlee, and direct feeds: what is actually under the hood

The bank-feed layer in Xero, QuickBooks, and FreeAgent is not a single integration. It is three or four different connector types:

  • Open banking (UK CMA9 banks): real-time access, refreshed every 90 days when the user re-authenticates.
  • Direct integration (some larger banks): typically the same as open banking now but historically used proprietary APIs.
  • Yodlee / Plaid / TrueLayer aggregators: covers banks without direct integration; reliability varies.
  • Manual statement import (CSV / OFX / QIF): fallback for any feed that breaks; the 2-month-per-quarter feed outage problem is common with smaller banks.

Stripe payouts: the bookkeeper's most common confusion

Stripe is the most common SME payment processor in 2026 and the most consistently misreconciled. The fundamental mismatch:

  • Customer pays £100 by card on day 1 (gross sale).
  • Stripe deducts fees (typically £1.40 for UK card) and creates a £98.60 entry in its balance.
  • On a 2-7 day rolling cycle, Stripe pays out a net amount to the bank (£98.60 in this simple case; in practice a pooled multi-customer payout).
  • The bank feed shows only the net payout, not the gross sale or the fee.

The correct reconciliation pattern uses A2X, Link My Books, or the native Stripe integration in Xero/QBO to split the payout into: (a) gross sales (recognised when customer paid), (b) processor fees (as an expense), (c) refunds (as contra-sales), and (d) the net bank-feed match. Manual reconciliation is impractical above ~20 Stripe transactions per month.

PayPal pending holds and the multi-balance trap

PayPal's historic "21-day hold for new sellers", currency-balance segregation, and dispute-related holds create routine bookkeeping headaches:

  • PayPal balance shown in the GL must reconcile to the PayPal account balance as at month-end.
  • Held funds are still receivable assets, just not transferable; recognise them in PayPal balance, not bank.
  • Multi-currency PayPal (GBP, EUR, USD balances): each currency reconciles separately; FX moves between balances are accounting events.

Wise (formerly TransferWise) and FX reconciliation

Wise multi-currency accounts are now ubiquitous for SMEs with international customers or suppliers:

  1. 1Each currency balance is a separate GL bank account (GBP, EUR, USD, etc.).
  2. 2Inbound customer payment in foreign currency hits the foreign-currency balance; recognise at the spot rate on the day.
  3. 3Currency conversion within Wise is a journal: debit destination currency, credit source currency, recognise FX gain/loss to a dedicated P&L line.
  4. 4Year-end revaluation: restate non-functional-currency balances at the year-end spot rate; recognise unrealised FX in P&L.

The unidentified-deposit problem

Every active SME accumulates a trickle of unidentified bank-feed credits. Customer paid but used a wrong reference, two customers paid the same amount on the same day, payment from a third-party platform, refund from a supplier. The discipline that prevents these from accumulating into a year-end disaster:

  • Hold an "Unidentified Receipts" suspense account in the GL.
  • Code every truly unidentified credit to that account with a clear description.
  • Investigate weekly, not monthly: cross-check against open invoices, ask the customer-services or sales team, contact the customer if needed.
  • Suspense-account balance at month-end should be under 1-2% of monthly revenue. Above that, the discipline is broken.

Unidentified deposits left for 3+ months become almost untraceable

Bank feeds drop detail over time; customer memory is short; supplier portals may not retain payment details beyond 90 days. Year-end audits routinely find £5,000-£50,000 of unidentified receipts that cannot be matched because the trail is cold. Resolve within 30 days or accept the accounting risk.

Bank reconciliation taking longer than it should?

A specialist UK SME bookkeeper sets up the right Stripe/PayPal/Wise integration, runs disciplined weekly reconciliation, and keeps the suspense-account balance trivial. Free matching, no obligation.