In this section
Reports will arise in two ways:
Billing Authority Reports (BARs)
Under the provisions of S.27(6) of the Local Government and Finance Act 1992, Billing Authorities (BAs) have a statutory duty to let Listing Officers (LOs) know of information which they become aware of, which they consider would assist LOs in carrying out their function of maintaining the Council Tax Lists. BAs provide this information on Billing Authority Reports (BARs)
All BARs (in any format) are received and registered at one of the Agency’s Network Support Offices.
Listing Officer Reports (LORs)
If a LO becomes aware that the Council Tax List may need to be altered, from sources other than Billing Authority Reports, he or she is required under S.22(1) and S.27(7) of LGFA 92 to review the Council Tax List. These sources extend to schedules of changes from BAs that are not in the form of actual reports. When, on receipt of such information, the LO raises his or her own report, this is called a Listing Officer Report (LOR).
Listing Officer Reports are registered within the appropriate network office.
The Local Government and Finance Act 1992 prescribes no set form of notification. However, reports from Billing Authorities are normally received via:
Billing Authorities are encouraged to send reports via the EBAR (electronic billing authority report) system, which matches to the CDB entry, raises and allocates a Billing Authority Report automatically.
This is now the most common method of notification and receipt. Reports sent by email (not EBARS) must be treated as received on the actual day the message is received, regardless of the time of day. For example, a batch of reports received electronically on 13 May at 23.59 is deemed to have been received on 13 May; a batch received electronically on 14 May at 00:01 is deemed to have been received on 14 May. Reports received during a weekend or on a Bank Holiday should be treated as received on the next working day. On the rare occasion when this occurs, the retained e-mail message should be endorsed accordingly.
All Billing Authority Reports (BARs) received should be recorded by the designated Network Support Offices on the appropriate CT Report Allocation spreadsheets.
Some BAs insist upon submitting schedules of changes and not actual reports. These must be accepted and LO Reports raised for the notified changes (*see paragraph 1.3).
Billing Authority Reports (BARs) must be scrutinised immediately upon receipt at the appropriate Network Support Office for any discrepancies such as incorrect address or reason code. The report numbers will also be examined to ensure that they follow on from those used previously. Any queries or omissions should be resolved by telephone between the Network Support Office and the BA (sometimes in liaison with the appropriate CT Unit or Location office)
The process for dealing with reports, received via the EBAR system, that require manual matching of addresses to the CDB, or for reports received via e-mail or in hard copy, may be found in the Council Tax Process Maps. Additional guidance can be found in the Council Tax Registration Manual produced for use by the Network Support Offices (the NSO Training Manuals can be found here).
Listing Officers are required under S.22(1) and S.27(7) of LGFA 92 to maintain fair and accurate Council Tax Lists. As well as reports from Billing Authorities (BARs) referred to in 1.2, other sources of information may be brought to the attention of the LO which could result in the Council Tax List being reviewed and updated.
These sources include:
- requests for review of banding made by taxpayers or their agents
- knowledge obtained as a consequence of dealing with other reviews, proposals or appeals (valid or invalid) on neighbouring dwellings. This may include noting information submitted as a Taxpayer’s representation that identifies errors or anomalies in the information in our records.
- schedules of changes from BAs which are not in the form of BARs .
In cases where it is clear that the entry in the Council Tax List requires review, the LO should raise a Listing Officer Report (LOR) against the property whose entry in the Council Tax List requires review.
LORs, such as those emanating from taxpayer enquiries, must be input onto the central database immediately.
Care should be taken not to raise LORs inappropriately. A taxpayer’s enquiry may not be valuation driven or, if valuation driven, it may be clear that any potential change in value is not band significant. These initial enquiries can often be resolved at the first or second point of contact.
If the enquiry does not result in a formal review of banding it is important that a record is held of the initial taxpayer enquiry on the CDB. In these instances Reason for Report Codes 90 or 99 must be used.
Where an invalid proposal is made by the taxpayer, the LO should raise a report to review the band (see Section 3). This should show Reason for Report code CR15 unless the invalid proposal relates to a new dwelling, a reconstitution or a deletion, in which case the appropriate Reason for Report code should be used (CR03, CR05 and CR01/CR02 respectively). If an invalid proposal is appealed against, the band must be reviewed prior to any VT/VTE hearing.
It is essential to create or amend an address on the CDB accurately;
- To assist customers in identifying properties on an internet search.
- To maintain a correct order of list entries.
- To enable SDLT matching (automated and manual).
- To facilitate efficient searching of the database for current work purposes.
When a new BA Reference Number is required, this should be requested from the BA by telephone. If the BA requires a written submission, letter VO7487 from MS Word Template may be used.
For requests to enter a new dwelling into the Council Tax List, the postal address of the new dwelling will first need to be created on the central database.
Additional guidance is available via the e-learning module ‘Address Application 2006 (July)’. All staff responsible for the creation and maintenance of addresses within the central database must complete this e-learning module. Additionally, it is recommended that staff refresh their knowledge by reviewing the e-learning module (the Address Application e-Learning module can be found here) on an annual basis. Guidance on correctly creating addresses can also be accessed via the Property Directory Work Aid (the Property Directory Work Aid can be found here) available on the intranet.
Every report (BARs and LORs) must be allocated a ‘Reason for Report’ code when entered onto the CDB. A complete list of Reason for Report codes is provided in the CT Mini Work Aid. Their use is mandatory and must not be varied locally. Billing Authorities are not obliged to use them but they need to be input appropriately whether supplied or not. If codes are not supplied, LOs will need to arrange for the reports to be annotated with the appropriate Reason for Report code prior to input.
It is the responsibility of the Council Tax Referencing Manager to monitor outstanding reports through the CS1 spreadsheet. This will ensure that all work is allocated to the appropriate grade of staff.
All BARs (in any format) are received and registered at one of the Agency’s Network Support Offices. LORs are to be registered within the appropriate network office.
The relevant information shown should be loaded (magnetic reports) or input to the computer within three days of receipt (for BARs). The actual date of receipt of the BAR, or the date originated (LOR), has to be typed in for each report. The date of receipt/origination may be before the date of input, i.e. the system date, but it cannot be later.
All reports for existing dwellings must be linked to the correct address within the CDB so information already held in other applications relating to the same property is displayed. This is particularly relevant when dealing with reports with Reason for Report Code CR10 where the computer will need to search the Property Transactions application for any relevant transaction. For newly built dwellings, an initial search should be made for the address, which may have been created when inputting a sale to Property Transactions. A new address should only be created when searches fail to identify that it already exists in the CDB.
As part of the inputting process, reports must be allocated to a Council Tax team and to a caseworker within that team. Allocating them to a team other than one designated as a Council Tax team can cause delays, particularly in becoming aware that a logged report (Reason for Report code CR10) has been triggered and a working docket is available for output.
The Network Support Offices will allocate all BARs to a ‘designated’ member of staff within each network office (normally a member of the Council Tax casework support team). Before printing the working dockets in the network office, the case owner should then be changed to the appropriate person.
LORs raised in network offices should be allocated to the appropriate Council Tax maintenance caseworker in the first instance.
If the caseworker, to whom the LOR is to be allocated, is not known at this stage, 999 can be input in order to progress to the next field. However, this must be amended as soon as the papers have been allocated to a caseworker.
Remarks should also be input where these are supplied on the report and these will then be output on the working dockets. This reduces the need in most instances to attach a copy of the report to the case papers. The inputting of any remarks which have been supplied is particularly crucial where the Reason for Report is CR10.
The computer will generate the report number for LORs.
Triage codes reflect the complexity of Council Tax reports and are linked directly to timeliness, inspection policy and caseworker grade. The reports that are measured for elapsed time and those that are excluded from elapsed time are shown in Appendix 2.1.
The five triage codes are:-
Triage 1 - Straightforward ‘off the desk’ cases.
Triage 2 - Non-inspected (simple & complex).
Triage 3 - Simple inspected.
Triage 4 - Complex inspected.
Triage 0 -This is for Working In Advance (WIA) cases where the effective date is later than the registration date.
When a report is registered on the CDB the ‘Triage Type’ field is automatically populated as a result of the ‘Reason For Report’ code that is allocated. The ‘Default Triage Codes’ and their respective ‘Reason For Report’ codes are shown at Appendix 2.2. It should be noted that all reports, whether or not they currently count towards the elapsed time target, are given a Default Triage Code.
Triage Code Timescales:-
Triage 1 = date of next available schedule – unless this is within two days of receipt in which case the date will then default to the next available schedule - a further 7 calendar days. After that the case will show as overdue.
Triage 2 = 14 calendar days.
Triage 3 = 28 calendar days.
Triage 4 = 35 calendar days.
Triage Code Timescales are NOT targets in themselves; they provide general guidance and enable work to be progressed and monitored through the CS1 spreadsheet.
The ‘default’ triage codes allocated should be reviewed by Referencing Line Managers and Case Owners and amended if appropriate to do so.
Once the information from the LOR Request has been input and the LOR number generated, the report exists and can never be removed. It can only be cleared by altering the band appearing in the List or by a formal No Action. The only changes permissible are the addition of another address where, on inspection, it is found that the address to which it has been linked is not the only one involved in the change, or exceptionally a change of address where it has been linked to the wrong address. The report number can never be cancelled or reused for another completely different report.
As part of their Service Partnership Agreement with the VOA, some BAs have asked to be supplied with details of reports raised.
A letter VO7491 can be obtained from MS Word Template to list them. This avoids the need to send copies of reports to the BA.
Working dockets VO7453 are automatically generated and output by the computer. Network offices are required to print out working dockets VO7453 on a daily basis.
By selecting the Print Working Dockets option from the menu the operator activates this function. An operational requirement of the system means that separate batches must be requested for each team. The batch will include working dockets for all reports activated since the last batch for that team was requested, including reports with Reason for Report code CR10 which have been triggered by relevant transactions (see Part 2). Schedules to working dockets (VO7454) are also produced where there is additional information which is not shown on the working docket.
Where remarks have been input as described in paragraph 1.7 above, they will be output to the working docket. No 'Remarks' section will appear on a working docket when none have been input.
Because of operational limitations, the earliest date working dockets can be output by batch is the next day following input of the relevant reports. Dockets can be requested for output on an individual basis on the same day as the report is registered.
No working dockets will be output for reports which have been registered and then reported immediately using the “Hot Key” functionality.
It is also possible to print out working dockets for selected outstanding reports, either singly or in batches. This action can be undertaken before the batch output is activated or at any time thereafter whilst the report is outstanding. Outputting a working docket before the batch run has no effect upon the contents of the batch, which will therefore include a duplicate in such instances.
Subsequent instructions are given in Part 3.
It is necessary to retain requests from Billing Authorities for audit purposes. These should be held in the format indicated below:
Requests via the EBAR system will automatically be stored within the central database. No further action is required
Following input, requests received via e-mail are processed by the appropriate Network Support Office and saved in the P drive.
Following input, hardcopy requests should be scanned at the appropriate Network Support Office and the scanned image stored by them into the respective network office ‘P’ drive. With EDRM, hardcopy originals once scanned, can be destroyed.