Standardized chart of Accounts

The traditional approach to COA design leads to sub-optimal implementation advice and operational difficulties.

Unfortunately, the traditional flat block account layout that should have been retired along with green eyes hades and sleeve protectors continues to hang on through sheer force of will or, in jurisdictions such as this or this, legislative mandate.

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
Required by German law

Plan Comptable Général
Required by French law

For example, one accounting software producer introduces their COA this way.

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

A promising start.

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.

But, when it pivots to the challenges, it becomes self-contradictory.

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.

Then, it suggests.

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

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.com/portal/resource/articles/accounting/chart-of-accounts.shtml

Perhaps, as a producer of accounting software, it bears no responsibility for how that software will be employed and selling a seemingly simple and carefree solution to a complex and intractable problem makes selling software easier. Or, perhaps, we are just being cynical.

In any event, while accounting software producers are free to suggest sub-par alternatives and suggest allowing staff to ad hoc accounts willy-nilly, the chief accountant is free to say no.

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

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

Specifically, the systemic risk that software vendors often choose to ignore: if the COA does not have a slot for a non-negotiable accounting rule, that rule has to be managed manually. From an AI/Data perspective, manual workarounds are dirty data. From an accounting perspective, they are internal control deficiencies. Deficiencies that in a high stakes environment such as SOX compliance can lead to very serious consequences.

But seriously.

The Simplicity trap: why "lean" charts of account are an internal control failure

Modern ERP implementation guidance frequently advocates for a "simplified" or "lean" COA. The argument is that fewer accounts reduce complexity and user error. We argue the opposite: oversimplification in the G/L does not eliminate complexity. It merely decentralizes it. By removing the granular "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 lean 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:
   
   • 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 granular COA is more than a list of accounts. It is a preventative control.
   • 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 "Other employee related accruals" balance exceeds 1% of all employee benefits, serious questions will be asked.
   • The escalation trigger: if a junior accountant is presented with 40 possible classifications related to employee benefits, they will make absolutely certain they 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. Note: if they ask the same question twice, it is a good indication that junior staff should, without delay, become former junior staff. This is 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 that is different from the IFRS report submitted to stakeholders in London or a US GAAP report for the minority shareholders who acquired their stake on the New York Stock Exchange. At some point, local teams must know when a G/L item can be plugged into a reporting package, when it must be adjusted before being plugged in and, most importantly, when it cannot be adjusted at all, but must be completely re-recognized and remeasured. Unambiguous accounts with unambiguous titles (and XBRL tags) go a long way to making these distinctions clear


4. Dimensions and determinants
   
   Some dimensions (e.g. FVOCI or FVNI, the currency in which monetary assets are denominated, accumulated depreciation or amortization or depletion or even impairment, the function of an expense, etc.) are crucial for IFRS | GAAP compliance and should be hard wired. Other dimensions (department, customer type, geographic region, etc.) are nice to have, but will not cause an audit report to become qualified. Having a COA clearly shows each new hire where that line is simply makes both compliance and operations management simpler.

A contemporary alternative yields better results.

However, adopting an apparently flexible, expandable COA, then using it unwisely will likely lead to even worse results.

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 does seem like bloat, but only if those accounts are created for the wrong reason. While the snippet does not allow a drill down so may just be a case 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).

Fortunately, the author does identify the real culprit.

Without any doubt, allowing just any manager to add an ad hoc account unsystematically without any planning or forethought is certain to guarantee a bloated, unworkable COA.

Instead, the chief accountant should assert control over this fundamental structure. While this advice seems to be a recipe for a centralized and inflexible accounting, if applied as outlined on this page, it will yield superior results to allowing just any manager to add accounts willy-nilly.

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.

Note: as the script on this page (link) illustrates, account numbering is optional. The hierarchy itself dictates structure.

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 reflects IFRS | full GAAP guidance, even when adjusted for user friendliness, 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, this 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.

The face that recently greeted me from the FASB's home page

Me when I need to process the 12.59^th (on average)
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.

IFRS approaches accounting from a reporting-focused perspective, with emphasis on recognition, measurement, and financial statement presentation and disclosure. As such, it does not prescribe bookkeeping procedures or a standard chart of accounts. Entities operating in jurisdictions such as the UK, Canada, Australia, Japan, Korea, China, India, etc. may generally define any COA provided it yields a financial report consistent with IFRS guidance.

Nevertheless, as designing a workable COA is a time consuming and laborious process, many entities prefer to use an off-the-self version particularly if it can be, with minimal effort, adjusted to reflect the entity’s financial structure.

US GAAP approaches accounting from a reporting-focused perspective, with emphasis on recognition, measurement, and financial statement presentation and disclosure. As such, it does not prescribe bookkeeping procedures or a standard chart of accounts. Entities operating in the United States may define any COA provided it yields a financial report consistent with US GAAP guidance.

