Atlas Specialty Metals Limited (Formerly Southward Engineering Company Limited) v KPMG New Zealand HC Wellington CIV 2003-485-1331

[2007] NZHC 1571

IN THE HIGH COURT OF NEW ZEALAND WELLINGTON REGISTRY

CIV 2003-485-1331

BETWEEN  ATLAS SPECIALTY METALS LIMITED (FORMERLY SOUTHWARD ENGINEERING COMPANY LIMITED) First Plaintiff

AND  ATLAS SPECIALTY METALS LIMITED (FORMERLY STAINLESS ALLOYS LIMITED)

Second Plaintiff

AND  EXHAUST SYSTEMS AUSTRALIA PTY LIMITED

Third Plaintiff

AND  KPMG NEW ZEALAND Defendant

Hearing:         27-30 November, 1, 4-8 December 2006

Appearances: J S Kos, J K Goodall & C A Brown for Plaintiffs

M A Gilbert & S M Hunter for Defendant

Judgment:      1 February 2007 at 10 am

RESERVED JUDGMENT OF MILLER J

ATLAS (FORMERLY SOUTHWARD) AND ORS V KPMG NZ HC WN CIV 2003-485-1331  1 February

2007

CONTENTS

Introduction

The Southward group

Selection of Baan 4 enterprise resource planning software

The legacy TIMS system

The request for proposals
Baan’s proposal
The scope document for stage 1 implementation

The contracts

KPMG’s appointment as auditor

The audit request for proposals

KPMG’s appointment and audit presentation

The Baan 4 set-up, integration, and testing processes

Implementation management

Sim 1
Sim 2

Sim 3

The 1 April deadline

KPMG’s information risk management assurance work

The state of the Baan system on going live

Acceptance of Sim 3

The 31 March 1999 balance sheet audit

Implementation at Exhaust Systems Australia The long and winding road to reimplementation Baan problems and their implications

Integrations

Accounts payable and receivable
Ageing analysis code for debtors and creditors

Sales pricing

Cost price calculations Foreign currency transactions Payment differences

Freight recoveries

Customer accounts Financial statements Average/standard costing

Debits and credits set up the wrong way around

Anticipated payments Company structure set up Conclusions

The pleadings

Who    might     enforce    KPMG’s    data    conversion    assurance

obligations?

What obligations did KPMG assume?

Did KPMG perform its obligations?

What risks ought KPMG to have foreseen?

Would  Southward  have  delayed  implementation  had  KPMG

warned against going live?

Steps required to remedy defects as at 2001

Decision

[1] [6]

[9] [10] [13] [19] [22]

[25] [33]

[35] [39] [41] [45] [50] [53] [60] [64] [72] [76] [78] [88] [89] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104] [105] [107] [116]

[120] [128] [130] [133]

[136] [140]

Introduction

[1]      Southward Engineering Company Limited was a substantial manufacturer of metal products, notably mild and stainless steel tube and vehicle exhaust systems.  In

1998 it decided to install a new ‘enterprise resource planning’ computer system intended to integrate its production and quality control, purchasing and inventory management, sales and marketing, and finance and accounting functions.  Southward selected Baan 4 software, which was tailored to its needs and implemented under a software implementation contract dated 17 November 1998 with Baan Australia Pty Limited.    KPMG,  which  operates  in  New  Zealand  as  a  partnership  providing business advise and auditing services,  acted as a sub-contractor to  Baan, taking responsibility along with Southward’s management for tailoring the software to fit Southward’s needs.   The “go-live” date for the Baan system was designated as 1

April 1999.

[2]      Southward  was  a  family-owned  firm,  and  its  managing  director,  Roy Southward, was nearing retirement.  He was to be succeeded in January 1999 by a chief executive from outside the family.   For that reason, the directors decided to have the firm’s accounts and those of its subsidiaries audited for the first time.  That would require verification of the balance sheet as at 1 April 1999, and an audit for the year ended 31 March 2000.  A request for proposals was issued on 27 November

1998, drawing the attention of bidders to the contemporaneous Baan 4 implementation.   KPMG saw an opportunity to exploit its role in the Baan 4 implementation, and its successful bid volunteered “data conversion assurance” as part of the initial balance sheet audit.  It took the form of a review the objective of which was to minimise the risk associated with converting data from the legacy system, called TIMS, which Baan was to replace.  It would include a brief evaluation of the risks of going live, an assessment of the data conversion process, and a review of data matching.

[3]      Relying on its longstanding finance and business advisors, Deloitte Touche Tomatsu, Southward also announced a restructuring just before Christmas 1998, and implemented it in mid-February.  Staff numbers were reduced significantly, largely in anticipation of changed needs after the Baan system went live.

[4]      Set up and testing of the Baan software was both delayed and to some extent incomplete, partly because of the restructuring.  Nonetheless, the system did go live on 1 and 6 April 1999.  There were some data conversion errors, and a number of integration errors affecting the mapping of transactions among parts of the Baan software.   These affected the finance and accounting areas in particular.   Many of these issues were immediately apparent and were sorted out by around August when Southward accepted the system.  Southward did not take up Baan’s offer of ongoing support.     After  some  key  users  resigned,  Southward  staff  encountered  many problems, most of which involved inability to obtain accurate financial data from the system.  In 2001 Southward engaged IBM, which advised that the system should be reimplemented using new Baan 5 software.

[5]     In this proceeding, Southward sues KPMG for costs associated with reimplementation, saying that KPMG failed to carry out data conversion assurance as promised, and failed to warn Southward of the risks of going live after inadequate testing.     Had  KPMG  warned  Southward  in  strong  terms  against  going  live, Southward would have delayed so Baan could remedy defects that later emerged. KPMG responds that it did adequately warn of implementation risks, that Southward decided to go live despite that advice, that Southward would not have delayed going live had KPMG identified the issues that Southward now complains of, that there were no unusual implementation problems and the errors that emerged were easily remedied, and that most of the problems that led, much later, to reimplementation were of Southward’s own making; Southward made  many staff redundant  while setting the system up and later failed to replace key staff who resigned, with the result that the system was not properly administered in operation.

The Southward group

[6]      Southward Engineering Company had manufacturing plants in Wellington and Auckland, and a distribution warehouse in Christchurch.  It had two subsidiaries, Stainless Alloys Limited, a steel merchant that imported and sold various types of steel, with branches in Auckland, Hamilton, Wellington and Christchurch, and Exhaust Systems Australia Limited, which was established as an outlet for selling Southward exhaust systems in Australia and had branches in Melbourne, Sydney and Brisbane.

[7]      Roy was the managing  director of Southward  Engineering  Company and Stainless  Alloys,  and  his  brother  John  was  the  other  director.    Roy  retired  in December  1998.    His  impending  retirement  led  to  a  decision  to  hire  a  chief executive, Keith Spacapan, who formally took up his position in January 1999 but appears to have been onsite some time before that; he received a presentation on the project on 30 October 1998.

[8]      The Southward group was sold to Atlas Specialty Metals Limited in June

2004.   Southward Engineering Company and Stainless Alloys were amalgamated into Atlas Specialty Metals on 1 October 2006 and 1 July 2005 respectively, and struck off the Register of Companies.  The amalgamated company assumed the name of Atlas Specialty Metals.  In the meantime, this proceeding had been issued in July

2003.  It appears that Atlas has no substantive interest in the proceeding, which is being  conducted  for the benefit  of Southward’s  former  shareholders.    After  the amalgamation was revealed during cross-examination of Mr Southward, Mr Kos sought  to  amend  the  pleading  to  substitute  Atlas  Specialty  Metals  Limited  as plaintiff, and that was eventually done without opposition from Mr Gilbert.   For convenience, I will continue to refer to the first and second plaintiffs by their former names and I will call the plaintiffs ‘Southward’ unless it is necessary to distinguish among them.

Selection of Baan 4 enterprise resource planning software

The legacy TIMS system

[9]      Southward decided to replace the TIMS software for a number of reasons.  Its functionality was limited; because it was not integrated, information did not flow easily within the  business, and the costs of maintenance  and  support  were high relative  to  its  functionality.    Apart  from these  efficiency  limitations,  the  TIMS system that Southward used was version 8, Southward having chosen not to replace it with upgrades issued since it was installed in 1991.  Version 8 was not year-2000 compliant.

The request for proposals

[10]     Selection of a computer  system supplier,  negotiation of the  contract  and implementation  were  delegated  wholly  to  management,   led  by  the  financial controller, Des Oliver, whose responsibilities extended to information technology.

[11]     Southward issued a request for proposals in March 1998.  It was prepared by Deloitte and set out the company’s requirements for an integrated enterprise resource planning system.  It envisaged that the solution would be implemented between July

1998 and February 1999, and recorded that the:

Project must be completed before the year 2000 date format causes problems in our current system.   To achieve this the new system must be fully operational by 1 April 1999.

[12]     The  RFP  provided  that  the  project  was  to  be  managed  by  Southward employees Mr Oliver, who was designated “project owner”, and Dave Campbell, who was to be the project manager.   Southward would provide business expertise through staff possessing extensive knowledge of the business requirements; they would work part-time on the project and become members of the project team.  The supplier was to supply, configure and implement the system, which was to comprise a number of modules.  They included, for example, accounts payable and receivable, fixed  assets,  general  ledger,  cost  management,  customer  service  management,

inventory management, production scheduling, sales and operations planning, and warehouse control.

Baan’s proposal

