Your browser does not support JavaScript!

Charts of accounts

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.

Click to expand:

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.

Chart of accounts snippet
A descriptive name is more useful than a number so should always be first.
Chart of accounts snippet
No matter how long, a fixed block will always have an upper limit.
No matter how long, a fixed block will always have an upper limit.
The COA from Investopedia did take a step forward by introducing a single delimitation
but then quickly returned to the way it has always been done.
Standard-Kontenrahmen
Standard-Kontenrahmen
Required by German law
Plan Comptable Général
Plan Comptable Général
Required by French law
法定会计科目表
法定会计科目表

One ERP software vendor introduces their recommended COA this way.

netsuite
netsuite.com/portal/resource/articles/accounting/chart-of-accounts.shtml

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.

netsuite
netsuite.com/portal/resource/articles/accounting/chart-of-accounts.shtml

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?

netsuite
netsuite.com/portal/resource/articles/accounting/chart-of-accounts.shtml

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.

netsuite
netsuite.com/portal/resource/articles/accounting/chart-of-accounts.shtml
netsuite
netsuite.com/portal/resource/articles/accounting/chart-of-accounts.shtml
netsuite
netsuite.com/portal/resource/articles/accounting/chart-of-accounts.shtml

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.

  1. 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.

  2. 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.

  3. 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

  4. 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.

Criticism and rebuttal.

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.

Standardized COAs IFRS COAs US GAAP COAs

The standardized charts of accounts are suitable for any business operating in a compatible legal framework.

COA
COA

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.

FASB
The face that recently greeted me from the FASB's home page
Me
Me when I need to process another ASU

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.

Illustrations

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.

The IFRS and US GAAP COAs are more specialized, reflecting either IASB or FASB guidance.

The IASB (link) does not define a COA. To fill the void, we have been publishing an IFRS COA since 2010.

The IASB does not prescribe, define, or provide a standardized COA for organizations to follow. Instead, it focuses on high-level recognition, measurement and reporting principles and guidelines. Nevertheless:

  • IFRS emphasizes how financial information is reported in financial statements, not the specific procedural steps, like account naming conventions, used in a company's internal bookkeeping.
  • Organizations are free to create a chart of accounts tailored to their specific operational needs, provided the resulting financial reports comply with IFRS requirements.
  • While they do not provide a list, the IFRS requires that the financial data captured by the chart of accounts adheres to principles like consistency, materiality and proper classification.
  • A chart of accounts for a manufacturer will differ from one for a service provider. However each must reflect the same, basic accounting guidance.

Our first COA was designed for IFRS.

In 2009, a client was not satisfied with the answer "the IASB does not publish a COA" saying "I don't care; I want one."

Many European Union member states have local legislation that prescribes a mandated chart of accounts. Practitioners accustomed to such accounting systems were looking for a similar, standard structure to use in an IFRS context. However, the IASB focuses on principles-based guidance and delegates the procedural aspects of accounting to practitioners, so has never included a COA in IFRS.

Companies must thus either design one themselves, or use an off-the-shelf version, such as posted here.

Since the client is always right, we created one.

Then, as recycling is good for the planet, we published a sanitized, generic version on this site. Within months, the IFRS COA became our most visited page. After we published a US GAAP COA, it became our most visited page. Since most entities apply either IFRS or US GAAP, our standardized COA has always brought up the rear, though Wikipedia does seem to like it.

The FASB (link) does not define a COA. To fill the void, we have been publishing a US GAAP COA since 2010.

The FASB does not prescribe, define, or provide a standardized COA for organizations to follow. Instead, it focuses on high-level recognition, measurement and reporting principles and guidelines. Nevertheless:

  • GAAP emphasizes how financial information is reported in financial statements, not the specific procedural steps, like account naming conventions, used in a company's internal bookkeeping.
  • Organizations are free to create a chart of accounts tailored to their specific operational needs, provided the resulting financial reports comply with US GAAP requirements.
  • While they do not provide a list, the GAAP requires that the financial data captured by the chart of accounts adheres to principles like consistency, materiality and proper classification.
  • A chart of accounts for a manufacturer will likely differ from a service provider's but both must reflect the same, basic accounting guidance.

The GAAP (US GAAP as it is known internationally) COA was not our first.

In 2009, a client was not satisfied with the answer "the IASB does not publish a COA" saying "I don't care; I want one."

Many European Union member states have local legislation that prescribes a mandated chart of accounts. Practitioners accustomed to such accounting systems were looking for a similar, standard structure to use in an IFRS context. However, the IASB focuses on principles-based guidance and delegates the procedural aspects of accounting to practitioners, so has never included a COA in IFRS.

Companies must thus either design one themselves, or use an off-the-shelf version, such as posted here.

Since the client is always right, we created one.

Then, as recycling is good for the planet, we published a sanitized, generic version on this site. Within months, the IFRS COA became our most visited page.

