Accounting layers provide different ways to segregate transactions posted to a single GL account in order to facilitate reporting requirements. The posting of transactions is controlled by associating daybook types with one of the three system-defined accounting layers: the primary layer, the secondary layer, and the transient layer.

The primary layer is used for daily transaction posting.

You can define one or more secondary layers to allow for adjustments required to meet different GAAP or IFRS requirements, or for management reporting.

The transient layer is used to temporarily post transactions pending approval, or to simulate postings.

Financials reports let you select multiple layers at a time, for example, you can select both the primary and secondary layers to include management adjustments.

Any combination is possible, as shown in the slide.

Daybooks, also known as journals, are system- or user‑defined views of the general ledger, and contain all transactions.

Daybooks play an important role in QAD Enterprise Financials, and their use is mandatory. It is recommended to use more than one daybook as a means of grouping transactions. You can use daybooks to distinguish between different types of journal entries such as auditor adjustments, payroll entries, GAAP adjustments, and manually prepared accruals.

Daybooks control the numbering of invoices and credit notes, in addition to GL transaction numbers. Daybooks are linked to an accounting layer, and can be controlled by the financial functions or by the operational functions. You can also create daybooks to store transactions from external third-party products.

Some of the features of General Ledger accounts in QAD Enterprise Financials include:

QAD Financials uses standard, industry-recognized components to implement the chart of accounts. The strength of the application is its flexibility. The business model can be configured to generate many different types of accounting information.

GL accounts, sub-accounts, cost centers, and projects combinations can be validated using a COA mask. The COA mask validates account element combinations when transactions are posted, preventing posting errors.

In addition to the four basic components of the general ledger, you can define five Supplementary Analysis Fields (SAFs) to fine-tune transactions. SAFs provide the basis for powerful and flexible financial reporting and analysis.

Default SAF codes are supplied with the system, and require no additional setup. You can also define your own SAFs, based on your unique reporting requirements.

In addition to the primary base currency at domain level, you can define a second management currency at database level, for reporting purposes. This currency is known as the statutory currency, and is normally the local currency of the country in which the organization must produce its declarations and financial reports.

The need for a statutory currency is most likely to arise in a country that is geographically close to a strong currency zone (for example, Mexico and Poland), where the country itself has another local currency. Companies operating in countries close to strong currency zones, such as the Euro and US Dollar, might use the stronger currency as their base currency (functional currency). However, local auditors and tax controllers can mandate that companies submit their declarations and financial reports in the local currency of the country. In these cases, the local country currency becomes the organizations’ statutory currency.

Foreign currency transactions can be stored in a maximum of three currencies: the transaction currency, the base currency, and the statutory currency. This three-currency system lets you display a transaction or create a report in any of the defined currencies. This feature is especially important in environments with high inflation and strong currency fluctuation.