[13]     Baan Australia Pty Ltd submitted a proposal through its New Zealand sales agent, Michael Murphy.   The proposal was made in conjunction with Axon and KPMG.  Baan was to provide the software, quality assurance, and support.  At start- up and thereafter from time to time Baan would also review “key deliverables” to ensure they were of good quality.   Axon was to provide hardware.   KPMG’s role was “leading the implementation of the systems into your business, including system configuration,  testing  and  training  for  your trainers”.    The  proposal went  on to explain that KPMG had an international business partnership with Baan, and a core of eight Baan product specialists in New Zealand.   It emphasised that the project team must include full-time Southward employees who would act as “champions”.

[14]     The project was to be divided into three phases, which were described in evidence as Sims 1, 2 and 3.  Sim 1 was the “mapping” phase.  It was to produce a migration plan or blueprint showing how Southward’s business processes should be transposed  or  mapped  into  the  Baan  system.    The  migration  plan  was  to  be developed by the project team, including Southward management, and approved by Southward.

[15]     Sim 2 was the “piloting” or “prototyping” phase, in which the Baan system was configured appropriately to Southward’s business.  This involved setting up and testing data conversion so that Southward’s data would be transferred to the correct location in the Baan system, setting up integrations or mappings between modules, testing the system to ensure these processes were set up correctly, and developing training documents.   For example, materials and operations (machine and labour) costs had to be recorded and mapped to the general ledger so that Southward could monitor its cost of sales and thus determine whether it was profitable or not.  At the end of the Sim 2 phase, the project team would produce a final business model for approval by Southward management.

[16]     Sim 3 was the “migration” phase, during which Southward data would be migrated to the new system, which would go live.  In this phase, end users were to be trained by Southward key users, who in turn had been trained by Baan, on how to use the system.

[17]     The Baan system is highly flexible and capable of extensive configuration to meet  the needs of a particular  business,  which can pick and choose among the modules it uses and add functionality after implementation.  Baan proposed that the system would not be fully customised on migration at the end of Sim 3; rather, it would be configured so that further customisation could be carried out by end users. When the system is running, users can alter mappings, add new items or customer groups, or change a warehouse.  Errors in data conversion are capable of being fixed by journal entry, and mapping errors can be fixed, by expert end users or system administrators.   As will be seen, some initial functionality in the finance area was sacrificed so that Southward could go live on 1 April.

[18]     Baan offered an estimated price of $1.147 million.

The scope document for stage 1 implementation

[19]     After reviewing all of the proposals that it received, Southward decided that it preferred the Baan proposal but required a fixed price.  Des Oliver agreed with Baan that it would conduct a scoping study at Southward to identify the precise scope of the implementation and arrive at a fixed price.  The scoping study was undertaken by Chris Day, a KPMG employee, and Dennis Gardner, a senior project manager at Baan, and delivered on 2 November 1998.  It recorded that it described the services necessary to implement the Baan system at Wellington and in the marketing/sales area at Auckland.  The internal Southward team would later implement the system at remaining branches, and in the distribution and production areas at Auckland.  The document set out Southward’s requirements at some length, identifying sales and marketing, production planning and quality control, purchasing and inventory management, and finance as the areas critical to success.  Finance included accounts payable  and  receivable,  fixed  assets,  general ledger,  management  reporting,  and budgeting.

[20]   The document outlined the project team, comprising Baan/KPMG and Southward teams.  On the Baan side, Dennis Gardner was to be the project director, and the project manager was to be Gideon Pieters.  Beneath him, a number of KPMG consultants would deal with manufacturing, finance, sales and marketing, and technical issues.  The KPMG finance consultant was Roger Grove.  Les Eriksen of Baan would provide operational quality assurance.  The Southward project team was to be headed by Des Oliver, and the project manager was to be Evelyn Ozorio, a Deloitte employee who had been seconded to Southward to replace Dave Campbell because Des Oliver  recognised that  Southward needed an expert  to  manage the implementation.   Ms Ozorio had been involved in preparing the RFP.     Her role included assessing risk and taking preventive action, and monitoring team performance.   Another Deloitte employee was later seconded to assist her.   Other Southward employees were designated as part of the project team.  Those employees were to take responsibility for developing business processes required by Southward and ensuring that the applications delivered supported those processes.

[21]     Attached to the scoping document was a Gant chart in which 1 April 1999 was   designated   as   the   go-live   date   for   Southward   Engineering   Company’s Wellington  operation  and  sales  and  marketing  functions  at  Auckland,  and  for Stainless Alloys.

The contracts

[22]   Southward required a software licence and support agreement, but the implementation was carried out under a separate software implementation services agreement dated 17 November 1998 between Southward Engineering Company and Baan Australia Pty Limited.   That agreement provided that Baan Australia would install and customise the Baan 4 application software, warranting that it was highly skilled and experienced in doing so.

[23]     40% of the total payment was to be made on milestone dates.  Payment for Sim 1 was due following examination to ensure that the business model complied with best practice standards.  Payments for Sims 2 and 3 were due following not less than 30 days testing of each deliverable to  determine  that  it  complied with the

functional requirements of the RFP.  Under clause 5.2, Southward was to operate the software, with Baan’s assistance, for a period not exceeding 30 days after going live to determine whether it conformed to the defined requirements and was capable of processing a variety of Southward’s actual data on a repetitive basis, without failure. Baan  agreed  to  make,  without  charge,  any  modifications  or  corrections  that Southward reported to it within 90 days after signoff of each deliverable.

[24]     The agreement provided that Baan’s liabilities to Southward arising out of any damages would not exceed in aggregate the total amount payable by Southward to Baan for the goods or services that gave rise to the claim, and excluded any claim for loss of profits or savings or indirect or consequential loss or damage.   It also provided that no action arising out of the agreement might be brought by either party more than two years after it learned of the cause of action.  It does not appear that Southward made a claim against Baan, or for that matter anyone else involved in the implementation.

KPMG’s appointment as auditor

The audit request for proposals

[25]     Mr Oliver issued a request for proposals on 27 November 1998.  It specified that the audit was required for the Southward group, including Stainless Alloys and Exhaust Systems Australia, and that consolidated accounts would be required. Southward required an audit of the opening balance sheet and a full audit for 31

March 2000 accounts.  The RFP identified a potential audit issue, in that Southward was   implementing   new   information   systems   encompassing    manufacturing, marketing and finance, and the system was to go live on 1 April 1999.   Inventory and debtor valuations would require review.

[26]     On 3 November, Mr Oliver met Mr Buckley and Mr Edwards of KPMG. Outlining the group structure and accounting issues, Mr Oliver explained that the Baan system was to go  live at the New Zealand companies on 1  April,  with a subsequent roll-out for Exhaust Systems Australia.   He noted that Southward was

moving to a new standard cost system, and he suggested that KPMG attach to its proposal  a   statement   of  capabilities   beyond   audit,   anticipating   an   ongoing professional relationship.

[27]     KPMG  delivered  its proposal on  15  December.    The  proposal  had  been prepared on the understanding that a group opinion was required, and it recognised that Southward required a balance sheet audit as at 31 March 1999, enabling a “full scope opinion” on the financial statements for the  year  ending  31  March 2000. Exhaust Systems Australia required a separate statutory opinion and was “excluded from this proposal”.

[28]     KPMG explained that it recognised that Southward was undergoing a period of significant change with the impending commencement of an independent chief executive and implementation of the Baan information system, both of which were said  to  be critical  for  Southward’s  development.    Information  risk  management (‘IRM’) personnel would be incorporated into KPMG’s audit plan to support the “Baan security implementations and data conversion assurance”.  Under the heading “our  audit  approach”,  KPMG  explained  that  it  would  focus  on the  information management process “as this is the critical link between Southward’s processes and its  financial reporting  functions and  produces key performance  indicators which management use to control their business”.

[29]     The document specified:

We propose to provide data conversion assurance as a part of the initial audit process.   The objective of this review would be to minimise the risk associated with converting the data from the legacy system, to provide assurance that the information is converted completely, accurately and at the same time efficiently.  The review will include a brief evaluation of risks of going live or “readiness review”, an assessment of the data conversion process, and review of the data matching.

Background on our Information Risk Management function is provided in an appendix.

[30]     The proposal identified the audit personnel involved together with specialist support personnel, who included Mr Grove, who  was well known to  Southward through the implementation of the Baan system.  He would have a role in the audit

team “to fully exploit his knowledge of the system and Southward”.  Steven Cohen was a Senior Manager - Information Risk Management who would be responsible for co-ordinating any IRM services to Southward, particularly relating to the audit review of the Baan system.   He would ensure that “risks surrounding the systems implementation” were addressed and that “data integrity” was maintained.

[31]     The  appendix  referred  to  by  way  of  background  was  a  statement  of information risk management capabilities for Southward.   It was a thicket of buzzwords, abstractions, and generalisations.  It explained that KPMG employed an IT risk benchmarking tool to assess risks, identify the controls required to manage them, and assist in management, but gave no other details of that tool and did not state that it would be used as part of the Baan data conversion assurance.  It pointed in a very general way to project, business, and support risks, referring to the need to manage the change to the Baan system.   KPMG could provide advice during the detailed design phase of the Baan project, but could also assist in a post- implementation environment to assess the effectiveness of controls.   In relation to data conversion assurance, the proposal emphasised that data conversion from the legacy system had a number of risks associated with it, specifically internal control specifications for data conversion and data cleansing.   KPMG’s objective was to assist  with  minimising  these  risks  to  provide  assurance  that  information  was converted completely and accurately and at the same time efficiently.

[32]     In a covering  letter, the proposed engagement  partner,  Graeme Edwards, explained that KPMG had incorporated into the proposal a substantial involvement by Mr Grove and Mr Cohen of KPMG’s IRM division.   That  involvement  had significant  value  for  the  audit.    KPMG’s  proffered  budget  of $53,200  included

