review of microsoft dynamics ax 4 0 final version · pdf filemicrosoft dynamics ax 4.0 offers...

ABCD

Microsoft Business Solutions

Microsoft Dynamics AX 4.0 Review

of General Accepted Accounting

Principles for

Computer Information Systems / International Financial Reporting

Standards/ US-GAAP/ and Sarbanes- Oxley- Act

Section 404- and 409 Requirements

November 2006 This report contains 41 pages

© 2006 KPMG Deutsche Treuhand-Gesellschaft Aktiengesellschaft Wirtschaftsprüfungsgesellschaft, the German member firm of KPMG International, a Swiss cooperative. All rights reserved. Printed in Germany. KPMG and the KPMG logo are registered trademarks of KPMG

International.

ABCD Microsoft Business Solutions

Microsoft Dynamics AX 4.0 ReviewNovember 2006

i © 2006 KPMG Deutsche Treuhand-Gesellschaft Aktiengesellschaft Wirtschaftsprüfungsgesellschaft, the German member firm of KPMG

International, a Swiss cooperative. All rights reserved. Printed in Germany. KPMG and the KPMG logo are registered trademarks of KPMG International.

Contents

1 Assignment and Execution 1 1.1 Review objectives 1 1.2 Legal baseline 2 1.3 Review approach 3 1.4 Type and scope of the review 3 1.5 Terms and Conditions 4

2 Management Summary 5

3 Release to Third Parties 6

4 Detailed results 7 4.1 System description 7 4.1.1 Soft- and hardware requirements 7 4.1.2 Application software 7 4.1.3 Test environment details 8 4.2 Voucher, Ledger and Account Function 8 4.2.1 Voucher Function 8 4.2.2 Ledger Function 9 4.2.3 Account Function 10 4.3 Software Security 10 4.3.1 Restricted Access to the software 10 4.3.2 Backup and Recovery Data 11 4.3.3 Evaluation of program development, maintenance and release 11 4.4 Documentation 12 4.5 Processing Functions supporting compliance with International Financial

Reporting 12 4.5.1 IFRS scope limitations 13 4.5.2 IFRS functionality with limitations 14 4.5.3 IFRS supported by the functionalities of Microsoft Dynamics AX

4.0 15 4.5.4 Software programmed controls 19 4.6 US-GAAP Compliance 33 4.7 Processing functions supporting compliance with Sarbanes-Oxley Act

(SOX) 35 4.7.1 Section 404 Requirements 35 4.7.2 Section 409 Requirements 37

5 Final Conclusion 39



1 © 2006 KPMG Deutsche Treuhand-Gesellschaft Aktiengesellschaft Wirtschaftsprüfungsgesellschaft, the German member firm of KPMG


1 Assignment and Execution Microsoft has requested a software review of the Microsoft Dynamics AX Financial Manage-ment module on 08/23/2006, which is an integrated component of the Microsoft Business Solu-tions.

Within Microsoft Dynamics AX Financial Management, the following individually packaged functionalities were assessed:

Microsoft Dynamics AX Financial Management I:

General ledger

Accounts payable

Accounts receivable

Fixed assets

Bank management

Multicurrency

Microsoft Dynamics AX Financial Management II:

Cost accounting

Inter-company accounting

Multiple-company consolidation

Account allocations

Cash-flow forecasting

Electronic banking

Inventory costing

1.1 Review objectives The objective of the software review was to assess the application features and functions used to support financial reporting compliance according to the legal baseline stated under section 1.2.

The functionality of Microsoft Dynamics AX Logistics, CRM, Master Planning, Production, Shop Floor Control, Human Resources, Questionnaire, Balanced Scorecard, Project, Service, Administration and Product Builder as well as interfaces to all other Microsoft Dynamics AX modules were not part of our review.

We have carried out the audit between September 1st and November 13th of 2006.





1.2 Legal baseline The review was carried out in accordance with the following requirements and regulations to the extent that they were relevant:

International Standards on Auditing (ISA), ISA 400 [AU section 8400] Risk Assessment, Internal Control and ISA 401 [AU section 8401] Auditing in a Computer Information Sys-tems Environment;

