Key Concepts & Terminology

This article explains the core concepts and terminology you will encounter throughout REDA Financials AI. Whether you are an accounting professional or a system administrator setting up the platform for the first time, understanding these foundational ideas will help you navigate the application confidently.

Organisational structure

REDA Financials organises your business into a three-level hierarchy: Territories contain Entities, and Entities own all financial transactions. Understanding this hierarchy is the first step to configuring the system.

Territory

A Territory represents a geographic or regulatory region — typically a country. Territories are organised in a two-level hierarchy: a parent territory (e.g. “Asia Pacific”) can contain child territories (e.g. “India”, “Singapore”). Each territory has a unique Territory Code (e.g. IN, US) and a system-generated Full Code that includes its parent (e.g. APAC-IN).

Territories serve two important purposes:

• They scope Accounting Periods — each territory has its own set of open and closed periods, so your India subsidiary can close its books independently of your US operations.
• They carry regional business policy settings such as whether grouped posting is enabled, whether aging snapshots are generated, and OCR confidence thresholds.

Entity

An Entity represents a legal company or subsidiary. It is the most important concept in REDA Financials — every financial transaction belongs to exactly one entity.

Each entity carries its own:

• Functional currency — the currency in which the entity reports (e.g. INR for an Indian subsidiary, USD for a US subsidiary)
• Accounting basis — Accrual or Cash (see Accrual vs. Cash Basis below)
• Default GL Accounts — a set of approximately 20 default accounts (AR Control, AP Control, Cash, Revenue, Expense, Discount, WHT, Intercompany, Retained Earnings, and more) that are automatically applied to transactions when no account is specified
• Territory — the territory this entity belongs to, which determines its accounting period schedule
• Fiscal year start month — entities can have different fiscal years (e.g. April–March in India, January–December in the US)

Master data

Master data records are the building blocks that all transactions reference. You set these up once and reuse them across every invoice, receipt, purchase order, and journal entry.

Product

A Product represents a good, service, subscription, digital item, or capital asset that your organisation buys or sells. Products are the link between what you trade and how it is recorded in your books. When you select a product on an invoice or purchase order line, the system automatically fills in:

• Default Revenue GL Account — the GL account to credit on sales (e.g. “Product Revenue”)
• Default Expense GL Account — the GL account to debit on purchases (e.g. “Cost of Goods Sold”)
• Unit of Measure — how the product is measured (Each, Hour, Day, Month, Kilogram, etc.)
• List Price — the standard unit price (can be overridden per line)
• Description — pre-fills the line description on documents

Each product has a Type:

• Goods — physical items
• Service — labour, consulting, support
• Subscription — recurring time-based access
• Digital — software, licences, downloadable content
• Asset — capital expenditure items that create a Fixed Asset when received on a Purchase Order
• Other

Products can be restricted to a specific Territory or Entity, so region-specific or subsidiary-specific products only appear on the relevant documents. Each product also has a unique Product Code used for data imports and integrations.

Customer & Vendor

Customers and Vendors are stored as standard Salesforce Account records. The same Account can act as both a customer (you sell to them) and a vendor (you buy from them). Accounts carry Tax Profiles and WHT Rules that determine the tax and withholding treatment on their transactions.

Payment Term

A Payment Term defines when payment is due and whether an early-payment discount is available. Each term specifies:

• Net Days — the number of days after the invoice date by which payment is due (e.g. 30 for Net 30)
• Discount Days — the window within which the early-payment discount applies (e.g. 10 days)
• Discount Percent — the discount offered for early payment (e.g. 2%)

For example, a term of “2/10 Net 30” means the customer gets a 2% discount if they pay within 10 days; otherwise, the full amount is due in 30 days. Payment Terms are assigned to customers and vendors and automatically calculate the due date on each invoice.

General Ledger concepts

GL Account

A GL Account (General Ledger Account) is a category in your chart of accounts. Every financial transaction in REDA Financials is recorded against one or more GL accounts.

Each GL account has three defining properties:

• Type — one of five classifications: Asset, Liability, Equity, Revenue, or Expense. This determines which financial statement the account appears on (Balance Sheet or Income Statement).
• Sub-Type — a more specific classification within the type (e.g. Current Asset, Fixed Asset, Long-Term Liability). Sub-Types follow IFRS classification standards.
• Normal Balance — either Debit or Credit. This is set automatically by the system based on the account type. Asset and Expense accounts have a Debit normal balance; Liability, Equity, and Revenue accounts have a Credit normal balance.

Control Account