$15,000 for IRM assurance and Baan technical assistance (representing, by way of illustration, more than 50 hours of Mr Cohen’s time).   The fee was discounted to

$33,500.

KPMG’s appointment and audit presentation

[33]     After some negotiations in which the fee was further reduced, KPMG was appointed on or about 22 December 1998.  No audit engagement letter was signed at that time.

[34]     KPMG’s audit team conducted a presentation at Southward on 25 February

1999.   Mr Oliver explained  in evidence that the presentation was intended as a relationship building exercise and to familiarise Southward staff with the audit process.  In a Powerpoint presentation, KPMG again emphasised its experience with the Baan project and stated that the 1999 audit would include data conversion assurance.   The focus was on the financial audit, however, and the presentation recorded that KPMG would carry out its work relating to 1999 balance sheet audit from 31 March with most of the work being done in May.  The deliverables were a board report, a management letter, an audit report, and ad hoc advice as required. KPMG did not specify that data conversion assurance would be completed before 31

March.

The Baan 4 set-up, integration, and testing processes

Implementation management

[35]   The implementation was managed by the project team, comprising the Southward project team and the Baan/KPMG consultants.   Mr Pieters chaired this group, which usually met weekly.

[36]     There was also a core team comprising the Southward project team (that is, Southward executives only), which also met approximately once a week.

[37]     Reports were prepared regularly by Mr Oliver, with the assistance of Ms Ozorio,  for  Mr Spacapan and the Board.    They were  titled  “project  morphing” reports.   Group managers also prepared regular updates to senior management to keep the latter informed of progress.  These reports were collated by Jeffrey France.

[38]     Although the project morphing reports were given to Mr Spacapan and the Board, there is no evidence that either paid attention to them.  There are no minutes of the Board meetings on 15 February and 22 March 1999.  The Southward family had taken advice from Deloitte about the ‘corporatisation’ process that resulted in Mr Spacapan’s appointment, and was advised to step back from day to day management. Evidently taking this advice to heart, the Board paid  little attention to the Baan implementation.  It approved a business case for the project and had a review role in the  project  organisation,  but  in  practice  confined  itself  to  approving  the  Baan proposal and ensuring that Mr Oliver engaged appropriate consultants.   The entire project was effectively delegated to him.

Sim 1

[39]     Sim 1 was completed and signed off on 18 November 1998.  A blueprint or business process model had been prepared, and training given to the  key users, including Ray Lala from the finance team.   He took over the work on the finance module during the implementation, relieving Mr Oliver of this task, and was the finance team’s designated key user.   Mr Eriksen, who was providing the quality assurance function, prepared a quality review assessment  report.   It  identified a number of risks, which included limited interaction between the finance area and the other areas, restructuring of the company in which most of the employees were being asked to reapply for their jobs, an issue with use of standard costing versus actual costing in Stainless Alloys, and lack of staff familiarity with computers.  These risks were generally confirmed in an internal report prepared by Ms Ozorio on 11 January

1999.

[40]     Baan’s proposal had envisaged that Mr Eriksen would continue to provide an independent quality assurance function, but Southward chose instead to use him on the implementation, trusting to the project team to manage quality assurance in Sims

2 and 3.  Thus there were no further quality assurance reports.  Other key users were Jeffrey France (sales, marketing and distribution), and Ronnie Ryan and Mark Olsen (production).

Sim 2

[41]     Sim 2 was to be completed on 4 February 1999 but was delayed.  Mr Oliver attributes this to problems with Southward’s Oracle database and heavy involvement of Southward’s key users in the change management process.  The latter refers to the restructuring, which was announced just before Christmas 1998 and implemented from mid-February 1999.   It appears that most staff had to reapply for their jobs including, remarkably, key users such as Mr Lala who were relied upon not only to help set the system up but also to train others in its use.  Staff numbers were reduced significantly.  In the finance area, a staff of seven in Wellington and two in Auckland was reduced to four in Wellington.

[42]     Testing in Sim 2 was to have been completed by 22 January 1999 but was delayed.  Responsibility for these processes lay with Southward and KPMG.  Core team meeting and notes of 29 January 1999 record that the sales and finance areas had yet to send their test plans to Ms Ozorio.  However, much had been done.  The TIMS  supplier,  a  firm  called  Geac,  had  completed  most  of  the  programming necessary for migration of data from its system, and that was being tested.  Hardware was being installed, and some training was being undertaken.   It appears that test plans had been prepared in December, and testing carried out, for the manufacturing and purchase and warehousing modules.

[43]     Delays and demands on key users meant that testing was compromised.   A project morphing report of 10 February recorded that due to heavy involvement of the managers in the restructuring exercise, the project team had agreed to delay a presentation on Sim 2 until 18 February.  The presentation was to involve scenarios that the project team would demonstrate, along with illustrations of resolution to issues identified in an earlier Sim 1 presentation.  Minutes of another meeting of 11

February record that the project team were working towards 18 February deadlines for Sim 2, although Baan and KPMG consultants noted risks due to lack of testing, including end to end testing.

[44]     The Sim 2 phase was completed on 24 February.  There was a presentation to

Southward managers on 25 February, consisting of a live data show of the system in

operation, with hypothetical business transactions being run.  The relevant key user presented each such transaction, with support from the Baan and KPMG consultants. The Sim 2 phase was then signed off.   A project morphing report of 25 February recorded that there were no major issues to stop Southward going live on 1 April.  It noted that Southward lacked resources to complete all of the outstanding tasks in the manufacturing and sales areas, so weekend work would be required.   Staff commitment was in doubt.   System testing in the manufacturing area was almost complete and documentation was almost complete for purchasing and warehousing, but not for planning and  job/cost control.   Testing and documentation had  been completed for accounts payable.  For accounts receivable, fixed asset management, and cash management, testing  was completed  but  documentation was not.   The budgeting function was not working, and Mr Grove was following up with Baan on that.   Test plans and test scripts had not been updated in the finance area; extra resources were required to complete the testing.

Sim 3

[45]     On 9 March Mr Pieters emailed the consultants seeking feedback as to what still needed to be done, who should do it, and when it should be done by.  Mr Cohen circulated an email of the same date, intended to raise issues about outstanding tasks that might affect a successful go-live at Southward.   They included set-up of end user  menus,  user  documentation,  data  conversion  issues,  whether  all  possible scenarios had been tested for system customisations, and whether go/no go decision criteria had been agreed.   Mr Pieters responded, questioning the purpose of a discussion of go-live risk, decision criteria, and contingency plans, and suggesting that Mr Cohen outline, for example, whether he proposed to use the exercise to draw up some advice for Southward.

[46]     On 15 March, Ms Ozorio reported in a project morphing report that Baan had supplied the data migration plan, and that  loading of data  into  the  database  for acceptance testing was progressing slowly because of  insufficient  resources  and more system errors than expected.  The Baan consultants had been asked to take over the acceptance testing process.   If the acceptance testing was not completed, the

implementation might have to be delayed.   She noted risks, in the form of lack of resources and insufficient testing.

[47]     The  final project  team minutes relate to  a meeting on 17 March.    They recorded that some testing was still going on, because data migration was taking more effort than anticipated and had interfered with some of the testing.  Mr Pieters warned that risks of going live would increase as a result.  The risks included invalid data, charging wrong prices, or planning incorrect quantities or timings.   A major effort was made to address testing during the remainder of March.

[48]     The decision to go live appears to have been made late in March.   It was made by the project team.  Mr Oliver described a round-table meeting where each team member was asked for his or her opinion.  Each indicated that more time would have been useful, but that he or she was not aware of any fundamental problems that would prevent Southward going live.

[49]     It  was understood that  some  functionality would  be  added  later,  but  the evidence did not clearly identify what it was.   Mr Pieters spoke of a number of customisations remaining to be completed but did not clearly identify what they were.  He said that Southward was happy to operate without these customisations for a period.   The only function clearly identified was a financial report writing programme called Safari; it was understood that because this was to be activated later, Southward would have limited ability to prepare financial reports for a time.

The 1 April deadline

[50]     As noted above, the original RFP made it plain that the new system was to be installed by 1 April 1999 to avoid year 2000 difficulties.   I accept, however, that Southward could have delayed the implementation, because the year 2000 problem would arise only with forward orders, when entering dates for that year.   In the ordinary way,  forward orders relating to  2000 would  not be entered until about September 1999, and even then such orders could have been managed by keeping a manual record of the dates.

[51]     However, the Baan and KPMG consultants were clearly given to understand that 1 April was a deadline to which Southward was committed.   Mr France gave evidence that Southward had fallen out with the TIMS supplier, Geac, and had no provision for TIMS support after 1 April. Mr Oliver denied this, maintaining that 1

April was chosen only because 31 March was balance date.   Neither witness was challenged on these conflicting accounts in cross-examination.   But Southward did cancel its support contract with Geac in February, and the evidence overwhelmingly points to the consultants having been told that 1 April was a real deadline.  Indeed, Mr Oliver confirmed that it was a firm date.

[52]     Mr Gilbert did not suggest that the fact that the team was working to a 1

April  deadline  could  excuse  a  failure  to  discharge  any  obligation  to  advise Southward of the risks of going live.   As the expert evidence made clear, a failed enterprise resource planning system implementation can have disastrous consequences, far exceeding those presented by the year 2000 problem.   As Mr Oliver  knew,  Southward  could  have  delayed  going  live  for  some  months  if necessary.    The  significance  of  the  deadline  was  that  KPMG  could  not  have persuaded Southward to delay implementation unless advice had been given in very strong terms.

KPMG’s information risk management assurance work