Nevertheless, as designing a workable COA is a time consuming and laborious process, many entities prefer to use an off the self-version particularly if it can be, with minimal effort be adjusted to reflects the entity’s financial structure.

A number of EU member states (e.g. France, Belgium, Germany, Luxembourg, the Czech Republic, etc.) implement the EU Accounting Directive through procedural rules that define 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.

Before mapping this COA to a national COA please, confirm the process would conflict with national legislation.

The Advanced COA is suitable for a single entity or group utilizing a single-dimensional account structure. It provides the core account framework, allowing users to append their own account attributes or dimensions as metadata. Sub-ledgers are incorporated using the same mechanics. This page illustrates the procedure. This structure may be used with basic accounting systems such as QuickBooks, FreshBooks, Wave, Zoho, Patriot or NetSuite.

The Expanded COA is suitable for a single entity or group utilizing a multi-dimensional account structure. This version includes pre-defined dimensions for accounting data such as a remeasurement attribute (e.g., FVPL|FVNI or FVOCI), adjustment attribute (e.g., accumulated depreciation or accumulated impairment), currency of denomination attribute, current / non-current attribute, etc. Additional, entity-specific attributes, dimensions or sub-ledgers may be added as illustrated on this page. This structure assumes a system built on a relational database such as S/4HANA, E-Business Suite, Infor CloudSuite, IFS Cloud or Sage X3.

The XBRL COA includes cross-references to IASB | FASB approved taxonomies for XBRL-tagged financial reports, intended for digital regulatory filings. While optimized to work with the multi-dimensional setup, it may also be used with the single-dimensional structure by focusing on the core account excluding the dimensions.

These COAs as well as illustrative implementation scripts are available for download in Pro View.

Activate Pro View above.

Note: Pro View activation provides full access to all site content for one year. It is not a subscription and will not auto-renew.

A thoughtfully designed COA eliminates the need for ad hoc subledgers and unsystematic workarounds often suggested by consultants (above) who would rather push the keep it simple at all costs mantra.

While the keep it simple COA argument sounds enticing, it may have dangerous repercussions, particularly in an international environment, where it may create inconsistency, inaccuracy and most frighteningly, a loss of control that could result in an adverse audit opinion, or worse, regulatory action.

The problem is structural. If a COA is overly general and staff are permitted to create subledgers ad hoc, the system as a whole becomes fragmented. Each manager, department or subsidiary develops its own workarounds under the same, vague, top-level structure. Over time, what appears to be a single accounting entity actually becomes a conglomeration of conflicting and inconsistent practices and conventions.

Consider a US parent that once gave its foreign subsidiary a US reporting package including a high level COA accompanied by a rudimentary policy statement. The subsidiary completed the package but failed to adjust for the local practice of recording the sale of fixed assets gross (revenue and expense), not net (gain or loss). While, in and of itself, this difference was immaterial, the foreign GAAP prescribed the same procedure for factored receivables. Imagine the US company's consternation when the controller sent to investigate cash flows that seemed inconsistent found the subsidiary had been inflating its reported revenue by approximately 40% each year without even realizing this was a problem.

Fortunately, this was a private company, so the only palpable effect was an embarrassed CFO (and embarrassed auditor who had failed to confirm what "In our opinion, the financial statements give a true and fair view of the financial position… and have been prepared in accordance with the Accounting Act and accounting regulations" from its foreign peer meant in actual practice).

Had it been a listed company, it may have had to explain to the SEC why it had to restate its consolidated revenue downward due to this misapplication of guidance error.

The point is, giving an ambiguous COA to an under-experienced staff and expecting the result to be free of misrecognition and mismeasurement is unrealistic.

In contrast, a thoughtfully-designed, appropriately detailed COA is not unnecessarily complex. It is an instrument for control.

By defining accounts precisely and structuring them thoughtfully, any entity reduces the risk of arbitrary misinterpretation, makes consolidating a foreign GAAP entity into a parent's structure repeatable and auditable, eliminating the need for improvised substructures that nobody fully understands. Detail is not a problem to be hidden in a subledger. Further, by giving staff the detail that allows them to make better decisions autonomously, it actually reduces the control burden while, at the same time, making certain top-level management receives the accurate comparable information they need from every department, regional office, profit center, division, international subsidiary, and so on.

While this standardized COA may be used for dual reporting purposes, adjustments will be necessary!

While comparable, IFRS and US GAAP guidance is not identical. It is thus not reasonable to run the generate IFRS statements | generate GAAP statements script on the same TB and expect results compliant with IFRS and US GAAP for both iterations.

Adjustments will be necessary!

The illustrative example section discusses and illustrates most pertinent differences between IFRS and US GAAP.

Data can be handled in many ways, but Excel remains the lingua franca of accounting.

