On this page you will find charts of accounts that are up to date and may be applied without compromise. While the advanced versions are neither simple nor brief, their detail reflects the requirements of complex accounting guidance rather than COA bloat.
Most sites that discuss charts of accounts stick to the same outdated flat block structure.
Fortunately, except in countries such as this or this, where the chart of accounts is required by law, entities are free to choose a more contemporary approach.
Optimally, the first step would be to dispense with the account number entirely.
True, when the books were kept in books, account numbers served a purpose. Today, they are a vestigial appendage that only gets in the way when even a minor change is required.
Further, using a traditional number block (above) puts a cap on the number of sub-accounts one can define.
True, it is possible to simply expand the block, but this makes the number practically unintelligible to anyone but a machine.
The counterargument: computers rely on numbers; accountants rely on computers; ergo, accounts must be numbered.
That is not correct. Computers do not rely on numbers. People rely on numbers. All computers rely on is logic.
As demonstrated by the very basic scripts written in the most basic programming language, all a computer requires is a set order, defined hierarchy and simple instructions. From this, it can easily generate a financial report with no need for numbered accounts. It can even be instructed to generate account numbers, even though it does not, itself, need any (these scripts may be downloaded on this page).
That being said, account numbers are the traditional way to organize and present accounts, so this page continues to use account numbers, even though it does not put them first.
Also, to make them as readable as possible, and remove any artificial upper limit, it uses a delimited scheme.
but then quickly returned to the way it has always been done.
Required by German law
Required by French law
One ERP software vendor introduces their recommended COA this way.
Very true. The detail put into a COA does set the ceiling for financial analysis. If the COA does not capture a data point, it will not make it to a financial report. A well-structured COA will support accurate, compliant financial statements and misclassified accounts can distort key metrics, trigger audits and make correctly applying complex guidance, especially guidance promulgated by the IASB or FASB, practically impossible.
However, when it pivots to the challenges, its advice becomes self-contradictory.
The page correctly points out that “a well‑structured COA supports accurate, compliant reporting.” But then points to overcomplication suggesting that "A chart of accounts can become unnecessarily complex if it contains too many categories and subcategories."
However, an oversimplified COA does not make details go away. It simply moves them off the COA, which is precisely where inconsistencies, misclassification occur and remain hidden until discovered by an auditor or, with more dire consequences, regulator.
Then comes the second contradiction.
The oversimplification mantra does nothing to address "Inconsistent naming and coding [that] can cause staff to interpret accounts in different, unintended ways."
Quite the opposite. It encourages, perhaps even forces, junior accounting staff, the staff least qualified to make the recognition and measurement to make recognition and measurement decisions.
While a provider of cloud-based accounting software can be forgiven for implying that only cloud-based accounting software will facilitate dimensionality, why would it encourage the use of ad hoc subledgers to plug holes in a vague COA when it does nothing to address one of the challenges it discussed earlier?
Perhaps because, as a producer of accounting software, it bears no responsibility for how that software will be used and selling an apparently simple, carefree solution to a complex problem makes a sale easier. Or, perhaps, we are just being cynical.
In any event, using the suggested account structure not only makes changes cumbersome (at best), but encouraging companies to use a primitive structure then telling staff to plug the holes using ad hoc sub-ledgers will almost certainly yield suboptimal results.
Specifically, the systemic risk that software vendors advocating abbreviated COAs choose to ignore: if the COA does require a data point mandated by accounting guidance such as IFRS or US GAAP to be captured, that data point must be managed off the COA. From data integrity perspective, such manual workarounds are dirty data. From an accounting perspective, they are internal control deficiencies. Deficiencies that in a high stakes environment such as, for example, SOX compliance, can have very, very serious consequences.
Fortunately, every chief accountant can easily avoid this simplicity trap.
The simplicity trap: why simple charts of accounts are an internal control failure
Modern ERP implementation guidance frequently advocates for a simplified (a.k.a. lean) COA. The argument is that fewer accounts reduce complexity and user error.
The counterargument: oversimplification in the account structure does not eliminate complexity. It merely decentralizes it. By removing the detailed forced-choice mechanism of a well-designed COA, organizations inadvertently delegate high-level technical accounting decisions to junior staff, increasing the risk of misclassification, reconciliation failure and audit non-compliance.
- The fallacy of the clean ledger
The push for a simple COA is often driven by a desire for aesthetic cleanliness in financial reporting. However, accounting requirements (IFRS, US GAAP, and Local Statutory) remain inherently complex. When a COA is stripped of specific categories, the data does not vanish. Instead, it migrates to:
- Unstructured sub-ledgers: where data governance is weak and compliance overlooked.
- Manual spreadsheets: the shadow ledgers that haunt year-end reconciliations.
- Ambiguous dimensions: where proper classification is ignored to facilitate high-volume data entry.
- The COA as control mechanism
A detailed COA is more than a list of accounts. It is a preventative measure.- Forced technical decisions: if a junior accountant is presented with 40 possible classifications related to employee benefits, they will make absolutely certain they pick the correct one, particularly if they know that if the balance on the "Other employee related accruals" exceeds 1% of all employee benefits, serious questions will be asked.
- The escalation trigger: if a junior accountant is presented with detailed classifications, they will make absolutely certain to check before classifying a particular item incorrectly. If they are not certain, they will ask. That is normal. That is how junior staff become senior staff and how compliance is actually achieved.
- The multi-jurisdictional issues
For global entities, simplification is an executive luxury that creates a subsidiary nightmare. Local statutory requirements (such as the French Plan Comptable) demand an approach far different from IFRS or US GAAP. At some point, local teams must know when a national GAAP item can be mapped into a reporting package, when it must be adjusted before being mapped and, most importantly, when it cannot be mapped at all, but must be re-recognized and remeasured. Unambiguous accounts with unambiguous titles (including and XBRL tags) go a long way to making these distinctions clear - Dimensions and determinants
It is also important to distinguish between data that belongs on the COA and data that does not. For example, measurement characteristics such as amortized cost or FVOCI or FVPL|FVNI must be captured. However, these are best captured in dimensions associated with accounts rather than on accounts. Likewise, the currency in which foreign currency financial asset is denominated does not belong on a COA. Also, while they have traditionally been included, adjustments such as accumulated depreciation or amortization or depletion or impairments are better kept off of the COA. Operational dimensions such as department, customer type, geographic region, likewise have no place among the accounts. However, the ability of keeping track of data in 3D does not, in and of itself, replace the role of the COA as the basic framework supporting the structure.
The transition from pen and paper to computerized ledgers brought freedom and flexibility to chart of account design. New accounts could be added with practically no effort, allowing managers to achieve granularity through the additions of ad hoc accounts. Since adding new accounts, particularly if the chart of accounts does not have a logical and consistent hierarchy, is much easier than eliminating superfluous accounts, the result, bloated COAs with thousands of often duplicate or superfluous accounts added for no reason than a particular manager's desire to capture a momentarily useful data point.
Then the pendulum swung in the other direction and the mantra became a lean account structure supported by subledgers and dimensions.
Unfortunately, lean is often confused with minimal. For example the basic standard chart of accounts (below) comprising 90 posting accounts, 29 summation accounts and 7 classes is both lean and minimal. The disadvantage, it requires staff sufficiently knowledge of IFRS | US GAAP's recognition and measurement guidance to fill in the blanks with no additional help or assistance.
In contrast, the advanced standard chart of accounts (also below) comprises over 1400 accounts broken down into 9 hierarchical levels because it contains sufficient detail to accommodate IFRS and US GAAP guidance.
This does not, however, mean it is bloated. Quite the opposite, it includes this detail to guide even staff with minimal training to make the recognition decisions necessary if IFRS | US GAAP compliance is to be achieved.
Optimally, the chart of accounts will be implemented in a robust ERP environment where information necessary for management decision making will be captured in additional dimensions. For example, organizational elements such as a profit center, department or product line should each occupy its own dimension and not appear on the chart of accounts. Similarly, each discrete project should also have its own, dedicated place.
Similarly, sub-ledgers play a very important role in supporting the COAs structure.
For example, as they often have significantly different useful lives and may also display a different pattern of economic benefit consumption, light duty trucks and heavy duty trucks should have dedicated accounts (unless the entity would rather put in the effort to estimate depreciation periods and methods item by item instead of class by class) that reflect the requirements of, for example, IAS 16.50 and 60 | ASC 360-10-35-3 and 7.
However, if an entity has a fleet of 1,000 long-haul trucks, having 1,000 separate truck accounts (and another 1,000 accumulated depreciation accounts) would be a seriously bloated chart of accounts and convoluted general ledger. These and other issues, such as individual construction projects, should certainly occupy dedicated subledgers.
On the other hand, if, for example, the entity has a foreign subsidiary which keeps its statutory accounts in a national GAAP sub-ledger and then simply maps that subledger into a reporting package the only comprises the parent's basic 90 posting accounts, it is very likely that IFRS or US GAAP reporting guidance will not be applied, particularly if the staff at that subsidiary has primary knowledge of their own, national GAAP.
As noted above, organizational elements such a profit center or department should be kept in dimensions and off of the chart of accounts.
Many IFRS and US GAAP requirements are also better fulfilled in this manner. For example, while it is theoretically possible to keep track of adjustments such as accumulated depreciation or amortization, allowances such as expected credit losses, etc. on separate accounts, the COA would become an unwieldy checkerboard of duplicate datapoints. Similarly, measurement attributes such as amortized cost or fair value through net income or fair value through other comprehensive income should optimally occupy dimensions rather than accounts. Likewise, the currency in which a foreign currency monetary item is denominated or even whether an item is reported as current or non-current is information better captured elsewhere than on an account.
To address these issues, the advanced charts of accounts (below) include sufficient detail to ensure that even inexperienced staff will be compelled to make the recognition and measurement decisions consistent with IFRS or US GAAP guidance. The expanded charts of accounts additionally outline the accounting dimensions necessary for IFRS | US GAAP compliance. Finally, the XBRL tagged charts of accounts include cross references to the pertinent XBRL names in the published IFRS and US GAAP taxonomies, as well as additional names for situations where additional items need to be reflected in the financial reports.
1. The administrative bottleneck
The criticism: a 1,400-account COA is a master data nightmare, requiring central approval for every new nuance slows down the business and creates a massive backlog for the CAO's office.
The Rebuttal: draw a hierarchal bright line. Governance does not have to be a choice between total chaos and total lockdown. By drawing a bright line at a specific hierarchical level, one may grant local autonomy where it matters. For example, allowing local staff to add accounts at level 4 or below meets the need for operational flexibility without central approval. Only changes to the core structural levels (1-3) would require high level approval. This preserves global comparability while allowing local agility.
2. The choice paralysis problem
The criticism: giving a junior accountant 1,400 choices is asking for errors. They will get overwhelmed by the nuance and simply pick the first account that looks close enough, leading to dirty data across the group.
The rebuttal: the COA is, above all, a control mechanism. An error in a detailed system is actually a diagnostic signal. If one has 20 subsidiaries and 19 are reporting comparable values on comparable accounts an advanced COA will immediately raise a red flag which allows the controller to identify exactly who needs additional training or which subsidiary should receive a visit from internal audit. In a minimalist COA, these errors may simply buried in a vague, aggregated bucket where they will only become visible when detected during an external audit which carries much more serious repercussions.
3. The shadow ERP management reporting gap
The criticism: if the COA is built strictly for IFRS | US GAAP compliance, it becomes useless for managers who need to run the business. They will stop using the ERP and start building their own Shadow systems to track the metrics they actually care about.
The rebuttal: dimensional decoupling. This problem only exists if one tries to make the COA do everything. By using dimensions for organizational elements (profit centers, departments, product lines, etc.), one satisfy the manager's need for who and where (the ERP) without bloating the what at what vlaue (the COA). If a manager wants to track revenue by square meter, they can set up a custom dimension for that. This information has no business being on the G/L.
4. The human error vs. automation debate
The criticism: companies should be moving away from human intervention entirely. A complex COA is a legacy solution to a problem that AI and automated mapping engines should be solving at the source.
The rebuttal: COA detail is the AI training set. Moving away from humans actually makes the case for a detailed COA stronger. An AI is only as smart as the labels it is given. If the COA is too vague or minimal, the AI lacks the necessary data points to make accurate classification decisions. You cannot automate IFRS | US GAAP recognition and measurement guidance if the target architecture is not detailed enough to reflect these specific rules.
5. Integration and mapping complexity
The criticism: mapping a complex National GAAP sub-ledger into a 1,400-account parent COA is a technical nightmare that is brittle and prone to breaking every time a change is made at HQ.
The rebuttal: given the choice between have a complex mapping that fulfills IFRS | US GAAP guidance and will stand up to auditor or perhaps regulatory scrutiny is probably better than simple mapping that violates the guidance. A simple map that rolls up detailed local data into a basic 90-account structure practically guarantees vital reporting nuances, for example IFRS | US GAAP's preference for substance versus a local GAAPs requirement to adhere to form, will be lost in the translation. The technical effort of a complex map is the cost but avoiding the risk and potentially much greater cost of regulatory non-compliance is the benefit.
While adopting a flexible, infinitely expandable COA such as advocated by this page can yield superior results, using it unwisely will certainly bring disaster.
For example, in this article (link / archive), the author identifies the problem clearly but, ultimately, fails to see the big picture.
For example, 5,000 accounts certainly seems like bloat, but only if those accounts are created in the way and for the reasons pre3sewnted in the acticle.
While the snippet does not allow one to drill down to make certain that it was not just a situation of careless labeling, adding individual fixed assets to a COA will certainly cause bloat. This information does not belong on a COA or in the G/L. It belongs in a dedicated subledger comprising, for example, all light-duty trucks (as opposed to heavy-duty trucks which, as a rule, have different useful lives so deserve separate recognition). Similarly, allowing just any manager to add any account just because they have a momentary need for a particular data point will certainly cause bloat.
While the optimal solution is to make certain information such as operating unit or geography location or sales per square meter is never captured on a COA but rather in dimension specifically tailored to provide operating data to managers not generate financial reports for capital market participants.
As shown on the COA implementation page, even a flat COA can be designed to keep such non-essential data from polluting the COA. It may simply be added to the additional metadata leaving the basic structure intact.
Fortunately, the author does eventually identify the real culprit.
This implies, the chief accountant must assert control over the COA. While this advice may seem a recipe for a centralized and inflexible accounting, if applied as outlined on the implementation page, it will yield superior results to allowing every manager to add ad hoc accounts on a whim.
Note: a CFO’s job is to plan, budget and forecast. But, most importantly, it is maintaining a solid relationship with important creditors and representing the company to investors and analysts. Delegating the task of ensuring the company's accounts provide managers with actionable information as well as adhere to external reporting guidelines to the Chief Accountant or, better yet, Chief Accounting Officer yields considerably better results than adding another responsibility to an executive already wearing too many, more pressing hats.
The basic charts of accounts are designed for entry-level ERP systems and suitable for businesses for whom standard, pre-configured templates are insufficient.
The advanced charts of accounts support more complex businesses while maintaining a flat account structure. They also include intercompany accounts to facilitate the preparation of consolidated financial statements.
The expanded charts of accounts move beyond a flat structure and are intended for multidimensional ERP environments. They are best suited for large, complex organizations, particularly those operating across multiple international jurisdictions.
The XBRL charts of accounts include cross-references to the two most widely used XBRL taxonomies, along with additional custom-defined XBRL elements.
Standardized COAs IFRS COAs GAAP COAsThe Standardized chart of accounts is suitable for any business operating within a compatible legal framework. Available in versions ranging from basic to professional, it provides a scalable architecture that grows with the entity's complexity.
A contemporary alternative yields better results. Guidance on how to apply these COAs is provided on this page.
They are aimed at companies of any size, but specifically at those that have outgrown their initial, QuickBooks setup.
A number of EU member states such as France and Germany mandate a COA. Internationally, such rules may be found in Russia, OHADA member states and elsewhere. In these jurisdictions, the COAs on this site may be used for intra-company purposes but may conflict with national legislation if used for tax and/or statutory purposes. Visitors to this site are strongly encouraged to consult with a qualified, national expert before attempting to use the COAs from this site in any such jurisdiction.
As a rule, IFRS and full GAAP are only mandatory for publicly traded companies. Nevertheless, their attention to detail can benefit smaller, non-public companies as well. Specifically, a COA that can accommodate IFRS | full GAAP guidance, even if adjusted to be more user friendly, introduces rigor and discipline that not only allows the accounting system to generate actionable information for management, but allows the company to fulfill external reporting obligations.
Reflecting IFRS | GAAP is not the same as being subordinated to IFRS | US GAAP.
For example, while IFRS 15 | ASC 606 have largely moved the special accounts traditionally associated with projects and POC (Contract costs, Billings and Recognized income) off the COA and G/L to dedicated subledgers, the practical value of this approach is debated.
Thus, the standardized COA continues to include dedicated POC account groups (e.g. Contract in progress #1.3.3.3.2.2 or Billings on contract in progress #2.2.3.1) even though the IFRS | US GAAP specific COAs omit them. Without such legacy features, a universal COA would cease being a universal tool for accountants and become a tool whose functionality is dictated by standard setters such as the IASB | FASB that are occasionally insensitive to the accountant and their needs.
ASU issued this year
However, the primary advantage, there is only one IFRS and one GAAP. These standards are universally known. As such, they significantly reduce the time and effort needed to train new staff in the way a particular company keeps its books, make entities comparable, can be scaled and, assuming a company grows sufficiently large to require it, make consolidation as painless as possible.
Note: while the guidance provided by IFRS for SMEs and PCC GAAP is somewhat more flexible, the similarities to full IFRS | GAAP are sufficient that creating a separate COA specifically for these frameworks would offer limited incremental value. In contrast, the more robust guidance provided by the full versions leads, logically, to a more robust, universal, standardized COA.
While generally comparable, IFRS and US GAAP do not provide identical guidance.
Thus, while this Standardized COA may be used for dual reporting purposes, adjustments will be necessary. Adjustments will also need to be made if, for example, a US GAAP parent consolidates its IFRS subsidiary or vice versa.
The Illustrations section outlines most common differences between IFRS and US GAAP.
We strongly recommend reviewing the Illustrations section thoroughly before attempting to use the Standardized COA for dual reporting and/or consolidation purposes.
A number of EU member states (e.g. France, Belgium, Germany, Luxembourg, the Czech Republic, etc.) implement the EU Accounting Directive through a procedural that defines a COA. Internationally, similarly rigid accounting rules may also be found in, for example, Russia or OHADA member states. Some jurisdictions, such as Nigeria, use a blend requiring fixed COAs for non-private entities while offering privately owned entities more flexibility.
For example, the French (link: anc.gouv.fr) accounting standard Art. 947-70 (view pdf) states: "… Les montants des ventes, des prestations de services, des produits afférents aux activités annexes sont enregistrés au crédit des comptes 701 "Ventes de produits finis", 702 "Ventes de produits intermédiaires", 703 "Ventes de produits résiduels", 704 "Travaux", 705 "Études", 706 "Prestations de services", 707 "Ventes de marchandises" et 708 "Produits des activités annexes"."
Deviating from the defined COA would thus not be permissible under French accounting law.
Before mapping this COA to a national COA please, confirm the process would conflict with national legislation.
Some jurisdictions allow or require certain entities to apply IFRS alongside, or in place of, national GAAP. In such jurisdictions, the COAs presented here could be used provided they do not conflict with other legislation.
For example, in the Czech Republic, the Accounting Act 563/1991 paragraph §19a (1) states:
"An [unconsolidated] entity that is a trading company and is an issuer of investment securities admitted to trading on a European regulated market shall apply international accounting standards regulated by European Union law (hereinafter referred to as "international accounting standards") for accounting and the preparation of financial statements" [paragraph § 23a requires IFRS at the consolidated entity level].
This implies, if the COA presented here is used for IFRS bookkeeping purposes and IFRS recognition guidance is applied correctly, it may (implicitly) be used in place of the chart of accounts mandated by the same law but only by a trading company (consolidated entity) that is an issuer of investment securities admitted to trading on a European regulated market.
Nevertheless, the Income Tax Act 586/1992 §23 (2) states:
"The tax base is determined a) from the net income (profit or loss), always without the influence of International Accounting Standards, for taxpayers required to maintain accounts. A taxpayer that prepares financial statements in accordance with International Accounting Standards regulated by European Community shall apply for the purposes of this Act to determine net income and to determine other data decisive for determining the tax base a special legal regulation [CZ GAAP]). When determining the tax base, entries in off-balance sheet account books are not taken into account, unless otherwise provided in this Act. ..."
Thus, since Czech accounting law assumes the mandated chart of accounts will be used for accounting purposes, if a different chart of accounts is used, it will need to yield the same result as if the mandated chart of accounts were used. While this is not impossible with careful mapping and associated adjustments, it is generally more practical to use the mandated national GAAP COA for Czech accounting and taxation purposes, and a separate IFRS compatible COA for IFRS recognition, measurement, reporting, and disclosure purposes.