[53]     As noted earlier, KPMG budgeted some $15,000 of time for its information risk management review.  Of that, KPMG assumed that $5,000 would be spent by its Baan implementation team and the remainder by Mr Cohen and his team, which in practice comprised Mr Cohen himself and Alan Shaw, an IRM auditor.

[54]     In practice, only eight hours was spent by the information risk management team before 1 April 1999.  Three and a half hours were spent by Mr Cohen and four and  a  half  by Mr  Shaw.    The  work  was confined  to  a process  review  of data conversion, business functionality following go-live, and controls.   Mr Cohen confirmed in evidence that his role, as he saw it, was that of carrying out a high level review of the project, focusing on controls.  It was not, as Southward would have it, an IRM audit.  Mr Shaw’s work plainly did not extend to checking source documents

such as test plans and test results to see that everything completed thus far had been correctly documented, nor does it appear that he and Mr Cohen maintained audit records that would allow someone else to retrace their steps.

[55]     Mr Cohen began his work on 8 March, meeting Roger Grove to discuss the status of the implementation and key documents he would need to review, which included the scoping document and data migration plan.  Mr Shaw reviewed the data migration plan, noting a number of process issues, incomplete master files, issues with transaction data including  reconciliation of the  general ledger  with  closing balances on TIMS, uncertainty whether key reports needed to manage the business would be available at go-live in accurate form, incomplete user and systems documentation, and a need for adequate training for the users.

[56]     Arrangements were made for Mr Cohen to meet key users and Mr Oliver on

19 March.  After those meetings, Mr Cohen reported at a briefing session with the project team.  He discussed the status of the project and the proposed financial and other controls, working through each of the points that Mr Shaw had noted in his review.    He identified  the  go-live  or  readiness  issues:    inadequate  training  and insufficient staff with Baan knowledge; internal controls, not all of which would be in place on going live; not all reports required to manage the business would be available from day 1; system testing, which he recommended should be completed before going live, bill of materials roll-ups (lists of the material required to make a particular product) which had not yet been verified but had to be if the standard costing was to be accurate; and contingencies in the event of system failures or other problems arising after go-live.

[57]     Mr Cohen’s evidence, which was not challenged in this respect, was that these points were accepted and he was told that they were to be addressed before Southward went live.  Like other witnesses, he was given to understand that the 1

April deadline was fixed.

[58]     Mr Cohen prepared two file notes of his meetings at Southward, one of which addressed internal controls and the other the issues discussed with the project team and Mr Oliver.   These were passed to Graeme Edwards, who placed them on his

audit file but did not copy them to Southward as suggested by Mr Cohen.  At no time before go-live did KPMG report Mr Cohen’s conclusions to Southward’s Board. However, I accept that the content of Mr Cohen’s filenotes had been discussed with the project team, including Mr Oliver, and Southward key users.

[59]     It was common ground between the expert witnesses, Mr Gross for KPMG and Mr Hart for Southward, that Mr Cohen correctly identified the issues that Southward confronted on going live.  The Baan witnesses agreed.  The project team was well placed to assess these risks and decide how to deal with them.  Indeed, it had already identified them.  Where the experts differed was on whether Southward ought to have gone live in the circumstances.  Mr Hart also contended that Mr Cohen ought to have gone further, saying “a competent auditor” ought to have followed up before going live to ensure the new system presented a true and fair view of the Group’s business.

The state of the Baan system on going live

[60]     The system went live on 1 April at Stainless Alloys and 6 April at Southward Engineering Company.  A filenote of 7 April recorded that the TIMS system would be kept on-line for another two months so that it could be accessed, and any adjustments that were to be made to 31 March figures would be accounted for in both systems.  It follows that the opening balance sheet audit could be based on the TIMS  system,  and the evidence confirms that  it  was.   But  it  was necessary to reconcile the two systems so that the Baan balance could be used as the opening balance for the full year accounts to follow.

[61]     The same filenote records that inventory differences between the TIMS and

Baan systems on going-live were $579,000 on a total inventory of approximately

$14M.   There was a dispute between Mr Gross and Mr Hart about whether this difference was material.  Mr Hart maintained that it was, although he accepted that some errors in data conversion are inevitable.  I accept Mr Gross’s evidence that the differences are not material; they are indicative, rather, of a successful implementation.  In any event, the difference in inventory valuations was identified immediately following go-live and was readily capable of being reconciled.  Further,

it appears that the amount of inventory was correctly transferred, and the differences are to a considerable extent, if not entirely, the result of the decision to move to standard costing.  Marita Robinson, who worked on the system in 2000, also said in evidence  that  the  raw  data was  in  the  correct  fields  in  the  Baan  database;  the problems concerned incorrect mapping of transactions.   In the result, Mr Kos in closing did not pursue the complaint that there were material data conversion errors. He focused, rather, on integration errors, arguing that these resulted from incomplete testing.

[62]     It is clear that the system suffered from integration or mapping errors on going live.  The two experts agreed that there must have been errors of that sort, and several were identified in the evidence.   I discuss each such error below.   I am prepared to infer that these point to incomplete testing since, as Mr Pieters conceded, testing ought to eliminate them.  However, it is a remarkable feature of the evidence that the witnesses were not able to identify any specific testing or integration errors that were material in the sense that they caused a subsequent need to reimplement the system.

[63]     The experts also agreed that problems present on going live could have been fixed, if monitored and addressed within two to three months.  The remedy involves identifying each incorrect integration, remapping it, and posting journal entries to correct the relevant transactions.  They accepted, however, that this process becomes more difficult  as time passes and the number  of  incorrectly posted transactions increases, and at some point it is better to reimport clean data, reimplementing the system.  They differed, as noted below, on how reimplementation would be done.

Acceptance of Sim 3

[64]     It was common ground that Sim 3 was signed off and the final payment made in August 1999.  In the meantime, Baan and Southward did much work on issues that emerged after the system went live.

[65]     As  planned,   the  system  was   initially  operational  only  at   Southward

Engineering  Company  and  Stainless  Alloys  Wellington  branches,  and  the  sales

module only was partly operational at the Auckland branches.  Mr Oliver explained that the rollout was structured in this way because systems at the other branches were not computerised.  It was rolled out at the other New Zealand branches in the first week of June, and at Exhaust Systems Australia on 28 August 1999.

[66]     Baan 4 logged errors in transactions that it could not complete because of incorrect mapping, but it could not be relied upon to identify all errors.  Users, who had been instructed to log errors as they arose, would identify others.  On 15 April Mr Pieters circulated a list of issues under a covering e-mail in which he said he was reasonably happy with how things had gone.  Most of the 50-odd items were to be attended to by Southward.  Further lists were prepared on 29 April, 13 May, 24 June,

7 July, 15 July and 5 August 1999, and there is a final list that must post-date 5

August.  It shows that at that time there were six system tasks outstanding, none of which appeared to be relied upon by Southward in this proceeding.

[67]     Baan provided a help-desk procedure that assisted in resolving these issues. On 18 June, it also offered to make available a Baan implementation specialist on site for four to five days per month to deal with miscellaneous queries from users and assist  while Southward optimised Baan and the Southward sites all became stable.  Southward decided not to take up this offer.

[68]     Mr Lala’s evidence was that the issues that remained to be resolved as at May

1999 were of a relatively minor nature, and he believed that they were all resolved. He left the company in September 1999, but not because of the Baan system; he thought it was a good system and he had no real difficulty overcoming problems as they came to light.   Rather, the company was under-resourced, especially on the accounting side, and inadequate attention was given to ongoing training of users. His own workload was unreasonably high.  Mr Pieters’ evidence was, in short, that the implementation was a success.  Issues identified by KPMG and the project team were addressed and signed off before going live.   There was insufficient time to finalise the financial reports that were to be available, and this work was deferred until after going live.   It was not considered significant because the data could be extracted from the system and the necessary reports prepared.  Mr France, the other key user,  found that on the sales and distribution side the implementation went

reasonably well.  The system worked satisfactorily, and problems that emerged were logged for resolution.

[69]     Mr Oliver’s evidence, by contrast, was that his experience at Southward after going live was perhaps the most difficult, stressful, and unhappy of his life.  He was working enormous hours dealing with Baan problems, which meant he was unable to function as financial controller, and he felt he was being held responsible by Southward for failures in the system.   The Baan consultants moved swiftly on to other work, and he spent the first three to four months working almost solely on customer-related issues with the accounts receivable clerk.  Invoices were formatted badly and customers were being billed incorrectly, some customer accounts having been merged when they were transferred.  Sales staff were unable to access accurate sales reports, and in some cases sales were being recorded in the finance module but not the sales module.  He put off doing any work on the Southward group accounts, and found when he came to do so after two or three months that a lot of the data did not make sense.  In particular, the value of work in progress was wrong, and seemed impossible to fix.   Because a reporting function had not been set up in the Baan system on implementation, Mr Oliver did not try to print off any financial reports for some time.  The evidence did not establish when he first attempted to do so, but it appears that  by June Southward was aware that  accurate financial data was not available.   Trial balances were grossly inaccurate, principally because work in progress figures were wrong.  Work in progress represents cost of all materials plus a share of labour and manufacturing costs, and is a crucial component in the profit calculation.   The list of outstanding Baan issues became longer over time.   In the end, Mr Oliver resigned in October 1999, but reluctantly stayed on until the end of the year.

[70]     Responding to Mr Lala and others in his reply brief, Mr Oliver said the key problem was that the system was  not  calculating cost of sales accurately.    The operational side of the system was functioning, meaning for example that daily sales and accounts payable and receivable could be processed, but the financial interface was not.  Without cost of sales data, Southward did not know if it was profitable.  He explained that it took some time to identify the problems with the financial interface because it was not until around June or July that he was able to focus on preparing

