Chart of Accounts Setup Best Practices

Q: I need to report P&L by department / branch / property. Don’t I need accounts for each?

No — this is the single biggest optimisation in REDA. Keep one Rent Expense, one Salaries account, and tag each posting with the department, branch, or property as a posting dimension. You then report P&L by that dimension without multiplying accounts. A chart of 300 accounts × 10 dimensions gives you the analysis of 3,000 accounts with none of the maintenance.

Q: Should accounts be global or entity-specific?

Default to global — one shared, standardised chart that every entity uses keeps your consolidation clean and your reporting consistent. Create an entity-specific account only when one company genuinely needs an account the others don’t (a local statutory account, say). Resist forking the whole chart per entity; that’s a maintenance and consolidation headache.

Q: Do I need separate accounts for each currency?

No. Each entity has one functional currency, and the shared chart records every posting in that currency with the corporate-currency equivalent carried automatically for consolidation. You don’t create “AR — USD” and “AR — EUR” accounts — one AR account serves all currencies, and the FX gain/loss and translation-reserve accounts handle the currency effects.

Q: Do I create a GL account for every fixed asset?

No — you map accounts at the Asset Type (class) level, not per asset. All buildings share one set of asset/depreciation accounts; all vehicles share another. Individual assets live in the asset register (the subledger) and report by dimension. Creating a GL per asset is the proliferation anti-pattern applied to fixed assets — avoid it.

Q: Can I clean up or consolidate accounts after go-live?

Yes — deactivate accounts you no longer use (never delete one with history), and move any analysis you were doing through accounts onto dimensions. You can’t merge posted history across accounts, so the cleaner your chart is at go-live the better — which is exactly why the sandbox dry run in step 3 is worth the time.

Best Practice 12 min read Updated July 2026

This is the guide for the accounting controller setting up REDA Financials AI. The chart of accounts is the foundation everything else posts against — get it right, and your modules, statements, tax, and consolidation all fall into place automatically. These are not generic accounting tips: they reflect how REDA Financials AI is built, and how to map your chart to each module so every posting is correct, reportable, and consolidation-ready.

Getting there. The chart of accounts lives in the App Launcher (the grid icon at the top-left of any page) → REDA Financials Admin → the GL Accounts tab, where you create and classify accounts. Entity defaults, tax, asset, bank, and product GL mappings are set on their own tabs in the Admin app (linked through this guide).
Access you'll need. Building and maintaining the chart requires the Accounting Admin v2 or Accounting Controller v2 permission set. The Accounts Payable v2, Accounts Receivable v2, and Read Only v2 sets can view accounts but not create or change them.

The one principle to hold onto REDA posts faithfully to whatever you map. The package guarantees the posting is structurally valid (a bank account must be an Asset; a depreciable asset must have all its lifecycle accounts) and complete (it won’t let you post a revaluation with no revaluation account). What it cannot decide for you is semantic correctness — whether this account is the right one under your policy. That judgment is yours; this guide is how to exercise it well.

1. Classify every account correctly

Every account carries structural metadata that the controls and reports rely on. Set these on every account and the rest of the system works on its own (full detail in Understanding GL Accounts):

Type & Sub-Type — the IFRS-aligned classification that drives statement placement. Always set both; set Sub-Type 2 where a specific line item applies.
Normal Balance — system-derived from Type. Mind the contra accounts: Accumulated Depreciation is an Asset with a Credit balance; it reduces the assets above it.
Control Account — flag accounts whose balance is a running total cleared by a subledger (AR, AP, intercompany, deferrals). See Control Accounts.
Cash Flow Category — tag balance-sheet and non-cash accounts for the IAS 7 statement.

Use a banded numbering scheme

Adopt a banded account-code scheme so accounts sort and report in statement order:

Band	Class
`1000–1999`	Assets
`2000–2999`	Liabilities
`3000–3999`	Equity
`4000–4999`	Revenue
`5000–6999`	Expenses
`7000–9999`	Other / non-operating

2. Dimensions, not account proliferation

This is the single most important optimisation in REDA, and the one that separates a chart you can live with from one you can’t.

Do not create a GL account per department, property, project, or cost centre That is the “10,000-account chart” anti-pattern — unmaintainable and unreadable. REDA carries those analyses as posting dimensions that flow from the source document onto every accounting transaction. Keep one Depreciation Expense account and report it by property or department through dimensions.

Keep the chart lean and standards-based; analyse by dimension. A lean chart is far easier to audit, consolidate, and trust.

3. Follow the setup sequence

Order matters — each step depends on the one before it:

Currencies first

If multi-entity, set your corporate currency and load exchange rates, then set each entity’s functional currency. (Single-currency orgs still record all three currency tiers at rate 1.)

Build or adopt the chart of accounts

Start from the seeded reference chart and extend it. Set Type, Sub-Type, Normal Balance, and control flags on every account.

Map entity-level defaults

AR / AP / cash / discount control accounts, FX gain & loss, and retained earnings — per entity. See accounting defaults.

Map the module configuration

Tax Rules, Withholding Tax Rules, Asset Types (all their GLs), Bank Accounts, and Product default GLs.

