Ledger Management
A ledger is the book a transaction belongs to. Every accounting transaction REDA posts is stamped with exactly one ledger — which means a ledger isn’t a setting or a folder, it’s a complete, self-balancing partition of your entire general ledger. You can produce a full set of financial statements from each one.
For most organisations there’s a single ledger and you barely think about it. But the moment you need to keep your books on more than one basis at the same time — IFRS and local GAAP, book and tax — ledgers are what make that possible without duplicating a single account.
Access you'll need. Creating and managing ledgers 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 ledgers but not change them.
Why you’d keep more than one ledger
Multiple ledgers exist for parallel accounting — the same business activity recorded under different rules, side by side:
| Use case | Why a separate ledger |
|---|---|
| Multiple standards | IFRS vs local GAAP vs US GAAP — depreciation, leases, and revenue recognition can differ. A ledger per basis lets you produce statutory accounts under each. |
| Tax vs book | Tax-basis figures (e.g. accelerated tax depreciation) kept separately from your book numbers. |
| Management view | Internal allocations or adjustments you don’t want in the statutory books. |
| Budget | Planned amounts held in a Budget ledger and compared against actuals. |
How the ledger gets onto a transaction
You rarely choose a ledger by hand — REDA resolves it for you, in a clear order of precedence:
An explicit ledger on the document, if you set one
Every source document (journal entry, invoice, receipt, payment, purchase order, asset entry) carries a Ledger field you can set — useful to direct a specific entry to a specific book.
Otherwise, the entity’s default ledger
Each entity has a Default Ledger — its primary book. Left blank on the document, the entity’s default is used.
Otherwise, the org-wide default
If the entity has no default set, REDA falls back to the one ledger marked as the org-wide default.
Whichever is resolved, that ledger is then stamped onto every Accounting Transaction the document produces — so the book a figure lives in is always explicit and auditable on the record itself.
Reporting is per ledger
Because every transaction belongs to one ledger, your financial statements are produced for a chosen ledger. When you run a Trial Balance, Income Statement, Balance Sheet, or Cash Flow, you pick the ledger (it defaults to the entity’s primary), and the statement reflects only that book. Run the same report against a second ledger and you get that basis’s view — same chart, same entities, different books.
The ledger record
| Field | What it controls |
|---|---|
| Ledger Code | A short, unique code (max 10 chars) — e.g. TXN,
BDG, APAC-AU-TXN. It’s used in
reports and acts as the ledger’s partition key. |
| Type | Transaction (actual entries) or Budget (planned amounts). |
| Default Ledger | Marks the org-wide fallback. It must be an active Transaction ledger, and you should keep exactly one flagged so the fallback is unambiguous. (Each entity also has its own default, which takes precedence.) |
| Territory | The territory the ledger serves — used for record-level access. Set once and not changed; leave blank for a global ledger. |
| Active | Whether the ledger can receive new postings. Turn off to retire a ledger — historical transactions stay visible, but nothing new posts to it. |
| Description | What the ledger is for — helpful once you run more than one. |
Creating & managing ledgers
On the Ledgers tab, click New to create one, set its code, type, territory, and whether it’s the default, then Save. To point an entity at a ledger, set the entity’s Default Ledger on the entity record.
The rules that keep ledgers clean
These are the exact messages REDA raises when a ledger setup or posting would break the model, with the fix alongside:
| The message | What it means / what to do |
|---|---|
| “Ledger Code cannot contain spaces. Use hyphens or underscores as separators (e.g. TXN, APAC-AU-TXN).” | Codes are identifiers, not names — reformat the code. |
| “The default ledger must be active. Activate this ledger before marking it as default, or remove the default flag before deactivating.” | An inactive fallback would strand postings — fix the flag or the Active box, in that order. |
| “Only a Transaction ledger can be set as the default. Budget ledgers cannot be the default — they never receive posted ledger entries.” | Budget books hold plans, never actuals — pick a Transaction ledger as the default. |
| “Territory cannot be changed once assigned to a ledger. Create a new ledger if a different territory scope is needed.” | A book’s scope is fixed for life — retire this ledger and create one with the right territory. |
| “No active ledger found. Please configure a default ledger for entity … or the organization.” | A posting couldn’t resolve any ledger — set the entity’s Default Ledger, or flag an org-wide default. |
| “The specified ledger is not active. Please select an active ledger.” | The document names a retired ledger explicitly — clear the field or choose an active book. |
Best practices
- One primary Transaction ledger per entity, unless you truly keep parallel books. Most organisations need exactly one. Add a second Transaction ledger only when you genuinely report on more than one basis (IFRS + local GAAP, or book + tax).
- Make the codes meaningful. Since the code is your
partition key and shows on reports, use clear codes (
TXN,IFRS,TAX) and describe each ledger’s purpose. - Set one org-wide default, and a default per entity. That makes the resolution path predictable for every posting.
- Retire, don’t delete. Deactivate a ledger you no longer post to — its history stays intact and reportable.
Where to go next
- Accounting Periods — periods a ledger posts into.
- Closing the Books — how ledgers behave when a period closes.
- How Posting Works — how a ledger is stamped on each entry.
- Accounting Transactions — the entries a ledger holds.
Frequently asked questions
Almost certainly not, to start. Most customers run a single primary Transaction ledger per entity. Add a second only when you genuinely keep parallel books — for example reporting under both IFRS and a local GAAP, or maintaining a separate tax basis.
Set the Ledger field on the document (e.g. a journal entry) to the ledger you want. Leave it blank and it defaults to the entity’s primary ledger. The chosen ledger is then stamped on the resulting accounting transactions.
A Transaction ledger holds your actual postings — the real books. A Budget ledger holds planned figures to compare against actuals. Real transactions only ever post to Transaction ledgers.
Reports are run per ledger — you choose which book to view, and the statement reflects only that ledger. To compare bases, run the same report against each ledger. (A combined session-level ledger view is a planned enhancement.)
A ledger’s territory drives record-level access and is fixed once set, and only an active Transaction ledger can be the default — both rules keep posting and access behaviour unambiguous. If you need a different territory, create a new ledger.
Was this article helpful?