The name AB-Compliance along with the “bee” logo and the word “AnyBank” are Trade and Service marks of Sastra Technologies Private Limited, Chennai, India.

This book is aimed at auditors who are engaged in statutory or internal audits for companies and institutions. The goal of this book is to introduce auditors to conduct their audit exercise in a manner such that the clients have a visibility in the progress of the audit.

The application also allows auditors to use the features of a word processor in conjunction with a database by maintaining a track of the version of the financial statements during the course of the audit.

Auditors can also reuse templates across their clients or create import financial statement templates. This allows auditors and their staff in saving a tremendous amount of audit hours.   

This book is organized in a way so as to help auditors to focus on their audits rather than on the underlying technology. Each of the chapters focus on the workflows that is provided by the application.  

AB-Compliance is part of the AB-Suite of products that helps an Auditor to generate the financial statements required for a company to comply with the annual regulatory reporting. AB-Compliance takes the trial balance as the input and generates the following regulatory financial statements:

• Balance Sheet
• Income Statement / Profit and Loss Account
• Directors Report
• Management Report
• Chairperson Statement
• Internal Auditor’s Report
• Statement of Financial Position
• Statement of Profit and Loss
• Changes in Member’s equity
• Statement of Cash Flows
• Notes to Financial Statement

AB-Compliance ships with a set of templates for each of these financial statements so that auditors can start off the audit process the moment the application is available to them. Additional templates can be created by the auditors at the global level or be purchased. Auditors can have separate templates for each client and can use these for a specific audit. Templates can be modified for an audit or for a client.

Financial Statements can be generated at each stage of the audit and cheeked, corrections can be made to the trial balance by passing journal vouchers, changes can be made to the  explanatory statements of the reports before the a final version of the statement can be generated in a PDF or Rich Text Format (compatible with most word processing software) format.

Using AB-Compliance to generate financial statements offers auditors and their client several benefits like -

• The ability to cope up with frequent changes in financial regulations by governments
• The ability to make make minor modifications to financial statements due to notifications on existing existing regulations 
• No overhead in deploying the AB-Compliance as its available as a service (unless you have opted to have it installed in-house)
• Capability to handle most time of financial statements with reasonable limits on payload of content that can be transmitted over the network.

AB-Compliance was aimed at automating the tasks of conducting the audit and it excels in this task by defining formal workflows for the audit process. It comes with a rich set of templates for Financial statements that have to be modified before being used as part of an audit.

AB-Compliance is agnostic to any financial standards and is capable of generating reports that comply with several domestic and international standards like IAS-18 etc. All that needs to be done is to use the appropriate template.

AB-Compliance can also be used as a reporting engine for other applications, infact the other Application components in the AB suite use Ab-Compliance as a reporting engine to generate several print, email and messages. It can also used to generate dunning letters.. Here is a sample list of templates that can be configured in AB-Compliance  :

• Welcome Letters 
• Installment due Letters
• Foreclosure Letters
• Dunning Letters 

To use AB-Compliance other than for conducting audits and generating financial statements requires  access to the underlying API. This is because the AB Platform is completely skinnable and Custom User Interfaces have to be built for rendering these letter formats based on data passed from the other business application. The access to the underlying API is priced separately. 

AB-Compliance is primarily targeted at statutory auditors to conduct statutory audits where each step of the audit is recorded so that decisions at each stage of the audit can be revisited. However AB-Compliance can also be used for generating other pre-formated reports. 

AB-Compliance is not an accounting application. Though AB-Compliance allows auditors to pass Journal Vouchers to check the effect on the trial balance the actual JV should be passed in the client’s accounting application before the accounts are closed for the Financial Year.

Before we embark on setting up Ab-Compliance we need to assimilate the data that is needed to set-up the application. Information on the following stakeholders is required

• Partners
• Audit-Incharge
• Signatories
• Clients
• Client Executives

The sections below explain the data required for each of these stakeholders.

People part of the organization conducting the audit and who require access to the AB-Compliance application should be listed down and flagged whether they are Partners and/or Audit-Incharge and/or Signatory. The following data is required  by the application. Use the format of the table below in a spreadsheet to collect the information

The Email Id and mobile Number are required for the People to receive notifications from the application as the audit moves ahead through various stages.

When creating members, some of them can be provided with higher entitlements to ensure that the audit progresses in a supervised environment. These memebrs can be allowed to

• Set up the audit parameters
• Open/Close an audit

Clients are entities whose financials will be audited. The following details are required to set up the clients on the application. Use the format of the table below in a spreadsheet to collect the information.

The Board of Directors and Management Team are key executives of the Client and these have to be setup in the application. Use the format of the table below in a spreadsheet to collect the information