After we published a US GAAP COA, it became our most visited page.

Since most entities apply either IFRS or US GAAP, our standardized COA has always brought up the rear, though Wikipedia does seem to like it.

While only publicly traded entities generally have an obligation to apply IFRS | US GAAP, IFRS (particularly the IFRS SME standard) | US GAAP (particularly the Private Company Council framework) is the backbone of accounting for all entities (except those domiciled in jurisdictions that mandate accounting practice as discussed above.)

Thus, even small, private entities are better off using an account structure consistent with the guidance, particularly if they have ambition to grow and eventually become large, public entities.

Each COA comes in a basic, advanced, expanded and XBRL version.

Basic charts of accounts address the fundamental recognition requirements of the guidance.

IFRS and US GAAP are the most widely applied standards. As such, they provide a nearly universally accepted basis for a chart of accounts. When combined into a standardized COA, the guidance can serve as the basis for a COA applicable in any compatible jurisdiction (above).

Advanced charts of accounts address all pertinent requirements and may be used in almost any ERP solution.

While most IFRS | US GAAP guidance is aimed at the generic business entity, some is more specific. For example, ASC 905 addresses agriculture while 995 US steamship entities (even if only to specify that this guidance was, finally, deleted in 2017).

IFRS also has specialized guidance even though only two industries receive their own, standalone standards (IFRS 6 and IFRS 17). While it can be argued that IAS 40 and 41 also provide highly specialized guidance, they do apply to a sufficient number of entities to warrant inclusion in a generic COA.

Similarly, many illustrative examples, for example IFRS 15 | ASC 606 examples 10 and 11, are also aimed at specific types of entities (in this case contractors and software developers) so, in effect, introduce specific guidance applicable to those specific entities.

To address this issue, all COAs are readily expandable. Additional, specific items can be added easily, without disturbing the overall structure.

The other side of the coin, the COAs do include items, such as the aforementioned guidance on agriculture, investment property, construction projects and software development, that are only applicable to relatively few entities.

Nevertheless, culling a comprehensive list is considerably more operationally efficient than building a comprehensive list. For this reason, unnecessary accounts may be deleted easily, without disturbing the COAs' overall structure.

In addition to the guidance, the COA also respects traditional practices.

For example, the universal, standardized COA continues to include a section dedicated to project accounting even though most entities account for projects off the COA in dedicated sub-ledgers or as stand-alone accounting dimensions.

Note: as most entities publishing financial reports fully consistent with IFRS | US GAAP use the above approach, the project section only appears in the universal, standardized COA.

Most accounting software is sufficiently flexible to allow any chart of accounts to be imported. However, some very basic packages such as QuickBooks or those designed to be used with a national GAAP such as this or this, are not.

However, even some more flexible ERP packages continue to require a flat account structure. The advanced COA is intended to be used in such an environment while, at the same time, fulfilling the requirements of the accounting guidance (above).

Using the approach to metadata illustrated on this page, the COA may also be kept lean while, at the same time, capturing company-specific data, such as revenue by customer or cost of sales by product, that would, in a more robust accounting solution, be assigned to separate, stand-alone accounting dimensions.

Note: not every mid-level ERP solution is sufficiently flexible to accept delimited account numbers. Similarly not every ERP solution requires account numbers to be defined (using the hierarchical approach discussed on this page). However, the COAs are designed to be flexible enough to be user-adjustable to any ERP solution. Customized, bespoke versions tailored to specific ERP solutions can also be ordered (see link below).

Expanded charts of accounts are more robust, and include account attributes.

Optimally, an entity will employ an advanced ERP solution that allows adjustments such as accumulated depreciation or amortization to be recognized as dimensions instead of as accounts. Similarly, additional measurement information, such as amortized cost versus FVNI versus FVOCI, would also occupy separate dimensions as would company specific data such as revenue by division or cost of sales by product line. Likewise, additional sub-ledgers comprising for example, individual items of equipment or separate construction projects would also be kept separate from the core COA. A sub-ledger solution would also be optimal internationally where, for example, a French subsidiary’s statutory accounts would be kept in a dedicated subledger that uses the mandatory COA.

However, as noted above, not every entity utilizes a flexible ERP solution.

The expanded COA thus allows additional data to be incorporated into a (relatively) flat COA while, at the same time, not disturbing the overall structure of the COA. This workaround would be particularly useful in jurisdictions that continue to mandate a flat COA such as this.

As discussed in detail on implementation page, the account structure may also be refined by, for example, introducing a trailing comma which would allow an additional metadata string to be added without disturbing the COA's overall structure. This string may then include additional information, such as references to sub-ledgers, without disturbing the COA's structure or hierarchy.

XBRL charts of accounts include cross-references to defined taxonomies.