monthly financial reports using Baan.  Nonetheless, it seems plain that by August he was well aware of the financial interface difficulties that he identifies.

[71]     It is difficult to reconcile the evidence of Mr Oliver and Mr Lala.  Both were credible witnesses.  I accept that Southward struggled with the system, particularly once Mr Lala left.   In the end, however, I preferred the evidence of Mr Lala, for several reasons.  First, the expert evidence compels the conclusions that there were no difficulties that were of an unexpected kind or could not be fixed readily, and that most of the difficulties were there to be identified immediately on implementation. Second, he was a key user, closer to the Baan system than Mr Oliver.   Third, his evidence was consistent with the evidence of Mr Gross, Mr Pieters, and Mr Eriksen, which I generally accepted, as well as that of Mr France, who was not called for cross-examination.

The 31 March 1999 balance sheet audit

[72]     KPMG began the balance sheet audit soon after balance date, expecting to complete it in May 1999.  It was eventually completed in June 2000.  Mr Edwards’ explanation for the delay was that Southward was unable to provide information that KPMG needed.

[73]     On 6 May 1999 KPMG sent an audit engagement letter to Mr Southward, addressed to the chairman, Southward Engineering Company Limited.   It was a standard form letter in which KPMG consented to act as auditor commencing with the year 31 March 1999, and defined KPMG’s role as examining and reporting to the shareholders on the company’s statutory financial statements.  The letter contained an entire agreement clause.

[74]     Southward did not sign the letter at that time.   When finalising the balance sheet audit for the year ended 31 March 1999, KPMG wrote to Mr Southward noting that it had not received a signed copy of the engagement letter and attaching another engagement letter, this time referring to a special purpose audit appointment.   The covering letter did not disclose that the attached letter differed in its terms, from the

6 May 1999 version, and Mr Kos made something of this in cross-examination, but I

do not think that anything turns on it.  The letter had been modified because the 31

March 1999 exercise was a special purpose balance sheet audit rather than an audit of statutory financial statements for that year.   It appears that Mr Southward responded to this letter by signing and returning the original 6 May engagement letter.

[75]     KPMG initially pleaded that the 6 May letter established the terms of the audit engagement, including any obligations in relation to data conversion, presumably by way of variation to the agreement established when KPMG’s audit proposal was accepted in December 1998, but Mr Gilbert did not pursue that contention in closing.  Presumably he changed tack because the 6 May 1999 letter was a standard form engagement letter directed to a full audit, and clearly did not fully  record  the  agreement  between  KMPG  and  Southward  with  respect  to  the special audit.  Whatever the reason, I need say nothing more about the engagement letter.

Implementation at Exhaust Systems Australia

[76]    Lawrence Southward managed Exhaust Systems Australia, which used a different legacy system called SYBIZ.  The decision to implement Baan at Exhaust Systems Australia was intended to commit a centralised accounting division in New Zealand and facilitate group financial reporting.  Mr Southward spent two weeks at Southward Engineering in New Zealand in July with the Baan project team.   Data was transferred from SYBIZ into Baan, and the system went live on 28 August.  He knew that Southward was experiencing teething problems with the Baan implementation, and agreed with Roy Southward that going live at Exhaust Systems Australia should be postponed until those had been resolved.   He knew that some problems were still being experienced on 28 August, but was assured by Southward Engineering that the problems would not affect Exhaust Systems Australia.

[77]     About a month after going live, problems began to emerge.   They included absence of postcode details, which are necessary in Australia, inaccurate migration of  transactions  completed  before  going  live  with  resulting  incorrect  customer

balances, failure to take account of a prompt payment discount peculiar to Exhaust

Systems Australia, and problems with ageing debtor analysis.

The long and winding road to reimplementation

[78]     Libby Southward had worked in the finance area at Southward but was living in England at the time of implementation.  When she learned in June 1999 that the system was not producing full financial reports, she purchased a book on implementing Baan 4 and began to educate herself about the system.  She returned to New Zealand in November 1999 to assist, because she had been told that Southward was still not getting financial reports from Baan.   In 2000 she was appointed information technology manager, employed to “learn the functionality of Baan 4 and assist  the Southward Group with functionality and reporting  issues”.   She  made changes to ageing debtor and credit analysis, the fault stock prices, cost price calculations, foreign currency transactions, small payment differences, freight recoveries and customer identity errors.

[79]     Southward took advice from a firm called Capitalise Limited, which in turn engaged Marita Robinson, an employee of Tait Electronics Limited and an expert Baan user and administrator.  She assisted Southward on a part-time basis between July and December 2000, spending over 200 hours reviewing and fixing the system.

[80]     In a report of 9 July 2000, Mr Ewing of Capitalise noted an absence of clear instructions and training, which leads to data problems and  much administrative work to tidy up.  He was clearly pointing to the risk that errors had been introduced by users.  Ms Robinson also suspected at the time that some errors might be due to changes made in 2000.  Users were not well trained.  It was common ground before me that users might introduce integration errors when they added new customer groups or new products, for example,  although there  is no  evidence of specific changes of that sort to the system.   It is also plain that the system had not been properly administered since implementation.  Ms Robinson counted some 200 pages of  error  logs,  an  extraordinary  number  establishing  in  itself  that  for  some considerable time no one had taken responsibility for correcting errors as they arose.

[81]     Ms   Robinson   identified   many   failed   financial   transactions,   corrupted accounts  payable  and  receivable  transactions,  and  inability  to  close  the  1999 financial year due to data corruption and out of balance accounts.  She fixed most of the error logs and associated mapping errors.  But she concluded that the set-up of the finance module was “a complete mess”, with incorrect general ledger accounts and integrations and customer groups, an absence of the latest patches or fixes that should have been installed before going live, and a bad set-up in that the implementation did not appear to suit Southward’s business requirements.

[82]     Ms Robinson recommended that Southward start again with the new Baan 5 system.  It appears that an important reason for suggesting that Southward move to Baan 5 was a perception, later found to be incorrect, that Baan did not intend to continue supporting Baan 4.  To some extent, it appears that the decision was also driven by a perception that Southward users lacked confidence in Baan 4.

[83]     In mid 2000 Southward approached IBM in the United Kingdom, believing that IBM had Baan consultants that might be able to fix Southward’s problems.  Roy and Libby Southward travelled to England in January 2001 and spent three days with IBM’s Baan consultants while they logged into the Southward system and reviewed it.  In October 2001, IBM Australia consultants came to Southward and reviewed the system.   They recommended that Southward should reimplement Baan 4 or implement Baan 5, which had additional functionality and was thought to be better supported.

[84]     The project manager of the IBM implementation was Rohan Cattanach.  His evidence was that after only two weeks IBM identified a number of problems, such that it became clear that the better course was to start again with the new system. There were problems with the finance module that could not be properly fixed, in that finance customer groups and supplier groups, and integrations in the finance module had not been set up correctly.   Other problems could have been fixed but with substantial effort; they included ineffective item numbering, inadequate general ledger structure, incorrect set-up of the standard costing, debits and credits being set up the wrong way around, and errors in the migration of data.

[85]     IBM advised Southward that  fixing Baan 4 was not a sound or practical course of action; it would have been time consuming and potentially more expensive than starting with a new system, and there was a real risk that all the data could not be reprocessed  correctly.    It  would  also  be  difficult  to  do  so  while  Southward continued to operate the system.

[86]     Unfortunately,  Mr  Cattanach’s role was that  of project  manager,  and  his evidence  was  directed  to the  costs  of  reimplementation  and  IBM’s  reasons  for recommending it.  When it came to describing the problems, it became clear that he was reporting the views of others in his evidence.  Further, the finance area was not within his expertise.   Mr Gilbert objected to the admissibility of his evidence of problems in the finance module, maintaining that in its absence Southward had failed to prove there were problems as at 2001.   This objection had implications for the expert evidence, because Mr Gross and Mr Hart both proceeded on the assumption that   Mr   Cattanach’s   evidence   correctly   identified   the   problems   evident   in Southward’s system as at October 2001.

[87]     The objection was well-founded.   Mr Cattanach’s evidence is inadmissible insofar as it describes problems in the finance module and what was required to fix them.  But it added very little, in its description of the errors in Southward’s system, to the evidence of other witnesses such as Ms Robinson and Ms Southward, to which I now turn.

Baan problems and their implications

[88]     I  now  examine  the  specific  integration  or  mapping  problems  that  were identified by Southward after going live, to establish whether they may have been present on going live, to confirm whether they were capable of being fixed and when they were fixed, and to assess their implications for KPMG’s data conversion assurance work.  This list is based on the evidence of Ms Southward, Ms Robinson, and Mr  Hart.   I  do  not  deal with specific data migration complaints,  since the evidence established that discrepancies were not material.

Integrations

[89]     Mr Hart identified several integration errors.   A finished goods in transit account was being used incorrectly to record the cost of sales of automotive components, which are not finished goods. The correct account was raw materials in transit.  The second was that the set up of a purchase commitments account as the account to which purchase price variances were posted to was incorrect.   Third, some financial transactions were not mapped; specifically, a non-standard stock item purchased for a specific customer should have been mapped to a particular general ledger code but was instead directed to an indent stock account.  Lastly, the finished goods account was debited and credited for all replenishment orders whether they were raw materials, components, or finished goods.   Raw materials replenishment orders should have been debited and credited to their own account.