AB-Compliance can be deployed on the Cloud (recommended) or in-premise. This chapter explains the preparation and infrastructure for in-premise deployments. AB-Compliance has three components that make up the application

1. The User Interface that users will use to interact with the application using their browsers
2. The processing engine where business rules are located and all functional processing takes place
3. The Database that stores the data 

Users provide the data using the User Interface by invoking a URL (a web address) on their browsers which then gets processed by the processing engine and gets stored in the database. Infrastructure has to be provided for each of these three components.

In the simplest form of deployment all these three components can reside on a single server. But we suggest that the deployment be based on the volumes of anticipated transactions. The deployment options available are given below along with their advantages and disadvantages

AB-Compliance can be deployed either on a Cloud Infrastructure or In-premise. We recommend a Cloud Deployment as the complexity of managing the technology infrastructure is handled by competent technical staff at the datacenters. Cloud infrastructure also provide unlimited scaling features and allow client to increase or decrease the processing infrastructure. Ab-Compliance can work on the following cloud Infrastructure

• Amazon Web Services
• Azure
• Digital Ocean
• E2E Networks
• Google Compute Platform

Unless otherwise the latency between the server and clients are huge we do not recommend an in-premise deployment.

AB-Compliance can also be purchased as a appliance from our Hardware partners. Please get in touch with Sales for details on the appliance.

If the choice to deploy AB-Compliance is in-premise as opposed to on the cloud then we have to make a choice whether to deploy it on a Baremetal server or a Virtual Private Server (VPS). In this case our recommendation is to go in for a Bare Metal Server as it does not involve the additional complexities of managing the virtualization layer that is inherent in a VPS.

Setting up AB-Compliance on a VPS is relatively easy. It can be set up on Amazon Web Services, Google Compute Platform and Digital Ocean. Though the method to set up the VPS is slightly different on each of these vendors in effect it involves the following steps

• Spinning a VPS and obtaining the system generated Password or use the SSH keys
• Changing the host name
• Setting up the appropriate timezone
• Creating Users on the Operating System
• Installing the required infrastructure
• Deploying the applications

AB Compliance uses Terraform and Ansible to deploy the application on remote Virtual machines. We suggest that you use a configuration management tool to deploy the application in premise.

Firewalls block most operating system ports unless explicitly opened and configured. There are router firewalls and operating system firewalls. The following ports are required to be opened.

The recommended operating system to run AB-Compliance is Ubuntu. We suggest that a LTS or Long Term Edition be used. Choose the recent most LTS edition. As the time of writing this book it was Ubuntu 20.04.

AB-Compliance can also run on Centos, Debian and Red-Hat but has to be thoroughly tested for package support from the developers of databases and webservers. 

AB-Compliance can run on proprietary operating systems but users are likely to encounter performance bottlenecks due to the Operating System architecture. 

AB-Compliance supports MariaDB, MySQL and Percona databases as of writing this book. AB-Compliance can also run on Postgres and Oracle but the compatibility is being tested and will be released at a future date.

Ab-Compliance requires PHP 7.4 or above. It also requires Symfony components. AB-Compliance may not work correctly on PHP versions prior to 7.x and also PHP version 8.x. We recommend that PHP be installed a s a Fast-CGI interface.

AB-Compliance runs best when Nginx is used. Its faster compared to other webservers and handles a large number of concurrent connections. We recommend that Nginx connects to PHP-fCGI on port 9000. Though Nginx can also connect to the PHP-fCGI using sockets our best results have been obtained using the port connectivity.

In addition to the usual settings recommended by the installation notes of PHP and Nginx , AB-Compliance requires special settings to handle the large number of pages in the financial statements. 

On Nginx : client_max_body_size and client_body_timeout

On PHP : Upload_max_filesize, and post_max_size

On high traffic environments Ab-Compliance uses Redis and Memcached to cache OpCode to ensure that the responses are within a few seconds. Users should not attempt this as this requires advance technical caliber to install and use caching mechanisms for Opcode. 

AB-Compliance is relatively easy to implement within the organization. Every digitization project involves a core implementation team to hand-hold users during implementation and to ensure that they are provided training. It is important that the implementation team is drawn from within the organization and not from sub-contracted staff or external vendors who offer staff augmentation.

The team in charge of implementing Ab-Compliance within the organization should prepare a schedule of implementation activities. The AB site provides sample implementation templates that can be used by the implementation team as a starting point for their projects. These templates are available in Project Libre format and hence can be edited in several operating systems.

See previous sections on the method to identify the stakeholders

We suggest that the AB-Compliance application be implemented in workflow wise for each client. It is better to start with a client implement it and then move on to the next client.

If we have the data on the users, clients and key executives we can set up the AB-Compliance. If we do not have them ready then it is time to collate them. 

