17. Mrs A complained that due to system or user errors, HMRC repeatedly overstated her BBSI in tax codes and in some calculations. Mrs A has a personal savings allowance of £1,000 because she is a basic rate taxpayer. This means that she is only taxed on bank interest she receives above £1,000 each year. Certain bank accounts, such as tax-free ISAs, are not counted for this purpose. Other taxpayers may have a different savings allowance depending on their total income.
What should happen when HMRC receives information about BBSI?
18. HMRC receives BBSI data directly from financial institutions, after the end of the tax year on 5 April. Taxpayers can also give HMRC estimates of what they are likely to receive, or the actual figures when they receive information from their bank or building society. Where the tax due on BBIS is collected via a restriction to the taxpayers PAYE code, HMRC estimates the amount of BBIS based on either the previous years’ record, or estimates provided by the taxpayer. After the end of the tax year HMRC performs a reconciliation using the actual amount of BBIS. HMRC collects additional tax due or issues a refund following the reconciliation, if necessary.
19. The data financial institutions provide to HMRC includes the name of the financial institution, the account number, and the gross amount of untaxed interest received. HMRC processes this data to taxpayer accounts after the deadline for institutions to send information - usually this happens in the Autumn. When reviewing taxpayer records HMRC staff cannot see the full account number, only the final 4 digits, the rest is masked for security purposes. If it becomes necessary, the full account number can be accessed.
20. When HMRC processes the BBSI data onto its records the system checks the existing BBSI data on file for that year. If the institution name and account number match one of the existing entries, it updates that entry with the actual BBIS amount for the year. If the system does not find a match for the account number or institution name, it creates a new entry with the information it received, as it assumes this is a new source of BBIS.
21. If the account number was previously entered in a slightly different format, either by the institution or in a manual update, this can cause the system to believe this is a new account in error and create a duplicate account. This can also happen if the bank name is entered differently. Many banks operate under a trading name, for example if a taxpayer advises HMRC they have a Post Office savings account, this must be entered as a Bank of Ireland account.
22. Information can also be added manually by HMRC staff. PAYE130061 instructs staff to use the full valid account number (if known) when manually adding BBIS to the system. This is to prevent accidental duplication when records from banks are added to the system. Staff have three options to choose from when manually adding a new source of BBSI. They can tell the system they will be entering a valid account number, or a ‘dummy account’, or a source of untaxed interest which is not from a bank or building society.
23. A dummy account is used when the full account number was not provided to HMRC, but a record needs to be made on the system of BBSI received. It might include BBSI from more than one source, for example if a taxpayer informs HMRC the total BBSI they expect to receive from four accounts without further detail. If HMRC already has the details of some accounts, the dummy account should only include the BBSI required to reach the total advised by the taxpayer.
24. Staff cannot see the full account number for existing accounts, so if they try and enter a new source with an existing account number the system will alert them to this. The user can then consider whether they should amend an existing source, rather than add a new one. This is to prevent duplicate accounts.
25. HMRC staff can only see the final four digits of the bank accounts and different accounts could have the same last four digits. When staff are making a manual update, they must update the closest match if several appear to be the same account.
26. Staff can also manually enter start and end dates on accounts. As well as being informative, the end date tells the system that the account will not be a source of BBSI the following year. This stops it from carrying the information forward to the next year as part of the estimate for BBSI. Although an end date for an account can be input on a record, institutions do not report dates of closure. If the account is not reported as closed by a taxpayer, it will continue to get carried forward as an estimate with the last known amount. If a source of BBSI is deleted from the current year but remains on a previous year, the system will reinstate the source at reconciliation.
27. As accounts can also have more than one account holder, the system has a record of how many account holders are named on the account. This defaults to one account holder, but taxpayers can tell HMRC if the account should be split. The BBSI is split equally between the account holders by default, but taxpayers can tell HMRC if the interest is split differently. As Mrs A has not complained about how the BBSI is split, we have not considered this further.
28. In summary, there are four ways that BBSI records can be double counted on the system: · The institution changes the format of the bank account number when it reports to HMRC, making it appear to the system as a new source of BBSI. This could be by changing the format from year to year. Alternatively, adding extra characters to the account number so that, even when the taxpayer has supplied the correct sort code and account number and the user has added this to the system correctly, the system cannot match the data to the correct account.
· The user adds an account manually and fails to recognise that it is a duplicate account, either from carelessness or because the record on the system does not have a standard account number.
· The user adds an account manually but then when the institution provides accurate figures after the end of the year, the account number does not match. This can be due to the user making an error adding the number, the taxpayer providing an incorrect number, or the institution using a format that differs from the standard sort code and account number.
· An account is deleted rather than having an end date entered. When the system next reconciles, it will reinstate the account.
29. When the record has been changed, either by importing end of year data from institution, or manually by a user, the system totals the current estimated BBSI. If this exceeds the personal savings allowance (£1,000 for Mrs A), the excess is included in the tax code as a deduction to collect the estimated additional tax due. At the end of the tax year, when actual BBSI has been imported from bank records, an automatic reconciliation is performed to check if the correct tax has been paid. If it has not, an HMRC operator will manually review the record.
What did happen?
30. On 14 January 2018, HMRC issued a tax code to Mrs A, which included no restriction to collect tax due on BBSI. At the time HMRC’s records showed that Mrs A was expected to receive BBSI of £468 – as this was below £1,000, it did not expect her to pay any tax on her BBSI. Mrs A did not query this code. She has told us she felt the BBSI recorded on her record was incorrect at this point, but as it made no difference to her tax, she did not correct it.
31. On 3 April Mrs A made an online application for Marriage Allowance. HMRC issued refunds in respect of 2015-16 and 2016-17 and amended her tax code. Her BBSI record did not change so no restriction was included in her tax code.
32. On 21 June HMRC reviewed the 2017-18 tax year and issued notification that a refund of £266.40 was due. This calculation included the estimated savings income of £468. However, on 25 June Mrs A told HMRC about a change to her savings income (as well as other income she received) by completing a form R40. HMRC updated her record to include BBSI of £1,400 and it amended her tax code for 2018-19 to include a BBSI restriction of £400.
33. Mrs A responded to an HMRC query about other income she had received and on 30 August it issued notification that a further refund of £122.42 was due. Mrs A corrected the figures HMRC used in the calculation on 7 September via secure message. HMRC cancelled this refund as a larger refund of £200.73 was calculated. Mrs A told us she still felt the figures did not match what she told HMRC in June, but the result was close enough. As she did not raise a complaint about this, we did not consider it further.
34. Until this point there were no problems with the BBSI restriction in Mrs A’s tax code.
35. HMRC completed its annual coding review on 17 January 2019. Following this it issued a code for 2019-20 which included a BBSI restriction of £2,140 as it had estimated total BBSI of £3,140. This was based on the BBSI estimation of £1,400 – now included twice – and added to BBSI reported by institutions of £340.46.
36. When HMRC investigated what happened in June 2020, it determined that the problem was caused the BBSI estimate of £1,400 being entered onto the system as a valid account type, with no account number entered. If the guidance was followed correctly, it should have been entered as a dummy account. HMRC’s findings are supported by its records.
37. If HMRC had correctly entered Mrs A’s June 2018 estimate as a dummy account, the full balance would not have carried forward. The system would have adjusted the dummy account to £1,059.54 to maintain a total of £1,400 when BBSI data was processed onto her record. However, HMRC entered her estimate as an actual bank account with no account number in the 2017/18 and 2018/19 years. The system could not match any of the 2017/18 data reported by institutions to this account and it also carried the balance forward into 2018/19, inflating Mrs A’s BBSI by a further £1,400.
38. Mrs A contacted HMRC on about the incorrect code on 5 February 2019 and queried whether it was caused by a system error. HMRC corrected her 2019-20 code manually. The two ‘valid’ accounts of £1,400 were amended to zero and a dummy account of £873 was added. At this point the system had carried forward valid accounts totalling £406. This meant the system recorded a total BBSI of £1,279 and restricted her code by £279 to collect this tax. This change appears to have been made in line with guidance.
39. The next day Mrs A contacted HMRC again and it amended her BBSI to £1,347 for 2018-19 and 2019-20. The dummy account was amended to £941 for both years. She called to again on 12 and 25 February, and HMRC change the BBSI figures to £1,306 and £1,349 respectively. HMRC amended the dummy account to £842 on 12 February. By 25 February, Mrs A was provided details of nine accounts and no dummy account was used. During the 25 February call, Mrs A estimated that her 2019-20 BBSI would be £1,360, leading to a code restriction of £360. Mrs A told us that she called so many times about this tax code as she struggled to get HMRC staff to update the BBSI to the correct amount.
40. On 6 September Mrs A started to receive her State Pension. DWP notified HMRC of the amount and HMRC automatically updated her tax code on 8 September to include a restriction to collect the tax due on her state pension. The BBSI restriction was increased to £3,648 at the same time, because most of the BBSI records were duplicated or even triplicated. HMRC’s investigation concluded that this was because accounts had erroneously been deleted in June 2018, instead of being zeroed or having an end date added. Consequently, the system resurrected the accounts and brought them forward to the new code.
41. We could also see that one institution was using an internal reference for its accounts, whereas Mrs A provided the bank account number known to her. HMRC’s system therefore could not match the information it received to the details provided by Mrs A and assumed these were new accounts.
42. On 20 September Mrs A rang HMRC regarding the tax code. She provided figures from her records for BBSI and HMRC updated these to show total BBSI of £1,096 and a tax code restriction of £96. It appears that HMRC staff deleted some of the BBSI records on the system, which is not in line with guidance.
43. Following these events, Mrs A first complained about the errors in her BBSI records and tax codes.
44. On 19 January 2020, Mrs A’s 2020-21 tax code was issued. The BBSI figures and code restriction were unchanged.
45. On 14 October HMRC issued a new tax code to Mrs A with updated BBSI. Accounts had again been duplicated in the BBSI record when data was processed onto Mrs A’s records, giving total BBSI of £2,959. A restriction of £1,959 was included in her tax code. It also issued a tax calculation for 2019-20 including the incorrect BBSI, which resulted in a tax bill.
46. Mrs A asked HMRC to correct this on 20 October. Her tax code was manually amended to include correct figures totalling £1,427 and the duplicate accounts were zeroed. This action appears to have been taken in line with guidance. HMRC also corrected the tax calculation and determined that it owed Mrs A £35.60.
47. On 20 January 2021 annual coding was carried out and BBSI of £2,528 was calculated leading to a code restriction of £1,528. This was incorrect but picked up by an HMRC complaint handler before Mrs A received her tax code, who was able to warn her. In February HMRC recalculated Mrs A’s tax for 2019-20 and determined she owed £444. This was also wrong and was again spotted by the complaint handler who was able to warn Mrs A. HMRC told us it subsequently set a flag on Mrs A’s record to ensure that her tax code was reviewed manually before being issued.
48. Having considered the timeline of events, it appears that on several occasions HMRC staff failed to follow the guidance in HMRC PAYE130061 when updating the BBSI record on Mrs A’s account. Evidence we have seen suggests some accounts were deleted instead of being zeroed or given an end date. On one occasion an account was not marked as a dummy account, leading the system to try (and fail) to match it to imported BBSI data.
49. In addition to this, there was the known issue of an institution using internal account numbers. If Mrs A contacted HMRC with BBSI details after the institution submitted its data, staff should be able to locate and update the relevant accounts by following the guidance. However, if this happened before HMRC received the data and staff followed the guidance, the system would not be able to match the accounts once the BBSI data was received, because the account number would be different.
50. Our Principles of Good Administration say that public bodies should handle and process information properly and appropriately in line with the law. Mrs A provided HMRC with information about her BBSI, but it did not always process this information in line with the relevant guidance. We consider that this amounted to a failing.
51. Having identified a failing, we went on to consider the impact this had on Mrs A.
52. Every time Mrs A received an incorrect tax code, she contacted HMRC to ask it to put this right. She did so at least six times, as she was not always able to resolve the issue on the first call. If she had not taken steps to tell HMRC her code was wrong the issue would not have been resolved, as HMRC relies on taxpayers to check their code.
53. Our Principles for Remedy say that public bodies should: · acknowledge when things have gone wrong · accept responsibility · learn from its maladministration or poor service • put things right.
54. Following her initial complaint in 2019, HMRC acknowledged that mistakes and system errors had caused BBSI amounts to be duplicated on more than one occasion. It explained the sequence of events leading to each error and acknowledged that it must have been very time consuming and frustrating for Mrs A. It apologised and offered Mrs A £100 redress. HMRC also said that there was a ‘system issue’ causing duplication, which was under investigation.
55. These actions are broadly in line with our Principles for Remedy, however Mrs A was not satisfied that HMRC would learn from its mistakes, as it did not seem to know why some of the duplication issues were occurring. She escalated her complaint to the Adjudicator’s Office (AO), which is the final stage of HMRC’s local complaint process.
56. The AO agreed that HMRC could have handled her complaint better. It identified delays, which we are not considering here, and it also asked HMRC to write to Mrs A to better explain the steps it had taken to improve the level of service to customers.
57. In response to the AO’s findings, HMRC wrote to Mrs A in June 2020. It told her that the errors were caused by ‘operator error’, rather than technical error as it had initially believed, and it had now resolved this through feedback to that department. Mrs A was initially satisfied with that response.
58. In October 2020, a further tax code was issued including inflated BBSI. Mrs A wrote to HMRC to complain again.
59. In November 2020, HMRC told Mrs A there was known issue with the system duplicating bank interest. It apologised to Mrs A again and offered her a further £25 redress.
60. HMRC’s April 2021 letter attributed the problems to human error, late submission of information from banks and building societies and manual updates, which were still in the process of being fixed. It explained that in October 2020 it had inappropriately deleted some of her accounts, although we note that these accounts seem to have been deleted earlier and had reappeared in October 2020. It also warned that ‘late submissions by banks and building societies and changes to account numbers and sort codes may result in incorrect tax codes and calculation in the future’.
61. We have no doubt it was frustrating for Mrs A to believe an issue to be resolved, and then realise it was happening again and likely to happen in the future. Furthermore, it was unclear exactly what was going wrong - whether it is a problem with the software, or with the staff failing to implement guidance properly, or with staff following poor guidance.
62. Mrs A told us she felt a sense of outrage that these issues could be affecting many other people, who may or may not have knowledge to identify the problem and put it right. HMRC informed her on several occasions that the issues were already known, which implies that other taxpayer accounts were affected before she raised the problem. We saw no reason to doubt she was outraged by this.
63. We considered whether HMRC had done enough to put things right in line with our Principles for Remedy. HMRC did acknowledge what went wrong by providing an explanation, it apologised, and it put things right by paying financial redress totaling £225. These actions are in line with our Principles, and Mrs A did not ask us to consider these further.
64. Mrs A brought her complaint to us as she remained concerned that HMRC had still not learned from the mistakes she had experienced over a two-year period. Our Principles say that organisations should also seek continuous improvement.
65. We consider that HMRC had not learned effectively from Mrs A’s initial complaint, as she suffered the same issues two years later. She was concerned these issues could be affecting many people. At the time Mrs A brought her complaint to us, we consider HMRC had not yet demonstrated it had put improvements in place.
66. That being said, we acknowledge that there were several factors involved which were causing error and duplication of accounts. It would need to take a great deal of care with changes to ensure that further issues were not inadvertently created. In November 2020 HMRC told Mrs A, ‘this is a complex situation and we do not have, at this time, a date for when the situation with duplication of BBSI will be resolved’.
67. We asked HMRC for evidence of any changes it had made, or planned to make, to avoid these issues in future. It sent us details of changes it had made to OCELOT, a piece of software which gives HMRC staff interactive guidance while undertaking their work. It also confirmed it had reached an agreement that, in future, the financial institution which was reporting internal references would switch to using customer references. We considered whether these actions would address the type of mistakes we had seen.
68. Our investigation did not identify any instances of institutions reporting account numbers inconsistently which caused duplication of accounts. We note that the switch from internal to customer references mentioned above may cause an issue and we trust that HMRC will have mitigation in place.
69. OCELOT now displays a warning note to staff to help them enter data accurately. This explains that BBSI is always submitted by the parent company of an institution and provides a link to a list of which parent company each financial brand should be listed under. It also warns staff that some companies do not give account numbers in the familiar sort code and account number format, so they should take care not to create a new entry when they should update the existing entry. OCELOT goes on to say that if staff need to add a new source of BBSI, they need the sort code and account number, as well as the interest amount – although some accounts have won’t have this format of account reference, OCELOT has already caveated this, and the implication is they need the account reference.
70. The guidance was communicated to relevant staff through a regular cascade on 29 October 2021. The cascade highlighted the problems caused by failing to update records correctly, explaining that the system will create a new entry if it cannot match an account, and this results in duplication. It added that this was not a system fault, but a quality error caused by staff failing to follow the appropriate guidance. We think these changes help to address inaccuracy and carelessness. If staff still fail to follow the appropriate guidance, then this can be addressed through its existing employee management procedures.
71. If a taxpayer only provides total BBSI to HMRC, OCELOT asks staff to update existing accounts so that the balance matches the customer total. It notes that at the end of the financial year the actual BBSI figures will be received and will overwrite whatever is entered. This alternative to using a dummy account is simpler and appears to give less opportunity for error, and we think this is an improvement. If this guidance had been in place in June 2018, we think it likely the operator who updated Mrs A’s record would not have created the new account for £1,400 which caused code errors at later dates.
72. If staff have any uncertainty about whether account details received from a taxpayer matches an existing entry, or if the taxpayer disputes an entry, OCELOT tells them to send a referral to a specialist team.
73. The October cascade also reminded staff that, in line with PAYE130061, it was important to only remove accounts where there is clear evidence that it is incorrect or not the customer’s. While the guidance on this was previously clear, we think this shows HMRC identified that staff did not always follow this correctly and were deleting accounts instead of entering end dates. It has taken steps to remind staff of the correct process and, as previously mentioned, employee management processes can be used if staff still fail to follow guidance.
74. While it may not be possible to eliminate all errors in recording BBSI, we consider that HMRC have taken appropriate steps to reduce the chance of these happening.
75. We were sorry to hear that Mrs A had to repeatedly take steps to correct errors in her BBSI records and tax codes, and it is understandable that she had concerns that she (and others) would continue to have to do so in future. Having considered the changes HMRC has made to its guidance and the reminder of the consequences of error it gave to its staff, we think that it has done enough to put this right. Therefore, we do not uphold Mrs A’s complaint.