Understanding GL Accounts
The GL Account (general ledger account) is the most important record in REDA Financials AI. It is the building block of your chart of accounts — the structured list of every account your organisation uses to classify money as it moves. Every posting the system makes, every line on every financial statement, and every number your auditor checks ultimately traces back to a GL account.
Because the chart of accounts sits at the centre of everything, REDA doesn’t treat a GL account as a simple label. Each account carries a layered, standards-based classification that tells the system exactly what kind of account it is — which financial statement it belongs on, how it behaves in double-entry, how it maps to regulatory taxonomies, and where it appears in the cash flow statement. Set up correctly, this classification means your statements are compliant by design, not by manual rework at period end. This article explains what a GL account is and walks through every field on the record.
Access you'll need. Any REDA Financials permission set can view GL accounts; creating, editing, or deactivating them 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 change them.
Built on global accounting standards
REDA Financials AI is engineered as a standards-compliant accounting platform. The structure of a GL account is not a REDA invention — it follows the frameworks that govern financial reporting worldwide, so the books you keep here are ready for statutory audit, group consolidation, and regulatory filing in any jurisdiction.
| Standard | How REDA applies it |
|---|---|
| IFRS & IAS 1 Presentation of Financial Statements |
The Type → Sub-Type → Sub-Type 2 classification spine and the IFRS Category field map every account to the current/non-current line items IAS 1 prescribes for the Statement of Financial Position and the Statement of Profit or Loss. |
| IAS 7 Statement of Cash Flows |
The Cash Flow Category field tags each account as Operating, Investing, Financing, or a non-cash adjustment — so the cash flow statement is generated under the indirect method without manual reclassification. |
| US GAAP ASC framework |
The same classification model supports a US GAAP chart. REDA ships a parallel GAAP reference chart, and the reporting framework layer lets one chart be presented under IFRS and US GAAP without duplicating accounts. |
| Double-entry bookkeeping the universal rule |
The Normal Balance of every account is derived from its Type and enforced by the posting engine: every transaction balances debits against credits, and accounting entries are immutable once posted. |
| XBRL & consolidation regulatory filing |
The IFRS Category supports XBRL-style taxonomy tagging for regulatory filing, and the Consolidation Account field lets each account carry its parent-company group code for roll-up. |
The anatomy of a GL account
The fields on a GL account fall into four groups. The most important is the classification spine — it decides everything about how the account behaves and reports. The rest control scope (who can use the account), behaviour flags (special handling), and reference & lifecycle data.
1. The classification spine
These fields answer the question “what kind of account is this?” They drive financial statement presentation, the account’s debit/credit behaviour, and its regulatory tagging. A companion article, GL Account Types & Sub-Types, lists every available value.
| Field | What it controls |
|---|---|
| Type required |
The top-level classification: Asset
(resources owned), Liability (obligations
owed), Equity (ownership interest),
Revenue (income earned), or
Expense (costs incurred). Type drives the
Normal Balance and decides whether the account lands on the
Balance Sheet or the Income Statement.
Locked after the first transaction posts — so the books can’t be retroactively reclassified. |
| Sub-Type required |
Categorises the account within its Type for statement presentation — for example, within Asset: Current Assets (expected to convert to cash within 12 months) versus Non-Current Assets (long-term). This is the IAS 1 current/non-current split. Your Sub-Type choice controls which Sub-Type 2 values are available. |
| Sub-Type 2 optional |
Pinpoints the specific IFRS statement line item — e.g. Trade and other receivables, Property, plant and equipment, Revenue from contracts with customers. This is the most granular level of the built-in taxonomy and is what financial statements group on when no custom framework is in use. |
| Normal Balance system-set, read-only |
Whether the account naturally carries a Debit or Credit balance. REDA calculates this automatically from the Type — Assets and Expenses are Debit; Liabilities, Equity and Revenue are Credit — and you can’t edit it. See the note on contra accounts below. |
| IFRS Category optional |
The IFRS financial statement line item the account maps to, used for regulatory reporting and XBRL filing (XBRL is the standardised electronic format regulators require for statutory financial filings). Where Sub-Type 2 drives REDA’s own statements, IFRS Category is the bridge to external regulatory taxonomies. Refer to your auditor if unsure of the correct classification. |
| Cash Flow Category optional |
How the account is treated on the IAS 7 cash flow statement: Operating (day-to-day flows), Investing (long-term assets), Financing (debt and equity), Non-Cash (depreciation, provisions — added back under the indirect method), or Excluded (cash/bank and intercompany balances). Detailed in Cash Flow Categories (IAS 7). |
2. Scope — who can use the account
A GL account can be shared across your whole organisation or restricted to one region or one entity. This 3-tier scoping lets a global chart coexist with country-specific accounts (a local tax account, say) without forking the whole chart. There are three ways to scope an account:
| Scope | Entity | Territory | Use it when… |
|---|---|---|---|
| Global | — | — | The account applies everywhere — your standard, shared chart. The right default for most accounts. |
| Territory-wide | — | Set | The account belongs to one region — e.g. a local VAT account that every entity in that country shares. |
| Entity-specific | Set | Matches the entity | The account belongs to a single company — one entity needs an account the others don’t. |
Two fields set this, plus a system-managed code that drives sharing:
| Field | What it controls |
|---|---|
| Entity | Leave blank for a global account available to all entities. Select an entity to restrict the account to that entity only — the entity must be active, and postings for any other entity to this account are rejected. |
| Territory | Leave blank for a global account, or select a territory to restrict the account to entities within that region. If you set both Entity and Territory, the entity’s territory must match. The three combinations give you: global (neither set), territory-wide (territory only), and entity-specific (both set). |
| Territory Full Code system-managed |
A read-only code stamped automatically from the territory’s Full Code. REDA uses it to drive sharing rules so the right people see the right regional accounts. You never edit this directly. |
How REDA enforces scope when you post
Scope isn’t just a label — it’s enforced from selection all the way through posting, so an account can never be used where it doesn’t belong:
- You can only pick active accounts. The GL Account lookups on transaction lines filter to active accounts only. Deliberately, they do not filter by type or flag — your accounting controller keeps full freedom over which account fits which entry, and the save-time and posting-time checks below catch anything out of scope.
- Posting re-checks every line. When a transaction posts, the engine verifies each line’s account is active and in scope: a global account is valid for any entity, while an entity-specific account must match the entity being posted. A mismatch is rejected before anything reaches the ledger.
- Sharing controls who even sees regional accounts. Each account carries its territory code, which drives Salesforce sharing — so a user working in one region sees that region’s accounts and the global ones, not another region’s.
3. Behaviour flags
Four checkboxes give an account special handling. They are how REDA protects the integrity of your ledger — keeping control accounts clean, tax postings segregated, and bank accounts reconcilable.
| Field | What it controls |
|---|---|
| Control Account | Identifies a subledger- or schedule-driven account — e.g. Accounts Receivable, holding a running balance that clears as items are applied, recognised, or settled. The flag tells REDA to treat it as a control account for financial-statement grouping and AR/AP exposure reporting. It is a classification marker, not a posting block — manual entries are permitted but best avoided for routine changes. See Control Accounts (AR & AP). |
| Bank Account | Check only if the account represents a real bank account, petty cash float, or cash equivalent that will appear on bank statements and be reconciled. Do not check it for clearing, suspense, or intercompany accounts. A bank account must be classified as an Asset. |
| Tax Related | Marks the account as used for tax postings (VAT, GST, WHT, etc.). Tax is resolved and posted by the tax engine rather than chosen by hand, so the flag keeps these accounts identified for tax classification and reporting. |
| Active defaults to on |
Whether the account can receive new postings.
Uncheck to deactivate — historical transactions stay
visible in reports, and you can reactivate at any time. This is
how you retire an account you no longer use.
Deactivate, never delete, an account that has transaction history. |
4. Reference & documentation
| Field | What it controls |
|---|---|
| GL Account Name required |
The human-readable name of the account, e.g. Trade Receivables — Third Party. Your naming convention is owned by your accounting controller. |
| Code required |
A unique code used for seeding, integrations,
and cross-referencing — e.g. 1200-AR-GLOBAL,
2311-CGST-IN. Acts as a stable external key, so
re-running the seed or importing data matches accounts by code
rather than by name. Must be unique across the org. |
| Consolidation Account Code | The matching account code from your parent company or group consolidation system. Used during financial consolidation to map this subsidiary account to a group-level account. Leave blank if consolidation doesn’t apply. |
| Description required |
A clear statement of the account’s purpose — what it represents, what should be posted here, and any special rules (e.g. “VAT collected on standard-rated sales; do not post exempt sales here.”). REDA requires this so every account is self-documenting for the next person — and for the auditor. |
Keep the chart lean: dimensions, not accounts
The single most valuable habit when designing your chart is to resist creating an account for every department, property, project, or cost centre. That path leads to a 10,000-account chart that is impossible to maintain and meaningless to read.
Where to go next
- GL Account Types & Sub-Types — how every account is classified.
- Creating & Managing GL Accounts — add and edit accounts by hand.
- Control Accounts (AR & AP) — the special accounts that track pending items.
- Chart of Accounts Setup Best Practices — design a chart that scales.
- GL Account Groups & Members — gather accounts into statement lines.
- Trial Balance — see every account balance at once.
Frequently asked questions
Because Type drives the Normal Balance and decides which financial statement the account sits on. Once transactions have posted, changing the Type would retroactively reclassify history and break the integrity of your books. If an account was set up wrong, deactivate it and create the correct one — that keeps a clean audit trail.
They’re optional, but recommended. The built-in Type → Sub-Type → Sub-Type 2 spine already lets REDA produce your core statements. IFRS Category adds regulatory/XBRL tagging, and Cash Flow Category is what makes the cash flow statement generate automatically. Fill them in for accounts that feed statutory reporting.
A global account (no Entity set) is available to every entity — ideal for a shared, standardised chart. An entity-specific account (Entity set) exists only for that entity, for cases where one company needs an account the others don’t — posting it from any other entity is rejected by the posting engine.
No. Uncheck Active instead. Deleting an account with transaction history would orphan that history and compromise your audit trail. Deactivating stops new postings while keeping every historical figure intact and reportable.
Was this article helpful?