Bank feeds and bank rules in accounting software

A bank feed copies transactions from your bank account into your accounting software automatically, usually through an account information service regulated under the Payment Services Regulations 2017. A bank rule then tells the software how to code a recurring transaction, sometimes without anyone looking at it. Both save time, but HMRC’s Making Tax Digital guidance says it remains your responsibility to check your digital records are accurate, so rules need regular review and the feed still has to be reconciled to the real bank statement.

How does a bank feed actually work?

Some feeds are direct arrangements between a bank and a software provider, but many now use open banking. Regulation 2 of the Payment Services Regulations 2017 defines an account information service as an online service that provides consolidated information on payment accounts the customer holds with one or more other payment service providers. Your software provider, or a firm it partners with, acts as the account information service provider. You give consent and authenticate with your bank, and the provider then pulls each transaction into the software.

What arrives is limited. A feed line normally carries the date, the amount, the direction of the payment and whatever narrative the bank shows, such as a payee name or reference. It does not tell the software what was bought, whether the supplier charged VAT, whether the item was for business or private use, or whether it was capital or revenue. That missing information is exactly what the record keeping rules ask for.

Why do feeds stop working?

Access to account data does not last indefinitely. Before the Financial Conduct Authority changed the rules in policy statement PS21/19, customers had to reauthenticate with their bank every 90 days. PS21/19 created an exemption from that requirement and instead required the third party provider to reconfirm the customer’s consent at least every 90 days. If nobody responds to the reconfirmation request, the feed can stop and a gap opens in the records that is easy to miss. Some accounts cannot be fed at all, such as cash, some cards and some payment platforms, and these need manual entries or a statement import.

What does a bank rule do?

A bank rule is an instruction of the form “if the narrative contains this text, code the transaction like this”. The action can set the nominal account, the VAT rate, the contact and any tracking category. Depending on the software and settings, a rule either suggests a coding that a person accepts, or posts and reconciles the line with no human step at all.

It helps to separate two different things the software does with a feed line:

• Matching links the bank line to a sales invoice or purchase bill already in the system. The income or expense was recorded when the invoice or bill was entered, and the bank line only settles it.
• Creating records a brand new receipt or payment directly from the bank line. This is where rules are usually applied, and it is where most errors start, because the transaction is being recorded from the bank narrative alone.

What goes wrong with bank rules?

• VAT claimed without an invoice. A rule that applies the standard rate to every payment to a supplier assumes the supplier is VAT registered and that everything bought was standard rated. VAT Notice 700 paragraph 19.5 says you must hold valid evidence, normally a VAT invoice, to reclaim input tax. A bank statement line is not a VAT invoice.
• Double counting. If a bill was entered from the supplier’s invoice and a rule also creates a payment from the bank line, the expense is recorded twice and the bill stays unpaid in the creditors list. The same happens on the sales side when a customer receipt is coded straight to sales although an invoice was already raised.
• Mixed suppliers. A rule keyed to a marketplace, a payment platform or a supermarket catches business stock, equipment and personal shopping alike. One coding cannot be right for all of them.
• Capital coded as revenue. A rule for a builder or IT supplier that normally sends repair invoices will treat a one off purchase of equipment the same way.
• Loan and mortgage payments. A rule that codes the whole repayment to interest overstates the expense. HMRC’s Making Tax Digital guidance says that where a transaction is part capital and part revenue, such as a mortgage payment, you record either just the revenue part or the full amount followed by an adjustment.
• Net receipts. Card processors and online platforms usually pay out sales after deducting their fees. The Making Tax Digital guidance says that if you only know the net figure you should find out the full amount and record the income and the expenses separately.
• Transfers and private items. Transfers between your own accounts are not income, and a director’s personal spending on the company account belongs in the director’s loan account, not in expenses.

What does HMRC expect if you rely on a feed?

