A common misreading
Why bank feeds do not eliminate bookkeeping work
Because a bank feed is a record that money moved — not evidence of what it was for. It supplies a date, an amount, a direction and a counterparty string. Everything the books need beyond that is absent by construction: what the payment bought, which invoice it settles, which period the underlying event belongs to, and whether your record of cash and the bank’s record of it actually agree.
Feeds are good, and they deserve the credit. They removed an enormous amount of manual typing and the errors that came with it. What they did not do is remove the work — they moved it from data entry to judgement, evidence and agreement, which is harder to automate and more expensive to get wrong.
A feed records movement. Books record meaning.
The two are often treated as the same information in different clothes. They are not. A bank feed is an excellent primary source about one narrow thing — the movement of cash through an account. A set of books is a statement about what the business did, which is a different subject and rarely the same shape.
| A feed reliably supplies | The books additionally need | Where that has to come from |
|---|---|---|
| The date the money moved | The period the underlying event belongs to | The invoice, delivery or contract date — frequently a different month |
| The amount and the direction | What the amount was actually for | A document, or a person who knows |
| A counterparty string from the payment rail | The real party, matched to your own records | Customer and supplier records, plus judgement on near-matches and trading names |
| That the balance changed | Whether two independently kept records agree | Reconciliation, which is an act of agreement rather than an import |
| One line per movement | One or more entries per business event | Allocation, splitting and matching — the relationship is rarely one to one |
What feeds genuinely fixed, and it was a great deal.
Any argument that starts by attacking automatic bank data is selling something. Before feeds, a meaningful share of a bookkeeper’s month went on transcription: reading a paper statement and keying it in, line by line, usually weeks after the fact. That work is gone, and nobody should want it back.
- Manual keying of statement lines, and the transposition errors that came with it.
- The lag. Cash visibility used to arrive with the statement; now it arrives daily, at no extra cost.
- Whole classes of duplicate and omitted entries created by typing the same thing twice, or once too few.
- Most of the truly routine matching. Familiar, repeating payments can be proposed automatically from past behaviour, which absorbs a large share of ordinary volume.
- The argument about what the bank statement said. The feed is the bank’s own record, so that particular dispute is over.
The correct conclusion is not that feeds failed. It is that they cleared away the visible half of the job and left the half that was never visible — and because the visible half disappeared, the remaining work now looks like an unreasonable amount of effort for a small number of lines. It is not. It is the difficult part, standing on its own for the first time.
Six things a feed cannot settle on its own.
Each of these produces a line that arrives automatically and then stops. None of them is unusual; most businesses generate all six in a normal month.
- Ambiguous transactions. A payment out to a name that is a holding company, a payment processor or a trading name you do not recognise. The feed has told you the truth and it is not usable.
- The document that never arrives. A payment is proof that money left. It is not proof of what was bought, and it is not the evidence a figure needs to stand behind it later.
- Allocation. One transfer settling four invoices, a part payment against one, or a customer who has short-paid by an amount nobody has explained. A single feed line has to become several decisions.
- Transfers between your own accounts. Money moved and nothing happened. Treated as ordinary transactions these inflate both income and expenditure, and the error is invisible because the balances are still correct.
- Commercial context only the owner has. Whether a payment was a deposit or a settlement, whether a cost belongs to a specific engagement, whether an unusual item is a one-off or the start of something recurring.
- Refunds, reversals and returned payments. A credit landing in the account is not automatically income, and a reversal is not automatically the cancellation of the thing it reverses.
Which produces the pattern owners keep meeting: the software reports that almost everything has been handled, and the month still cannot be closed. Both statements are true. The automatic share is large and the remainder is what decides whether the accounts are right.
Reconciliation is an agreement, not an import.
The word gets used loosely enough that two people can mean opposite things by it. Assigning a category to every line that has come in is coding. It is useful, it is necessary, and it is not reconciliation.
Reconciliation is the act of proving that two independently produced records of the same cash agree: the bank’s record and the business’s own. It only means something because the two records are kept separately. A genuine reconciliation produces four things:
- A closing balance per the bank, on a stated date.
- A closing balance per the ledger, on the same date.
- A dated list of every difference between them, each with a named reason — payments not yet presented, deposits in transit, charges not yet recorded, errors on either side.
- A remaining unexplained difference of nil.
If categorising an imported feed were the same act, the two balances would agree by construction and the difference would always be nil. That is precisely why it is not a check. A control that cannot fail is not a control; it is a display.
Where At Par fits — and the limits.
At Par does the part the feed hands on. Ambiguous lines get chased to a document or a person rather than a plausible category. Payments are allocated against the invoices they actually settle. Own-account transfers are treated as movements rather than trade. Every account is agreed to a statement, with each difference named. What genuinely cannot be settled without the owner comes back as a specific question, and a qualified accountant (ACCA) is accountable for the work.
Where a business already runs QuickBooks or Xero, the file stays theirs — the work sits on top of the system in place, not beside it. It runs as bookkeeping and month-end close, with receivables followed up where payments arrive unallocated and unexplained. Where feeds have been imported and coded for a year without ever being agreed, that is catch-up work before it is monthly work.
If the underlying question is whether software alone can carry this, that comparison is set out at AI bookkeeping services, compared. If it is which finance outcomes anyone should be accountable for, see what a provider should actually own.
Asked by owners whose software says everything is up to date.
Do bank feeds replace bookkeeping? +
No. A bank feed is a record that money moved. It carries a date, an amount, a direction and a counterparty string, and nothing about what the money was for, which invoice it settles, or which period the underlying event belongs to. Feeds removed most of the manual typing, which was real work worth removing. What remains is judgement, evidence and reconciliation — the part that was always the harder half and is now the whole visible job.
Is a categorised bank feed the same as reconciled books? +
No, and the distinction matters. Assigning a category to every imported line is coding. Reconciliation is proving that two separately kept records of the same cash agree: the bank balance, the ledger balance, and a named explanation for every difference between them. Coding an import cannot fail, because both sides come from the same source. A check that cannot fail tells you nothing, however complete the screen looks.
Why does a bookkeeper still need receipts if the bank already shows the payment? +
Because the payment proves money left the account, not what it bought. The receipt or invoice establishes what was supplied, when, by whom, on what terms, and whether any tax was involved. It is also the evidence a figure rests on when somebody later asks where it came from. Records that are reconciled but unevidenced hold up until the first serious question, which usually arrives from an auditor, a lender or a buyer.
How should a payment covering several invoices be recorded? +
It should be allocated against the specific invoices it settles, not posted as a single lump against the customer. Without allocation the ageing is wrong, follow-up chases invoices that are already paid, and any shortfall stays invisible. Where a customer has paid a round amount that does not match any combination of invoices, the correct outcome is a question to the customer rather than an assumption, because the difference is frequently a deduction nobody has mentioned.
Why do transfers between a business’s own accounts cause problems in the books? +
Because they look exactly like trade. Money leaves one account and arrives in another, and if both sides are treated as ordinary transactions the business appears to have spent and earned an amount it never did. Revenue and costs are both overstated while every balance remains correct, so nothing looks wrong. Transfers, owner drawings, credit-card settlements and inter-entity movements all need identifying as movements rather than activity.
What is a reconciliation difference, and does a small one matter? +
A reconciliation difference is any amount by which the bank record and the ledger record disagree at a given date. Legitimate ones have names — payments not yet presented, deposits in transit, charges not yet recorded. An unexplained difference has no size at which it becomes acceptable, because the amount is not the point: it indicates that something is recorded incorrectly, and a small net figure is often two larger errors partially cancelling.
If accounting software imports everything automatically, what is actually left to pay for? +
The exceptions and the judgement. Automatic import handles routine, repeating, self-explanatory volume well. What remains is deciding how unusual items should be treated, obtaining the evidence behind them, allocating payments to the right invoices, separating movements from trade, agreeing every account to a statement, and closing the period on a date. That work does not shrink in proportion to volume, which is why it is the part that gets bought.
Send us a month your software says is already done.
Pick a recent month that has been fully imported and coded. We will agree it to the bank, allocate what has not been allocated, and give you back the list of everything the feed could not settle.
Prefer to reach us directly? Tell us a little and we'll come back with a time.
Check a coded monthWe use your details only to prepare for and hold this call. No spam, ever.
Reviewed by an ACCA on the At Par team · Last updated 29 July 2026 · No claim is made here about any specific accounting product or bank. See what we actually do.