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 G/L and 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 chose 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 classification represents the accounts and which represents 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 stall 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 emplyee 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 efficiently?
Note: this issue is explored in more death 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 delimited account numbering scheme.
Since the traditional approach to COA construction has drawbacks, the COAs on this page use delimited account numbering (a.k.a. hierarchical coding) which makes the account structure flexible and infinitely expandable. As a bonus, it eliminates the need for superfluous sub-ledgers.
For example, the accounting software producer that publishes this page (link) has this to say: "The detail put into a chart of accounts sets the ceiling for financial analysis. If the chart of accounts doesn’t capture a data point, it won’t make it into any report" and "A well-structured chart of accounts also supports accurate, compliant financial statements. Misclassified accounts can distort key metrics and trigger audits, especially for businesses following Generally Accepted Accounting Principles (GAAP)."
So far so good.
However, it then goes on to say: "A chart of accounts can become unnecessarily complex if it contains too many categories and subcategories" and recommends "If a chart of accounts has more than three levels, consider setting up subledgers."
The difficulty, allowing staff to add subledgers or items to subledgers on an ad hoc basis opens up a very wiggly can of worms and does nothing to address the fundamental issue which, as the page also correctly points out, happens when "Inconsistent naming and coding can cause staff to interpret accounts in different, unintended ways. This inconsistency creates reconciliation problems, reporting gaps, and trouble rolling up results across departments or entities."
Why vague COAs and ad hoc subledgers are 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.
Why would a reputable software producer publish a page that seems this self-contradictory?
Perhaps because it assumed entities would use a traditional approach to account numbering it also illustrated.
Without any doubt, a numbering scheme such as this will make anything more than three levels practically unworkable. Also, as a bonus, it will likely cause chaos if even a small change is needed, particularly if more than 9 changes need to be made.
In some situations, no additional delimitation is necessary. For example, if the entity had cash on hand of 100,000 it would represent that balance as When it is necessary to identify a particular item recognized to an account a comma should be used. For example, assuming the entity had a bank balance at bank number 456 and bank number 567 it would If a particular item A particular item recognized to an account (
One would think, a such a software producer would have the resources to come up with a better solution than simply recommending sub-subledgers. Evidently not.
That said, accounting software, as any software, can be re-programmed to support a disciplined structure. The problem is not technical, but rather professional momentum and an unwillingness to break with tradition, not unlike the difficulty early humans likely had when someone suggested leaving the cave for a purpose-built house.
The traditional approach account numbering (block coding) has significant drawbacks. If done as suggested by some pages, it would limit the number of subordinated accounts to nine. While this can be overcome, this solution is far from optimal, practically guaranteeing that the result would only be readily readable to a machine while also making the changes humans must periodically make more difficult and prone to errors than necessary.
For example by defining two or more digit blocks:
Vague COAs requiring ad hoc subledgers may even be dangerous.
A frequently repeated recommendation (discussed above) 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.
That being said, it does require some finesse, and IT involvement, to work as advertised.
Please give the following instructions to your IT department. Subscribers to pro view may download several simple Python scripts that illustrate how it should work in practice.
Technical logic: the value-driven dynamic hierarchy
Traditional accounting software is "structure-heavy," requiring accounts to be hard-coded as either posting or summation. This implementation uses value-driven logic, where the system determines the hierarchy's behaviour based on where data actually resides, not just how the number is formatted.
1. The "value as signal" rule
The primary factor determining an account's state is the presence of a value:
• Automatic posting state: Any account level that holds a value (entered manually or via sub-ledger link) is treated as a posting account.
• Dynamic summation: If a value is added to an account that has subordinated levels (see examples below), the system is "liquid." It shifts the summation point to the next highest level that does not contain a direct value. This ensures that the general ledger remains mathematically consistent without forcing the operator to manually toggle account types.
2. The optional delimiter (the metadata comma)
While the hierarchy is delimited with decimals and the summation trigger the absence of a value, a comma may be added so additional metadata (e.g. bank account number or associated subledger) can be added to the account string without upsetting the summation structure.
• Not mandatory: To reduce the workload on the operator, the comma may be optional. In this setting only the presence or absence of a value determines if the account is posting or summation.
• Comma backstop: To force summation, the comma may be set as a mandatory field. In this setting, only accounts with a trailing comma would be treated as posting accounts. If a value were added to an account without a trailing comma, that value will be ignored and an error message displayed. This option should be implemented if less experienced accounting staff populate the COA with data.
3. Relational vs. block logic
By moving away from traditional block coding, the system achieves:
• Operational ease: Operators can post at the level that makes sense for the transaction. If more detail is needed later, sub-accounts can be added without "breaking" the existing history.
• Mathematical integrity: The system’s aggregation engine performs a recursive check. It sums up all values from the bottom-up, including only entered (or linked via sub-ledger) values and skipping any intermediate summations to avoid double-counting.
• Mapping to the report: The posting accounts remain in the COA. The summation accounts are then mapped to the financial statements, to the footnotes, or to subsidiary systems such as a sub-ledger used to populate the statement of cash flows. Note: if a direct SCF is presented, the additional data may be added following the comma as metadata or be kept in a sub-ledger.
Note to IT implementers: The system must be programmed to recognise "data occupancy." A summation total for any given node must be the sum of its children, but if that node itself contains a value, the aggregation logic must "float" the summation to the parent level to ensure the trial balance remains in equilibrium.
For example, if the entity had only two assets (petty cash of 5,000 and cash in vault of 65,000), its COA would comprise:
By default, when a value is entered into any account, that account is treated as a posting account in that all higher level accounts are summation accounts. This simple rule removes the need to explicitly define the type and parent columns typically required by off-the-shelf ERP systems (e.g. the plug and play version posted here). Removing these superfluous structures removes much of the rigidity implicit in such a COA set-up.
While, as shown in the COA scripts page, not necessary for mathematical consistency, a trailing comma may be added to explicitly designate posting accounts:
The trailing comma can be even more useful, but more on that later. First, some variations.
If a value is entered into an account that would otherwise be a summation account (if without a value), it changes into a posting account and the summation moves one step up in the hierarchy. For example, 65,000 in the vault, 5,000 in petty cash, and 5,000 in an unspecified location (e.g. manager's pocket).
Or, instead of cash in a manager’s pocket, 3,000 in one petty cash drawer, 5,000 in a second and 7,000 in a third. The entity also wanted a subtotal for all petty cash and another for all currency on hand:
The three additional petty cash accounts with entered values are posting accounts. The first higher one above becomes their summation account.
Returning to the trailing comma, so it could keep track of the accounts, additional identifying metadata can be added after the comma. While this would not change the mathematical rollup, adding this information would make the structure more understandable. For example, if it called its three cash drawers one, two and three.
If it wanted additional summation accounts, it could simply add them (to keep the structure rational, their placement in the hierarchy would determine what they are summing):
Note: since the comma is optional, it can be added to the title even when omitted from the number.
The remainder of this page is available in Pro view.