A Control Account is a GL account marked as a summary or header account. You cannot post transactions directly to a control account — it exists purely for reporting purposes. Sub-accounts within the same group are used for actual postings, and their balances roll up to the control account on financial statements.

Common examples include “Accounts Receivable Control” and “Accounts Payable Control”. The system manages these accounts automatically when invoices and payments are posted.

Normal Balance

Every GL account has a Normal Balance — the side (Debit or Credit) on which the account’s balance normally increases. This is a fundamental concept in double-entry bookkeeping:

In REDA Financials, the Normal Balance is set automatically when you choose the account type — you never need to set it manually.

Debit & Credit

Debit and Credit are the two sides of every accounting entry. In REDA Financials, every posted document produces one or more Accounting Transaction records, each with either a Debit amount or a Credit amount (never both). The golden rule of double-entry bookkeeping applies: total debits must always equal total credits for every posted document.

If you are new to accounting, think of it this way: when your company receives cash, the Cash account is debited (it goes up), and another account is credited (to balance the entry). When your company pays a bill, the Cash account is credited (it goes down), and the Expense or AP account is debited.

Accounting Period

An Accounting Period is a time window (typically one month) within a fiscal year. Each period is defined by a Start Date, End Date, and Period Number (1–12). Periods are scoped to a Territory, which means different regions can have different fiscal calendars.

Accounting Periods do not carry their own open/closed status. Instead, period closure is managed through three “Closed Through” date fields on each Entity:

• AP Closed Through — blocks posting of AP documents (Purchase Invoices, Cash Disbursements, Vendor Memos) on or before this date
• AR Closed Through — blocks posting of AR documents (Sales Invoices, Cash Receipts, Credit Memos) on or before this date
• GL Closed Through — blocks posting of Journal Entries on or before this date

Closing follows a specific sequence: Accounts Payable closes first, then Accounts Receivable, then the General Ledger. The GL Closed Through date can only advance after AP and AR have already advanced to that date.

Ledger

A Ledger is a container for Accounting Transactions. It is where your posted entries live. Every organisation has one default Transaction ledger, and entities can optionally have their own default ledger.

Ledgers are particularly important for Fixed Assets: each asset can maintain multiple depreciation rules, each posting to a different ledger (e.g. Book depreciation, Tax depreciation, IFRS depreciation). This allows you to track different depreciation schedules side by side without them interfering with each other.

Fiscal Year & Year-End Close

A Fiscal Year is your organisation’s 12-month accounting cycle. Each entity can start its fiscal year in any month — for example, April in India or January in the US.

At the end of a fiscal year, the Year-End Close process rolls forward your Balance Sheet balances and resets Income Statement accounts (Revenue and Expense) to zero. The net income or loss for the year is transferred to the Retained Earnings GL account. REDA Financials automates this process, generating the necessary closing journal entries.

Posting & transactions

Document Status lifecycle

Almost every financial document in REDA Financials (invoices, journal entries, purchase orders, payments) follows the same status lifecycle — Cash Receipts are the one exception, covered below:

• Draft — the document is being prepared. You can freely edit all fields and add, change, or remove lines. No impact on the General Ledger.
• Posted — the document has been finalised. Accounting Transactions are created in the General Ledger. The document is locked from most edits.
• Void — the document has been cancelled. All associated Accounting Transactions are reversed. The document is permanently locked.

The transition from Draft to Posted is called Posting. The transition from Posted to Void is called Voiding. Both actions are triggered by changing the Status field on the document.

Posting

Posting is the act of finalising a financial document and recording its impact in the General Ledger. When you post a document (by changing its status from Draft to Posted), the system automatically:

1. Validates the document (balanced entries, valid GL accounts, open accounting period, and more)
2. Creates one or more Accounting Transaction records — the immutable debit-and-credit entries that form your General Ledger
3. Locks the document to prevent further edits

All posting in REDA Financials flows through a single centralised Posting Engine. No matter which module you are working in — AR, AP, Journal Entries, or Fixed Assets — the same engine creates the Accounting Transactions. This guarantees consistency across the entire platform.

Accounting Transaction

An Accounting Transaction (AT) is an individual debit or credit entry in the General Ledger. These records are the foundation of your financial data — everything in REDA Financials ultimately produces Accounting Transactions.

Key characteristics:

• Immutable — once created, an Accounting Transaction can never be edited or deleted by any user, regardless of their permission set. This is a core audit control.
• Always balanced — for every document that is posted, total debits equal total credits.
• Traceable — every AT links back to its source document (the invoice, receipt, or journal entry that created it) and records the source type, entity, GL account, transaction date, and the user who posted it.

Each Accounting Transaction has a Transaction Type:

