Difference between revisions of "Chart of Accounts"

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.
(I_ELEMENTVALUE)
(give big pic from event)
Line 1: Line 1:
 +
[[Image:EventAcct.gif|right]]
 
== Purpose of the Chart of Accounts ==
 
== Purpose of the Chart of Accounts ==
  

Revision as of 17:31, 30 September 2009

EventAcct.gif

Purpose of the Chart of Accounts

Chart of Accounts Design

  • a Chart of Accounts (COA) means literally a list of accounts that are available in the system. Some of these accounts may be postable and others may not - such as summary accounts or those accounts controlled by the system.
  • However, managers think of COAs as more than just a list of accounts. In practise, they think of all of the controlling data structures that (should) reflect the informational needs of the business. These should answer questions like what is the loan default rate on various portfolios of mortgages, how much revenue do we make per kilometre of optical fibre owned/operated, or simply what is our revenue this month/quarter/year from this product, product group business area. Whilst these are all legitimate informational requests, I often find that businesses' financial system are unable to serve quality data to report users.
  • ADempiere users may import their COA using an excel spreadsheet that users may adapt to their own format. This file can then be saved as a comma separated value file or accting.csv and imported into ADempiere.
  • Daniel Tamm has created a nice COA Editor to access that csv file to change or create a new COA without looking at the excel file.
  • The COA follows accounting classifications underlying General Accepted Principles of Accounting (GAAP) in practice throughout the world.

Recommendations and Pitfalls in COA Design

This section is designed to provide assistance with COA design and provide you with a few examples of what to do and what not to do when implementing your chart of accounts.

A chart of accounts is different for every organisation because:

  • in many countries there is no hard and fast rule requiring COAs to be conforming to a specific structure (however there are suggested forms like the EU level 7 schedule of accounts which has been adopted to various degrees of prescription in EU member states)
  • the chart of accounts should reflect the informational needs of the organisation which include the needs of the regulatory environment(s) in which the operation (industries, countries, etc), the needs of the share holders & stakeholders (private, public owned businesses, banks, private equity firms etc) and the needs of management and various other reporting/informational requirements.

It is difficult (if not impossible) to satisfy all of the informational needs with a single dimensional chart of accounts. ADempiere provides the following dimensions which can be 'sliced and diced' in order to meet your reporting requirements:

  • organisation
  • element
  • product
  • business partner
  • sales region
  • activity
  • project
  • campaign

TIP: You should use these for the purpose they are intended rather than trying to recreate dimensions within your account elements. A common mistake is to build your products in to the account elements in order to report revenue / margin by product.

In one case (a Telecoms company), one of their subsidiary businesses had over 130,000 accounts to account for a relatively small part of the business. This is by no means uncommon and I've seen it literately dozens of times. Obviously, as a result of the large number of accounts, there was a large amount of administration around changing an account and new accounts were still being added. A target to aim for in large businesses is around 1000-1400 accounts. This can be difficult when you operate in many countries and use of permissions in the system can be used to control access to posting to account combinations which allows accountants to feel happier about sharing account codes rather than creating specific accounts that belong only to them. (i.e. the people own a slice of the matrix of the code rather than the whole code and this is enforced with user permissions)

TIP: Create a process for adding and re-organising account codes and other organisational dimensions. Find and allocate owners in build them in to the approval process (you can use summary accounts to delegate sub-groups of your structure)

Each country has special requirements imposed by the government and in some cases, reflective of that societies values. For example, when doing some work on a global chart of accounts for a business, the Japanese contingent explained to me that it is polite in Japanese culture when requesting payment from your customer, to provide them with a bank account at the same bank that they use for which they can use to pay you. As Japan has many banks, this requires polite organisations to maintain many bank accounts in order not to offend their business partners. Whilst I accept this is a business need, we do not need to manage these accounts at a management level (whilst I accept they need to be reconciled and accounted for separately). You can gain informational benefits by using sub-accounts to record the myriad of bank accounts. A similar technique can be used to sub-ordinate information about local payroll deductions and other social costs and taxes.

TIP: Use sub accounts to deal with local variations and names whilst preserving your COA structure

Many organisations find themselves in a position where in each new region they have entered, they have allowed the accountant to select an accounting system and get on with it - knowing they will ensure the correct forms are lodged and that the business has complied with the filing requirements. However, with no common strategy defined, it is common to select an accounting system and structure your COA on your local financial and other reporting requirements. Whilst this practise is a fast track route to satisfying the requirements of external users, it does not balance the need for internal users and hence many organisations find themselves in a position where satisfying the internal users for never ending informational requests is time consuming. Whilst the use of a good BI tool and some analysts can mitigate this issue in some businesses, a better solution is to balance the informational needs when designing your COA (and other master data structures)

