General Ledger

You can independently define dimensions and use them to prepare analyses of ledger account transactions and balances. You can use up to 12 dimension types. You can define a name and an entire structure of dimension codes for each of these dimension types. There is no relationship between the dimension types. Dimension types and codes can be derived from logistic code tables.

Cross Validation Rules (CVR) functionality allows you to indicate which combinations of GL accounts and dimensional values are valid. Cross validation rules help to reduce data entry errors, enforce segregation of duties, and improve reporting accuracy.

Three financial period types exist: Fiscal, Reporting, and Tax.

You enter transactions based on transaction types. The transaction types are grouped by transaction category.

Transaction entry default values set authorizations and provide quick access to transactions types for each user.

To distribute a transaction across a number of ledger accounts and dimensions, you can use a transaction template. For each transaction template, you can define one or more transaction template lines to specify the distribution of the main transaction amount across a number of ledger accounts and dimensions.

When a transaction that matches a specified transaction type and ledger account in the master data is finalized, LN generates parallel transaction lines. The amounts will be posted to the specified ledger accounts according to the specified percentages.

You can match credit and debit entries of multiple transactions on the same ledger account with each other. A matching transaction can be generated to post differences that are within the specified tolerances.

A cash flow statement provides information about the history of the cash flow. The statement provides an overview of the sources and uses for cash, and is used to assess the ability of the company to meet its short-term obligations. In some countries, a cash flow statement must be submitted periodically to authorities.

In an integrated ERP system, most of the financial postings result from logistic transactions. For example, a warehouse issue is an operational transaction that requires financial postings. For each transaction that must be reflected in Financials, LN generates an integration transaction.

You can import journal transactions into LN from an outside source.

Recurring journal transactions are journal transactions that LN can generate periodically, based on the transaction details and templates that you set up in the recurring journal master data.

In a multicompany environment, transactions between the logistic companies and between financial companies create the need to balance the accounts through intercompany transactions.

General Ledger transactions can also occur between groups of financial companies that have separate chart of accounts, calendars, and so on, but are affiliated in a multicompany structure.

You use the year-end procedure to move the closing balances from one year to the opening balances for the next year. If the books are not final and you require the opening balances for the next year, you can run a provisional year-closing procedure.

The dimensions can be specified manually or populated automatically through Integration transactions. The user can manually specify the dimensions using manual journal voucher. The dimensions can be populated automatically with the segment value of the source transaction (that is the credit side of the integration transaction).

In a number of countries, journal voucher numbers must be consecutive for each month or year. You are not allowed to have gaps between a given number and the next number. The application includes Protocol Codes and Number functionality which has been enhanced to support different formats and numbering methods.

The functionality is extended so that external journal batches can now be modified, based on the Authorized User for External Journals in the Finance Company Parameters (tfgld0503m000) session.

In Italy, when the customer is a public sector company the tax liability shifts to the customer. The tax component paid by customer directly to tax authority must not be included in the receivables. The Vat Book reports must display the sales tax amount, as not payable. The Shifted sales tax must be handled as non-deductible for VAT book & VAT liquidation report. The Accounts receivable created directly from finance must allow shifted tax codes for domestic sales transactions.

The integration transaction can now be printed in the home currency.

The application can uniquely identify and report the VAT corrections. The VAT corrections must be distinguished in the VAT Report.

The legal regulations binding in Poland require that accounting books be periodically printed and/or transferred into another durable storage medium by a company. According to Art. 13.1 of the Accountancy Act, accounting books consist of sets of accounting records and constitute the following

Flexible reporting structures, or taxonomies can be created in the general ledger. The closed taxonomy can be archived or deleted.

In the Czech and Slovak Republic, companies are obliged to add additional VAT information to purchase invoices, bank transactions and journals for the purpose of VAT reporting.

The Bad Debt Reliefs and Bad Debt Recoveries on receivables and payables can be now processed easily & consistently. The necessary distinctive journals related to relief and recovery can be processed in the General Ledger.

Dedicated purchase and/or sales tax codes that are used for purchase and/or sales transactions can be specified.

For business purposes, a debt is regarded as bad when the decision has been made that it is non-recoverable. This decision is usually arrived at when all reasonable efforts have been made to collect the debt in question, without success, and the supplier is in a position to reduce the amount of debts by indicating it as such in the system. It is necessary to write off a bad debt when the related customer invoice is considered to be uncollectible.

GL Diagnostics Workbench is used to monitor the general ledger on a daily basis to improve reporting processes. Using this workbench, issues, exceptions and errors regarding transactions in the general ledger can be detected and solved upfront.

If workflow is enabled for manual Journals or Purchase Invoices., specific transactions types are excluded from workflow.

Year can be defined to make it easier for the user to create and maintain the financial periods and update the statuses of these periods.

In Mexico, a taxpayers must submit La Contabilidad Electrónica (electronic accounting) through the Tax Mailbox portal provided by the Mexican Fiscal Authority. For this purpose Infor LN is integrated with Local.ly eAccounting (LEA) . Infor LN generates the different files in csv format, which must be placed outside of the ERP system. LN also generates the query mapping XML file (querys.xml), which provides the link between the file/fields in the ERP database (in the csv file) and the eAccounting database.

The ledger history can be sorted sorting based on 'Print Sequence'.

LN is enhanced to block export based tax transactions or correction invoices until proof can be provided that export is tax exempt or zero rated. When the evidence of export is available or corrections are made, proof and correction information (custom document number, export date, etcetera) can be added to the regarding tax transactions and can be unblocked for reporting.

Mapping Scheme functionality is improved to simplify its setup, visibility and use.

'Purchase invoices (with tax related transactions) for which invoice date is after tax period are not allowed.