[90]     Mr Pieters and Mr Gross accepted that most of these were integration errors, but  emphasised  that  problems  of this  nature  are typical of all  implementations, normally show up very quickly, and are very easy to correct; further, Baan would have corrected them had they been brought to its attention.   Some were not implementation errors; the treatment of replenishment orders would have followed the chart of accounts established by Southward personnel, who were responsible for defining the desired business and accounting processes.   Mr Gross observed that some of the errors were identified by Southward users shortly after going live, as one would expect, but it appears that they were not taken up with Baan.

[91]     In the end, the experts agreed that errors of this sort are readily fixed, and are to be expected in any implementation.   They ought to have been identified very shortly after going live.  Had they been drawn to Baan’s attention, they would have been fixed in a straightforward manner without any need for reimplementation.  The procedure is that the integration error is first fixed, and any transactions that have already been processed are then corrected by journal entry.

Accounts payable and receivable

[92]     Ms Southward gave evidence that after starting work at Southward she was able to improve processing methods so the full functionality of Baan 4 was being used for daily processing of accounts payable and receivable.  This does not appear to be an implementation error.   Ms Robinson said  that  she spent  a lot  of time working on these accounts, which could not be reconciled with the general ledger, but the evidence did not establish why that was so.

Ageing analysis code for debtors and creditors

[93]     Ms Southward explained that  she had to set up a new analysis code  for debtors and creditors, because the ageing analysis appearing on customer statements was being calculated by actual days rather than on a calendar monthly basis as TIMS had done.  In Baan this function can be set to suit customer preferences.  This is not an implementation error, and did not appear to be material.

Sales pricing

[94]     Southward required a default stock price for carbon steel tube, stainless steel tube, and automotive items.  This was the highest price charged to customers.  Ms Southward manually entered this price in 2000, replacing a default price of $0.00. She also explained that the set up of the pricing and discount structure in Baan 4 was not fully considered and applied to Southward’s requirements; for example, price breaks by quantity were not set up at the time of implementation.  This appears to be a master data error made on setting up, but it is one that ought to have shown up and been remedied without difficulty immediately on implementation, because for those customers for whom the default price was used the price shown on invoices would have been nil.  There is no evidence that this was a material problem.

Cost price calculations

[95]     Ms Southward explained that Stainless Alloys had to work off a spreadsheet as  its price book, which  listed  inventory on  hand,  cost  price  and  selling  price. Stainless Alloys had asked for a report to be created in Baan 4, but it was not.  Had it been created, she said, the cost prices would have been wrong because they were calculated from the average purchase price.  However, this is not an implementation error.   Mr Pieters explained that Southward had used average costs in the TIMS system but  moved to  standard costs when changing to  Baan.    Stainless  Alloys’ decision to  persist  with average purchase price as the basis  for  cost  prices had nothing to do with any defect in the implementation.  In any event, Stainless Alloys did not  rely on  Baan  for  its  price  book,  so  this  cannot  have  led  to  a  need  to reimplement the system.

Foreign currency transactions

[96]     Southward  had  New  Zealand,  United  States,  and  Australian  dollar  bank accounts, and had processed foreign currency transactions through foreign currency general ledger accounts in Baan 4.  On implementation, such transactions were being processed  through  the  New  Zealand  dollar  general  ledger  account  and  then transferred  into the  foreign  currency general  ledger  account  by  journal  entry,  a clumsy process that could lead to discrepancies when reconciling bank accounts.  It does not appear that this was an implementation defect; Mr Eriksen said that Southward chose to deal with foreign exchange transactions in this way.   In any event it was readily capable of remedy and does not appear to have caused anything more than a degree of inconvenience.

Payment differences

[97]     Payment differences refer to small discrepancies arising from cash sales or small errors made by customers when writing cheques.  These are common and must be written off.   At set up, Ms Southward explained, Southward’s system did not possess this functionality.  It is not clear that this is an implementation defect, and

there is nothing to show that it was material.  Ms Southward was able to deal with it by setting up a new general ledger account.

Freight recoveries

[98]     Ms  Southward  explained  that  freight  recoveries  represent  funds  received from customers who were charged freight for the delivery of product.   There is a freight recoveries general ledger account in Baan 4, but freight recoveries were being recorded incorrectly in the “other income” general ledger account.  This appears to be an integration error that was present on going live, but there is nothing to show that it was material in that it caused significant difficulties for Southward or contributed to a need to reimplement the system.

Customer accounts

[99]     It appears that there were a number of errors with customer accounts being merged.  Ms Southward gave an instance of a customer called Amega Wire whose account was merged with that of Amega Coatings, a different company.  It appears from Mr Oliver’s evidence that there were a significant number of such instances, which caused customer complaints.  In my view this is correctly characterised as a data migration error.  It is attributable to human error, probably by Southward staff, when cleansing TIMS data by checking it before setting it up for migration.

Financial statements

[100]   Ms Southward explained that she had to set up new financial statements by each department in the Southward Group, because the standard financial reports in Baan 4 were not in the same format as TIMS and could report on either branch or location, but not both.   There is nothing to show that this was an implementation error, in that Southward had identified a need to report in this way at the Sim 1 or Sim 2 phase and Baan had failed to set the system up accordingly.   It is entirely possible, in other words, that Baan was not told of the requirement.  More generally, Ms Robinson said that the setup of the financial module was a mess, but the details

and causes of what she saw were not clear.  Financial reporting was one of the areas where functionality had been deferred in the interests of going live on time.

Average/standard costing

[101]   This refers to the fact that Baan used standard costing while TIMS had used average costing.  Ms Robinson described this as a major issue in her first brief.  But it was a Baan feature that Southward understood when planning the implementation, and it cannot be described as an error.

Debits and credits set up the wrong way around

[102]   The evidence established that variances in standard costs were credited to the purchase variance account when they should have been debited to  it.   This was attributable to a Baan system error; that is, a problem with the Baan software rather than the integrations.  It ought to have become apparent immediately.  There was a service pack supplied by Baan which could remedy this problem, had it been identified.  The evidence does not establish that the error was material.

Anticipated payments

[103]   Unpresented cheques were recorded in a cash clearing general ledger account in Baan, although it had an account available specifically for unpresented cheques. Ms Southward was able to set this account up.  This may be an implementation error, but its impact is not specified; one would not expect unpresented cheques to present a material problem.

Company structure set up

[104]   Southward  initially complained  that  the  finance  module  had  been  set  up incorrectly for consolidation purposes, in that Southward Engineering Company was not treated as the parent.   During the hearing, however, I was given to understand

that  the  parties  agreed  that  as  set  up  the  system  was  capable  of  presenting consolidated accounts correctly.

Conclusions

[105]   The evidence establishes that there were several integration errors present on implementation, but all ought to have become apparent more or less immediately on implementation, all were readily capable of being fixed, and none can be said to have caused a need to reimplement.  It is unclear why they were not in fact fixed during routine post-implementation work.  Ms Southward and Ms Robinson fixed those that they identified.

[106]  I accept that as at 2001 there were significant integration errors in the Southward system and a great many failed transactions.  I am not prepared to infer, however, that all errors found in 2000 and 2001 must have been there on going live. On the contrary, the evidence established few integration errors on going live.   To the extent that others were present by 2001, it is entirely possible that in the two and a half years since going live the system had been corrupted by ill-trained users and lack of attention to system administration.

The pleadings

[107]   The claim is brought by the three Southward companies.  All sue in contract, alternatively in  tort.    KPMG  admits  a  contractual  relationship,  but  says  it  was confined to Southward Engineering Company and its terms were contained in the audit engagement letter dated 6 May 1999, which contained no reference to data conversion assurance or go-live readiness, and included an entire agreement clause. Counsel approached the pleading on the basis that the tort action was co-extensive with the contract claim, and assumed significance only if the Court were to accept that the contract was confined to Southward Engineering Company.

[108]   The plaintiffs plead, and KPMG accepts, that KPMG was required to perform its professional services with reasonable skill and care, but KPMG denies further

allegations that it was obliged to provide data conversion assurance, review data matching, evaluate the risks of going live, and report any matters of significance to Southward’s management and directors.

[109]   The plaintiffs plead that  KPMG failed to provide proper data conversion assurance,  and  that  it  failed  to  review  closing  balances  in  TIMS  and  opening balances in the Baan test environment before going live, failed to request or review test results, failed to review the run time taken to convert the test data, and failed to follow up issues arising from a data migration plan prepared by Baan.  They say that KPMG also failed to review data matching; that is, closing balances in TIMS and opening balances in the Baan system after go-live.  They say that KPMG failed to carry out a proper evaluation of the risks of going live and that it failed to prepare a risk analysis or risk action plan, failed to assess risk methodically, failed to use the IT risk bench-marking tool referred to in its audit proposal, failed to review testing documentation, project status reports, minutes of project team meetings and quality assurance reports, and failed to discuss the state of readiness for go-live with project team members.  KPMG is said to have made just one visit to Southward’s premises before go-live.  The nub of the pleading is para 27(e), in which the plaintiffs allege that KPMG failed to properly bring to the attention of Southward, including  its Board, “the risks of going live” on 1 April 1999 at Southward Engineering Company and Stainless Alloys and 1 September 1999 at Exhaust Systems Australia.  The risks concerned are not specified, and Mr Kos presented his case on the basis that what was required of KPMG was a process audit; in particular, it ought to have noted the incomplete testing and called a halt, warning Southward that it risked serious problems of a sort that might force re-implementation.   He accepted that such a warning would have to be given in strong terms, or Southward would not have delayed going live.

[110]   The plaintiffs plead that as a result of these failings, system parameters were not set up correctly and data conversion was not successful.   The parameters or mappings pleaded are:   financial transactions were mapped to the wrong general ledger code, some financial transactions were not mapped, and debits and credits were set up the wrong way around.  The plaintiffs say that as a result of these failings it was necessary to install the new Baan 5 system, but that would have been avoided