Verify with a dry run

In a sandbox, post one transaction per module and inspect the resulting accounting-transaction lines — the debits/credits, the resolved GL account names, and the currency tiers — before go-live.

4. The accounts each module needs

This is the heart of setup: what your chart must contain, module by module, and where each account is mapped.

GL & foundation

The full Balance Sheet and P&L hierarchy, your control accounts, Retained Earnings, and a current-year-earnings account. Retained Earnings is what the year-end close rolls profit into.

Accounts Receivable

Account	Type	Notes
AR control	Asset (control)	Debited on every sales invoice. Mapped via entity default.
Revenue accounts	Revenue	From the product/line; a default revenue account catches unmapped lines.
Customer Deposits / Unapplied Cash	Liability (control)	Holds receipts not yet applied to an invoice.
Bad Debt Expense	Expense	Write-offs.
Discounts Allowed	Contra-revenue	Settlement/early-payment discounts given.

Accounts Payable

Account	Type	Notes
AP control	Liability (control)	Credited on every purchase invoice. Mapped via entity default.
Expense / COGS accounts	Expense	From the product/line; a default expense account catches unmapped lines.
CWIP / clearing	Asset	Holds purchase-order receipts before capitalisation (see Assets).
Supplier Prepayments / Unapplied Payments	Asset (control)	Holds payments not yet applied to a bill.
Discounts Taken	Contra-expense / income	Early-payment discounts received.

Tax (VAT / GST)

Provide Output VAT/GST Payable (Liability) and Input VAT/GST Recoverable (Asset), mapped on your Tax Rules. Keep per-jurisdiction accounts where you file separately.

Non-recoverable tax has no separate account Where tax isn’t recoverable, REDA capitalises it into the asset’s cost (per IAS 16.16) or rolls it into the expense — it is not posted to a separate GL. So you only need recoverable-tax accounts.

Withholding Tax

Provide WHT Payable (Liability — tax you withhold on payments to suppliers) and WHT Receivable (Asset — tax withheld from your customer receipts), mapped on your Withholding Tax Rules. REDA splits sales-side and purchase-side withholding, so map each side to its own account.

Intercompany

When one entity transacts with another, REDA settles it through dedicated control accounts and auto-generates the offsetting entry in the counterparty entity:

Account	Type	Role
Intercompany Receivable	Asset (control)	What a related entity owes this entity.
Intercompany Payable	Liability (control)	What this entity owes a related entity.

IC accounts must mirror — and eliminate on consolidation Entity A’s Intercompany Receivable should always equal Entity B’s Intercompany Payable. Keep them as dedicated control accounts (posted only by the engine), reconcile them regularly, and tag them so they’re eliminated in consolidation — they’re internal, not third-party balances. (For the same reason they’re Excluded from the cash flow statement.)

Fixed assets & depreciation

This is where the most accounts — and the most setup mistakes — live. In REDA you define an Asset Type (an asset class: buildings, vehicles, IT equipment, software…) and map its full lifecycle of GL accounts once; every asset of that class then posts to them automatically. Each Asset Type needs seven accounts:

GL mapping	Type	When it posts
Asset GL (cost)	Non-current Asset	Debited when the asset is capitalised.
Accumulated Depreciation	Asset — contra (Credit)	Credited each period as the asset depreciates.
Depreciation Expense	Operating Expense	Debited each period.
CWIP / Clearing	Non-current Asset	Holds cost before capitalisation (construction/PO receipts).
Impairment	Expense	When the asset is written down.
Disposal Gain / Loss	Other Income / Expense	On sale or retirement.
Revaluation Surplus	Equity (OCI)	On an upward revaluation.

The recurring entries these accounts drive:

Each period — depreciation: Dr Depreciation Expense  /  Cr Accumulated Depreciation
Capitalisation: Dr Asset (cost)  /  Cr CWIP (or AP / Cash)
Disposal: remove cost & accumulated depreciation, recognise the difference vs. proceeds in Disposal Gain/Loss
Revaluation (upward): Dr Asset  /  Cr Revaluation Surplus (equity)

Tangible vs. intangible — same structure, different class Intangible assets (software, licences, patents) use the same seven-account structure — “depreciation” is simply amortisation, and the Accumulated Depreciation / Depreciation Expense accounts serve as accumulated amortisation / amortisation expense. Best practice: create separate Asset Types for tangible and intangible classes, each with its own account set, so your statements show PP&E and intangibles distinctly. Goodwill is a special case — it is not amortised, only impairment-tested, so its Asset Type needs no depreciation accounts.

Multi-ledger depreciation If you depreciate differently for book, tax, and IFRS, each depreciation rule posts to its own ledger — so the same asset can carry a Book, a Tax, and an IFRS depreciation schedule simultaneously, each hitting the accounts above in its ledger. Map the accounts once per Asset Type; the ledger separation is handled for you.

Banking

Bank and cash accounts (Asset, with the Bank Account flag and a Cash Flow Category of Excluded), plus any in-transit / clearing and reconciliation-suspense accounts. Mapped on the Bank Account record.

5. Multi-currency & consolidation accounts