The law asks for more than amounts. Section 12B(3) of the Taxes Management Act 1970 requires a sole trader or partner to keep records of all amounts received and spent in the business and what each receipt and payment was for. Section 386(3)(a) of the Companies Act 2006 requires a company’s records to contain day to day entries of all money received and spent and what each sum was for, as explained in the duty to keep accounting records. A feed supplies the amount and date; the coding, the description and the supporting invoice supply the rest.

HMRC’s guidance on creating digital records for Making Tax Digital for Income Tax addresses bank feeds directly. It says that if your software connects to your bank account you may need to add detail such as the relevant Self Assessment category, that some transactions may not appear in full in your bank feed and will need to be created separately, and that it is your responsibility to check your digital records are accurate before sending a quarterly update. It also says you must keep original records or supporting documents, or copies of them, such as bank statements and invoices.

For VAT, Notice 700/21 lists bank statements among the business records you must keep. Importing data by API, CSV file or automated transfer counts as a digital link for Making Tax Digital for VAT, while cut and paste does not. A bank feed therefore satisfies the digital link rules, but it does nothing to make the underlying coding correct.

How should bank rules be reviewed?

1. Export or list every active rule with its condition, account, VAT rate and whether it posts automatically. Delete rules for suppliers you no longer use.
2. Switch rules for suppliers with mixed VAT rates, mixed business and private use, or mixed capital and revenue items from automatic posting to suggestion only.
3. Before each VAT return or quarterly update, sample transactions created by rules and check each to an invoice or receipt, paying most attention to VAT reclaimed.
4. Look for duplicates: the same amount to the same supplier on or near the same date, one created from a bill and one from the bank line.
5. Check the feed for gaps in dates, especially around the point when consent had to be reconfirmed.
6. Reconcile the software’s bank account to the closing balance on the bank’s own statement at each month end, as described in bank reconciliation. The feed balance is not independent evidence because it comes from the same data.
7. Limit who can create or edit rules, and review new rules when they are added.

What does a rule error look like in practice?

Illustration only. A VAT registered café sets up a rule that codes every payment to its cash and carry wholesaler to purchases with VAT at the standard rate. In a quarter it pays the wholesaler £3,000. The rule treats the £3,000 as VAT inclusive at 20% and reclaims one sixth of it, £500. The wholesaler’s invoices show that most of what was bought was zero rated food and the VAT actually charged was £150. The rule has overclaimed £350 of input tax in one quarter, and it will keep doing so every quarter until someone checks it against the invoices.

The fix is to stop the rule posting automatically, enter the wholesaler’s invoices as bills with the VAT shown on them, and let the bank line simply match those bills. Earlier returns with the overclaim then need correcting, as explained in correcting VAT errors.

What mistakes come up most often?

• Treating a line marked as reconciled in the software as proof that the books agree with the bank statement.
• Accepting suggested matches in bulk without reading them.
• Starting a feed on a date that overlaps statements already imported, which duplicates a block of transactions.
• Leaving unexplained items in a suspense or general expenses account because no rule fitted them.
• Throwing away invoices and receipts on the basis that the bank feed is the record. The feed shows that money moved, not what it was for.

Solar Protect provides tax investigation insurance for businesses and fee protection schemes for accountancy practices. Read how our cover works or get a quote.

Related Accountapedia entries

• Business credit card reconciliation
• The cash book explained
• Source documents and the audit trail
• Are photos of receipts acceptable to HMRC
• Sales and purchase day books explained

Sources

• legislation.gov.uk: SI 2017/752, regulation 2
• FCA: Ps21 19
• FCA: Ps21 19 changes sca rts and guidance approach document and perimeter g
• GOV.UK: Vat guide notice 700
• GOV.UK: Create digital records
• legislation.gov.uk: Act 1970 c. 9, section 12B
• legislation.gov.uk: Act 2006 c. 46, section 386
• GOV.UK: Record keeping for vat notice 70021

Reviewed by Christine Anderson, Broker, Solar Protect. Last reviewed 8 October 2026. Part of Accountapedia, the Solar Protect guide to UK tax and accounting. This page is general information, not personalised advice.