The COAs do not usually make a current/non-current distinction.
As an item's status as current or non-current is a reporting and disclosure, not recognition issue. For example, a receivable due in 90 days represents a claim to cash just as a receivable due in 730 days. Nevertheless, from an accounting guidance perspective, while a receivable is a receivable, a receivable with a long payment term also provides debtor financing, which the creditor must account for. Specifically, both IFRS and US GAAP require all receivables with a term of more than one year to be discounted and measured at present value.
Technically, as outlined in IFRS 15.62 | ASC 606-10-32-17, not every contract with a customer results in a claim to cash with a significant financing component that would require discounting. However a receivable (IFRS 15.106 | ASC 606-10-45-2: a right to an amount of consideration that is unconditional) would always require discounting unless the entity chooses to apply the practical expedient outlined in IFRS 15.63 | ASC 606-10-32-18.
Thus, the question is not whether an item's current/non-current status should be reported, but whether it should be given accounting recognition at the account level.
Both options are technically feasible. However, one introduces additional complexity and may even involve unnecessary effort. For example, in a current/non-current chart of accounts, a receivable with a 730-day term would be non-current. Then, when its term dipped below 365, it would be current and would need to be reclassified.
However, non-current receivables are measured at present value from inception to derecognition. Thus, when reclassified, the original 730-day receivable would have a different measurement basis than the other 30, 60, or 90-day receivables in the same account, even though they all now represent identical, unconditional claims to cash. Messy.
Obviously, nothing would prevent an entity from not applying the practical expedient and discounting all receivables. However, in practice, discounting is practically always reserved for receivables with terms extending past one year.
This begs the question: why have two separate accounts when a receivable is always a receivable, and its current/non-current status only influences its measurement?
The practical solution, a single natural account (receivables) on which all unconditional claims to cash would be recognized. To this account two attributes (a measurement attribute and a reporting/disclosure attribute) would be added. Not only is the solution simple and elegant, but it allows the item to remain on the original account untouched until derecognition.
Nevertheless, some accountants insist on a current/non-current COA (for valid reasons).
The Counterpoint
While a single-account, attribute driven solution can be considered "simple and elegant," many accountants stick to separate accounts for a few practical reasons:
- System limitations: not every ERP handles dimensions well. Many mid-range accounting systems generate financial statements directly from the COA structure. If it is not in a separate account, the software cannot "see" it as non-current.
- Trial balance clarity: a Trial balance is the "truth" for many auditors. If they see ¤100,000 in one account, they would need to dig into a sub-ledger to see that ¤50,000 of that is non-current. Separate accounts provide that visibility at a glance.
- The discounting reality: while the claim to cash is unconditional, the time value of money \( PV = \sum_{t=1}^{n} \frac{CF_t}{(1+1)^t} \) means that a claim to cash today is not a claim to cash in two years. From a reporting perspective, they are not comparable assets until that time gap closes.
As a dimensional COA will lead to the correct amount being reported in either case, this is a moot point.
Neverthless, some practitioners prefer to see PV clearly reflected in the TB, not just on the BS.
Since it is not our place to dictate judgment, in addition to the unclassified COAs, we also provide COAs that do make the current/non-current distinction.
The COAs include both nature and function of expense sections.
The COAs include both, but the accountant will always choose one.
Obviously, summation account #5 (total expenses) cannot comprise summation account #5.1 (expenses by nature) plus summation account #5.2 (expenses by function). That would be double counting.
Thus it is up to the user to select which of the two classifications represent the accounts and which represent the attributes (dimensions) of those accounts.
While one works better, it is not the place of this page to prescribe how practitioners should apply professional judgment, both variations are presented.
While the decision is up to the practitioner, one variation has clear advantages
For example in nature : function account order, account #5.1.2.1.1.1 (Employee benefits / Wages and salaries / Wages) would capture the total amount of wages paid out. When some of those wages were paid out to production workers, attribute # 5.2.1.1.2.2 capture that amount so account #5.1.2.1.1.1, 5.2.1.1.2.2 (the comma separates the account from its attribute) could be mapped directly to the direct wages line item of the cost of goods sold section of a function of expense P&L with little effort.
In contrast, a function : nature order would require separate accounts for, for example, production wages, sale’s staff wages, administrative staff wages, R&D staff wages, marketing staff wages, repairs and maintenance staff wages, quality control staff wages, that would then need to be mapped to employee benefits, which would represent aggregate wages paid.
Note: as a bonus, allocating in nature : function order allows the allocation process to be accomplished by a simple, easy to adjust weighting. For, at the end of a period, 50% of total wages paid could be allocated to, for example, COS: Direct wages, 5% to COS: MRO, 5% COS: QC. 15% Selling expenses: Wages, 5% Administrative expenses: Wages, 5% R&D: Wages, 5% to Marketing: Wages.
Employee benefits are a good example.
Assume a very simple company with three employees (one in production, one in sales and one in administration) which it compensates in three ways: hourly wage, salary plus commission and monthly salary. Associated with these costs, it also incurs: social security and health insurance.
As each cost has a different measurement basis, it would be reasonable to use three direct payroll accounts : Wages 5.1.2.1.1.1 (hourly measurement), Salaries 5.1.2.1.1.2 (monthly measurement), Commissions 5.1.2.1.1.3 (measured by sales amount), and two indirect accounts: Social Security 5.1.2.1.4.1 and Health Insurance 5.1.2.1.4.2 (whose measurement is derived from the direct compensation amounts).
If the company decided to structure its accounts by function instead, it would need:
In Cost of Sales: Wages 5.2.1.1.2.2.1, Social Security 5.2.1.1.2.2.2 and Health Insurance 5.2.1.1.2.2.3.
In Selling Expenses: Sales Salaries 5.2.2.1.1.1.1.1, Sales Commissions 5.2.2.1.1.1.1.2, Social Security 5.2.2.1.1.1.1.3 and Health Insurance 5.2.2.1.1.1.1.4
In General and Administrative Expenses: Salaries 5.2.2.2.1.1.1.1, Social Security 5.2.2.2.1.1.1.2 and Health Insurance 5.2.2.2.1.1.1.3.
The better approach is thus to use nature of expense accounts for day-to-day recognition and measurement, in that these would be mapped to the function accounts for disclosure at the end of each period.
Assume the entity recognized period direct compensation costs of currency unit 1,000,000. In addition, it incurred social security tax and health insurance costs at rates of 30% and 10% respectively (for simplicity, also assume that production wages are expensed as incurred rather than being capitalized to inventory).
At the end of the accounting period the balances on the employee benefit (nature of expense) accounts were:
Wages 5.1.2.1.1.1: 400,000
Salaries 5.1.2.1.1.2: 400,000
Commissions 5.1.2.1.1.3: 200,000
Social Security Tax 5.1.2.1.4.1: 300,000
Health Insurance 5.1.2.1.4.2: 100,000
XYZ next determined that its production workers spent 90% of their time on production and 10% on repairs and maintenance, in that 40% of that maintenance was performed on delivery equipment. The entity also determined that 25% salaries were paid to sales staff with the remainder paid to administrative workers, split 60%/40% between office staff and officers.
To prepare its (function of expense) financial report it allocated:
Wages 5.1.2.1.1.1 to accounts: Cost Of Sales/Direct Labor 5.2.1.1.2.2: 384,000 and Selling/Repairs And maintenance 5.2.2.1.3.3 CU16,000
Salaries 5.1.2.1.1.2 to accounts: Selling/Sales Staff Compensation: 5.2.2.1.1.1.1: 100,000, General And Administrative/Office Staff Compensation 5.2.2.2.1.1.1: 180,000.00 and General And Administrative/Officer Compensation 5.2.2.2.1.1.2: 120,000
Commissions 5.1.2.1.1.3 to account Selling/Sales Staff Compensation: 5.2.2.1.1.1.1: 200,000
Social Security Tax 5.1.2.1.4.1 to accounts: Cost Of Sales/Direct Labor 5.2.1.1.2.2: 115,200, Selling/Repairs And maintenance 5.2.2.1.3.3 CU4,800, Selling/Sales Staff Compensation: 90,000, General And Administrative/Office Staff Compensation 5.2.2.2.1.1.1: 54,000, and General And Administrative/Officer Compensation 5.2.2.2.1.1.2: 36,000
Health Insurance 5.1.2.1.4.2 to accounts: Cost Of Sales/Direct Labor 5.2.1.1.2.2: 38,400, Selling/Repairs And maintenance 5.2.2.1.3.3 CU1,600, Selling/Sales Staff Compensation: 30,000, General And Administrative/Office Staff Compensation 5.2.2.2.1.1.1: 18,000, and General And Administrative/Officer Compensation 5.2.2.2.1.1.2: 12,000
Besides a simpler account structure, this approach also allows individual expense to be recognized, day-to-day, by relatively inexperienced staff, while the period end allocations can be performed (supervised) by personnel well versed in the nuances of IFRS and US GAAP guidance
Similarly, as many national GAAPs prefer or prescribe nature of expense recognition, this approach works well at local subsidiaries of (especially) US based companies, that the day-to-day accounting can be performed by local staff (accountants trained in the local GAAP), while the period end adjustments can be performed by reporting specialists (staff trained in US GAAP and/or IFRS).
Obviously, since knowledgeable does not necessarily require presence, the local accounting staff can perform their tasks locally, while the reporting specialists can perform their tasks in close proximity to the management responsible for the final reports.
From a reporting perspective, a function of expense scheme yields better results.
Providing the minimum possible information, ABC and XYZ published function of expense P&Ls:
|
|
ABC |
XYZ |
|
Revenue |
100 |
100 |
|
Cost of sales |
60 |
40 |
|
Gross profit |
40 |
60 |
|
Administrative expenses |
30 |
50 |
|
Net income |
10 |
10 |
Again providing the minimum possible information, ABC and XYZ published nature of expense P&Ls:
|
|
ABC |
XYZ |
Revenue |
100 |
100 |
Material |
10 |
10 |
|
50 |
50 |
|
Services |
10 |
10 |
Depreciation |
20 |
20 |
Net income |
10 |
10 |
In a nature of expense P&L, production and administrative employee benefits are not distinguished from one another.
Of the two formats, which would allow financial statement users to better assess the entity's operating efficiency?
Note: this issue is explored in more depth in the overall section of this page.
A combined approach leads to the best results.
To reflect that both nature and function of expense reporting have merits, ASU 2024-03 (ASC 220-40-50-6) updated US GAAP disclosure guidance to require entities to disclose nature of expense items in the footnotes.
From an accounting perspective, this makes a chart of accounts that captures both nature and function of expense information necessary for compliance with both US GAAP and IFRS.
Technically, IFRS 18 always requires key information by nature of expense. Presenting operating expenses by function (as under IAS 1) remains optional, even though practically all IFRS reporters do present expenses by function in their financial statements.
The COAs use a hierarchical structure / delimited account numbering scheme.
The traditional approach to COA design is sub-optimal leading to equally sub-optimal implementation advice.
Most COAs use the old, tried and true, format based on block numbering.
However, a COA designed in this way soon begin to feel tattered and torn rather than tight and tailored.
In countries such as France or Germany, charts of accounts are defined by law and mandate numbers.
Everywhere else, the account number has become a vestigial appendage.
It was useful when books were actual books, but today it makes little sense and only gets in the way if an addition is needed or makes any structure with any detail practically unreadable to a human.
But, the hand in the back of the room goes up "Computers need numbers. Accountants need computers. Ergo, accounts need to be numbered."
That is incorrect. Computers do not need numbers. People need numbers. All computers need is logic. As shown by the incredibly simple script written in the simplest of all programming languages on this page, dispensing with the account number is as simple as deciding to dispense with the account number.
That being said, account numbers are the traditional way to organize acocunts so this page continues to present numbered accounts even though it does put the number in its place.
It also uses a a delimited number because it is flexible, infinitely expandable and, if used as outlined below, can prevent the uncontrolled COA bloat discussed this article.
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 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.
To overcome the inherent 9 sub-account limit of a single digit number block, the blocks can be expanded to two or more digits. However, this "fix" practically guarantees the result will not be human readable and will always have an upper limit.
For example, one accounting software producer introduces their COA this way.
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 somewhat 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 (even if it does allow executive decision makers to punt responsibility to subordinates). It simply forces the details off the G/L, which is precisely where inconsistencies, misclassification and reconciliation problems love to hide.
This leads to 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 may actually encourage, perhaps even force, accounting staff, particularly junior accounting staff, to use non-standardized workarounds. Come audit, reviewing each of these hamburger helper solutions to (vague) company policy making certain the accounts comply with (not vague) IFRS | US GAAP guidance is the quick road to a qualified audit opinion (particularly if the culinary delights are concocted by staff at a subsidiary in a jurisdiction where national accounting standards are not IFRS | US GAAP).
Finally, it drops these pearls of wisdom.
While a provider of cloud-based accounting software can be forgiven for implying that only cloud-based accounting software will facilitate dimensionality (even though a multi-dimensional account structure can easily function on a company's own server running its own database, even a free open source database), encouraging the setting up of ad hoc subledgers to plug holes in a poorly designed COA opens up a very wiggly can of worms and does nothing to address one of the most important challenges introduced earlier.
Why are vague COAs and ad hoc subledgers so dangerous?
A frequently repeated recommendation is to keep the chart of accounts as simple and high-level as possible, and to “push detail” into subledgers or dimensions when needed. In theory, this keeps the general ledger tidy. In practice, especially in international groups, it often produces the opposite of what good accounting requires: inconsistency, inaccuracy, and loss of control.
The problem is structural. If the COA is overly general and staff are allowed to create subledgers ad hoc, the system as a whole becomes fragmented. Each accountant, department, or subsidiary can develop its own unofficial structure under the same top-level accounts. Over time, what appears to be a single, consistent account in group reporting actually represents a patchwork of different local practices and interpretations.
This is particularly acute in cross-border groups. Consider a US parent that gives its foreign subsidiary a rudimentary US GAAP reporting package with a handful of broad lines to fill out. The subsidiary completes the package to keep the parent satisfied, even when the mapping from local GAAP to those broad US GAAP categories is approximate at best. If local staff are also free to “solve” gaps by building their own subledgers and coding schemes, the risk is that the reported numbers look acceptable on the surface, but are structurally wrong underneath.
The less familiar local staff are with IFRS or US GAAP, the greater this risk becomes. Giving them wide latitude to modify the underlying structure through subledgers and custom codes is effectively delegating COA design to the people least equipped to do it. The very issues many experts warn about—“inconsistent naming and coding” causing reconciliation problems, reporting gaps, and trouble rolling up results across departments or entities—are made worse, not better, by vague COAs plus ungoverned subledgers.
A detailed, well-designed chart of accounts is the opposite of unnecessary complexity. It is a control instrument. By defining accounts precisely and structuring them carefully, the entity reduces the scope for arbitrary local interpretation, makes mappings from local GAAP to IFRS | US GAAP repeatable and auditable, and limits the need for improvised substructures that nobody fully understands. In this context, “detail” is not a problem to be hidden in subledgers; it is the means by which the entity protects itself against quiet, systemic misclassification in its financial reporting.
One would hope a publisher of accounting software in the twenty-first century could offer a better solution than plugging holes with sub-subledgers. Evidently not.
Any accounting software (besides starter kits like QuickBooks, FreshBooks, Wave, Xero, Sage 50, Zoho Books, etc.) can be programmed to support a custom, multidimensional account structure.
However, even the most basic software (including QuickBooks or Wave) can be updated.
Specifically, current entry-level small-business iterations possess sufficient modularity to bypass legacy block-numbering constraints in favor of multifaceted data structures. The operational bottleneck is not a factor of software capability or professional accounting logic. Rather, it is a product of organizational inertia. Non-financial executives frequently prioritize legacy-mode stability over informational density. They opt for sub-optimal frameworks due to legacy concerns or to maintain parity with industry peers, effectively choosing 'sufficient' historical continuity over the high-velocity insights facilitatable by a modernized schema.
Or, somewhat more colloquially, even a primitive software package lets users dump block-numbering for something better. The roadblock isn’t the software. It's not the accountant. It's the boss unwilling to get rid of the way Grandpa Jake and Grandma Josefine set up the books when they founded the company way back when green eyeshades were a thing particularly if, hazard the thought, it's not the way every other guy at the club thinks it should be done.
Why would a reputable producer of accounting software publish a web page giving such substandard advice?
Perhaps because it assumes all companies continue to use a structure that should have been retired along with green eyeshades, but continues to hang on through sheer force of will.
Without any doubt, this structure is primitive. Besides having to be patched with ad hoc subledgers, unsystematic Excel files, gum, popsicle sticks and, always a fan favorite, crazy glue, it will make adding accounts an adventure, and cause the system to implode if more than 9 are required.
So, rather than use unsystematic fixes to continually bail out a leaky boat, maybe it is time for a new boat.
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 account structure 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.
- 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.
- 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.
- 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 national GAAP 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 - 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.
Instead of this approach, the COAs on this page are hierarchical, making them flexible and infinitely expandable.
Using the methodology outlined below, the account structure dynamically adapts to the data. As such, it is not necessary to use account numbers or to distinguish explicitly between posting and summation accounts.
It is, however, necessary to maintain the correct hierarchy, making the depth columnthe key to the COAs functionality.
Note: both IFRS and US GAAP XBRL taxonomies use a similar depth-defined structure, which makes mapping a COA that follows the same structure more practical.
A flexible and expandable COA does not imply accounts can or should be added at random.
In this article (link / archive), the author makes some good points but, unfortunately, misses the big picture.
For example, 5,000 accounts does seem like bloat, but only if 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 even a 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 lives).
Fortunately, the author then goes on to clearly 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 of a bloated, unworkable COA. A COA best deleted before it leads to consequences (such as a qualified audit report, or regulatory enforcement action, or, in a SOX reporting environment, something potentially much more severe).
Specifically, it is a Chief accountant's job to ensure proper controls over the company’s fundamental accounting structure. While this may seem like recipe for centralized inflexible accounting, allowing managers to add accounts willy-nilly, particularly managers at international subsidiaries whose working knowledge of local legislation and local enforcement is likely much more thorough than their knowledge of IFRS | US GAAP and the compliance demands of regulators such as the SEC, FSA, FCA, AMF or BaFin is worse.
A CFO’s job is to plan, budget, and forecast. More importantly, it is to maintain a working relationship with important creditors and represent the company to investors. Delegating the actual, day-to-day task of making certain the company's accounts not only provide managers with the information they need but facilitate IFRS | US GAAP compliant financial reports to professionals explicitly trained and experienced in these matters, is probably the more rational choice. In other words, CFOs are usually not particularly good accountants. Accountants are good accountants.
This also implies that taking professional advice from a site aimed at the former tends to not be as effective as taking it from one aimed at the latter.
It means achieving the proper balance of high-level control and lower-level operational adjustability.
Achieving both accounting rigor and operation flexibility can be challenging, particularly as no two organizations are identical. The mechanism used by this page is the hierarchical COA. While not strictly necessary for the COA to operate as intended, the best way to illustrate this structure is using a delimited account number.
To balance and fine tune the COAs structure, a multiple level or dynamic hierarchy can be used. For example, above a certain depth only the management with the highest levels of responsibility is allowed to make changes, additions or subtractions. This level can also be fine-tuned giving, for example, a UK subsidiary more flexibility than a French or German subsidiary.
Returning to the number, the delimitations could be expanded to include both dimensions and the inclusion of supplanted metadata. In the illustrations below, the trailing comma is used for this purpose.
Depending on the circumstances, the trailing comma could also be used to force additional control, for example making its use mandatory to differentiate between posting and summation accounts (even though this would defeat the purpose of the recursive aggregation engine outlined below).
To summarize, the hierarchical / delimited number COAs illustrated in this section, if set up as intended, can provide both sufficient control and flexibility for any entity, regardless of size or organizational structure.
On the surface, IFRS and US GAAP take a reporting-focused approach, emphasizing faithful financial statement presentation over rigidly defined accounting mechanics.
Under the surface, they can be surprisingly rigid, categorical, prescriptive and detailed.
For example, when an option is used to hedge cash flows under IFRS, the cost of that option is commonly added to the acquisition cost of the hedged item. US GAAP, in contrast, charges the costs to earnings. The accounts must reflect and accommodate this guidance.
Similarly, while they have more in common with a banknote than a patent, both IFRS and US GAAP require cryptocurrencies to be recognized as intangible assets not cash or financial instruments. The accounts must reflect this regardless of the accountant's opinion on the matter. In addition, they must also reflect that under IFRS measurement basis could (theoretically) be cost less amortization while, in US GAAP, it would be fair value.
A vague, poorly defined chart of accounts, for example one that does not explicitly classify cryptocurrency as an intangible asset, may yield misclassification errors. In fact, it may even encourage them.
For example, assume an entity listed in London (IFRS) or New York (US GAAP) has a French or German subsidiary. If that subsidiary is given a reporting package based on a vaguely defined COA that does not specify otherwise, what would stop them from mapping their French or German GAAP accounts to that package without making adjustments?
If, however, instead a single employee benefits line, the COA listed 40 separate sub-accounts, the French or German staff would have no choice but to make certain they understand the nature of each of those accounts before copy pasting. Further, since the parent would see all 40 accounts, if one had an unusually high or low balance, it would be an immediate call to action. A much better option than simply waiting for year end when an auditor might decide to test whether the subsidiary made all the adjustments necessary to turn French or German employee benefits into IFRS | US GAAP employee benefits.
Or take something as prosaic as fixed assets. A French or German accountant may have few qualms using a tax depreciation schedule even if the result is zero net value assets sitting on the books for years. Or they may just recognize the sale of a machine as revenue and expense gross, instead of the difference net. Or they may apply the same procedure to record factored receivables. Or, if a contract explicitly states the customer will receive some goods for free, they could conclude those goods are free, not a separate performance obligation that must be reported at stand-alone selling price.
Without adequate oversight, or a detailed COA built using self-policing DNA, it is quite possible the reporting packages submitted by foreign subsidiaries would be hiding material recognition and measurement errors that would surface if subject to auditor or regulatory scrutiny.
A vaguely defined, overly generalized COA creates a structural problem where key decisions are pushed down to those staff members least qualified to make them. The solution is a structure designed from the start to guide staff to make the right decisions. Specifically, if a staff member is faced with 40 possible accounts dealing with employee benefits, that staff member will be compelled to understand what each of those accounts is for before hitting Ctrl-c / Ctrl-v. In other words, a detailed, well-designed COA is the opposite of unnecessary complexity. It is a self-enforcing control instrument.
By defining accounts precisely and structuring them carefully, the entity reduces the scope for arbitrary low level misinterpretation, makes mappings from subsidiary to parent repeatable and auditable, sets the limits and removes the need for improvised ad hoc subaccounts or subledgers that are commonly used to plug holes in leaky COAs.
To prevent too much of a good thing from causing paralysis, clearly defined limits must also be set. Junior staff must be allowed some level of autonomy otherwise the constant requests for new sub-account sub-ledger approvals will cause gridlock at the Chief Accountant’s office. However if the overall structure is logical, and that logic is clearly communicated throughout the organization, even junior staff can be trusted to make reasonable decisions (including the decision to ask for help or clarification).
While large, listed companies with an IFRS | US GAAP obligation benefit most, smaller, mid-sized businesses are also better served by a structure more robust than generic solution often suggested (above).
For this reason, the COAs presented on this page, particularly the standardized COA, are designed to serve as the basis for an upgrade for any entity that has outgrown its, for example Quickbooks, accounting solution.
Note: if an recursive aggregation engine is used, the account number becomes optional. Nevertheless, keeping an account number makes the charts of accounts easier to read and illustrations easier to follow. For this reason, all the charts of accounts continue to include account numbers.
The recursive aggregation engine.
A Python script illustrating how to set up an RAE is available for download on the scripts page.
For example, if the entity had two assets (petty cash 5,000 and cash in vault 65,000), its T/B or post close G/L would show:
To illustrate the logic, post close Dr / (Cr) balances are shown.
For readability, values such as 5,000 are blue or red (not shown), rollups such as 70,000 are grey.
An illustrative Python script demonstrating how to program this hierarchy is available on the scripts page.
An optional trailing comma may also be used to specifically denote posting accounts (unless an RAE above was used where the logic itself would serve this purpose).
A Swiss army knife, the comma may also be used to indicate that anything that follows, for example a cross reference to the sub-ledger detailing the petty cash transactions, is additional metadata.
If more control is needed, it can also be hard wired, forcing staff to specify posting accounts (trailing comma) and summation accounts (no trailing comma). This rule may also be applied at various depths to protect the COA's core integrity if, for example, a foreign subsidiary is given some autonomy to adjust the COA's structure (beyond a certain depth). If used this way, the comma would not, obviously, be optional.