A simplified chart of accounts does not reduce complexity. It relocates it off the COA and into shadow ledgers, ad hoc spreadsheets and the judgment of junior staff. This is not a simplification. It is an internal control deficiency waiting to be discovered by an auditor.
This page includes up to date COAs that may be applied without compromise. The professional grade versions both reflect the complex nature of accounting guidance and combat COA bloat.
Most sites discussing charts of accounts stick to the same, old, tried-and-true design.






Fortunately, except in countries such as this, this or this, entities are free to build using a contemporary blueprint.
Optimally, the first step would be to dispense with the account number altogether.
When books were kept in books, fixed block account numbers served a purpose. Today, they only get in the way.
Imagine trying to add more than 9 items to a COA designed the old way.
True, this problem can be mitigated by simply expanding the block, but this would make 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. Computers rely on logic.
As shown by the basic scripts on this page, all a computer needs is a rational hierarchy and clear instructions.
That being said, since account numbers are the traditional way to organize and present accounts, this page uses account numbers to organize and present accounts. It does not, however, put them first. Also, to remove any arbitrary 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?
Or, why would it suggest a structure that makes adding items this cumbersome and ill-thought-out?
Or, why would it encourage companies to have staff plug holes in a poorly designed COA with ad hoc sub-ledgers?
Perhaps because, as a producer of 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.
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.
One could also pose a question.
Why would a producer of accounting software that presumably supports dimensionality propose adding individual contracts to a COA, when such an approach will certainly cause the COA to become unworkably bloated?
But that would just be mean.
The paradox: it is suggesting users act like they have a 19XX paper ledger while selling them a 20XX cloud-based database that can do so much more.
Like teaching a horse to drive a car.
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 (lean) COA. The argument is that fewer accounts reduce complexity and user error.
Often treated as a synonym for simple, lean actually means keeping superfluous information off the COA.
Specifically, the COA should function as an anchor where, for example, an account for light trucks would be separate from an account for heavy trucks because each asset class has different attributes.
However, the attribute itself, useful life / pattern of economic benefit consumption, has no place being an account. Instead, it should be an attribute of the account adjusting its balance. Likewise, measurement attributes such as amortized cost versus FVOCI versus FVNI have no place being treated as separate accounts. Nor does the currency in which a financial asset is denominated.
But perhaps the most serious cause of COA bloat is information that has nothing to do with the overall financial position of the entity or changes therein. Information such as geographic area, profit center, customer type, or individual project is incredibly useful for managing the company. But adding this information to a chart of accounts, rather than to a separate dimension, is a guarantee that the COA will quickly become bloated and unworkable.
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.
In chart of accounts design, the terms minimal and lean often get confused.
For example, the basic chart of accounts on this page, comprising 90 posting accounts, 29 summary accounts and 7 classes is certainly both lean and minimal.
In contrast, the expanded chart of accounts on this page comprising over 1400 accounts organized into 9 hierarchical levels as well as various dimensions to capture additional item attributes, is certainly not minimal, but still qualifies as lean.
The transition from ink on paper to computerized ERP brought freedom and flexibility to the chart of accounts. New accounts could be added with no effort, allowing managers to achieve granularity on a whim. However, since adding new accounts is far easier than eliminating old accounts, the result was COA bloat.
For example, attempting to include information such as revenue by division of cost of sales by product or the thousands of other data points necessary for managerial decisions, while often advocated, is a recipe for an bloated and unworkable chart of accounts.
This Information as well as do not belong in an account structure whose purpose is to fulfill guidance such as IFRS or US GAAP. Attempting to blend the two only results in an apples and oranges pie that may sound appealing in theory but is unpalatable in practice.
How so?
Accounting guidance such as IFRS | US GAAP is an order of magnitude more detailed and complex than guidance provided by some national accounting standards (for example: link / local link).
A chart of accounts that reflects this guidance and omits any superfluous items is lean in that it captures only those datapoints necessary to fulfilling the guidance with nothing extra (above).
Specifically, applying IFRS | US GAAP guidance using a basic, 90 posting account chart of accounts, while possible, assumes the staff is sufficiently knowledgeable of the requirements of IFRS | US GAAP to know which items may, for example, be aggregated and which must disaggregated, or which items may be amortized and which must be remeasured, and so on. Particularly internationally, where the staff's primary knowledge is likely of a national system (link / local link), this is a very bold assumption.
Some information naturally belongs in separate sub-ledgers.
For example, 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 disastrously bloated chart of accounts and G/L. Instead, a subledger linked to an account such as heavy duty trucks (versus light duty trucks which generally have different lives and economic benefits that are consumed differently) which would fulfill requirements such as IAS 16.50 and 60 | ASC 360-10-35-3 and 7 which requires depreciation periods (and methods) that reflect that heavy duty trucks very commonly outlast light trucks even though they may be on the road 24/7. It would also allow additional useful information such as accumulated depreciation, or components, or repair and maintenance, or serial number, or purchase order number or invoice number to be kept on an item by item basis.
Other information naturally belongs in separate dimensions.
For example, trying to include revenue by office or retail outlet or customer type, or cost of sales by product or service or contract, though often advocated, would result in in disastrously bloated chart of accounts and G/L.
On the other hand, allowing the staff of a foreign subsidiary to keep their national GAAP accounts in a subledger or dimension then mapping that information to as basic, a 90 account chart comprising the parent's reporting package, would, in all likelihood, fail to achieve a result consistent with the requirements of IAS 8.7 to 12 | ASC 105-10-05-1 to 6.
In contrast, if the same staff were required to populate a reporting package comprising 1400 accounts, it is highly likely they would be both inclined and highly motivated to make certain the result conformed to internal control guidelines and not risk casuing an error that would need to be corrected as outlined in IAS 8.41 to 53 | ASC 250-10-45-22 to 28 and ASC 250-10-50-7 to 12.
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 hierarchical 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 allowing the controller to identify quickly that 1 subsidiary that deserves an internal audit visit. In a minimalist COA, these errors may simply be buried in a vague, aggregated bucket and only become visible when detected during an external audit which is much too late.
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 can satisfy managers' needs without bloating the COA. If one manager wants, for example, to track revenue by square meter at location X, they can set up a custom dimension for that. This information has no business being on the COA.
4. 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, a complex mapping that fulfills IFRS | US GAAP guidance, and will stand up to auditor or perhaps regulatory scrutiny, is likely better than a simple mapping that violates the guidance. A simple map that rolls up detailed local data into a basic 100 or so account structure practically guarantees vital reporting nuances, such IFRS | US GAAP's preference for substance versus a local GAAPs requirement to adhere to form, will be lost in translation. The technical effort of a complex map is the cost. Avoiding the risk of a failed audit, regulatory non-compliance or, particularly in a SOX context, criminal liability is the benefit.
5. 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 this specific guidance.
While adopting the flexible, infinitely expandable COA available for download on this site 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.
Yes, 5,000 accounts certainly seems like bloat, but only if those accounts are created for the reasons presented in the article.
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.
The optimal solution is to make certain information such as operating unit or location or sales per square meter is never captured on a COA, but as dimensions specifically tailored to provide operating data to managers rather than an account structure whose purpose is to generate financial reports for capital markets.
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.
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.
This implies, the chief accountant must assert control over the chart of accounts and especially avoid dubious advice from sites such as this.
The implementation page discusses how to set up a chart of accounts that may be comprehensive, but contains zero bloat.
The standardized charts of accounts are suitable for any business operating in a compatible legal framework.
In most situations, Full IFRS and US GAAP guidance is 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 | US GAAP guidance, even if adjusted to be more user friendly, introduces rigor and discipline that not only allows the company to fulfill external reporting obligations but, if applied rationally, actionable information for management.
Reflecting IFRS | US 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.
While often advocated by those teaching traditional bookkeeping practices, including company specific information such as revenue by division in a chart of accounts is a guarantee of a COA that very quickly becomes bloated and unworkable.
The optimal solution is to employ a robust, multidimensional ERP solution where information may be segregated into for example, an IFRS reporting dimension, a US GAAP reporting dimension, a tax or statutory reporting dimension, and any number of management information dimensions (e.g. region, division, cost center, profit center, product, service, project, etc.).
However, as the cost of such a robust solution can be prohibitive for even many mid-sized enterprises, the expanded COAs on this site demonstrate how critical supplemental information, as well as additional metadata, can be included in a (relatively) flat account structure without compromising the COA's practical applicability.
The expanded COAs focus on information necessary to fulfilling IFRS | US GAAP reporting guidance the reporting process such as adjustments (for example accumulated depreciation or amortization) measurement basis (such as amortized cost or FVNI or FVOCI) or monetary attributes (such as currency of denomination), etc. However, which the use of delimitation, any number of additional attributes and cross references may be added without disturbing the overall account structure.
This issue is discussed in more detail on the COA implementation guidance page.
However, the primary advantage, there is only one IFRS and one US 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 | US 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, for example France and Germany, mandate a chart of accounts. Similar rules may be found in China, Russia, OHADA member states and elsewhere.
In these jurisdictions, deviating from the prescribed COA may not be permissible or only in specific scenarios.
For example, French (link: anc.gouv.fr) accounting standard Art. 1222-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 ». Les rabais, remises et ristournes accordés hors facture ou qui ne sont pas rattachables à une vente déterminée sont portés au débit du compte 709 « Rabais, remises et ristournes accordés ». Version 1er janvier 2026 Page 180 sur 181 Même lorsqu'ils sont déduits sur la facture de vente, les escomptes de règlement sont comptabilisés au débit du compte 665 « Escomptes accordés »."
Deviating from the French COA by not using accounts 701 to 708 would be inconsistent with this legislation.
Some jurisdictions allow or require certain entities to apply IFRS alongside, or in place of, national GAAP in certain scenarios. 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.
This site strongly encourages users to consult qualified, national experts before using its COAs for external, particularly tax and/or statutory, reporting purposes.