Every transaction is recorded in its entity’s functional currency, with the corporate-currency equivalent always carried for consolidation. Your chart needs a few currency-specific accounts:

FX Gain / Loss — provide a Realized account (when the settlement rate differs from the invoice rate). Map it on the entity. Type is Other Income / Expense.
Foreign Currency Translation Reserve (CTA) — an Equity (Other Equity Components) account used when consolidating entities whose functional currency differs from the corporate currency.
Exchange rates must be loaded and kept consistent — a stale or inverted rate silently skews the corporate-currency figures.

Consolidation tip: use the Consolidation Account Code on each GL account to map it to your group’s consolidation system, so subsidiary accounts roll up cleanly.

6. Common pitfalls to avoid

These are the configuration mistakes seen most often — each one produces wrong or misleading numbers:

Pitfall	Why it’s wrong
Asset GL mapped to Cash or AP	Capitalisation then debits cash/payables — meaningless. The Asset GL must be a non-current fixed-asset account.
Accumulated Depreciation mapped as a Liability	It’s a contra-asset (Asset type, Credit balance). Mapping it as a liability inflates payables.
Missing Revaluation Surplus / Impairment account	The engine blocks the posting (good) — but set them at config time so you’re never stuck mid-process.
Inconsistent or inverted exchange rates	The corporate-currency tier silently skews. Audit your rates for direction and magnitude.
A GL account per department / property	Use posting dimensions instead. Keep the chart lean.
Hand-posting a manual JE into a control account for routine changes	It’s permitted, but prefer the subledger for everyday adjustments so AR/AP stay reconciled. Reserve manual entries for true adjustments and reconcile after.

7. Start from the seeded chart

You don’t build from a blank page. REDA ships a complete, IFRS-aligned starter chart — with the standard accounts already created and pre-mapped to the default Asset Types, tax, FX, control, and intercompany slots — plus an IFRS reporting framework. Adopt it, extend it, or replace it; it’s a starting point, not a lock. Starting from the seed closes the most common gap of all — accounts that simply don’t exist yet — without imposing a chart on you.

The controller’s checklist Before go-live: every account has a Type, Sub-Type, and Normal Balance; control accounts are flagged; entity defaults are mapped; every Asset Type has its seven GLs; tax, WHT, and bank accounts are mapped; FX and CTA accounts exist; and you’ve posted a sandbox dry-run transaction per module and inspected the result. Tick those, and your chart is ready.

Where to go next

Understanding GL Accounts — the record your chart is built from.
GL Account Types & Sub-Types — classify every account correctly.
Creating & Managing GL Accounts — add accounts as you grow.
Control Accounts (AR & AP) — the accounts that track subledgers.
Posting Dimensions — slice data without extra accounts.
Reporting Frameworks & Taxonomy — present the chart as statements.

Frequently asked questions — optimising your chart

There’s no magic number, but the test is simple: an account should exist because it’s a distinct line on a financial statement or a distinct accounting treatment — not because you want to analyse by something. Most mid-size entities run comfortably on a few hundred accounts. If you’re heading into the thousands, you’re almost certainly encoding analysis (department, branch, project) that belongs in dimensions instead.

No — this is the single biggest optimisation in REDA. Keep one Rent Expense, one Salaries account, and tag each posting with the department, branch, or property as a posting dimension. You then report P&L by that dimension without multiplying accounts. A chart of 300 accounts × 10 dimensions gives you the analysis of 3,000 accounts with none of the maintenance.

Default to global — one shared, standardised chart that every entity uses keeps your consolidation clean and your reporting consistent. Create an entity-specific account only when one company genuinely needs an account the others don’t (a local statutory account, say). Resist forking the whole chart per entity; that’s a maintenance and consolidation headache.

Granular enough that your statutory statements and your management view read clearly — and no more. Split where the accounting or presentation differs (product revenue vs. service revenue; cost of sales vs. operating expense). Push everything else — by customer, by region, by salesperson — to dimensions and to the product/line GL mapping, which already defaults the right revenue/expense account per line.

No. Each entity has one functional currency, and the shared chart records every posting in that currency with the corporate-currency equivalent carried automatically for consolidation. You don’t create “AR — USD” and “AR — EUR” accounts — one AR account serves all currencies, and the FX gain/loss and translation-reserve accounts handle the currency effects.

No — you map accounts at the Asset Type (class) level, not per asset. All buildings share one set of asset/depreciation accounts; all vehicles share another. Individual assets live in the asset register (the subledger) and report by dimension. Creating a GL per asset is the proliferation anti-pattern applied to fixed assets — avoid it.

Map the legacy chart to REDA’s lean, standards-based chart and convert the “analysis” segments of your old account codes into dimensions. A legacy code like 6100-200-ProjectX (expense-department-project) becomes one 6100 account plus a department and a project dimension. Use the Account Code field to carry your old reference for traceability, and bring opening balances in against the slimmed chart.

Yes — deactivate accounts you no longer use (never delete one with history), and move any analysis you were doing through accounts onto dimensions. You can’t merge posted history across accounts, so the cleaner your chart is at go-live the better — which is exactly why the sandbox dry run in step 3 is worth the time.

Was this article helpful?