We recommend that users be set-up with a Single Sign-On (SSO) capabilities. With SSO users will need to login-in once to gain access to AB-Compliance and any other products that are part of the AB-Suite without having to login once again.

Ab-Compliance ships with a set of templates for each financial statement. You could copy them to a client and modify them to suit a specific audit. Additional templates can be purchased from us.

Clients have to be set up so that the audit exercise can be initiated. Ab-Compliance is always set-up for a specific country due to the variations in regulations between different countries. Do not attempt to combine clients located in different countries within the same installation.

AB-Compliance ships with a standard templates one for each type of financial statement.  Implementation teams should ensure that these statements are copied for each client and modified so that they can be used by the audit teams in their audits

Currently AB-Compliance doesn’t allow users to bulk upload their templates because it poses a security risk as malicious code can be uploaded by making it appear as a harmless template.

The templates that ship with the application have placeholders for ledger codes, these have to be changed to contain the ledger codes of the client once the templates are copied.

It is recommended that ledger codes start with alphabets instead of a number. That is for example if a client has several Bank Accounts then it can be codified as B001, B002 or BNK001, BNK002 instead of 001, 002, 003. 

We suggest that the format for trial balance be downloaded and the trial balance be prepared according to this format before being uploaded. This is because AB-Compliance supports upto five levels of sub-ledger and whenever the JV’s are passed they have to be passed at the bottom most level. For example if a client has a several bank accounts and they structure is defined as follows

Conducting an audit is a systematic process and AB-Compliance allows partners and audit incharge to communicate effectively during the audit process. The financial statements can be generated multiple times, corrections made to the financial figures can be made if requierd before a final statement is generated.

Prior to starting an audit the templates should have been copied to a client as explained in the previous chapter. You should also identify the audit incharge who will set up the application for the audit.

Setting up the audit parameters involves choosing the client for whom the audit should be conducted, the Financial Year for which the audit should be conducted (Should have been set up during the application set-up), Flag whether the audit exercise will result in an audited set of Financial Statements or unaudited statements, The number of years of financial statement that should be included (maximum is three, keeping in mind that an A4 size paper can accommodate only as much when printing on a portrait mode). Once these have been done the partner can “Open” the FS preparation activity on the system.

The audit-incharge and the signatories should be identified and specified on the application. AB-Compliance will list all users who have accounts on the application.

The trial balance can be uploaded onto Ab-Compliance. Please ensure that the Trial Balance is proper in all respects. The following list will help in ensuring thet the trial balance can be uploaded without any issues

• Trial Balance should be a CSV file i.e. Comma Separated Value
• Numeric values or ledger names should not contain commas
• Ledger Codes and Names should be alphanumeric and not numeric. If you happen to have numeric ledger codes then precede it by an alphabet in the CSV sheet
• Ensure that the Debit and Credit figures match otherwise the application will reject it when it does its checks. 

At this point the Financial Statements can be generated and the figures verified. They might not be accurate or the way we expect them to reflect the financial figures but then this is the first draft. Going forward the financial statements can be modified and Journal Vouchers can be passed to arrive at the intended output.

Once the statements are generated they are stored in the Database. We can view them and pass the necessary rectification entries to arrive at the final intended output .

Journal Vouchers can be passed to correct ledger figures to arrive at the final intended figure. Journal Vouchers cannot be modified. If an incorrect entry has been passed then a rectification entry should be passed.

Once we finalise the financial statement we can then provide a PDF or wordprocessor copy to the client for their approval. 

Once the financial statements have been accepted by the client the partner of the audit firm can close the financial Statement preparation activity.

AB-Compliance implements some state of the art security features at each stage of the application. These security features are available to protect the application irrespective of the deployment method that is whether it is on the cloud or within the enterprise. 

AB-Compliance uses browser certificates to determine if the user is authorized to use the application. This ensures that access to the application is restricted to a specific device. This prevents people from sharing passwords and effectively solves the age old problem of floating passwords across the organization.

The communication between the browser and server is over HTTPS and hence all requests and responses are encrypted. AB-Compliance by default uses “Lets encrypt” as the certificate authority but partners can choose the certificate authority for their organization. Partners have to procure these certificates and involve additional costs. Deployment will be done by the DevOps team of AB Suite and additional charges may apply.

AB-Compliance implements strict CORS or Cross Origin Resource Sharing protocol that ensures that no unauthorized application can access the process and data. This prevents “Man In the Browser” attacks and CORS attacks on the Cloud.

The AB-Compliance application is a “12 Factor” application that implements the best of micro services and offers Open Banking API’s. It is headless which means that there is a separation between the User Interface and the underlying process and data. If for some reason the server running the user interface is compromised or vandalized the process and data are still safe. It is for this reason that we deploy the User Interface components on a separate server and the process and database on their own separate servers on the cloud. We suggest that enterprises follow this deployment procedure.