• Original — the primary entry created when a document is posted
• Reversal — an equal-and-opposite entry created when a document is voided or reversed

Voiding

Voiding cancels a posted document. When you void a document, the system deletes its original Accounting Transactions — effectively removing the document’s impact from the General Ledger. The document itself remains in the system with a status of Void for audit purposes, but it no longer affects any account balances.

Voiding is only allowed when the transaction date falls after the entity’s Closed Through date. If the period has been closed, you must use a Reversal instead (which creates new equal-and-opposite entries dated in a period that is still open).

Document Sequence

A Document Sequence provides automatic, sequential numbering for your financial documents. Each sequence is configured per entity and per document type, and can include a prefix, a number format, and an optional year component.

For example, Meridian Properties Group India might number its sales invoices as MI-IN-SI-2026-0001, MI-IN-SI-2026-0002, and so on. The sequence increments automatically each time a new document is created.

Source documents

Source documents are the financial records you create and work with daily. Each source document type serves a specific purpose, and when posted, generates Accounting Transactions in the General Ledger.

Accounts Receivable (AR)

Sales Invoice

A Sales Invoice records revenue earned from a customer. It can be one of two types:

• Invoice — a standard sales invoice (e.g. you delivered goods or services and are billing the customer)
• Receipt — a cash sale where payment is received at the time of the transaction

When posted, a Sales Invoice debits the AR Control account and credits the Revenue account (under accrual basis). It can carry tax lines, withholding tax, and custom dimensions.

Credit Memo

A Credit Memo reduces the amount a customer owes. In REDA Financials, a Credit Memo is a special type of Sales Invoice (with the type set to “Credit Memo”). It reverses the accounting entries of an invoice — crediting AR and debiting Revenue. Credit Memos can be applied to outstanding Sales Invoices to reduce their balance.

Cash Receipt

A Cash Receipt records money received from a customer. When posted, it debits the Cash/Bank account and credits the AR Control account. Cash Receipts can be applied to one or more Sales Invoices to settle outstanding balances.

Accounts Payable (AP)

Purchase Order

A Purchase Order (PO) is a commitment to purchase goods or services from a vendor. Unlike invoices and receipts, a posted Purchase Order does not create Accounting Transactions in the General Ledger — instead, it commits budget (if budget controls are enabled) and serves as the basis for receiving goods and matching against Purchase Invoices.

Purchase Invoice

A Purchase Invoice records an obligation to pay a vendor. It can be one of three types:

• Invoice — a vendor bill matched against a Purchase Order
• Expense — a direct expense not tied to a Purchase Order (e.g. utilities, office supplies)
• Vendor Memo — a credit note from a vendor that reduces the amount you owe

When posted, a Purchase Invoice debits the Expense (or inventory) account and credits the AP Control account.

Cash Disbursement

A Cash Disbursement records a payment made to a vendor. When posted, it debits the AP Control account and credits the Cash/Bank account. Cash Disbursements can be created individually or as part of a Batch Payment Run that processes multiple vendor payments at once.

Vendor Memo

A Vendor Memo is a credit note from a vendor that reduces the amount you owe. In REDA Financials, a Vendor Memo is a special type of Purchase Invoice (with the type set to “Vendor Memo”). It can be applied to outstanding Purchase Invoices to reduce their balance.

Journal Entry

A Journal Entry (JE) is a manual accounting adjustment. Unlike invoices and receipts, which generate their accounting entries automatically, a journal entry lets you specify the exact debit and credit lines yourself. Common uses include period-end accruals, reclassifications, intercompany transfers, and corrections.

Each Journal Entry contains one or more Journal Entry Lines, each with a GL account and either a debit or credit amount. The total debits must equal total credits before the entry can be posted.

Applications & settlements

Application

An Application is the act of linking a payment or credit to an invoice to settle (or partially settle) the outstanding balance. REDA Financials tracks four types of application:

• Cash Receipt Application — applying a customer payment to a Sales Invoice
• Credit Memo Application — applying a Credit Memo to a Sales Invoice
• Cash Disbursement Application — applying a vendor payment to a Purchase Invoice
• Vendor Memo Application — applying a Vendor Memo to a Purchase Invoice

Each application records the amount applied and creates the appropriate Accounting Transactions to reflect the settlement in the General Ledger.

Outstanding Balance

The Outstanding Balance (also called “Balance Due”) on an invoice is the amount that remains unpaid. It is calculated as the invoice total minus all payments and credits that have been applied. When the outstanding balance reaches zero, the invoice is fully settled.

Multi-currency

Three-tier currency architecture

