How to update your chart of accounts for PSAK 118, so the new statements come from the ledger


The 2026 trial balance mapping is open on the controller’s screen: four hundred accounts, each with a financial statement line beside it. The auditors have asked for one more column, the PSAK 118 category, and most accounts take a second to fill in. Then comes account 6990, “Other expenses”, with a balance of Rp 2,140 million and more than a thousand entries behind it. Someone exports the detail and starts tagging lines by hand.
That spreadsheet will get the 2026 comparatives done. But if the account stays as it is, someone will tag it again after every quarter of 2027, and every year after that.
Your chart of accounts is the list of accounts your ledger records transactions in. PSAK 118, which replaces PSAK 201 from 1 January 2027, asks more of it than PSAK 201 did. This guide explains what the standard needs from your accounts, how to structure them, a worked example of splitting one “other expenses” account, the mistakes that bring the work back every quarter and a step-by-step plan you can start in the 2026 close. For the standard itself, start with what PSAK 118 is and what changes.
What does PSAK 118 need from your chart of accounts?
PSAK 118 is a presentation standard, so it doesn’t change what you record. It changes the questions your accounts have to answer. For every income statement account, there are three:
- Which category? Every item of income and expense is classified as operating, investing, financing, income taxes or discontinued operations. An account that holds items from two categories has to be analysed every time you report.
- What nature? If you present expenses by function, a note shows five expenses by nature: depreciation, amortisation, employee benefits, impairment of non-financial assets and inventory write-downs, each with the amount in every line of the income statement.
- Which function? The line the cost belongs to, such as cost of sales or general and administrative. This usually comes from the cost centre, not the account.
Two more requirements land on the accounts. Labels have to describe what’s in a line, so a large “other” needs a better name or a note explaining it. And if you publish a management-defined performance measure such as adjusted EBITDA, every adjustment in its reconciliation has to be traceable.
The rule that follows is simple: one account, one category and, where the standard asks for it, one nature. The account says what the cost is; the cost centre says what it was for.
How to structure it
- Category as an attribute of the account. Record a PSAK 118 category against every income statement account in the ledger itself, as a field or a reporting mapping, rather than in a spreadsheet beside the trial balance.
- Separate accounts where the category differs. The usual candidates are exchange differences (operating balances, borrowings, deposits), interest expense (bank loans, leases) and gains and losses on disposals (fixed assets are operating; investments are usually investing).
- A clear group for each specified expense. Depreciation by asset class, amortisation, employee benefits, impairment and inventory write-downs each need accounts that hold nothing else.
- Employee benefits wherever they’re paid. Salaries, overtime, THR, BPJS contributions and post-employment benefit provisions belong in employee benefit accounts, and so do the allowances and medical costs paid through expense claims, not “office expenses” or “welfare”.
- Cost centres that map to one function. Each cost centre should map to exactly one function line, such as cost of sales or selling and distribution. A shared cost centre, such as a warehouse that serves both production and sales, needs a written allocation rule.
- Few, small “other” accounts. Keep one “other operating expenses” account for items that really are miscellaneous, and review its balance every month.
- Accounts or tags for MPM adjustments. If adjusted EBITDA excludes restructuring costs or one-off legal fees, give those items their own accounts or a tag, so the reconciliation comes from the ledger.
A worked example: splitting “other expenses”
Back to account 6990. The analysis of its 2026 entries looks like this. The amounts are only illustrative:
| In the account (Rp million) | Amount | Category |
|---|---|---|
| Exchange loss on supplier payables | 610 | Operating |
| Exchange loss on dollar bank loan | 480 | Financing |
| Staff medical reimbursements | 320 | Operating |
| Bank charges and transfer fees | 260 | Operating |
| Loss on sale of investment shares | 150 | Investing |
| Donations and sponsorships | 140 | Operating |
| Loss on disposal of office equipment | 90 | Operating |
| Small unrelated items | 90 | Operating |
| Total | 2,140 |
What the analysis shows:
- One account fed three categories: Rp 1,510 million operating, Rp 480 million financing and Rp 150 million investing. Left as it is, it has to be analysed again after every reporting period.
- Rp 320 million of employee benefits was hidden in “other”, so the employee benefits note would be understated by that much.
- Only Rp 90 million is truly miscellaneous. That’s small enough to stay in “other operating expenses”.
From 1 January 2027, account 6990 is replaced by eight accounts:
- Exchange differences on operating balances
- Exchange differences on borrowings
- Employee medical benefits, in the employee benefits group
- Bank charges
- Gains and losses on sale of investments
- Donations and sponsorships
- Gains and losses on disposal of fixed assets
- Other operating expenses
Account 6990 is then blocked for posting, and the analysis above becomes the bridge for the 2026 comparatives.
Why it goes wrong in practice
- Fixing the mapping, not the accounts. The category is added in the reporting spreadsheet and the mixed accounts stay. The 2026 comparatives get done, and the same analysis comes back every quarter.
- New accounts nobody posts to. The accounts are created, but the expense tool’s categories, vendors’ default accounts, the payroll interface and the fixed asset module still point at the old ones. Postings carry on into the account that was meant to be retired.
- Splitting too finely. Thirty new accounts that people choose between at random are worse than eight they understand. Split where the category or a specified nature differs, or where the amount matters, and stop there.
- Breaking the history. New accounts start on 1 January 2027, but the 2026 comparatives are still in the old ones. Without a documented bridge, the auditor can’t follow the restatement.
- Each PT doing it differently. In a group, every entity changes its chart of accounts its own way, and the consolidation mapping stops working, much like intercompany recharges coded differently on each side.
- Coding that depends on who enters it. The same software subscription goes to IT costs in one office and to general expenses in another. New accounts don’t help while the choice is still made from memory.
What it means in Indonesia
- Groups with different systems. The parent often runs SAP or Dynamics while smaller PTs use Xero or ABSS. Agree one group chart of accounts, or at least one mapping to the PSAK 118 categories that every entity follows, before each PT changes its own.
- Subsidiaries on SAK EP. A subsidiary that reports under SAK EP doesn’t apply PSAK 118 itself, but if its parent reports under full SAK, its accounts still have to feed the group’s categories.
- Costs with their own tax treatment. Some costs are treated differently for tax, such as donations, benefits in kind (natura) and entertainment, which needs a nominative list (daftar nominatif) to be deductible. Separate accounts for them help the fiscal reconciliation (rekonsiliasi fiskal) as well as PSAK 118.
- Employee benefits under Indonesian rules. THR, BPJS Kesehatan and BPJS Ketenagakerjaan contributions and the provision for post-employment benefits are all employee benefits. Check that each has a home in the employee benefits group.
- Change at the year boundary. Make the change from 1 January 2027, not partway through the year, so each year sits in one structure and the bridge has one date.
Signs your chart of accounts isn’t ready
Your chart of accounts probably needs work if any of these sound familiar:
- An “other” account is among your ten largest expense accounts.
- All exchange differences go to one account.
- Interest on bank loans and interest on leases share an account.
- Employee costs are spread across “office”, “general” and “welfare” accounts.
- The same kind of expense lands in different accounts depending on who enters it.
- Some cost centres can’t be mapped to a single function.
- Your PSAK 118 mapping lives in a spreadsheet outside the ledger.
If a category has to be worked out from the line descriptions every quarter, it belongs in the chart of accounts.
How to update it, step by step
- Tag the 2026 trial balance. Give every income statement account a category and the source of its function, plus a nature where the standard asks for one. Flag every account with more than one answer.
- Analyse the flagged accounts. Break down their 2026 entries as in the example. The same analysis designs the new accounts and restates the comparatives.
- Design the smallest set of new accounts. Split only where the category or a specified nature differs, or the amount is material, and name each account after what it holds.
- Map cost centres to functions. Write down the allocation rule for every shared cost centre.
- Update every system that posts to the ledger. Expense categories, purchase categories, vendors’ default accounts, the payroll interface, the fixed asset module and bank feeds.
- Block the old accounts from 1 January 2027. Nothing new should post to an account that has been replaced.
- Document the bridge. Keep the old-to-new mapping and the 2026 analysis together, ready for the auditor.
- Watch the first months closely. In the first quarter of 2027, review the “other” balances and the new accounts at every month-end close, and correct coding at the source rather than with journals.
How Procapy helps
Most of the entries in an account like 6990 started as a purchase, a vendor invoice or an expense claim, and that’s where Procapy codes them. In Proca to Pay, the cost centre, project and expense category are filled in automatically on purchase requests, with mandatory fields enforced. In Capy Expense, ProcAI proposes the category, cost centre and project from the receipt, and the employee confirms in a tap, so the coding finance needs is done at the source.
Procapy proposes the GL account and cost centre from the vendor, category, submitter and history. When your team corrects a suggestion, the next similar transaction arrives coded the way the last one was, so after the new accounts go live, the corrections thin out over time. Approved transactions sync to Dynamics, SAP, Xero, QuickBooks or ABSS with their coding, tax treatment, attachments and approval reference, and anything that fails to post is flagged rather than discovered at close. Spend by cost centre, vendor, project, category and entity is available as soon as a transaction is approved, so in January you can see whether the new accounts are being used.
The finance team resources page has more. Book a 30-minute walkthrough, bring your close checklist and your chart of accounts, and we’ll map the manual steps to Procapy live.