had KPMG performed its obligations because the go-live date would have been postponed to allow Baan 4 implementation defects to be corrected and the system would then have served Southward’s requirements.  (It was common ground that the Baan 4 system was capable of doing so.)

[111]   Mr Kos significantly reshaped his case in closing, acknowledging that the evidence did not establish material data conversion errors.  Nor was he able to point to any integrations or mappings that were present on going live and caused the need for reimplementation in 2001.   In the ordinary way, integration errors should be reported quickly when the system is in operation, and there were no  integration errors identified that could not have been fixed without delay.  Rather, Mr Kos’s case was that there must have been substantial integration errors not all of which can be identified, because the financial reports produced from April 1999  until at  least November 1999 were wildly inaccurate.   He relied on Mr Gross’s acceptance that after two to three months of such errors, the volume of incorrect transactions would have been such that some form of reimplementation was necessary.

[112]   As noted, KPMG pleads that its role was confined to that of auditing the opening balance and the financial statements as at  31 March 2000, and says its obligations were confined to Southward Engineering Company.   It specifically excluded Exhaust Systems Australia. It was not engaged to audit the Baan implementation.  Any data conversion assurance obligations were ancillary to audit and, apart from the brief readiness review, to be performed after 1 April.  It says that any losses suffered were caused by the failure of those responsible (Baan Australia Pty Limited, Deloitte, and the plaintiffs) to  manage adequately the Baan system implementation  and  data  conversion,  Southward’s  failure  to  optimise  the  Baan system as recommended by Baan, Southward’s failure to maintain and operate the Baan system properly, Southward’s decision to  make staff redundant  during  the implementation, and Southward’s failure to provide adequate training and support in the use of the Baan system.  For the same reasons, KPMG says, the plaintiffs were contributorily negligent.

[113]   The  plaintiffs  called  Roy  Southward,  Des  Oliver,  Libbi  Southward,  and

Lawrence Southward.  They also called Paul MacKenzie, who works for Geac, the

supplier of the former TIMS software, Marita Robinson, Rohan Cattanach, Kerry Hart, an IT consultant and project management expert with long experience of designing enterprise resource planning systems but no Baan experience, Denis Foy, an auditor, and Leon Briggs, a forensic accountant who attempted to quantify the plaintiffs’ losses.

[114]   KPMG called Ross Buckley (the lead audit partner), Graeme Edwards (the audit engagement partner), Alexander Skinner (the audit manager), Gideon Pieters, Leslie Eriksen, Ray Lala, Roger Grove, Michael Murphy (the sales agent in New Zealand for Baan Australia), Jeffrey France, Stephen Cohen, and Peter Gross, who heads the Canadian management consultant firm Pemeco and is very experienced in managing Baan implementations.

[115]   Messrs Hart, Gross, Foy, and Briggs all gave evidence after the fact witnesses for both sides.   Messrs Hart and Gross gave evidence as a panel.   They helpfully reached agreement on a number of issues that counsel defined for them, and agreed to some extent on the costs of remedying the system as IBM found it in 2001. Where there was conflict between Mr Hart and Mr Gross, I generally preferred the latter’s evidence; he is a leading Baan expert while Mr Hart is not, and that was evident in some minor errors in Mr Hart’s evidence as well as his initial belief that integrations were very difficult to fix.  In his brief of evidence, he also based his conclusions to a significant  degree  on  data  migration  errors,  which  proved  not  to  be  material. Because Mr Kos relied on Mr Foy’s evidence in important respects, it is also necessary to say that while he is a very experienced auditor he had not given expert evidence previously and, perhaps as a result, plainly saw himself as an advocate for Southward.  That approach significantly affected the reliability of his opinions.

Who might enforce KPMG’s data conversion assurance obligations?

[116]   Mr Kos contended that contractual obligations were owed to each of the three plaintiffs because they were party to the group audit contract; in the alternative, if Southward Engineering Company was the only party, the contract  could still be enforced for the benefit of each plaintiff under the Contracts (Privity) Act 1982.

[117]   Mr   Gilbert   contended   that   the   contract   was   confined   to   Southward Engineering Company Limited.  A group audit must include the subsidiaries, but the subsidiaries are not separately audited.   He accepted, however, that a co-extensive tortious duty would extend to Stainless Alloys.  But Exhaust Systems Australia was expressly excluded  from the  proposal.    He  maintained  that  any data conversion assurance obligations and readiness review were ancillary to the balance sheet audit, which was that of Southward Engineering Company and its subsidiaries.   A group audit must include the subsidiaries, but it does not follow that the auditor owes a duty to the subsidiaries.

[118]   It is evident that KPMG did not pay close attention to the identity of the contracting party in its audit proposal.  Mr Gilbert’s case was that KPMG addressed its proposal to Southward Engineering Company only, but KPMG loosely defined Southward Engineering Company Limited as “Southward” or “the Group”.  And the substance of the obligation undertaken was data conversion assurance associated with  the  initial  balance  sheet  audit, that  is,  as  at  31  March  1999.    Southward Engineering Company and Stainless Alloys were both to go live on 1 April 1999.  I am satisfied that the data conversion assurance work was intended to extend to both of them.  It follows that Stainless Alloys may rely on KPMG’s promise, in tort if not in contract.

[119]   But I accept Mr Gilbert’s submission that Exhaust Systems Australia was excluded, for two reasons.   The first is that the scope document made clear that Exhaust Systems Australia was not to go live on 1 April 1999, the date at which the data conversion assurance work was to be done.   Under the scoping  document, implementation at Exhaust Systems Australia was to be undertaken by Southward staff after 1 April; as the evidence of Lawrence Southward made clear, that work involved  its  own  data  conversion  process.    The  second  is  that  the  work  was associated with statutory audits, and Exhaust Systems Australia was expressly excluded from the proposal because it  required a separate such audit.   Mr  Kos resisted this conclusion, arguing that only the statutory audit at Exhaust Systems Australia was excluded.  That may have been the reason for excluding the company but the language was explicit; Exhaust Systems Australia was excluded from the

proposal.   It follows that KPMG did not owe duties to or in respect of Exhaust

Systems Australia, either in contract or in tort.

What obligations did KPMG assume?

[120]   As framed in its audit proposal, KPMG offered “data conversion assurance” as part of the 31 March 1999 initial audit.  This would take the form of a review, the objective of which was to minimise the risk associated with data conversion, to provide assurance that the information was converted completely, accurately, and efficiently.  The review would include a brief evaluation of risks of going live, an assessment  of the  data  conversion  process,  and  a  review  of the  data  matching. Counsel did not focus closely on the last of these, which indicates that KPMG was to check  that  data  had  been  converted  accurately.    I  do  not  accept  that  KPMG undertook to use its IT benchmarking tool; that was included as part of the capability statement but KPMG did not specify that it would be used in the data assurance review, nor did the evidence establish that a prudent auditor would use such a tool when checking a new system.  Indeed, the evidence established that its designed use is for systems in operation; that is, it was not directed to setting up a new system.

[121]   Mr Gilbert accepted that the brief readiness review was to be undertaken before 1 April 1999, but contended that the assessment of data conversion process and the review of data matching were to be carried out as part of the initial audit process,  after  balance  date.    He  relied  on  Mr  Edwards’  evidence  that  KPMG intended to do most of the data conversion assurance work post-implementation, as part of the financial audit.  I do not accept that evidence, because the data conversion assurance work budgeted was that of the IRM team and there is no evidence that the team expected to, or did, continue work after Southward went live.  It follows that the data matching work was to be done before going  live, after the Sim 2 data conversion testing, and not after going live as Southward pleaded.

[122]   Accordingly, I accept  Mr Kos’s submission that the natural and ordinary meaning of KPMG’s proposal was that KPMG would carry out its data conversion assurance before Southward went live on 1 April.  The objective of the review was to minimise the risk associated with data conversion, and that  would ordinarily be

achieved  by doing  the  work  before  the  data  was  converted.    A  review  of  the conversion process after the fact would be of little utility to Southward.   I do not rely, in reaching this conclusion, on Mr Foy’s evidence that KPMG’s financial audit work depended on doing the data conversion work before 31 March; that opinion seems to me to be wrong.  The audit work was not scheduled to begin in earnest until after balance date, and it was based on TIMS.  Reconciliation with the Baan system was a requirement of the full year accounts, not the initial audit.

[123]   Mr Kos accepted that what was required was a process review, in that KPMG was to audit the procedures that the Baan implementation team were adopting; that is, KPMG was not required to identify any specific data conversion or mapping problems that might exist, but rather to point to any process failings that created a risk of such errors arising on going live.

[124]   However, Mr Kos maintained that what was required was an IRM audit.  He relied on the evidence of Mr Foy, who asserted incorrectly that Southward made a clear and specific request for an audit to address the Baan implementation.   That would require, in Mr Foy’s view, detailed checking of test scripts and test results to ensure that everything the project team claimed to have done had been done, and maintenance of an audit trail in which Mr Cohen and his team recorded what they had done.  It also imported, in his view, Auditing Standard 710, which provides that the auditor  must  communicate significant  matters identified as a  result  of audit procedures to the appropriate person or body within the entity.  Certain matters may be of such significance that they should only be reported to the audit committee or the governing body of the entity.

[125]   I am satisfied that KPMG did not offer an IRM audit in the sense used by Mr Foy.   Rather, it offered data conversion assurance which was independent of the finance audit, except in the sense that the auditors would later rely on data produced by the Baan system.  That assurance involved a review of process, and carried with it an implied obligation to report  KPMG’s conclusions to  Southward.   Because  it extended to testing, the review would tend to lead to identification of integration errors, but  it  is important to recognise that  KPMG’s work  was directed to  data conversion, not mapping of transactions after going live.  KPMG did not undertake