When your organisation operates in multiple currencies, REDA Financials uses a three-tier model:

1. Document Currency — the currency the invoice or transaction is denominated in (e.g. a sales invoice to a UK customer might be in GBP)
2. Entity Currency — the functional currency of the entity that owns the transaction (e.g. INR for Meridian Properties Group India)
3. Corporate Currency — the group-level reporting currency used for consolidated reporting (e.g. USD)

When the document currency differs from the entity currency, the system automatically converts amounts using exchange rates. This ensures that your entity’s books are always in its functional currency, while the original transaction amounts are preserved for reference.

Exchange Rate

An Exchange Rate is the conversion factor between two currencies on a given date. REDA Financials uses dated exchange rates — meaning the rate applied to a transaction depends on the transaction date. Rates can be maintained manually or synced automatically from an external provider (e.g. Open Exchange Rates).

Tax concepts

Tax Engine

REDA Financials includes a three-layer Tax Engine that calculates taxes on invoices and purchase orders:

1. Tax master data — Jurisdictions (countries/regions where taxes apply), Tax Types (e.g. Standard VAT, Reduced VAT, GST), and Fiscal Operations (the type of transaction that triggers taxation)
2. Tax Rules — the calculation rules that combine a jurisdiction, a tax type, and a rate to determine how much tax to apply. A single rule can have multiple components (e.g. CGST + SGST in India).
3. Tax Profiles — assigned to customers and vendors to determine which tax rules apply to their transactions based on the jurisdiction and the type of goods or services

Tax amounts are calculated at the line level and stored as Source Line Tax records. When a document is posted, each tax component is recorded as a separate Accounting Transaction line with its own GL account.

Withholding Tax (WHT / TDS)

Withholding Tax (also known as TDS — Tax Deducted at Source, in India and similar regimes) is tax that is deducted from a payment before it reaches the recipient. In REDA Financials:

• Purchase-side WHT — deducted when you pay a vendor (on the Purchase Invoice)
• Sales-side WHT — deducted by your customer when they pay you (on the Cash Receipt)

WHT Rules define the rates and thresholds, and WHT Transactions track each deduction for reporting and compliance.

Accrual vs. Cash Basis

The Accounting Basis determines when revenue is recognised in your books. REDA Financials supports two methods, configured per entity:

• Accrual Basis (IFRS / GAAP standard) — revenue is recognised when earned, regardless of when payment is received. Posting a Sales Invoice immediately records revenue.
• Cash Basis — revenue is deferred until payment is received. Posting a Sales Invoice parks the amount in a Deferred Revenue account; revenue is recognised only when a Cash Receipt is applied to the invoice.

Fixed Asset concepts

Fixed Asset

A Fixed Asset is a long-term tangible asset owned by the company — such as equipment, vehicles, buildings, or furniture. In REDA Financials, fixed assets are created through the Purchase Order receipt process and follow a defined lifecycle:

• Under Construction — the asset has been received but not yet capitalised (awaiting final invoice and cost confirmation)
• Active — the asset has been capitalised and is depreciating
• Fully Depreciated — the asset has reached the end of its useful life but is still in service
• Impaired — the asset has been written down below its carrying amount (per IAS 36)
• Disposed — the asset has been sold, scrapped, or transferred out of the company

Depreciation

Depreciation is the systematic allocation of an asset’s cost over its useful life. Each asset carries a Depreciation Method (defaulted from its Asset Type, overridable per asset):

• Straight Line
• Declining Balance
• Double Declining Balance
• Written Down Value (Block)
• Immediate / Full Expense
• Units of Production (schedule entered manually)
• Manual (accountant builds the schedule)
• No Depreciation (land and other non-depreciables)

When an asset is activated, REDA generates its depreciation schedule as Asset Ledger lines using the method, convention, useful life, and residual value. A daily batch then posts each line to the General Ledger as it falls due — so the period’s depreciation lands in the books automatically.

Budget concepts

Budget

A Budget defines planned spending for an entity, a fiscal year, and a budget type (Operating, Capital, or Project). Each budget contains Budget Lines that allocate amounts to specific GL accounts.

REDA Financials tracks four amounts on each Budget Line:

• Budgeted — the planned amount
• Committed — the amount committed via approved Purchase Orders (updated automatically when a PO is posted)
• Actual — the amount spent via posted Purchase Invoices (updated automatically when a PI is posted)
• Available — Budgeted minus Committed minus Actual — the amount still available to spend

When Budget Enforcement is enabled (configured at the entity level), the system blocks Purchase Orders that would exceed the available budget.

Banking concepts

Bank Account

