In Your Face

The Merging of the Customs and Inland Revenue

Gordon Brown, in his recent UK budget, announced that the offices of Customs and Excise and the Inland Revenue would be merged. The timescale for this is estimated, by KPMG tax chief Laughlin Hickey, to be around five years.

The disruption and chaos to the UK tax and VAT systems, that it will undoubtedly cause, is beyond measure. Needless to say, the overburdened tax payers will bear the brunt of the chaos.

One area that will undoubtedly cause the most difficulty will be the merging of the departments’ computer systems. As anyone who has managed an IT changeover knows, the process of upgrading or changing an IT system needs to be carefully planned controlled and monitored.

Many private sector firms find IT system changes to be unexpectedly costly, both in terms of time overruns and money expended trying to fix “bugs” etc; which were not expected at the planning stage. The history of public sector IT changes is littered with even more expensive failures, the IT upgrade of the air traffic control system is one such example of poor planning and control.

This seems an apposite time to remind IT managers (and the Treasury) of the basics of planning, and managing, a successful IT change.

Here is a very generic checklist, which can be used when reviewing the merits/demerits of a new IT system. Note, it is very basic, and is not intended to be comprehensive.

General

System/user specification - compared with standard Internal Control Objectives. Is the package in conformity with company recommendations?

• Is the system being taken "as delivered" or is it being customised?


• if so, additional development costs and timescale


• if so, implications for system size and response time


• use of PC packages to replace or supplement larger systems


• are features being lost which will have to be replaced e.g. inputs to planning at head office level.

Cost rentability/payback savings:

• what are the alternatives?


• have all costs been identified and included e.g. incremental licence fees?


• has the in house IT department been permitted to bid for service and have cost-comparisons been prepared on a rational basis?


• downsizing risks.


• cost implication for remaining users.

Interfaces to other systems

Organisational issues:

• user profiles set up to reflect organisation.


• discipline in manufacturing environment.


• is integration within the package matched by an integrated approach to the implementation?


• is system ownership/module ownership clearly defined?


• is the role of Data Administrator defined?


• is there sufficient local expertise for a stand-alone IT dept. especially if there is a change to unfamiliar hardware and operating system?

Controls

• Security and disaster recovery.


• what is covered by a Service Contract with the in house IT department, and what is a local responsibility e.g. order desk terminals?


• Maintenance/support:


• costs of third party support

Internal Control Checklist

This checklist covers the key issues which will arise from the initial review of the application.

Access controls:

Validation checks:

• both within the system and by responsible officials e.g. credit referral


• All points of data entry identified/controlled


• Clearance of rejected data/dump accounts:


• clearly defined who should receive the data


• timescale for reacting to that data


• escalation procedure if a serious problem manifests itself


• log for registering error reports and their disposal

Processing/proving checks (closed loop):

• goods movement:


• consider all aspects of logistics chain e.g. is material removed by Quality Control?


• identify exit and entrance points.


• Are transactions registered in correct chronological sequence e.g. if work in progress is back flushed before stores issues are booked, there will be an apparent negative consumption.


• Does opening balance plus each class of transaction produce an amount equal to sum of closing balances on stock file?


• Does opening balance of debtors plus each class of transaction produce an amount equal to sum of balances on sub-ledger?


• Does same logic apply to accounts payable sub-ledger?


• Batch thinking can be usefully carried over to modern packages when considering completeness of processing.

Exception reports:

• responsibility for acting on them


• Authorisation of sensitive transactions e.g. special discounts, credit notes, write offs/ons, adjustments. VAT implications.


• All physical points of despatch identified and controlled, including direct deliveries. Proof of despatch to and receipt of goods at remote sites e.g. telecommunication infrastructure project.

Exceptional transactions outside normal system parameters:

• one-offs, manual dockets, specials, projects, tooling charges.


• Cancellation/reversal of transactions. Authority and method of booking e.g. tends to be basic data capture as distinct from system-generated transactions. Effective communication of effect on net net turnover.

Master data file maintenance:

• customer, product, price files, vendor record, classification of accounts.
  

Bill of Materials:

• completeness and accuracy.


• Processing/job dependency sequences control. Quality of user manual - are dependencies explained?


• Interface/reconciliation of operational system with financial accounts - nominal ledger:


• order processing, goods movement, accounts payable, accounts receivable, cash


• Month end/year end procedures. Closing off and archiving procedures.


• Ability to restore. Initialisation of new accounting period.


• Initial transfer/loading of files from previous system including manual systems. Are front-end validations/checks being used or by-passed? If latter, will copied over data be regarded as corrupt by new package?
  Watch for reversible entries when transferring over a trial balance.
  

Goods Received Note/Receiving Report clearance:

• age listing and price difference analysis.


• Audit trail/history records:


• days/months available on screen?

Back-up/contingency planning:

• risks prioritised


• disaster recovery plan


• Control of change management. Implications for software and organisation. Will home-grown changes make it impossible to take new releases of third party software?


• Is there an ability to fix problems locally or is all technical expertise in, say, the USA of Germany? If overseas, what is response time?

EDI links with suppliers and customers:

• cost benefit of reducing goods movement pipeline but need to minimise exposure to hacking.

System reporting

• Do people get the reports they need and does the IT department know the distribution list?



• Does the package provide an addressing facility; do not take it for granted that it will.



• Are the reports acted on and/or do staff know what to do with them?



• Training of operators and users. Are features understood and are they being used cost-effectively? Are staff working around the system e.g. is it in danger of migrating to PC spreadsheets?



• Control of charges from software houses for maintenance and development. Proper contracts in writing and proper system for screening orders for change requests.