Nevertheless, some experts insist on data structured as CSV (or, better yet, TSV). To accommodate this request, read this.

Pro view includes additional scripts illustrating how to generate a dynamic hierarchical COA from an Excel source file. It also includes scripts to map the output to balance sheet and P&L in IFRS or US GAAP format (also in Excel).

By small, we do not mean a business that has no need for a formalized accounting system.

We are referring to businesses for which the generic, built-in functionality of QuickBooks, FreshBooks, Wave, Zoho, Patriot, etc. is no longer sufficient.

Businesses that have grown, prospered and now comprise multiple locations, or divisions, or international branches. Businesses that have outgrown starter-kit, off-the-shelf solutions but have yet to face the unfiltered rigor of IFRS or US GAAP that comes with a stock market listing.

While the COAs on this page assume the latter, being flexible and adjustable, they can easily accommodate the former.

The point is, trimming a clearly defined structure, that may be excessive, is far easier than researching the complete structure one may actually need.

As anyone who has ever started a business knows, starting a business is the easy part. Keeping it running smoothly and profitably is where the real challenge lies. To help those just starting out, this site publishes workable, basic COAs, that can be expanded as needed, free of charge. After all, every business that survives the startup phase makes the business community richer and more diverse so is in everyone's best interest.

While copyright protected, the COA below may be used free of charge. If you find it useful, simply copy paste.

As outlined in IFRS 16.47.a.i, an ROU should be classified like the underlying asset if that asset were owned (unless the ROU is presented separately). Thus, the right to use, for example, a building, would be presented in PP&E while the right to use a patent would be intangible (below).

While the ASC does not provide similarly explicit guidance, the FASB-defined XBRL taxonomy includes PropertyPlantAndEquipmentAndFinanceLeaseRightOfUseAssetAfterAccumulatedDepreciationAndAmortizationAbstract.

This implies that an ROU associated with an underlying asset that is PP&E should be recognized as PP&E.

Since the guidance provided by the ASC (specifically 842-20-45-1 through 3) does not preclude presenting an ROU within PP&E, this account would be consistent with that guidance.

Note: provided the right-of-use asset is recognised on the balance sheet, the guidance is flexible about how it is presented. For example, a leased building may be presented within the “Buildings” line item rather than on a separate “right-of-use asset” line, as long as the notes explain that the amount relates to a leased (right-of-use) building rather than an owned building. From an internal accounting perspective, the building could thus be posted either to the Buildings account with a metadata flag indicating that it is an ROU or to the ROU account with metadata describing the underlying asset as a building.

A right to use an asset is a contractual right. Thus, the right-to-use asset (ROU) is, strictly speaking, always intangible. Nevertheless, as outlined in IFRS 16.47.a.i, an ROU should be classified (unless it is presented separately) in the same way as the underlying asset if it were owned. Thus, an ROU of a building would be presented in PP&E (above) while an ROU of a patent would be presented here.

Since ASC 842-20-45-1 and 2 do not preclude recognizing the right to use an intangible asset as an ROU within intangible assets (provided financial and operating ROUs are not mixed as outlined in ASC 842-20-45-3) it would not be incorrect to recognize those ROUs here.

Note: provided the right-of-use asset is recognised on the balance sheet, the guidance is flexible about how it is presented. For example, a leased patent may be presented within the “Patents” group or as a standalone "Patent" rather than as a separate “right-to-use patent” item, as long as the notes explain that the amount relates to a leased (right-of-use) asset rather than an owned asset. From an internal accounting perspective, a patent could thus be posted either to the Patents account, with a metadata flag indicating that it is an ROU, or to an ROU account, with metadata describing the underlying asset as a patent.

While crypto assets have more in common with financial assets than intangible assets, ASC 350-60-15-1.a defines: a. Meet the definition of intangible assets as defined in the Codification ... d. Are secured through cryptography... The 2026 FASB-approved XBRL taxonomy (link) likewise places CryptoAssetFairValue on the balance sheet as a separate line item directly below intangible assets and above right-of-use assets.

For its part, the 2026 FASB-approved XBRL taxonomy (link) places both FinanceLeaseRightOfUseAsset and OperatingLeaseRightOfUseAsset following intangible asset and immediately following crypto assets. This suggests the FASB would prefer if ROAs were classified as intangible.

IFRS does not specifically discuss Crypto but the IFRIC (June 2019 agenda decision) concluded that typical cryptocurrencies meet the definition of an intangible asset under IAS 38, unless they are held for sale in the ordinary course of business, in which case IAS 2 (inventories) applies.

The 2026 XBRL version has been updated with cross-references to the 2026 FASB issued XBRL taxonomy.

A version reflecting the 2026 IFRS taxonomy will not be posted as the IASB has decided to not update its taxonomy.

The COA published on this page may be republished provided the following citation is provided:

Source: https://www.ifrs-gaap.com/chart-accounts.