A Bank Account in REDA Financials represents a real-world bank or credit card account. It is linked to a Cash GL account and an entity. Bank accounts are used for reconciliation, payment processing, and statement import.

Bank Reconciliation

Bank Reconciliation is the process of matching transactions in your accounting system with entries on your bank statement. REDA Financials uses an AI-powered three-pass auto-matching engine:

1. By reference — matches based on invoice or receipt reference numbers
2. By date range — matches transactions within a date window
3. By amount — matches based on transaction amounts

Any unmatched items can be reviewed and matched manually. The system learns from your manual matching patterns to improve future auto-matching accuracy.

Intercompany transactions

When two entities within your organisation transact with each other — for example, Entity A pays an invoice on behalf of Entity B — this is called an Intercompany Transaction. REDA Financials automatically generates the offsetting Intercompany Receivable and Intercompany Payable Accounting Transactions to keep both entities’ books balanced.

Intercompany settlement requires bilateral consent — both entities must have the cross-entity settlement flag enabled on the relevant document. On Journal Entries, the system validates that debits and credits balance at the entity level for each entity referenced in the lines.

Platform concepts

Permission Sets

REDA Financials ships with five Permission Sets that control what each user can see and do. Rather than creating custom profiles, you assign one or more permission sets to each user:

• Accounting Admin — full access to every REDA Financials object, field, and feature; configures entities, GL, tax, territories, periods, and app settings
• Accounting Controller — full access to the general ledger, journals, banking, reconciliation, budgets, assets, aging, and master data; read access to AR and AP
• Accounts Receivable — manages sales invoices, credit memos, cash receipts, and applications
• Accounts Payable — manages purchase orders, vendor invoices and memos, and payments
• Read Only — read-only access to all data; designed for CFOs, directors, external auditors, and compliance officers

Segregation of Duties (SoD)

Segregation of Duties is an internal control that prevents a single person from handling both sides of a transaction. In REDA Financials, write access is split across the sets — Accounts Payable and Accounts Receivable are separate scopes, and banking and reconciliation belong to the Accounting Controller — so the person who reconciles bank statements need not be the same person who creates invoices or processes payments. Posted Accounting Transactions are read-only to every set, so no one can alter the ledger directly.

Configurable field lists & dimensions

REDA Financials uses configurable field lists extensively for extensibility — named lists an administrator can change without code. Three kinds shape a source document:

• Dimension list — custom accounting dimensions (e.g. Property, Department, Cost Centre) that flow through to Accounting Transactions. When you add a field to the dimension list, it automatically appears on posted ledger entries.
• On-screen field list — additional fields that appear on the New/Edit form. Use these to capture client-specific data without changing the installed package.
• PDF column list — custom columns added to PDF documents by extension packages.

Posting Dimensions

A Posting Dimension is any field added to the dimension list on a source document. These dimensions are automatically copied to the resulting Accounting Transactions when the document is posted. This means you can slice and filter your General Ledger by any custom dimension — for example, viewing all transactions for a specific property, cost centre, or project — without writing any code.

Grouped vs. Line-Level Posting

When a document is posted, the Posting Engine can create Accounting Transactions in two modes:

• Line-Level (default) — one Accounting Transaction per invoice line. Provides maximum detail and traceability.
• Grouped — lines with the same GL account and dimensions are consolidated into a single Accounting Transaction. Reduces the volume of ledger entries for high-line-count documents.

Grouped posting is controlled at the territory level and applies to AR and AP documents only. Journal entries always use line-level posting to preserve the authored detail.

Recurring Templates

A Recurring Template defines a transaction that should be generated automatically on a schedule. REDA Financials supports recurring templates for Journal Entries, Sales Invoices, Purchase Invoices, and Purchase Orders. Each template specifies the document content, the recurrence frequency, and the start/end dates. The system generates new documents automatically when scheduled.

Bulk Status Update

A Bulk Status Update lets you change the status of multiple documents at once — for example, posting 50 draft invoices in a single action. This feature is available on all major document types (Journal Entries, Sales Invoices, Purchase Invoices, Cash Receipts, Cash Disbursements, Purchase Orders, and Expense Allocation Batches).

Quick reference: abbreviations

You may see these abbreviations used throughout the application, reports, and documentation:

Next steps

Where to go next

1. Your Setup Roadmap — put these concepts into a setup sequence.
2. Compliance & Standards — the standards behind the terminology.
3. Understanding Entities — the entity concept in depth.
4. Understanding GL Accounts — the chart of accounts foundation.
5. How Posting Works — double-entry posting in REDA.

Frequently asked questions