International Auditing Practice Statements (IAPS), sections 10,010 – 10,030 (IT Environ-ments) and 10,080 (Risk Assessments and Internal Control – CIS Characteristics and Con-siderations;

COBIT (Control Objectives for Information and Related Technology) established by the Information Systems Audit and Control Association® (ISACA™);

Sarbanes-Oxley-Act, July 30, 2002, section 404 (Management assessment of internal con-trols) regarding an adequate internal control structure and procedures for financial reporting;

Sarbanes-Oxley-Act, August 1, 2002, section 409 (Real time issuer disclosure- Issuers must disclose information on material changes in the financial condition or operations of the is-suer on a rapid and current basis);

PCAOB (Public Company Accounting Oversight Board) Release No. 2004-001, March 9, 2004;

International Financial Reporting Standards (IFRS);

United States Generally Accepted Accounting Principles (US-GAAP);

“Principles of Proper Accounting for the Use of Information Technology” of the Technical Committee for Information Technology of the Institute of Public Auditors in Germany, In-corporated Association released on September 24th, 2002 (FAIT 1) and

Auditing Standard 880 “Issue and Use of Software Certificates” of the Institute of Public Auditors in Germany, Incorporated Association released on June 25th, 1999 (PS 880).

Financial Accounting Standards Board (FASB) 52, Foreign Currency Translation





1.3 Review approach The review was conducted under laboratory conditions and did not include the organizational and process environment at clients/user. The evaluation of the review is therefore, restricted to the application software as configured within the test environment reviewed. We performed the review for Microsoft Dynamics AX in a test environment running under Microsoft Windows XP and Microsoft Windows Server 2003 (operating system used for the virtual PC). Microsoft Dynamics AX 4.0 is run as an image with Microsoft Virtual PC 2004.

The review was restricted to the software release version which was provided by Microsoft Business Solutions within the test environment. During our review activities we used two dif-ferent release versions of Dynamics AX (4.0.1659.26 and 4.0.1659.36).

Furthermore, the hardware, operating system and implementation-specific customization inter-relationship and specific rules were not included in the review.

We did not carry out an audit of financial statements or similar examinations. Accordingly, we have not issued an audit opinion or any other certificate or confirmation relating to the recogni-tion or valuation of the components of financial statements generated by Microsoft Dynamics AX.

1.4 Type and scope of the review

We conducted our review based on the documentation received by Microsoft, tests performed on the test environment and live meetings/ phone conferences made with the responsible parties from Microsoft.

We carried out our review in four phases:

1. Review of Documentation provided by Microsoft

All the documentation necessary to conduct the review to include an appropriate test environ-ment was provided by Microsoft. Any additional information or explanations required were given willingly by the employees of Microsoft.

Based on the documentation received in advance and during the introduction phase, we re-viewed the programmed processing rules to establish specific control procedures over the finan-cial reporting process. This was done in order to provide reasonable assurance that all transac-tions are authorized, recorded, and processed completely and accurately in a timely basis.

2. Introducing the test environment

We obtained a detailed introduction of the application environment by working directly with the test system as well as with the system description made available for us.

The review of program-based processing functions for financial reporting was carried out using several test cycles, which were performed by random sampling.





3. Review Process

Based on the documentation we received and the tests we performed on the test environment we have reviewed the programmed processing rules to establish specific control procedures over the financial reporting process in order to provide reasonable assurance that all transactions are authorized and recorded, and are processed completely, accurately and on a timely basis.

4. Conclusion and Preparation of the Report

At the end of the review process we issued this report. The type, scope and results of the de-tailed review activities performed are recorded in the relevant working papers.

We received a letter of representation from Microsoft stating that all the significant documenta-tion, disclosures, explanations and information required for our review have been completely and correctly provided.

1.5 Terms and Conditions Both contracting parties may terminate the Agreement subject to a two-week notice period to the end of a given month. The right to effect termination for good cause shall remain unaf-fected.

Any notice to terminate this Agreement must be in writing.

In the event of premature termination of the Agreement, KPMG shall, upon Microsoft’s request and payment of a fee to be agreed separately, prepare appropriate and detailed closing and trans-fer documents in relation to the services provided by KPMG up until the date of termination of the Agreement in order to facilitate continuation of the project by Microsoft. Microsoft shall pay for preparation of such documents in accordance with the per diem rates set forth above.

In all other cases of premature termination of the Agreement, KPMG shall be compensated for any and all services rendered until the entry into effect of such notice of termination. Section 649 sentence 2 of the German Civil Code (Bürgerliches Gesetzbuch, "BGB") remains unaf-fected.





2 Management Summary We reviewed the integrated application functionality for Microsoft Dynamics AX Financial Management I1, Microsoft Dynamics AX Financial Management II2 and inventory costing.

The test case method was used to assess the existence of features to support single legal subsidi-ary or entity financial reporting compliance of the application with respect to relevant IFRS, US-GAAP and Sarbanes-Oxley Act (SOA) requirements.

The review was restricted to the software Microsoft Dynamics AX 4.0 provided by Microsoft within the test environment.

Based on our audit of Microsoft Dynamics AX release 4.0, the software is compliant with the generally accepted accounting principles for computer information systems with respect to the legal baseline stated under section 1.2

Microsoft Dynamics AX 4.0 contains a basic ‘consolidations function’ (legal entity financial statements can be combined in a consolidation company). However, this function allows only a summation of legal entities and is not adequate to prepare consolidated financial statements automatically. For consolidated financial statements, it is necessary to carry out several adjust-ments of the combined financial statements like elimination of intra-group transactions, bal-ances and profits/losses and consolidation of equity. These functionalities can be achieved within Dynamics AX only manual postings in General ledger.

Microsoft Dynamics AX 4.0 offers a flexible ‘divisional’ reporting functionality through the use of dimensions. However, this reporting can not be classified as a segment reporting in accordance of IAS 14, as the intra-company transactions between the segments cannot be presented and consolidated.

The Microsoft Dynamics AX user should be aware, when running on Microsoft Dynamics AX 4.0; the solution does not provide certain pre-defined reports. These reports include cash flow statements in accordance to IAS 7, asset history sheets, which are often required as a supple-ment to both the individual and consolidated financial statements to show changes in asset val-ues between the opening and the closing balance. The user, however, is able to create those re-ports by using the financial statement functionality in the General ledger.

1 Including General ledger, Accounts receivable and Accounts payable, Bank management, Fixed assets, Multicur-rency 2 Including Cost accounting, Inter-company accounting, Multiple company consolidation, Account allocations, Cash flow forecasting, Electronic banking





3 Release to Third Parties The results of our work will be prepared solely in connection with the planned work and will not be suitable for any other purpose. We will report exclusively and directly to Microsoft.

Our written report concerning our observations and recommendations and the final statement of our report may be disclosed to third parties only subject to the following rule:

Microsoft may refer to the certification on a web-site, in e-mails and in other printed and elec-tronic media without referring to KPMG and using the following wording

”Microsoft Dynamics AX 4.0 has been assessed and certified by an independent third par-ty auditor to allow data processing for the purpose of financial reporting in accordance with IFRS, US-GAAP and the Sarbanes-Oxley Act requirements applicable as of Novem-ber 30th, 2006.”

The report and the final statement will be placed in a separate KPMG extranet that you can make accessible to third parties through a link in your web site. Every third party entering the extranet site will be able to access the documents only after accepting our General Engagement Terms and limitation of liability by opening these terms and clicking an accept button.

Microsoft will indemnify KPMG from all claims or costs arising from a breach of this restric-tion on the circulation of our work results to third parties.





4 Detailed results

4.1 System description

4.1.1 Soft- and hardware requirements

According to Microsoft Dynamics AX 4.0 can be used if at least one of the following software requirements within each area is fulfilled:

• Clients: Windows XP Professional, Windows 2000, Server and Server Advanced, Windows Server 2003 Web, Std. and Enterprise Edition, Windows Server 2003 Datacenter, Data-center x64 Edition, Enterprise x64 Edition, Windows Small Business Server 2003, Standard and Premium Edition

• Server Platforms: Windows Server 2003 Web, Std., Enterprise, Datacenter and Datacenter x64 Edition, Windows 2003 IA64, Windows Small Business Server 2003, Standard and Premium Edition, Windows Server 2003

• Databases: Microsoft SQL Server 2000 Desktop, Personal, Std., Developer, Enterprise, Workgroup Edition, Microsoft SQL Server 2000 (64-bit) Developer Edition, Microsoft SQL Server 2005 Express, Standard, (64-bit) Standard, (64-bit) Itanium Enterprise, (64-bit) Enter-prise, Enterprise, Workgroup Edition, Oracle 10g Release 2 Enterprise Edition

The following hardware requirements need to be covered according to Microsoft:

Processor: Pentium III Xeon 1.1 gigahertz (GHz) or higher

Disk configuration: Microsoft SQL Server minimum recommended deployment

RAM: 512 megabytes (MB)

CD-ROM drive

Free disk space: 700 MB

4.1.2 Application software

Microsoft Dynamics AX 4.0 is an enterprise resource planning (ERP) software, designed for multinational corporations or companies working in several languages and different currencies.

The software is usually installed at the customer site by affiliated partner companies of Micro-soft. Customer-specific settings and adjustments in line with the customer’s processes (e.g. valid currency, chart of accounts) are made during the installation procedure. Data is processed by means of the entry, posting, editing, management, and system plausibility checks.





4.1.3 Test environment details

Microsoft Dynamics AX 4.0 is emulated as virtual pc which is set up with Microsoft Virtual PC 2004. Therefore it is necessary to distinguish between physical and virtual test environment, i.e. virtual PC image containing the audited Dynamics AX installation and the computer running the virtual PC emulator.

• Hardware configuration Computer running the virtual PC emulator is an Intel Pentium 4, 2.8GHz, 1024 MB RAM, 40 GB hard drive. The PC image virtually runs on an Intel Pentium 4, 2.8GHz, 128 MB RAM, 20 GB hard drive. RAM and hard drive space are different, because only part of the physical RAM and hard drive space was allocated to the virtual PC emulator.

• Operating system Host operating system: Windows XP Professional, Service Pack 2 Guest operating system: Windows Server 2003 Enterprise Edition, Service Pack 1

• Network software This audit area is not applicable since in our test environment Microsoft Dynamics AX 4.0 is set up as a one-computer solution where Application object server, Microsoft Dy-namics AX application file share, Database and Microsoft Dynamics AX client are working on a single machine and not within a network.

• Database applications Guest database: Microsoft SQL Server 2005

4.2 Voucher, Ledger and Account Function As part of the systems audit we have evaluated processing functions which are significant for compliance with generally accepted accounting and bookkeeping principles (GoB). In particu-lar, these include the proper functioning of the accounting records (Voucher function), journals (Ledger function) and accounts (Account function).

4.2.1 Voucher Function

When business transactions are entered manually, all elements of the document that are neces-sary in accordance with Generally Accepted Accounting Principles must be entered in the input forms. Within the voucher functionality, the software has to ensure that the correct amount is booked, the correct account is assigned and that each posting has to have a unique document number. When booking entries are made, the software must ensure that each posting has a cor-rect document date, posting date and an accounting period. It also has to make sure that the posting contains a booking text.





Results:

Mandatory fields in Dynamics AX are the account number, offset account number, the voucher number, creating- and posting date. Furthermore the user can assign a transaction text to de-scribe the posting.

Microsoft Dynamics AX 4.0 posts transactions according to dates and not according to periods. The data of an individual document displayed on the screen represents a copy of the original document. Plausibility checks are performed by the system when the document data is entered manually to ensure that it is complete and correct. Checks performed on the document data en-sure, for example, that the posting data is within the permissible posting period and that the de-bit and credit amounts balance. Business transactions that are posted can be selected and dis-played.

The voucher number is the identifier for a posting. According to legal requirements in some countries the voucher number needs to be unique. During customizing it can be defined whether the systems rejects duplicates, rejects duplicates only within the same fiscal year, accepts dupli-cates or just warns in case of duplicates. It is the user’s responsibility to make sure to comply with legal requirements of its country by using the right settings in this area.

Conclusion:

Based on the results of our audit, we can conclude that Dynamics AX fulfills the requirements of the voucher functionality of generally accepted accounting and bookkeeping principles. We recommend that the users of Dynamics AX take appropriate actions to make sure the uniqueness of the voucher number is given.

4.2.2 Ledger Function

The ledger functionality of software includes the ability to produce a list of booking data in chronological order. The software has to make sure that a journal can be created for all business transactions. It should be able to support the printing of posting data or filing posting data in combination with availability for printing.

Results:

A journal can be created and output for all business transactions in Dynamics AX. The postings appear in the chronological order in which they were entered and posted. Once the journal has been created, it can be printed out as a report and made available as file. In General ledger, the journal number is used to uniquely identify a posting and ensures that the posting is included and can be located properly in the audit trail. It can also be used as a tool for checking that the posting data is complete. The entered and posted business transactions can be displayed in full chronological order and in a clearly-structured and user-friendly manner.

Conclusion:

Based on our audit procedures, we can conclude that Dynamics AX fulfills the requirements of the ledger functionality of generally accepted accounting and bookkeeping principles.





4.2.3 Account Function

While posting manual transactions within the accounts, the software has to ensure that the book-ing documentation contains details of the account description, evidence of an unbroken number sequence, identification of the bookings, the individual amounts, the totals and balances in debit and credit, the posting date, the offsetting account, document reference such as booking text or the text in coded form.

The software has to make it possible to create lists of the posting data not only as journal but also as an account format. It also has to ensure the possibility to retrieve posting data within a reasonable given period of time. Results:

The data recorded for a posting includes the accounts, a unique journal number, totals and bal-ances (debit/credit) in the relevant currency, as well as the posting date and posting text.

Conclusion:

Based on the result of our audit, we can conclude that Dynamics AX fulfills the requirements of the account functionality of generally accepted accounting and bookkeeping principles.

4.3 Software Security The audit of software security includes restricted access, data back-up and restarting procedures and an evaluation of program development, maintenance and release.

4.3.1 Restricted Access to the software

4.3.1.1 Logging of user access

The software has to have the ability to record each access to the system giving the user ID.

Results:

Microsoft Dynamics AX 4.0 is logging the user access to the system. For each user you can see a detailed user access log with User-ID, login date and time and online time.

4.3.1.2 Password Conventions

The following controls have to be in the software:

a. Is the secrecy of passwords ensured (i.e. the password is not shown on the screen; it is not possible for password data to be read by an unauthorized person)

b. Does the system require periodic changes to the passwords?

c. Are trivial passwords not permitted?





Results:

The user management for general access to Microsoft Dynamics AX 4.0 is based on Microsoft Active Directory which is a constitutional part of Microsoft Windows Server 2003 and not part of Dynamics AX 4.0 (including logging into the system with User-ID and password, password handling, complexity criteria and password changing intervals). The benefit for the customer is the Single-Sign-On functionality, i.e. logging into its operating system grants automatically general access to Dynamics AX 4.0. However the user management in terms of specific func-tional assignments and user rights management are handled by Dynamics AX 4.0 itself.

Password Conventions as part of the functionality of Microsoft Active Directory are therefore not in the scope of our audit.

4.3.1.3 Logging of access violation

Following controls are tested within this area:

a. How does the system react to unauthorized access (e.g. by shutting down after a number of unauthorized attempts, time-out)?

b. Is it possible to grant access based on specific functional assignments (i.e. access is only granted to the extent required to complete a specific task)

Results:

Questions of unauthorized access are part of the general access user management which is han-dled by Microsoft Active Directory. In terms of specific functional assignments and user rights management Dynamics AX 4.0 provides a user group concept. User groups are typically used to provide different access combinations for various groups of similar users.

4.3.2 Backup and Recovery Data

This area is not relevant for the audit since Microsoft Dynamics AX 4.0 does not have a specific backup or recovery functionality. Data backup and restoring procedures can be implemented by using other solutions to backup and restore the database (e.g. Microsoft SQL Server) and server program files.

4.3.3 Evaluation of program development, maintenance and release

Microsoft has a well defined product development cycle in place. The development process consists of five phases: plan, design, implement, stabilize and release. During the Planning and Design phases Microsoft uses a functional specification development and review process to en-sure quality management.

Software development and maintenance processes are mainly supported by using Product Stu-dio. It is a tool for the development and testing of a product. Included are bug tracking and link-ing, test case management, project contacts, and interaction with Microsoft's feedback channels. Having sufficient development and maintenance processes in place Microsoft Business Solu-





tions is able to deal with code defect, collaboration requests, content issues, design changes, documentation inaccuracies, security issues and specification issues.

4.4 Documentation We have reviewed system and user documentations. All the documentation provided to the auditor by the software supplier need to be complete, up-to-date, unambiguous, understandable and clearly laid out.

Results:

The user documentation consists of online help as well as “Microsoft Official Courseware” training material. The “Microsoft Official Courseware” contains sufficient and easy-to-follow descriptions of the modules and functionalities which are in the scope of this audit. It is com-plete and up-to-date. The online help provides basic information about the most important func-tions, but the online help in the given test environment is not complete. The user can find the most current version of the online help on the Microsoft site on the Internet (http://msdn.microsoft.com/library/). It is updated regularly, but there were topic areas incom-plete at the time of the audit process.

The technical system documentation consists of online developer help as well as of one course of “Microsoft Official Courseware” training material regarding installation and configuration. The online developer help in our test environment is not complete. The “Microsoft Official Courseware” contains sufficient and easy-to-follow descriptions for the basic installation and configuration of the system.

Conclusion:

All the materials we have received via e-mail contain sufficient information. However, we recommend to improve the online help of Dynamics AX, which was not complete in our test environment as well as on the Microsoft site in the internet.

4.5 Processing Functions supporting compliance with Interna-tional Financial Reporting

The scope of our review was limited to the Microsoft Dynamics AX 4.0 Financial Management I and II and Microsoft Dynamics AX 4.0 Trade and Logistics modules as described in chapter 2.

Microsoft Dynamics AX 4.0 does not support IFRS accounting via pre-defined settings that are automatically available when the system is installed. The chart of accounts, as well as journal definitions and reporting functionalities, will need to be reviewed. However, the software can be configured via individual settings and general journal entries.

In the first step, we analyzed the IFRS standards applicable from the first of January 2006 to determine if they were within the scope of our review (section 4.5.1 ‘IFRS scope limitations’).

In the next step, we identified standards which are not supported by functionality in Microsoft Dynamics AX 4.0. However, compliance could be achieved by general journal entries. We refer to section 4.5.2 ‘IFRS functionality with limitations’.





In the final step, we identified those IFRS Standards which are supported by functionalities of Microsoft Dynamics AX 4.0. We refer to section 4.5.3 ‘IFRS supporting functionalities’.

4.5.1 IFRS scope limitations

The following IFRS issues do not fall within the scope of our review:

First-time adoption/conversion period

IFRS 1 First-time Adoption of International Financial Reporting Standards

A major requirement of IFRS 1 is a dual reporting in local GAAP and IFRS for the IFRS opening balance and the comparartive period. Although Microsoft Dynamics AX 4.0 is able to produce information for different posting layers, a detailed reconciliation of the differences between them in respect of the equity and profit/loss in accordance with local GAAP and IFRS for the reporting and comparative periods has to be made. This automated reconcilition is not supported by Microsoft Dynamics AX 4.0.

IFRS 1 also contains specific accounting rules for first-time adopters. These can be taken into consideration with general journal entries.

Consolidated Financial Statements

Microsoft Dynamics AX 4.0 contains a basic ‘consolidation function’ (legal entity financial statements can be combined in a consolidation company) including currency translation. However, this function allows only a summation of legal entities and is not adequate to pre-pare consolidated financial statements according to IFRS. For consolidated financial state-ments there are several adjustments of the combined financial statements like elimination of intra-group transactions, balances and profits/losses and consolidation of equity neces-sary. Therefore, requirements given by the following standards relevant for consolidation are not within the scope:

IFRS 3 Business Combinations

IAS 27 Consolidated and Separate Financial Statements with respect to the preparation and presentation of consolidated financial statements

IAS 28 Investments in Associates with respect to their recognition/measurement in the consolidated financial statements

IAS 31 Interests in Joint Ventures with respect to their recognition/measurement in the consolidated financial statements

Accounting issues of special businesses/sectors

IFRS 4 Insurance Contracts

IFRS 6 Exploration for and Evaluation of Mineral Resource

IAS 26 Accounting an Reporting by Retirement Benefit Plans

IAS 41 Agriculture





IAS 39 Financial Instruments: Recognition and Measurement

Companies need a special treasury management solution to support business activities related to IAS 39. A software needs to have a portfolio analyzer capability to calculate the yields the company has achieved in the treasury department. It has to be able to calculate net present values and many derived key figures, as well as value at risk, using different methods.

Microsoft Dynamics AX 4.0 does not support tracking of this kind of detailed and customized financial information. Nevertheless, journal entries can be posted in the General ledger to accounts for financial instruments.

Notes

In practice, notes including accounting policies are generated manually based on a variety of information available to management supported by several applications. Almost all IFRS standards contain regulations concerning notes . The following standards only deal with notes and are therefore out of scope:

IFRS 7 Financial Instruments: Disclosures

IAS 24 Related Party Disclosures

IAS 33 Earnings per share

4.5.2 IFRS functionality with limitations

The compliance with the following IAS/IFRS standards is not supported by Microsoft Dynam-ics AX 4.0 functionalities automatically. However, they can be achieved by general journal en-tries supported by the system:

IFRS 2 Share-based Payment

IAS 8 Accounting Policies, Changes in Accounting Estimates and Errors

Mircrosoft Dynamics AX 4.0 provides the possibility to adjust entries in prior accounting periods depending on the status of the system: ‘closed’, ‘stopped’ or ‘open’. Entries of periods marked as stopped or open can be changed.

IAS 10 Events after the Balance Sheet Date

IAS 11 Construction Contracts

IAS 12 Income Taxes

IAS 17 Leases

IAS 18 Revenue

IAS 19 Employee Benefits

IAS 20 Government Grants





To register the amount of the grant, the fixed asset module can be used if the government grant is deducted directly from the related asset. The user has to adjust the acquisition price and the depreciation is calculated from a reduced basis.

Alternatively the government grant can be booked as an accrual and allocated during the useful life of the asset. In this case there is no possibility to link the depreciation of the asset and the allocation of the accrual.

IAS 23 Borrowing Costs

If the alternative treatment is used and the borrowing costs that are directly attributed to the acquisition, construction or production of a qualifying asset are capitalised as part of the cost of that asset recognised in the fixed asset module.

Borrowing costs can be recorded as a part of the acquisition price. Borrowing costs have to be calculated outside Microsoft Dynamics AX 4.0. There is no function to determine the borrowing costs as a function of the current assets under construction.

IAS 29 Financial Reporting in Hyperinflationary Economies

IAS 32 Financial Instuments: Presentation

Microsoft Dynamics AX 4.0 provides flexible means of classifying financial instruments. Disclosures are out of scope.

IAS 37 Provisions, Contingent Liabilities and Contingent assets

Microsoft Dynamics AX 4.0 does not generate a provision movements schedule, but the user is able to create one based on the stored data and with the built-in reporting functionality.

4.5.3 IFRS supported by the functionalities of Microsoft Dynamics AX 4.0

The following IFRS Standards are supported by Microsoft Dynamics AX 4.0:

IFRS 5 Non-current Assets Held for Sale and Discontinued Operations

Assets classified as non-current assets held for sale or belonging to a discontinued operation can be recorded in the Microsoft Dynamics AX 4.0 Fixed Assets module. In that module, the depreciation of non-current assets held for sale or assets belonging to discontinued operations can be stopped easily. Users can use the sorting function within the module to generate special reports on these particular items of property, plant and equipment. Another way to prepare reports on that specific asset group is by using the grouping functionality. In this case depreciation of the assets will be stopped automatically when the asset is moved into that group. This is not part of the separate disclosure in the balance sheet or income statement of the non-current assets held for sale or the discontinued operations that must be done manually in the journal ledger. Microsoft Dynamics AX 4.0 does not provide support for the remeasurement of non-current assets held for sale or of discontinued operations.





IAS 1 Presentation of Financial Statements

According to IAS 1, a complete set of financial statements comprises a balance sheet, an income statement, a statement of changes in equity, a cash flow statement and notes, comprising a summary of significant accounting policies and other explanatory notes.

Within Microsoft Dynamics AX 4.0 the chart of accounts structure will need to be individually configured to have sufficient Balance Sheet Codes/Income Statement Codes to address the standard. A distinction of assets and liabilities in current and non-current is supported via individual settings. The setting will also be applied to the comparative figures for the previous year.

Microsoft Dynamics AX 4.0 does not include the functionality to generate a statement of equity automatically but the user is able to derive one based on the General ledger.

The results concerning the cash flow statement are described under IAS 7 Cash Flow Statements.

Notes are as explained in 4.3.1 not within the scope of our tests.

IAS 2 Inventories

Inventories shall be measured at the lower of cost and net realizable value.

Purchased inventories shall be measured by using either the first-in, first-out (FIFO) or weighted average cost formula. Microsoft Dynamics AX 4.0 inventory management module supports this functionality.

The standard costing is also implemented in Dynamics AX and it is possible to have a reconciliation between actual and standard cost.

Costs of inventories such as costs of purchase, costs of conversion and other costs can be recorded in the Microsoft Dynamics AX 4.0. However, the system does not support the impairment testing for work in progress or finished goods. However, this could be achieved by general journal entries supported by the system. It is required that impairments are reversed if the reason for the impairment does not exist any longer. The functionality to record an impairment or reverse the impairments can only be handled manually in Dynamics AX.

IAS 7 Cash Flow Statements

A cash flow statement reports cash flows during the period classified by operating, investing and financing activities. Operating activities are the principal revenue-producing activities of the entity. They also include activities that are not investing or financing activities. Cash flows from operating activities are reported using either:

• Direct method, whereby major classes of gross cash receipts and gross cash payments are disclosed; or

• Indirect method, whereby profit or loss for the period is adjusted for non-cash items, and items of income or expense related to investing and financing activities.





Dynamics AX supports cash flow statement only with the indirect method and it should be noted that the user has to prepare the cash flow statement by assigning the General ledger accounts.

IAS 14 Segment Reporting

Microsoft Dynamics AX 4.0 offers a flexible ‘divisional’ reporting functionality through the use of dimensions. The solution also provides 10 dimensions that can be used for assigning each transaction to a given dimension. The dimensions used for registering transactions can later be used for generating divisional reporting. However, this reporting does not classify as a segment reporting in accordance of IAS 14, as the intra-company transactions between the segments cannot be presented and consolidated.

IAS 16, IAS 38 Tangible and Intangible Assets

Through the Microsoft Dynamics AX 4.0 Fixed Assets module, useful support for the account of asset belonging to property, plant and equipment (IAS 16), intangible assets (IAS 38) or investment properties (IAS 40) is provided. Assets that are recorded in the module might also result from finance lease transactions. The module allows the user to record all transactions.

The recorded cost of the asset may comprise borrowing costs (IAS 23), as well as government grants or government assistance (IAS 20), see 4.5.2.

The Fixed Assets module supports the requirements of IAS 16. It can record new assets, define asset groups and calculate different depreciation methods. The Fixed Assets module does allow the acquisition price to be split into its different elements like borrowing costs and decommissioning costs.

Components of an asset that differ significantly in their useful lives or in their depreciation method shall be measured separately (component approach). Microsoft Dynamics AX 4.0 Fixed Assets module supports that treatment by splitting up an asset into components with sub-numbers. The components can be depreciated separately from each other.

Applying the revaluation model, revaluation amounts can be manually registered as own transaction types through Microsoft Dynamics AX 4.0 Fixed Assets journals. The revaluation amount will be recorded as additions to the given asset. The depreciation period will consist of the remaining useful life of the asset. The user can define different transaction types (e.g. revalution write down, revaluation write up) and different accounts to record the revaluation amount in conformity to IFRS. Microsoft Dynamics AX 4.0 provides reports per transaction type. There is no validation rule to ensure the IFRS requirement that all assets of an asset group are revalued.

Microsoft Dynamics AX 4.0 provides depreciation tables to reflect customizable depreciation methods. The depreciation method held on an asset record can be altered during its lifetime, if appropriate. An automatic depreciation calculation as well as a manual posting of any asset impairment is possible. The periodic depreciation run has to be started by the user manually. There is no validation that the depreciation run for the current year is done for an asset which initially was defined to be depreciated.





Disposals can be booked as a special transaction type. Microsoft Dynamics AX 4.0 automatically calculates the disposal gain/loss as a difference of the disposal price and the remaining net book value. There is no validation to ensure that all necessary depreciation runs are done before disposal.

Microsoft Dynamics AX 4.0 provides different customizable reports. The reports list each asset while it is not possible to show the values per asset group. Different reports offer the information for generating the statement of changes in non-current assets.

Microsoft Dynamics AX 4.0 offers the functionality of different layers to store different values (e.g. Local GAAP, IFRS, Tax) for a given asset in parallel accounting. Reports can list all assets per layer.

IAS 21 The effects of Changes in Foreign Exchange Rates

Microsoft Dynamics AX 4.0 can handle transactions denominated in any currency. Using the currency exchange rate table the transactions will be recorded at the currency rate as of the transaction dates if rates are adjusted on a daily basis.

Through a batch job Microsoft Dynamics AX 4.0 can adjust all open accounts payable or account receivable entries denominated in foreign currencies and convert these so they reflect the currency exchange rate at the balance sheet date. Any adjustments are posted to an income statement account specified by the user.

Microsoft Dynamics AX 4.0 provides functionality to support the translation of reports from foreign companies using different functional currencies.

Microsoft Dynamics AX 4.0 is not able to fulfill the requirement of IAS 21.30. This standard requires that when a gain or loss on a non-monetary item is recognized directly in equity, any exchange component of that gain or loss shall be recognized directly in equity. To be able to fullfill this requirement, a software has to recognize resulting exchange differences automatically as a separate component of equity. The Dynamics AX user is however able to fulfill this requirement by posting manually in the General ledger as it is not possible for the system to post automatically the resulting exchange differences in the equity. It is not possible in Dynamics AX to create transaction or movement types for certain business transactions, sothat the user has the flexibility to define the business transaction in the system and assign the appropriate accounts based on this business transactions.

IAS 34 Interim Financial Reporting

IAS 34 prescribes the minimum content of an interim financial report und applying the same accounting policies as the annual financial statements. With Microsoft Dynamics AX 4.0, the user is able to shorten or lengthen the reporting periods for the balance sheet or income statement for interim period purposes. The user may customize specific reports for his interim financial reporting.





IAS 36 Impairment of Assets

With respect to IAS 36, the financial reporting system and the asset register should be capable of being able to recognize impairments for individual assets or asset groups associated with a Cash Generating Unit (CGU).

Microsoft Dynamics AX 4.0 Fixed Asset module is capable of recording the impairment for each asset or asset group, however, it does not provide guidance on the estimate of the net selling price or the value-in-use, for either single asset or cash-generated-units. Any adjustments resulting from an impairment or reversal of an impairment will result in adjustment entries to the subsequent depreciation of that asset. Depending on the cost model or the revaluation model as measurement method in accordance to IAS 16 and 38, the impairment amount can be recorded as an expense or directly in equity.

Reversals can be recorded as a special transaction type. There is no validation to ensure that the reversal does not exceed the original impairment amount.

The user can manually group non-current assets to a cash generating unit within the program. A pre-defined allocation of assets is not available.

IAS 40 Investment Property

Microsoft Dynamics AX 4.0 provides the function to record investment properties with respect to IAS 40. Besides the cost model as applied in IAS 16 and IAS 38, the fair value model can be applied to investment properties. The fair value of an asset cannot be plugged in directly as the net book value is always calculated as a result of the different transaction types. Therefore the user can apply the fair value model by creating a special transaction type “fair value adjustments” and defining the appropriate accounts.

4.5.4 Software programmed controls

4.5.4.1 Software programmed controls in General ledger and Accounts allocation

The General ledger (GL) is at the core of a company’s financial records. As every financial event flows through the GL, the effective management of GL controls is a critical component in an efficient financial close cycle, accurate financial reporting, and sustained regulatory compli-ance.

Data Integrity:

It is essential for a software package not to allow stored data to be manipulated in a way that can seriously jeopardize the integrity of the data. Direct access to account balances should not be allowed, bypassing the transaction posting/audit trail activities, through data replacement. When an account can be replaced with a different value, integrity is then lost.

Results:

Overrides are not allowed to remove or replace entries, balances, or transactions. Every access to the General ledger accounts are logged through the audit trail.





Creating Fiscal Year, Opening and Closing accounting periods

For the process of preparation and reconciliation of periodic and yearly accounts, software needs to be flexible when it comes to the setup of a fiscal year and accounting periods. The fi-nancial closing process is important for a company as it is the function directly related to pro-ducing the company’s financial results for each period end. Restricting access to accounting and reporting applications for a closed period is an initial control in General ledger.

Results:

The fiscal year can be defined as beginning on any date, and can be divided into accounting pe-riods. At the conclusion of a fiscal year, the “Run of the Year End Close” transfers the year’s results to the balance sheet and at the same time balances out all the income statement accounts to zero.

Debits and Credits

Every accounting entry in the General ledger contains both a debit and a credit. Further, all deb-its must equal all credits. If they don't, the entry is out of balance. Therefore, the accounting sys-tem must have a mechanism to ensure that all entries balance.

Results:

Dynamics AX does not allow entering an out-of-balance entry.

Controls for handling of accounts

Controls must be in place to ensure that the financial information contained in General ledger accounts is complete and accurate. It has to be ensured that the entries within certain accounts can be restricted.

Results:

There are no issues found related to the tested controls for the handling of the accounts. The following detailed results have been noted:

• It can be defined whether the account should be locked. This means depending on the set up of the accounts, entries can be posted manually and/or automatically.

• An account can also be closed meaning that no entries can be made in the account di-rectly or indirectly.

• An account can manually be configured if it should be affected by changes in exchange rates. This means an account can be configured not to be affected by changes in the ex-change rates.

• Account numbers are unique in Dynamics AX.





• Each account can be set up with one account type. Account types determine how the ac-count is handled by Dynamics AX. Default account type is Profit and Loss. The follow-ing account types exist in Dynamics AX 4.0:

o Profit & Loss, Revenue and Cost o Balance, Asset and Liability o Header o Empty header o Page header o Total

• It is possible to define access rights for each account created in Dynamics AX making it impossible for certain users to post entries in certain accounts.

General ledger transaction reversal

The software has to ensure the ability to reverse the transaction, the ability to undo a reversal and inquiry on tracing reversals.

The following transactions can be reversed: General ledger transactions, customer transactions, except transactions that relate to sales order or projects and vendor transactions, except transac-tions that relate to purchase orders.

Results:

The software supports the ability to reverse transactions that have been posted incorrectly. It is also possible to undo the reversal. By assigning special voucher numbers reversals can be easily traced in various reports.

General ledger financial statement

This area is covered in our audit of IFRS 1 Reporting requirements.

Accounts allocation

Allocated transactions redistribute account balances from one account to one or more destina-tion accounts. This can be used to set up automatic posting for example percentage allocation of accounts posting

We have set up terms of allocations. In our test scenario we have defined all postings to a speci-fied account to be split between four departments. Finally we have checked the correctness of the allocated transactions. We have checked if the audit trail to the original voucher is ensured.

Results:

With Microsoft Dynamics AX the user can set up terms of allocations. The allocation of post-ings is done correctly and accurately. The software keeps the audit trail by assigning the same voucher numbers to the allocated transactions.

Conclusion: Based on the performed audit work we have noted that it is possible to define relevant controls regarding basic posting of transactions within the General ledger.





4.5.4.2 Software programmed controls in Accounts payable

Controls around master data

Vendor master data configuration of software determines not only the effective and correct functioning of the processes within the Accounts payable module but also smooth interfaces to other modules.

Results:

Creating a new vendor with the corresponding mandatory fields is possible. The system does not allow duplicates in terms of the vendor account number. Deleting vendor accounts where there are transactions assigned to is not possible. When creating a new vendor, terms of deliver-ies and terms of payment are selected and posting profiles are defined, including the specific group allocation of the vendors. The posting profile and group allocation determines how trans-actions regarding goods and payments are automatically created in the General ledger accounts through the Accounts payable.

Plausibility checks

Plausibility checks of Accounts payable or Accounts receivable modules are a basic part of the validation procedures which include system audits such as warnings when exceeding credit lim-its, correct calculation of discount and due dates, uniqueness of number sequences, etc.

Results:

Number sequences can be created in Dynamics AX to ensure that transactions in Accounts pay-able are unique numbers (transactions trail). It is also possible to define credit limits for each vendor of the company to ensure vendor debts do not exceed established limits. Different meth-ods and terms of payment can be created in Microsoft Dynamics AX, ensuring that payments for vendors are handled accordingly.

Transactions within Accounts payable

As all the expenses that affect the net profit are included in Accounts payable, daily transactions in this module have to be recorded properly. Interfaces between Accounts payable and other functionalities (for example, Inventory Management, Cost Accounting, etc) in Dynamics AX have not been covered in this review.

Results:

The system records all vendor transactions on the relevant vendor-specific account automati-cally and on a number of specified accounts in the General ledger such as Accounts payable, discount accounts, sales tax accounts, etc.





Reporting and controlling on vendors

Reporting is a key element of the controlling of business transactions. Microsoft Dynamics AX offers a wide range of reporting functionalities.

Results:

An account statement can be created for each vendor. It is also possible to get a list of invoices that have not been approved and create an Accounts payable aging report in order to follow up on due payments. For each vendor a balance report with credit limit is provided to support de-tailed analysis on a specific vendor.

Conclusion:

Based on our audit of Accounts payables module, no issues were noted.

4.5.4.3 Software programmed controls in Accounts receivables

In Accounts receivable the same type of controls as in the Accounts payable have been created regarding creating of a customer, setting credit limits, creating an invoice and following up on invoices that have not been paid.

Interfaces between Accounts receivables and other functionalities Inventory Management, which are not in our scope have not been covered in this review.

The system automatically records all customer transactions on the relevant customer-specific account and a number of specified accounts in the General ledger such as sales accounts, receiv-ables accounts, discount accounts, etc.

Dynamics AX can create customer aging and detailed trial balance reports and track customers’ current and past balances.

Conclusion:

Based on our audit of Accounts receivables module, no issues were noted.

4.5.4.4 Software programmed controls in Fixed assets

Controls around master data:

The options in the settings of the fixed asset master data can have major influence on transac-tions and processes in this module. Duplicate asset master records can be prevented from being added to the master files if the asset numbers are unique. The settings should not allow the sys-tem to post depreciation or retirement for incomplete assets (assets that have been entered in the system, in which important master data was not entered such as account assignment informa-tion).





Results:

The asset numbers in Dynamics AX are unique. There are two mandatory fields for creating an asset (Fixed asset group and Fixed asset number). There are fixed asset groups in Dynamics AX to simplify the setup of assets, to help reporting and to create a template with default informa-tion that is copied to a new asset whenever the company acquires a similar asset. We have noted that the system does not post depreciation or retirement for incomplete assets.

Fixed assets transactions:

By creating test scenarios, we have tested several transactions in Fixed assets module of Dy-namics AX. We have accomplished transactions such as acquisitions, disposals, depreciations, extraordinary depreciations and revaluation and tested whether they are recorded completely and accurately. We have analyzed the ability of the software to post these transactions per asset in more than one value model. We have also tested whether it is possible to post asset transac-tions in the closed period/ year.

Results:

Dynamics AX offers several transaction types to categorize and track fixed assets (Acquisition, depreciation, value adjustments, disposal). Separate ledger accounts must be set up on the post-ing profile for each transaction type.

Multiple versions of financial information may be recorded about each asset by using value models. Each value model assigns an additional life cycle to the asset. Ledger accounts must be set up for each value model used for posting. The same ledger accounts can be used for several or even all value models.

Interface to the General ledger

There has to be a consistency between General ledger accounting and Fixed asset accounting.

Results:

The Fixed asset module matches with the General ledger account on a totals basis. The gains and losses on asset disposals are appropriately recorded in the General ledger.

Depreciation Process

The depreciation calculation is based on depreciation key, as well as on the planned useful life of the asset. We have tested the correctness of depreciation calculation and the accurate posting of the depreciation calculation.

Results:

Depreciation profiles are used to define rules for calculating depreciation. The creation of pro-files is required for depreciable assets. Eleven methods are available for depreciation calcula-tion. We have tested straight line and manual method and noted no issues.





Reporting ability in Fixed assets

Three inquiries are available in Fixed assets of Dynamics AX:

• Inquiry on transactions • Inquiry on balances • Inquiry on future transactions

Microsoft Dynamics AX offers many reports for Fixed assets: Here are some of them:

• Fixed asset listing (List of fixed assets and the net book value for the selected value for the selected value models and depreciation books)

• Fixed asset in fixed asset statement rows (List of fixed assets included in the selected fixed asset statement row(s)

• Fixed asset statement rows (Prints information about how fixed asset statement rows are set up)

• Fixed asset basis (Reports the depreciation basis for a specific book and date range.)

We have tested the accuracy and the completeness of the “Fixed asset statement”.

Conclusion:

Based on our review of the Fixed assets module and testing conducted, the basic controls for accounting standards are being met; however, some opportunities for improvement were noted.

We have noted that there are no validation rules in the Fixed assets module. The validation function enables the user to check values and ranges of values as they are being entered in the system such as “Only certain depreciation keys are allowed for certain asset groups” or “The allowance of reversal of the extraordinary depreciation can be maximum xx Dollars”. The lack of automated and customizable validation rules increase the risk that data entry errors will not be detected if there is no monitoring or subsequent manual review of data entry.

We have also noted that the depreciation run can only be controlled manually. There is no rule defined for a warning message if the user mistakenly does not run the depreciation. This might cause some problems by transactions such as disposal, where some corrections have to be made manually after this event.

4.5.4.5 Software programmed controls in Bank Management and Electronic Banking

In Microsoft Dynamics AX, the bank management module is used to create and maintain bank accounts.

Electronic banking in Microsoft Dynamics AX is covered by Electronic vendor and customer payments as part of advanced payment functionalities. Electronic vendor payments are used to electronically and directly pay vendors as a fast and efficient way of handling payments.

Electronic customer payments can be received in a file from the bank when the bank has col-lected payments from the customer.





We have defined the minimum necessary controls in Bank Management and Electronic Banking and tested, whether these controls are in place.

Exporting bank transactions to 3rd party bank applications and creating statistics will not be part of this audit.

Master data settings, Reconciliation of bank accounts

Bank transaction types have to be defined in Dynamics AX to manage transactions such as de-posits, fees, or payments. Groups of transaction types can be created for analysis and reporting. Dynamics AX has an option to create bank groups for banks in which they hold more than one bank account. The bank account window holds all the information about each of the company’s bank accounts including transactions and current balance.

We have created a new bank account and tested the settings. Furthermore we reviewed the as-signment of Bank management transactions to General ledger accounts.

We have also reviewed the functionality of reconciliation of the bank accounts.

Results:

The mandatory fields are effective and creating a new bank account is possible. Microsoft Dy-namics AX does not allow the user to create bank accounts that already exist. It also ensures that only bank accounts which do not have any transactions can be deleted.

The reconciliation of bank accounts is working accurately.

Settings of electronic banking

Within the scope of this audit we could only review the settings of the electronic payments for vendors and customers. We were not able to test the functionality of the electronic transactions as we did not have an environment with interface to a bank and/or the necessary 3rd party tools.

We have reviewed Electronic vendor payment settings and tried to generate an Electronic ven-dor payment. We have tried to create an exchange file with all the payments details to be ex-changed with the bank to process the payment

Results:

Microsoft Dynamics AX provides the ability to exchange payment data with banks. The soft-ware has file formats for various countries pre-set up. We could create an electronic vendor payment. However, we could not pull out the exchange file to transfer to the bank.

Conclusion:

Based on our audit, no issues have been noted.





4.5.4.6 Software programmed controls of Multicurrency functionality

Multicurrency handling

Microsoft Dynamics AX offers the functionality with multicurrency handling such as recording transactions in various currencies and the ability to report in parallel currencies.

In scope of the multicurrency functionality, we have recorded transactions in various currencies. We have checked whether the software rounds correctly and handles cent differences resulting from rounding when dealing with foreign currencies. We carried out exchange rate adjustments in General ledger and reviewed the availability to track profits and losses caused by exchange rate fluctuations.

Results:

With Microsoft Dynamics AX it is possible to set up a company currency and its corresponding rate. The software handles rounding differences and is able to run exchange rate adjustments in General ledger, Accounts payables and receivables in a correctly and accurately.

Reporting Abilities

Microsoft Dynamics AX automatically converts all transcation into a secondary currency. We have tested the ability to report in parallel currencies to fulfill reporting purposes.

We have also tested the exchange adjustment simulation to show the overall effect of exchange adjustments before running exchange rate adjustments.

Results:

Microsoft Dynamics AX is able to handle exchange rate adjustments. There is a function in place which supports the user in making the necessary adjustments for previous periods.

Conclusion:


4.5.4.7 Software programmed controls in Cost Accounting

Cost Accounting in Dynamics AX is integrated into other modules through cost transactions and service transactions. Cost transactions created in the General ledger module are automatically created in Cost Accounting Module. Service transactions booked in Production and Project modules are automatically created in the Cost Accounting Module. As Production and Project modules are not within our scope, we could test the functionality of service transactions only limited.





Controls around cost categories:

Cost categories are usually equivalent to ledger accounts in Dynamics AX. However, it is also possible to set up different cost categories. Cost amounts are posted to cost categories either through General ledger postings or through posting entries created in the Cost accounting mod-ule.

Results:

Cost categories created in the Cost Accounting module should not have a connection to a Gen-eral ledger account. We have created cost categories in the Cost accounting module and noted that they can not be used as General ledger accounts.

The automatically creation of ledger accounts in the cost category form is possible.

It is not allowed to create duplicate cost category records in the master files

Controls around dimensions:

Dimension in Dynamics AX are used to analyze and classify the financial transactions. There are 3 dimensions in Cost Accounting: Department, cost center and purpose. Additional dimen-sions can be created for cost accounting purposes.

Results:

Duplicate dimensions are prevented from being added to the master files

Dimensions can be closed if they are not going be used.

Dimensions can be blocked for cost transactions, service transactions, distribution and alloca-tion.

Controls around journals:

Journals have the same functionality as in General ledger. They can be used as templates for creating cost and service transactions.

Results:

Dimensions that are used in the journals can be selected in the journal settings. We have tested, whether it is possible to post a transaction other than the defined dimension settings in the jour-nal. No issues noted.

It is possible to have an approval of each journal before this journal is posted.





Creating cost transactions and service transactions:

Journal templates are used for posting the transactions in the Cost Accounting. The method that is used to create cost transactions in Cost Accounting is the same method as creating transac-tions in General ledger. .

Results:

We have created a cost transaction and noted that the amount posted has been recorded correctly on the selected cost category and dimension.

We have created a service transaction and noted that the quantity posted has been recorded cor-rectly on the selected dimension.

Create a cost distribution/ service distribution

There are seven types of calculation methods (Fixed percentage, Cost category, Service cate-gory, Cost line, Reference table, Reference specification, Fixed amount). There are reference tables used to determine fixed debit amounts used for the calculations of distributions and allo-cations. For example, building costs are allocated from a cost center Building to other cost cen-ters by the square footage the cost centers are using. These values are entered by using the refer-ence table.

All these settings are used in the calculation version, which validates and summarizes all calcu-lations for a certain period.

The costs that are posted in Dynamics AX can be distributed:

• with or without dimension

• to other dimensions, or

• on the same cost category

Service distribution functionality works basically same as cost distribution. This functionality is used to distribute services (quantities) that are posted in Dynamics AX.

Results:

We have created a cost distribution and noted that the calculation and the distribution were cor-rect and accurate.





Create an allocation

Allocations are used to allocate costs that are posted with dimension to other dimensions and on another cost category.

Three types of allocation are supported in Dynamics AX:

• Allocation: Used for allocation of cost amounts posted to one dimension and must to be allocated to other dimensions as secondary costs.

• Internal cost allocation: Used to allocate service quantities as cost amounts. The quan-tities are multiplied with a cost rate and posted on a secondary cost category.

• Surcharge Calculation: Used to allocate a multiple of an allocation reference to another dimension and credits the allocation reference with this amount using secondary cost categories.

Results:

We have created a cost distribution and noted that the calculation and the distribution were cor-rect and accurate.

Conclusion:


4.5.4.8 Software programmed controls in Inter-Company Accounting and Multi-ple-Company Consolidation

Review of the settings for the inter-company transactions:

Necessary settings have to be completed to be able to post inter-company transactions:

• Necessary Accounts in the Chart of Accounts have to be created • Journal names have to be set up • Posting relationships between the companies have to be set up

Results:

We were able to create inter-company accounts in the Chart of Accounts, set the intercompany journal and define the relationship between the inter-company accounts as debit and credit ac-counts.





Inter-company Transactions and Tracing the inter-company records

Based on the settings above, we have created and posted inter-company transactions in Dynam-ics AX and tried to trace the postings.

Results:

With inter-company accounting a single entry can be made which posts to multiple companies. Postings made to multiple companies can be traced through the transactions of related accounts. There are no specific reports for inter-company transactions.

Review of the settings in the consolidation:

Necessary settings such as settings of a consolidation company, subsidiary company, charts of accounts, currency and exchange rates have to be completed to be able to perform consolida-tions within Dynamics AX.

Results:

We were able to set up a consolidation company, subsidiary company and chart of accounts.

Performing the consolidations

There are two options for the consolidation in Dynamics AX:

• From the same database using the online option • From and/or to another database using the import/export option

If a subsidiary’s books are not kept in the same currency as the consolidated company, the books are re-measured into the functional currency before translation.

There are three conversion methods that can be set up in chart of accounts:

• Average (The subsidiary amounts are converted by the exchange rate that is entered for each foreign currency in the Average Rate field of the Exchange Rates Form.)

• Closing (The subsidiary amounts are converted by the exchange rate that is entered for each foreign currency in the Closing Rate field of the Exchange Rates Form. The clos-ing rate is the rate that applies to the last date in the period.)

• Historical (The subsidiary amounts are converted by the historical exchange rate for the foreign currency as defined for periods of the year by the From date field of the ex-change rates form).

Results:

We were able to run the consolidation based on the settings of the test system. After performing the consolidation, we were able to review the entries that were created.





Conclusion:

Inter-company and consolidation capabilities of Dynamics AX enable businesses with several subsidiaries or distribution centers to set up inter-company journals in which transactions posted by one subsidiary are automatically updated in designated accounts of the other subsidiary or distribution center. Accounts in a foreign currency can be consolidated at special consolidation exchange rates. However, the software does not support the equity consolidation. It also does not support the elimination of inter-company transactions and elimination of inter-company profit and losses during the consolidation.

4.5.4.9 Software programmed controls of Cash Flow Forecasting functionality

Cash flow forecasting is used to estimate the company’s future need for cash. There are 5 areas in Microsoft Dynamics AX, where cash flow forecasts can be viewed:

• Accounts receivable (Sales order) • Accounts payable (Purchase order) • General ledger (Chart of accounts) • General ledger (Ledger budget) • Inventory management

The ability to accurately forecast cash flows depends on projections of future cash receipts and disbursement. In order to review the cash flow forecasting functionality of Microsoft Dynamics AX several settings across the modules have to be completed.

Results:

During a live meeting with Microsoft Business Solutions team in USA, we have observed all the necessary settings for the cash flow forecast. We have also observed that the cash flow fore-cast is calculated correctly and reports related to future cash flows are complete and accurate.

Conclusion:






4.5.4.10 Software programmed controls in Inventory Costing

The accounting method that a company decides to use to determine the costs of inventory can directly impact the balance sheet, income statement and statement of cash flow. Therefore, inventory valuation can have a big effect on the financial statements.

We have reviewed the inventory costing methods that are supported by Dynamics AX and tested whether the necessary controls are in place.

Results:

To create a new item in inventory management in Dynamics AX, following settings have to be specified in the system:

• Item number

• Item group

• Item type

• Inventory Model group

• Dimension group

Item groups play a very important role in Dynamics AX. They can be posted to different Gen-eral ledger accounts, they can be used for retrieving sales and purchase data on groups of prod-ucts and they can be used to report detailed financial information.

Inventory Model groups are an important part of calculating inventory values and how the item is posted to the General ledger. There are 5 inventory models to be selected in Dynamics AX:

FIFO, LIFO, LIFO date, Weighted average, Weighted average date.

It can be determined in Dynamics AX, whether the inventory transactions are to be posted to the General ledger physically or financially by selecting the necessary parameters in the settings.

Conclusion:

Dynamics AX supports the FIFO, LIFO and weighted average valuation. Standard costing is implemented in the system and reconciliation between actual and standard cost is possible.

4.6 US-GAAP Compliance The scope of the review of the US-GAAP Compliance of Microsoft Dynamics AX 4.0 is limited on the principal sources of generally accepted accounting principles in the United States and does not comprise the SEC regulations. The principal sources are Statements of Financial Ac-counting Standards issued by the Financial Accounting Standards Board together with Account-ing Research Bulletins and Accounting Principles Board Opinions.

There are still significant differences existing between the accounting principles of US-GAAP and IFRS. Many of those differences consist of differing methods and principles in the recogni-tion and measurement of assets and liabilities, in the recognition of revenues or in disclosure





requirements. Only a few of those differences have impact on the Microsoft Dynamics AX 4.0 system in general.

With regard to this review of Microsoft Dynamics AX 4.0, we could not identify any significant system specification differences between US-GAAP and IFRS except inventories.

Inventory valuation at historical cost is the same under US GAAP as under IFRS. Therefore, the requirements of the system are the same as under IFRS. US GAAP additionally allows the cost-ing method of last-in, first-out (LIFO). LIFO accounting generally requires computations re-garding historical cost layers to be made outside of the accounting system. Microsoft Dynamics AX 4.0 supports LIFO inventory valuation.

Both US GAAP and IFRS require inventory amounts to be recorded at the “lower of cost or market”. However, unlike IFRS “market” under US GAAP takes into consideration replacement values. “Market” is initially determined to be replacement value, but is then subject to a ceiling and floor test.

1 If replacement cost is higher than net realizable value (the “ceiling”), then the ceiling is tak-en to be “market”.

2 If replacement cost is lower than net realizable value less a normal gross profit margin (the “floor”), then the floor is taken to be market.

3 If the replacement cost falls between the ceiling and the floor, the replacement cost is taken without adjustment for the lower of cost or market test

Microsoft Dynamics AX 4.0 provides support for lower of cost or market adjustment relating to purchased merchandise, since the required values can be entered into the system. It does not support lower of cost or market adjustments for finished and partially finished products, for the reasons explained under Section 4.3.3 – “Inventories”. Nor does Microsoft Dynamics AX 4.0 provide support for lower of cost or market adjustments relating to raw materials. To automate this would require selling prices to in the system for raw materials. Such selling prices do not exist, as raw material is either included in the manufactured products or consumed in the manu-facturing process. Therefore, write-downs of raw material are normally based on subjective or alternative methods, when write-downs of finished products indicate that other components may be overvalued.

Reversal of write-downs is prohibited. Microsoft Dynamics AX 4.0 supports this accounting by replacing original cost with lower amount resulting from the lower of cost or market test. This prevents amounts from being subsequently adjusted to higher amounts than the written-down values.





4.7 Processing functions supporting compliance with Sarbanes-Oxley Act (SOX)

Sarbanes-Oxley establishes new or enhanced standards for corporate accountability. Sections 404 and 409 of SOX require the company to establish and maintain internal controls and have the ability to report these controls real time.

Well designed, well-implemented and well-maintained IT solutions can deliver critical compo-nents of effective internal controls. However, the companies have to be aware that implement-ing SOX compliant software does not fulfill all the requirements of SOX for an organization.

4.7.1 Section 404 Requirements

Section 404 of the Sarbanes Oxley Act is concerned with the general controls that maintain the integrity of processing and reporting of financial data. Any process or system that could influ-ence the integrity of transaction processing or data must be examined, and controls must be in place to ensure overall process and system integrity.

Within the scope of our audit of Dynamics AX in compliance with SOS 404, we have included the following controls that contribute to a company’s ability to produce accurate, reliable finan-cial statements:

• Logical Access Controls in Dynamics AX including segregation of duties

• Access restriction to the software including logging of user access, logging of access viola-tions and password conventions,

• Backup and Recovery Data

• Ability to create quarterly financial statement

Access restriction, backup and recovery data have already been covered under the section 4.3 “Software security”.

The ability to create quarterly financial statements is covered under IAS 34 Interim Financial Reporting.

Logical access controls are analyzed below based on two control objectives:

Management's assessment of logical access controls

Operating effectiveness of controls regarding logical access controls

In order to ensure that management can assess logical access controls in Dynamics AX report-ing tools regarding the implemented logical access controls must be available.





In order to ensure operating effectiveness of logical access controls it has to be possible to im-plement segregation of duties with regards to functionalities and reports in Dynamics AX. The software should also be able to require a login via User ID/passwords from the users.

The user management for general access to Microsoft Dynamics AX 4.0 is based on Microsoft Active Directory which is a constitutional part of Microsoft Windows Server 2003 and not part of Dynamics AX 4.0. The benefit for the customer is the Single-Sign On functionality, i.e. log-ging into the operating system grants automatically general access to Dynamics AX 4.0. How-ever, the user management in terms of specific functional assignments and user rights manage-ment are handled by Dynamics AX 4.0 itself.

Our audit has covered following areas:

Defining logical access controls including tests of segregation of duties

Reporting (documentation) the setup of logical access controls to make access controls au-ditable

Password Conventions as part of the functionality of Microsoft Active Directory are not in the scope of our audit.

Our audit did not cover the database security as Dynamics AX can work on different databases and no database-related issues are in the scope of our audit.

User Administration and Segregation of Duties

In the Administration menu it is possible to define access rights in Dynamics AX. This is han-dled by creating roles (user group). User groups can be created, named or deleted. For each role a set of permissions must be defined. It is possible to define access rights within each main functionality in Dynamics AX. As an example it is possible to make a role giving access rights only to the vendors within Accounts payable. Defining this role makes it possible to implement segregation of duties as a role giving access to the vendor's bank account information but not access to post entries can be created.

There are the following possibilities when setting access rights to a functionality: No access, View, Edit, Create and Full control.

When the roles have been created, users can be removed and added to the roles making it possi-ble to define any kind of access rights for a specific user or a group of users having the same actual needs for access in Dynamics AX.

It is possible to disable users so that the user is not allowed to access the system any more.





Documentation of logical access rights

A list of users can be retrieved in Dynamics AX showing when the user was logged in. It is pos-sible to retrieve a list of users (enabled and disabled). The software can also provide the user administrator with a list of actual access granted for each user.

Results:

Dynamics AX provides the possibility of implementing concepts regarding segregation of du-ties. Each company in accordance with their own requirements towards logical access controls must define their specific access rights as Dynamics AX is not delivered with any standard roles.

Conclusion

Based on our audit of software security and tests of the functions and logic of the financial ap-plications that feed information into financial reports no issues have been noted.

4.7.2 Section 409 Requirements Section 409 of the Sarbanes Oxley Act says that “Each issuer reporting under section 13(a) or 15(d) shall disclose to the public on a rapid and current basis such additional information con-cerning material changes in the financial condition or operations of the issuer, in plain English, which may include trend and qualitative information and graphic presentations, as the Commis-sion determines, by rule, is necessary or useful for the protection of investors and in the public interest”

The resulting compliance requirement is that businesses must be able to make real-time assess-ments of their financial situation and report the material changes to the SEC within four busi-ness days in an 8K report if there are issues impacting and/or impairing the quality of an asset such as A/R (Accounts receivable).

It should be noted that implementing SOX 409 compliant software does not fulfill all the re-quirements of this section for an organization. There are many other factors beside technology that would affect the requirements of SOX 409, e.g.:

• The organizations should have a process in place (containing automated and manual controls) for identifying accounts or customer segments that show material changes.

• Identify these changes quickly.

• Adapt their policy to changes or shifts in risk.

• Report material changes to SEC within four business days.

• Etc.





Within the scope of the software audit, we have tested the following functionalities of Dynamics AX related to section 409 of the Sarbanes Oxley Act:

• Is the reporting system directly linked with accounting system to show automatically and immediately any material financial events?

• Does Dynamics AX easily provide visibility across all trusted data sources in the or-ganization?

• Does the solution integrate with existing security protocols to ensure that critical infor-mation is available to, and only to, those individuals who are supposed to see it?

• Does the solution allow you to access key supplier information and other relevant data sources to understand issues that may directly or indirectly affect your financial per-formance?

• Is the solution easily modifiable to respond to changes in the organization’s reporting structure?

Conclusion:

The changes of material financial events in Dynamics AX are directly linked to financial report-ing system. If a material financial event occurs and it is captured in the system, the information will be reflected in the financial reporting system.





5 Final Conclusion

Providing they are used correctly, the modules Financial Management I, Financial Man-agement II and Inventory costing of the software product Dynamics AX Version 4.0 as-sessed by us perform their functions correctly and allow a data processing for the pur-pose of financial reporting in accordance with IFRS, US-GAAP and the Sarbanes-Oxley Act requirements applicable as of 11/17/2006

Carsten Müller Partner

ppa. Thorsten Scharpenberg Manager

review of microsoft dynamics ax 4 0 final version · pdf filemicrosoft dynamics ax 4.0 offers...

Documents