reporting as people do not have to look through an enormous number of transactions. For instance, at the end of the month, a financial accountant consolidates all the paid vouchers by running a report on the system. The system's application layer provides a report with the total amount paid to its vendors for that particular month. With large corporations that generate large volumes of transactional data, running reports with even an AIS can take days or even weeks. After the wave of corporate scandals from large companies such as Tyco International, Enron and WorldCom, major emphasis was put on enforcing public companies to implement strong internal controls into their transaction-based systems. This was made into law with the passage of the Sarbanes–Oxley Act of 2002 which stipulated that companies must generate an internal control report stating who is responsible for an organization's internal control structure and outlines the overall effectiveness of these controls. Since most of these scandals were rooted in the companies' accounting practices, much of the emphasis of Sarbanes Oxley was put on computer-based accounting information systems. Today, AIS vendors tout their governance, risk management, and compliance features to ensure business processes are robust and protected and the organization's assets (including data) are secured. Implementation Many large and SMEs are now adopting cost effective cloud-based accounting information system in recent years. However the majority of existing automated accounting systems use typical databases (DBF, MS SQL, MS ACCESS etc.). In 2020 accounting software used 94% of pollees. Looking back years ago, most organizations, even larger ones, hire outside consultants, either from the software publisher or consultants who understand the organization and who work to help select and implement the ideal configuration, taking all components into consideration. The steps to implement an accounting information system are as follows: Detailed Requirements Analysis where all individuals involved in the system are interviewed. The current system is thoroughly understood, including problems, and complete documentation of the system—transactions, reports, and questions that need to be answered—are gathered. User needs that are not in the current system are outlined and documented. Users include everyone, from top management to data entry. The requirements analysis not only provides the developer with the specific needs, it also helps users accept the change. Users who have the opportunity to ask questions and provide input are much more confident and receptive of the change, than those who sit back and