Understanding Accounting Defaults
Accounting defaults are the set of GL accounts REDA Financials reaches for automatically when it posts — your receivables control, payables control, cash, revenue and expense fallbacks, foreign- exchange account, and more. You define them once, and every entity you create inherits them. This article explains why that matters, how defaults work at the global and territory levels, and exactly which accounts are defaulted.
Access you’ll need. Any REDA Financials permission set can view your defaults; setting or changing them requires the Accounting Admin v2 or Accounting Controller v2 permission set.
Why accounting defaults exist
The reason is standardisation. Every accounting transaction needs to know which control and clearing accounts to use — and you don’t want each entity (or each user) deciding that independently. By setting the defaults once at the top, you get:
- Consistency. Every entity posts receivables, payables, cash, FX, and intercompany to the same kind of account, so your books and consolidations line up.
- Speed. New entities are ready to transact immediately — their default accounts are filled in for you, not configured by hand each time.
- Fewer errors. Posting always has a correct account to fall back on, so transactions don’t fail or land in the wrong place because someone forgot to map an account.
Two levels: global and territory
Defaults are defined at two levels, so you can standardise across the whole organisation while still allowing regional differences:
- Global defaults — one organisation-wide set that applies everywhere by default. This is your baseline.
- Territory defaults — an optional set per territory, for regions that need different accounts (a different cash or tax account, say). A territory’s defaults override the global ones, and a child territory’s override its parent’s.
When you create an entity, REDA resolves its defaults from the most specific match first — child territory, then parent territory, then global — and copies the resulting accounts onto the entity. From then on, the entity posts to its own accounts. The mechanics are covered in How Defaults Flow to Entities.
Every defaulted account, explained
Here is the full set of accounts (and two settings) that the defaults cover — and exactly where REDA uses each one.
Control accounts
| Default | What it is & where it’s used |
|---|---|
| AR Account | Your Accounts Receivable control account — debited on every sales invoice you post. |
| AP Account | Your Accounts Payable control account — credited on every purchase invoice (bill) you post. |
| Cash Account | The default cash / bank account — debited when you record a cash receipt, credited when you record a cash disbursement. |
Revenue & expense fallbacks
| Default | What it is & where it’s used |
|---|---|
| Revenue Account | The fallback revenue account used for a sales-invoice line when its product has no specific GL mapping — so income always lands somewhere sensible. |
| Expense Account | The fallback expense account used for a purchase-invoice line when its product has no specific GL mapping. |
Prepayments & unapplied amounts
| Default | What it is & where it’s used |
|---|---|
| Unapplied Cash | A liability account credited when a customer cash receipt is posted without being applied to an invoice — i.e., a customer prepayment or deposit you owe back as goods/services. |
| Unapplied Payments | An asset account debited when a vendor payment is posted without being applied to a bill — i.e., a prepayment to a vendor. |
Deferral (cash-basis entities)
| Default | What it is & where it’s used |
|---|---|
| Deferred Revenue | A current-liability account for revenue invoiced but not yet earned (cash not yet received). Used when an entity’s accounting basis is cash. On a cash-basis sales invoice the posting engine parks revenue here at invoice date and releases it to the revenue account only when the cash receipt is applied. |
One quirk to know: the Deferred Revenue default is not on the Global Accounting Defaults form. If you run cash-basis entities, set their Default Deferred Revenue Account on the entity itself (the system requires it: “Cash basis entities require a Default Deferred Revenue Account. Configure it in the Default GL Accounts section before saving.”).
Period-end, FX & intercompany
| Default | What it is & where it’s used |
|---|---|
| Retained Earnings | The equity account the year-end close rolls the year’s net income into. |
| FX Gain / Loss | Where foreign-currency gains and losses are posted — used in multi-currency operations. |
| Intercompany Receivable | The account for intercompany receivables auto-generated when you post an intercompany journal entry. |
| Intercompany Payable | The account for intercompany payables auto-generated alongside the receivable on an intercompany posting. |
Ledger & framework
Two of the defaults aren’t GL accounts — they set where and how an entity reports:
| Default | What it is & where it’s used |
|---|---|
| Ledger | The transaction ledger new entities post to by default. |
| Reporting Framework | The default reporting standard (IFRS, US GAAP, or a local GAAP) new entities report against. |
Setting and reviewing your defaults
There are two places to manage defaults, matching the two levels:
- Global defaults — on the Financial Setup tab of the Financial Admin Console, under Global Accounting Defaults. This is where you review the accounts seeding filled in and change any of them. See Configuring Accounting Defaults.
- Territory defaults — on the Territory Management tab, use a territory’s Defaults action to set accounts that should differ for that region. Leave it unset and the territory simply uses the global defaults.
Where to go next
- Configuring Accounting Defaults — set the defaults up.
- How Defaults Flow to Entities — trace defaults onto records.
- Understanding Territories — where defaults are anchored.
- Creating & Managing Territories — build your hierarchy.
Frequently asked questions
No. Defaults are copied onto an entity when it’s created, and the entity then owns its accounts. Changing a default afterward affects new entities created from then on — existing entities keep the accounts they were given (you can update those on the entity directly). That’s why it’s best to review defaults before creating entities.
Only if a region needs different accounts from your global baseline. Many organisations run entirely on the global defaults. Add territory defaults when, say, one country should post cash or tax to a different account — the territory set overrides the global one for entities in that territory.
That’s exactly what the Revenue and Expense fallback defaults are for. If a line’s product doesn’t carry its own GL mapping, REDA posts it to the default revenue or expense account so the transaction still balances and posts cleanly.
Only for entities whose accounting basis is cash. Accrual-basis entities recognise revenue as it’s invoiced, so they don’t use the deferral account. Note that cash basis applies to the sales (AR) side only — there is no deferred-expense equivalent because purchases are always recognised at invoice acceptance.
They cover the core, but the entity record carries a few entity-only defaults that aren’t part of the global or territory set — such as the Default Bank Account, realized and unrealized FX accounts, withholding-tax payable and receivable accounts, and sales/purchase discount accounts. Those are set directly on each entity as the relevant features come into use.
Yes. The one-record-per-scope limit applies only to active records, so you can create the future configuration as an inactive defaults record, review it at leisure, then deactivate the old record and activate the new one when you’re ready. Remember it will affect only entities created after the switch.
Was this article helpful?