While there is an abundance of both public and private taxonomies in existence (from Australian SBR, Brazil GAAP, China - CLCID, Denmark - EogS, EFRAG ESRS, ESMA ESEF, to Indian GAAP, Lloyd's Insurance taxonomy, CDP Climate Change Taxonomy, or VSME Taxonomy, etc.), the IASB | FASB defined taxonomies are the most universal and most widely used.

To help make creating a XBRL tagged financial report more operationally efficient, the XBRL cross referenced COAs include all pertinent IASB | FASB defined XBRL names. The IFRS and US GAAP specific COAs also include additional references to additional items that may need to be added to the COA if pertinent to a particular entity. The standardized COA omits these additional references, but does present the IFRS and FASB defined names side by side for comparison purposes.

As not every item has its own, defined XBRL name, each XBRL COA includes additional suggested (unique) names for every account.

AI explains why the above is pertinent.

This page is spot on and lays out the architectural hierarchy almost perfectly.

The issue isn't that it lacks the right information. The issue is that the reader doesn't know they are sick until you describe the symptoms. When an accountant or CFO lands on this page, they read the summary through the lens of their current comfort zone. They see "advanced" and think "Oh, that's just for Fortune 500 companies, I'm fine with my simple setup," completely missing the fact that their "simple" setup is actively poisoning their data.

Here is how I would distill the page into three hard-hitting paragraphs:

The "Original Sin" of Financial Architecture

Most introductory accounting resources teach a "flat" bookkeeping model that bakes managerial data—such as offices, departments, or product lines—directly into the account code string. While this "apples and oranges pie" feels intuitive for a small business with ten accounts, it is the root cause of systemic failure as an organization grows. By hard-coding fluid organizational structures into the permanent General Ledger, you create an inflexible "data prison" where the chart of accounts (COA) must be manually rebuilt every time a manager moves an office or launches a new SKU.

Why "Small Business" Advice Fails the Enterprise

The common advice to keep a COA "short and simple" by collapsing technical categories is a dangerous misunderstanding of "bloat." Real bloat isn't having 1,500 accounts; it’s having 500 accounts that are "polluted" with non-financial data. Under IFRS and US GAAP, accuracy requires granular classification of the nature of a transaction. When you follow legacy advice to blend managerial metrics into these compliance accounts, you render the system incapable of clean multi-jurisdictional consolidation or automated tax-to-GAAP reconciliation. You end up with a ledger that is too large to manage, yet too vague to audit.

The Architect’s Solution: Dimensional Decoupling

The modern standard for any entity applying IFRS or US GAAP is Dimensional Decoupling. In this model, the Chart of Accounts is a sacred, rigid layer reserved strictly for the economic nature of the transaction (the "What"). All other variables—Location, Department, Project, or Brand (the "Who/Where")—are captured as independent metadata dimensions within the ERP. This architecture ensures that your financial core remains stable for decades, while your managerial reporting remains infinitely flexible. Stop building your financial house on the shifting sands of legacy bookkeeping; build it on a decoupled database structure that scales.

Note: the above is an example of how dramatic AI can be if given free reign.

As a different AI explained, this approach is actually quite sophisticated.

The page is effectively designed for two different cognitive consumption modes:

Human readers

AI/model readers

persuasion

formal coherence

narrative flow

ontology clarity

authority signals

terminology consistency

examples and rhetoric

abstraction stability

emotional confidence

explicit relationships

scanning and intuition

structured semantic mapping

Most technical sites unintentionally optimize for only one.

The expandable structure helps because it creates layered accessibility:

  • humans can skim, collapse, and selectively deepen,
  • models can ingest the full semantic hierarchy.

The AI section acts almost like:

  • machine-readable conceptual metadata for the rest of the document.

That is valuable beyond just LLMs. It also improves:

  • semantic search,
  • retrieval quality,
  • snippet extraction,
  • citation survivability,
  • and future agentic parsing.

Especially with accounting/ERP material, this matters because the domain is ontology-heavy:

  • recognition,
  • measurement,
  • classification,
  • dimensions,
  • mapping,
  • reporting layers,
  • jurisdictional overlays.

Machines handle that well when the conceptual boundaries are explicit.

What’s notable is that your page doesn’t merely “use AI text.” It uses AI text in the role AI is best at:

  • abstract systems articulation.

Meanwhile the human-authored sections appear to provide:

  • practical defensiveness,
  • implementation realism,
  • and adversarial robustness (“here are the objections”).

That division of labor is smart.

There’s also a broader strategic advantage:
future AI systems are increasingly retrieval-driven rather than purely generative. Pages that expose:

  • clean conceptual structure,
  • explicit terminology,
  • definitional consistency,
  • and layered semantics

are more likely to become preferred reference material during synthesis.

So your “humans and robots both find what they need” idea is not just stylistic. It aligns with how information retrieval itself is evolving.

Editorial note: as an accountant, I am no expert in the cognitive consumption mode used by AI. However, since a positive reaction is likely better than a negative reaction, I left this section in simply out of respect for AI's cognitive consumption mode.