‘Accounting Structure’ is considered as the foundation of an ERP system. Analysis of the current system, along with the needs and objectives of the future ERP system must be conducted in detail to design an effective accounting structure. Many ERP projects have failed due to improper and poor design. Early identification of incorrect design helps to review and come up with the revised version which better suits the organization needs.
Many projects realize about the improper design of ‘Accounting Structure’ during the later stages of projects in UAT (User Acceptance Test) or sometimes long after its implementation, which results in re-implementation of the project leading to wastage of vast amount of money and resources.
Incorrect design of ‘Accounting Structure’ will lead to:
- Inability to capture required data into the system.
- Inability to generate the required reporting from the system.
- Inability to meet the project objectives and goals.
To design a robust and optimum accounting structure for an ERP, we need to consider the below mentioned points in detail.
1. Current System Analysis
Current ERP system analysis is required to understand the below.
- Current pain points which need to be addressed by the proposed new system.
- Current process lacuna which requires process improvement and change management.
2. Reporting Requirements
The below reporting requirements need to be analyzed in detail.
Management Reporting
The level at which organization is generating the Trial Balance, Balance Sheet and Profit & Loss account and the level at which profitability and costs are measured should be analyzed in detail. This can be either be done at a company level or product/service level or location level or any other level based on an organization’s structure and needs.
Statutory Reporting
Statutory reporting needs must be analyzed in detail to understand current reporting requirements, manual efforts spent in making the reports audit-ready and country-specific compliance reporting needs.
IFRS/ Multi GAAP Reporting
Organizations that are required to comply with IFRS/GAAP reporting must generate an additional set of reporting. The proposed accounting structure should ensure that required reporting can be generated to facilitate ease of compliance.
3. Industry Specific Needs:
Inputs can be obtained from industry specific subject matter experts to understand the unique requirements. Whereas, industry specific needs must be addressed as part of the ‘Accounting Structure’ which can include, reporting/operational/compliance related requirements. We also need to understand how these requirements are managed by other companies belonging to similar industry within their ERP system.
4. Data Security and Operations
- Data security and operation requirements should be analyzed in detail and aligned with the proposed accounting structure.
- If an organization has multiple divisions and each division is independent in procuring and selling and managing their sub ledger operations, such divisions should be designed as a separate ‘Operating/Business Unit’ to facilitate independent security requirements of the division.
5. Segment Structure
Segment structure involves the following:
Ease of Use and Future Growth
Optimum number of segments should be devised to ensure ease of use and facilitate future roadmap of the organizational growth. Designing too many segments may cause difficulties during data entry. Also, if a user selects incorrect values, it may lead to incorrect reporting. Standard features like ‘Account Alias’ should be leveraged to facilitate the users with the ease of data entry or automatic selection of segment values during transaction processing.
In case, multiple company scenarios are operating in multiple countries with multiple businesses involving Holding & Subsidiary accounting, Global ‘Accounting Structure’ should be designed after considering all important factors to facilitate easy and quick reporting of standalone and consolidated financial results.
Sub Systems/Core Applications Data
One of the objectives of any ERP system is to facilitate effective and robust reporting. Data from sub systems or business transactions from core application needs to be interfaced with ‘General Ledger’. It would allow to generate complete reporting and financial statements from the GL. Core application data and transaction needs should be analysed in detail to ensure that all required business dimensions are a part of ‘Accounting Structure’.
Example: It can be a decision point to enable a line of business segment/product segment/branch segment/market segment.
Intercompany Requirements
If the organization is having multiple companies and subsidiaries resulting in large number of intercompany transactions, we should design ‘Inter Company’ as one of the segments to facilitate the tracking and reporting of intercompany balances in General Ledger.
Project Requirements
If the organization is engaged in executing projects and measuring costs and profitability by customer projects, a thoughtful approach needs to be followed to decide whether the ‘Project’ should be a part of an accounting structure or taken care through sub ledger modules like project costing/billing, etc.
Ideally, project-based organizations should leverage project costing modules to define and manage project structure and facilitate cost capture against a specific project across modules. Project billing module should be used for capturing project milestones and enabling customer billing. Budget feature in project module can be used to define and track budgets VS. actuals for project costs and revenue to facilitate reporting and analysis.
In addition to above, if the ‘Project’ segment is also enabled as a part of accounting structure in GL, it will lead to:
- Data redundancy and data duplication as details are already being captured and tracked in project module.
- Additional efforts to reconcile project accounts (cost and revenue accounts) in GL and increased reconciliation issues.
- Increased activity in GL regarding the maintenance of security rules, cross validation rules, hierarchy values for project segment.
Department/Sub Department:
In case of a large manufacturing organization, where costs are tracked and monitored against respective departments (cost center) and sub departments, a detailed analysis of department-wise costs and its impact on total overheads of the organization is important.
Example: In the below table, costs are tracked at sub department level by having ‘Sub Department’ segment as a part of ‘Accounting Structure’.
| No | Department | Sub Department |
| 1 | Purchasing | * Local-Pur * Export-Pur * Import-Pur |
| 2 | Marketing | * Product Development * Social Media * CRM |
| 3 | Finance & Accounts | * Treasury * Accounts * Internal Audit |
Future Segment:
It is always better to enable a provision for at least one ‘Future’ segment. It would help to cater foreseeable/unforeseeable business changes or expansions to facilitate future requirements of data capturing and reporting on additional dimension. Thus ‘Future’ segment can be used at any point of time after implementation based on business demands and needs.
6. Stakeholders Buy-in
Implementation partners need to have thoughtful meetings, firefighting sessions, and workshops with client stakeholders and implementation team to obtain the Buy-in on the proposed accounting structure. This will help to incorporate changes on the feedback received to reflect project objectives and goals.
Conclusion:
Implementation partners can consider the above major factors in detail while designing the ‘Accounting Structure’ for any ERP implementation project. The above list of points is not exhaustive but covers the majority of the points/scenarios. There can be an additional list of points which should be considered based on the client’s industry, ground reality, project circumstances or any other relevant factors. Accounting Structure should be validated during the early stages of the Project Envision Phase (Requirement gathering & Solution design) or CRP (Conference Room Pilot) to ensure that the proposed accounting structure meets the objectives and goals set forth.
Author
 |
Praveen Thiruveedhi comes with 16+ years of experience and works with Evoke Technologies as a Solution Consultant for Oracle Practice. He’s proficient in Oracle ERP involving implementations, upgrades, business process transformation, and project management activities across various industries. |