TIP: Consider designing your COA structure on your Management COA rather than your Financial COA


Summary List of COA

  • Here we lay out the general structure of the COA by displaying only the top level summary elements.
Account Value Account Name Account Type
1 Assets Asset
2 Liabilities Liability
3 Owner's Equity/Net Worth Owner's Equity
4 Sales Revenue
5 Cost of Goods Sold Expense
6 Expenses Expense

Example Charts of Accounts

Standard chart of accounts for UK government entities, funds, public corporations and reporting funds

http://www.wga.gov.uk/documents/SCOA_changes_2005-06_2006-07.xls

http://www.hm-treasury.gov.uk/d/wga_200809_appendix_4_list_of_scoas_and_changes.xls

Field Descriptions

I_ELEMENTVALUE

The fields below are from the I_ElementValue table. I_* tables provide a 'staging area' for importing data before this data is tested against business rules and if found to be conforming to these rules, is imported in to the C_ElementValue table. These tables describe 'element values' which might otherwise be described as the members of the element dimension - and most notably the Accounts dimension known to accountants as the chart of accounts.

Column Description
i_elementvalue_id ID for import processing
ad_client_id Client ID
ad_org_id Organisation ID
isactive Is Active flag
createdby Adempiere core field
created Adempiere core field
updated Adempiere core field
updatedby Adempiere core field
i_isimported Flag for import processing
i_errormsg Error message if import failed
c_element_id Element ID - see c_element
elementname Element Name
c_elementvalue_id Internal Element ID
value Account "Natural" code
name Account Name
description Account description
accounttype Account classification - A = Asset, L = Liability, E = Expense, R = Revenue, O = Owners Equity, M = Memorandum
accountsign Indicates the Natural Sign of the Account as a Debit or Credit
isdoccontrolled If the account is document controlled, users are unable to post directly to the account (you must post documents and they post to the account)
issummary If the account is a summary account then it is a header / total of the children accounts
parentvalue Key of the Parent
parentelementvalue_id The parent (summary) account - Parent node reference
postactual Is the user allowed to post actual values? (Y/N)
postbudget Is the user allowed to post budget values? (Y/N)
poststatistical Is the user allowed to post statistical values? (Y/N)
postencumbrance Is the user allowed to post commitments / encumbrance values? (Y/N)
default_account Name of the Default Account Column
ad_column_id Column in the table
processing Flags for import processing
processed Flags for import processing

COA Import File

The COA import file is a file provided to assist end users in importing their chart of accounts. The data contained in the spreadsheet is imported in to the I_ElementValue table and once validated, this is imported in to the C_ElementValue table where is is accessible via the element tree editor. The spreadsheet includes a number of fields to assist with the creation of report dimensions.

Column Description
Account value unique ID of the account
Account name short name of the account
Account description a description of the account
Account type type of the entries written to this account (Asset/Liability/Owner's Equity/Expense/Revenue/Memo)
Account sign Natural(+/-)/Debit(-)/Credit(+)
Document controlled if yes, then it is not possible to post manually to this account
Summary account No entries can be posted to this account, this is a summary of the subaccounts. All entries have to be submitted to the subaccounts
Default account Name of the Default Account Column - this is a link to a system controlled default account
Account parent Summary account where the entries of this account are summarized to
Balance sheet If this item appears in the balance sheet report - it's identifier
Balance sheet name If this item appears in the balance sheet report - it's name as displayed in the report
US 1120 Balance Sheet If this item appears in the form 1120 (US tax balance sheet) report - it's identifier
US 1120 Balance Sheet Name If this item appears in the form 1120 (US tax balance sheet) report - it's name as displayed in the report
Profit&Loss If this item appears in the profit and loss report - it's identifier
Profit&Loss Name If this item appears in the profit and loss report - it's name as displayed in the report
US 1120 Income Stmt If this item appears in the form 1120 (US tax profit and loss) report - it's identifier
US 1120 Income Stmt Name If this item appears in the form 1120 (US tax profit and loss) report - it's name as displayed in the report
Cash Flow If this item appears in the cash flow report - it's identifier
Cash Flow Name If this item appears in the cash flow report - it's name as displayed in the report
  • tri (only in definition csv/xls) - ?