to audit test summaries or results or project minutes, and the evidence did not satisfy me that the work of its nature required that a prudent auditor in KPMG’s position would do so.

[126]   Mr Kos maintained  that  KPMG  was obliged  to  report  its conclusions to Southward’s board.   I reject this submission, which is based in large part on Mr Foy’s opinion to that effect.  His opinion was founded on his beliefs that KPMG was to undertake an IRM audit, and that the implementation problems as at 31 March were more extensive, and less susceptible to remedy, than was the case in fact. Responsibility for managing the Baan implementation had been delegated to  Mr Oliver and the project team and Mr Oliver was the appropriate person to whom KPMG should report deficiencies in the process adopted.  It may be that there were circumstances in which KPMG ought to report to the board, as for example where it had concerns about the performance of Mr Oliver himself, or if there had been a disagreement between Mr Cohen and the project team about what needed doing.  But this is not such a case.  The issues identified by KPMG were within the competence of the project team to assess and address, and they made it clear in response to KPMG’s advice not only that they recognised the issues but also that they would be addressed.

[127]   Mr Kos further contended that KPMG should not have accepted the project team’s advice that the issues identified would be addressed, but should have undertaken a further readiness review before going live to ensure that all of the work had been done.  It is true that the data conversion assurance work was directed to a successful implementation, but it does not follow that it required a further review just before going live.  KPMG undertook its review after Sim 2 had been signed off, and about half way through the Sim 3 process.  It was the Sim 2 process that involved setting up and testing data conversion, and setting up integrations or mappings between modules.  I prefer the view that data matching was part of that process.

Did KPMG perform its obligations?

[128]   A great deal of the evidence and argument was devoted to showing that there were problems with the Baan implementation.   Mr Kos contended that Southward

should never have gone live on 1 and 6 April, because testing was inadequate.  He relied on Mr Hart’s evidence, which in summary was that there was no proper plan for testing, test cases were not properly prepared and testing was delayed, testing lacked focus and structure, and there was no evidence of end to end testing using migrated data.   I accept that testing as at 31 March 1999 was inadequately documented.  It is not clear to what extent the testing was actually incomplete, but it is a reasonable inference, which I am prepared to  draw, that it  must  have been incomplete in some respects because there were integration errors that testing ought to identify and which were not in fact identified.   Compromises are likely to have been made to meet the 1 April deadline.

[129]   Mr Kos next contended that KPMG failed to perform its obligations.  I reject that submission.   I accept that Mr Cohen and his team spent much less time than KPMG had budgeted, but KPMG did address itself to data conversion assurance, checking the scoping document and data migration plan, and identifying what the experts accepted were the significant issues confronting the implementation.   Data matching was addressed only to the extent that KPMG considered the results of data conversion testing as reported in the documents that KPMG reviewed.  It was, as Mr Kos rightly accepted, a process review, and I have found that it was not an audit.  Mr Cohen was reviewing KPMG’s own work, in part, but I see no substance in the suggestion, made by Mr Foy, that Mr Cohen’s work was affected by the conflict of interest.

What risks ought KPMG to have foreseen?

[130]   Mr Kos contended that KPMG ought to have told Southward that it risked having to reimplement the system.   He pointed to evidence of instances in which enterprise resource planning system implementations have caused  serious  losses. The  evidence  also  established  that  the  consultants  were  generally  aware  of  a potential for catastrophic failure, usually occurring immediately on going live, in this sort of implementation.  However, Southward did not plead or establish that KPMG ought to have foreseen a material risk of such failure in this case.  Nor, it should be made clear, did Southward’s problems fall into that category.  Mr Kos focused on the

need for reimplementation as a result of failings in the finance area.  In areas other than finance, notably production, it appears that testing had gone well.

[131]   However, nothing in the evidence establishes that a risk of reimplementation was a foreseeable risk when KPMG carried out its data conversion assurance.  Not only were the issues identified being addressed, but there was provision in the Baan implementation contract for post-implementation support, and a process was to be set up for logging errors.  Errors that the system did not identify itself would show up as users encountered and logged them.   The notion that  KPMG should have foreseen a risk of reimplementation presupposes that there were errors of a sort that could not be remedied in the scheduled post-implementation process.  The evidence failed to establish any such errors existed in fact, or were likely when viewed as at

31 March 1999.  On the contrary, the experts agreed that errors in the system could have been fixed quickly following implementation.

[132]   It follows that KPMG did not act carelessly by failing to foresee a risk that reimplementation, or serious business problems, would flow unless implementation was delayed.

Would Southward have delayed implementation had KPMG warned against going live?

[133]   Roy Southward said in evidence that he believed any problems would be identified by Baan and KPMG, with Southward staff, and, if necessary, notified to management and the board.  Had the KPMG IRM “audit” identified “the significant problems with the implementation” and KPMG advised Southward accordingly, he was confident that Southward would have delayed going live until the problems had been addressed.  I think this evidence is much informed by hindsight.  In my view, Southward would not have delayed going live, for two reasons.   First, Southward was committed to the 1 April date and would not willingly delay implementation. Second, the most that could have been expected of KPMG was that it should identify deficiencies in the process, thereby highlighting for the project team the risk of data conversion errors and subsequent business problems.  Had it done so at 31 March, it would likely have established that some testing remained to be completed.   For

reasons just outlined, KPMG would not have identified a material risk of serious business failure or need for reimplementation.   The project team’s response would have been unchanged; it would have responded that the issues were being addressed, and did not require delay.  It had already formed that opinion when making the go- live decision.

[134]   Mr Kos resisted this conclusion, pointing to Mr Hart’s evidence that testing was inadequate and resultant risks for data conversion and integration very high.  But Mr Gross’s evidence was to the contrary, and in this respect he was supported by Mr Pieters, Mr Eriksen, Mr Grove, and Mr Lala.

[135]   In summary, I am satisfied that Southward would have proceeded with the implementation even if KPMG had warned that there were deficiencies in testing that created significant business risks.   It would have done so without inviting the Board to make the decision, because the decision had been delegated to Mr Oliver and  the project  team.    If,  contrary to  this  finding,  Southward  management  had referred the decision to  the Board, Southward has  failed  to  satisfy  me  that  the directors would have opted to delay; on the contrary, I consider that they would have followed the advice of the project team.

Steps required to remedy defects as at 2001

[136]   In light of my conclusions, it is not necessary to deal with the remaining issues of causation, nature and quantum of loss, and contributory negligence.  In case the matter should go  further, however, I will briefly record my  findings on the question of what was necessary to repair Southward’s system as at 2001.

[137]   I have accepted that by 2001 there were significant integration errors, and by that time a great many transactions had plainly been processed incorrectly.  In these circumstances, Mr Gross and Mr Hart were agreed that reimplementation was appropriate.  They differed as to what it entailed.   Mr Hart’s view was that it was necessary to start from scratch, repeating the entire Sims 1, 2 and 3 processes.  Mr Gross’s view was that Baan consultants could copy the existing parameters, master data, and mappings to a ‘pristine’ test company, which would have the effect of

copying 75-80% of system settings that would not require changes.  The remaining settings would be adjusted and an abbreviated testing procedure used.  The pristine test company would be copied to a new production environment, and Southward’s business data imported.   This would save much consultant and internal time, and training costs.

[138]   Mr Gross is very experienced in Baan implementations and problem-solving, and I accept that the method that he proposed was viable.  IBM did not consider it.  I find that it did not do so because its preference, and that of Southward, was to reimplement using Baan 5, which meant a full implementation of the kind referred to by Mr  Hart.   Indeed,  in  his  reply  brief Mr  Cattanach  accepted  that,  in  theory, Southward could have reimplemented Baan 4 but said the suggestion that it do so ignored the reality of the situation, which was that Southward staff had lost faith in Baan 4.  As I have already noted, however, it was common ground that Baan 4 was in fact capable of meeting Southward’s needs.

[139]   Mr Gross considered that a reimplementation of the kind that he proposed could have been carried out at an estimated cost of $200,000.  He was challenged in cross-examination.   I accept that reimplementation of the kind that  he proposed would incur additional costs:  labour costs required to validate opening balances for the new system, including internal costs to the extent that such staff would not have been engaged but for the reimplementation; the IBM review and scoping exercise necessary to identify the problems with the system; and use of an additional server to provide   the   capacity   necessary   to   set   up   a   mirror   system   during   the reimplementation.  Exhaust Systems Australia would have to be excluded.

Decision

[140]   There will be judgment for the defendant.  I recognise that this decision will disappoint Southward, which acquired a Baan 4 system that undoubtedly contained some integration errors made during implementation, and suffered considerable business disruption and  expense  over  succeeding  years.    Whatever  Southward’s complaints about Baan, however, the claim asks too much of the limited data conversion assurance service offered by KPMG in its audit proposal, and overlooks

Southward’s substantial contributions to its own difficulties.  I am satisfied that, in substance, KPMG did what it promised to do, and was not negligent in failing to advise Southward to delay going live, and further that Southward would not have delayed if told that testing was incomplete.

[141]   KPMG is entitled to costs, with provision for two counsel.   My provisional view is that category 2B is appropriate.  Counsel may file memoranda if costs cannot be agreed.

"In accordance with r 540(4) I direct the Registrar to endorse this judgment with a delivery time of

10.00 am on the 1st day of February 2007."

F Miller J

Solicitors:

Russell McVeagh, Wellington for Plaintiffs

Gilbert Walker, Auckland for Defendant