This document provides an overview of how you set up a basic configuration of M3 Finance Management.
All basic components in the financial system are configured to support the company's processes, including transaction entry, financial monitoring and tax management.
Define Number Series
Enter Currency-Related Information
Define Chart of Accounts
Define Accounting Rules
Tailor Presentation of General Ledger Balances
Enable General Ledger Management
Define FAM Functions for Transaction Entry
Define Payment Categories
Enable Tax Management
Register Customers and Suppliers
Register Bank Information
When you exit a program that creates accounting transactions, one or several journals are printed, depending on the program. Examples are accounting journals, customer invoice journals, and supplier payment journals. Each journal is assigned a number from the journal number series. In the journal, every transaction receives a sequence number. This is done in order to give each transaction a unique identity in the General Ledger and to order the transactions chronologically for M3-internal purposes only.
If you have selected to have transactions separated into external and internal transactions in 'Settings - General Ledger' (CRS750), you enter a journal number series for each category. Otherwise, only one journal number series can be used per company and accounting year. The connection to accounting years allows work with two accounting years at the same time at the year-end close. Journal numbers and sequence numbers are displayed for each voucher transaction in 'Voucher. Display' (GLS210/B).
'Journal Number Series. Open' (CRS400). You can print copies of specific journals in 'Journal. Print Copy' (GLS500). As part of the company's periodic routines, use 'Journal. Check Number' (GLS965) to check for breaks in the journal number series or journals that contain transactions with no amount.
All financial transactions in M3 result in a voucher. The voucher consists of all account entries created during an entry session. You can use the voucher number to drill down to all related transactions in 'Voucher. Display' (GLS200). Or, you can identify the voucher used to record a particular invoice based on the invoice number in the Display programs in Accounts Receivable and Accounts Payable
You set a starting date for each series. This facilitates changing number series in order to work simultaneously with two accounting years at year-end close. Every series must be flagged for manual, semi-automatic (meaning that the first voucher number in the series must be entered manually at transaction entry), or automatic numbering.
'Voucher Number Series. Open' (CRS410).
In M3, there are many other types of number series used, for invoices, payment reminders, write-offs, and so on.
Each number series has a name, starting number, ending number, as well as a setting for if and when the series is replaced by another series. Every number series is connected to a number series type. These are predefined and indicate what the series is used for (such as 01 for Customer/service orders, 02 for invoices, 07 for delivery notes, and 50 for payment reminders).
'Number Series. Open' (CRS165). The only exception is for invoice numbers in a multiple unit environment (see below).
When using multiple unit coordination (MUC), define invoice number series for every division. They are automatically connected to number series 02. This means that different invoices with the same number can be entered in separate divisions.
'Internal Invoice Series. Open' (MFS165).
You can use any number of currencies in M3. There are three key currency types:
For each currency you select the number of decimal places and a rate factor. The rate factor indicates whether the amounts should be divided or multiplied to reduce the number of zeros at transaction entry. Although this might be convenient when working with inflated currencies, most companies find it more convenient in the long run to only use rate factor 4, that is, 1:1. You can also specify the maximum exchange rate deviation allowed as a percentage. In programs where the exchange rate is manually entered or changed, a warning is then displayed if the rate deviates from the exchange rate in 'Exchange Rate. Open per Date' (CRS058) more than the specified percentage. Another feature is rules for rounding-off. For MUC environments, you can enter division-specific rate factors and deviation percentages for each currency.
'Currency. Open' (CRS055); 'Currency. Connect Rounding-off Rules' (CRS053). A plus sign is displayed for the currency in (CRS055) if there are division-specific exceptions.
Begin by defining different categories or types of exchange rates: variable rate, budget exchange rate, or rate used for group consolidation, for example. These types are used for budgeting and annual financial statements and can be connected to customers, suppliers, and price lists. There is one predefined exchange rate type (01 = Variable rate). Types 02 to 99 are user-defined. Exchange rate types are then connected to the exchange rates (below).
'Exchange Rate Type. Open' (CRS056) and 'Exchange Rate. Open Rate Type' (CRS057), the latter displayed via 'Currency. Open' (CRS055).
You can define exchange rates with up to six decimal places and all places are used for the conversion to local currency. But, the results are displayed in two decimal places at the most. The mathematical operation (multiply or divide) to exchange a currency amount to the local currency based on the exchange rate is set in 'Company. Connect Division' (MNS100/G).
'Exchange Rate. Open per Date' (CRS058). The program is displayed via 'Currency. Open' (CRS055) or 'Exchange Rate Type. Open' (CRS056).
Each financial transaction in M3 is recorded based on an accounting string. This string consists of seven links, so-called accounting dimensions. Not all links need to be used for every transaction. The first accounting dimension is always reserved for the business account. Which types of accounting identities to reserve for any of the other dimensions (such as cost center, product group, or project) is based on the company's reporting and monitoring needs.
In this task, define names for each accounting dimension. Each name is entered in three versions: 15, 8 and 3 characters long. Which one is used in M3 and printed on reports is determined by the space available on the panel or report. When M3 is installed with several system languages (so that field and other headings can be displayed in each), you define the dimension names for each language.
'Accounting Dimension. Enter Names' (CRS012).
Account groups control the order in which accounts are reported on an income statement or balance sheet. To achieve a clear structure, you group similar accounts in a hierarchy consisting of up to five levels. Here is one example of a hierarchy of account groups consisting of four levels:
You then connect each business account to an account group in 'Accounting Identity. Open' (CRS630).
Where defined: 'Account Group. Open' (CRS633).
The parts making up an accounting string are called accounting identities. These are entered in the accounting dimensions. The accounting identities reserved for dimension 1 constitute the company's chart of accounts. As mentioned above, other types of accounting identities can be cost centers, for example. Each identity can have a date range set, so adjusting the chart of accounts and other accounting identities is easy. The accounting identities can also be entered in different languages, for use in inquiries and reports. The language selected for the user is the one used to retrieve the correct dimension name. Accounting identities can be entered on company level and division level.
Where defined: 'Accounting Identity. Open' (CRS630).
For a detailed description of how accounting rules are defined and applied, see Accounting Rules Setup and Usage.
For a brief description of all accounting rules, see "List of Accounting Rules in M3".
Accounting events represent all occasions in M3 where account entries are created automatically. Every accounting event results in at least two account entries—credit and debit. Examples of accounting events are AP10 (Manual entry of supplier invoices) and OI20 (Customer order invoicing). Accounting events are predefined in M3, so they are downloaded during configuration or when upgrading the system.
Where defined: 'Accounting Event. Open' (CRS375)– press F14 to retrieve the standard set.
Accounting type is a collective ID for various types of account entries created during the accounting event, for example the posting of VAT. Examples of accounting types are 211 (VAT receivable) and 301 (Realized exchange gains). Accounting types are also predefined in M3 and downloaded during configuration or at upgrade of the system.
Where defined: 'Accounting Type. Open' (CRS385)– press F14 to retrieve the standard set.
Define which accounting string to use for every combination of accounting event and accounting type, thereby predefining all account entries that may be generated automatically in the financial system. Each such combination set is called an accounting rule. Every accounting rule has a start date.
Apart from any accounting identities, you can also include so-called dynamic control objects such as country, customer, or order number in each accounting string. These values define from where the corresponding accounting identity is to be retrieved instead of using a fixed value. For example, if accounting dimension 3 in accounting rule OI20-120 (Customer order invoicing – revenues) is reserved for product groups, you can enter the ID of the item group field in the item master file. The product group is then automatically retrieved from this file instead. For each accounting rule you may define up to ten exceptions as well. An example could be the use of a different revenue account for non-domestic revenues.
Where defined: 'Accounting Rule. Set' (CRS395). The first time you enter this program, you must press F14 to create all predefined combinations of events and types. If you include dynamic control objects or exceptions, you continue the configuration in 'Settings – Accounting Error Methods' (CRS736). This program controls among other things whether to use the normal accounting rule if there are exceptions defined but none match the transaction in question, or whether the transaction should be marked with an error code. There you also define whether the use the first eight digits or last eight digits of order numbers to use as dynamic control objects; some order numbers consist of ten positions whereas each accounting dimension is only eight positions long.
One of the main requirements from a financial system is that you can access your information quickly and easily. In M3, you collect information in a systematic way in the General Ledger balance file by using accounting structures and balance keys. Whereas the General Ledger stores detail transactions, the balance file stores totals per periods. Whenever the General Ledger is updated, the balance file is updated simultaneously. By using the balance file for inquiries, the reply times are shortened. The balance file is available in 'GL Balance File. Display' (GLS215) and in the M3 Report Generator.
The accounting structure is a group of accounting identities or other accounting structures in a hierarchical model corresponding to your organization, for example. You integrate these structures as filters in balance keys. The balance keys are used in the General Ledger balance file to retrieve and present balances by product, or product line, region, customer or salesperson, etc. This can be done online or in the form of printed reports. For each balance, you can drill down into detail all the way to original transaction like materials, production or invoicing. There are two types of balance keys: fixed and user-defined. Accounting structures can be included in the user-defined balance keys. Since you can set up the balance file based on the fixed balance keys only, defining accounting structures is not a mandatory part of the basic configuration. However, accounting structures provides an almost unlimited flexibility when tailoring different financial views of the financial database. Another advantage of using accounting structures is that they make organizational changes easier. Substructures containing many accounting identities can be easily moved to new accounting structures. This has an immediate impact on all reports and queries that are based on the structure.
For details how accounting structures can be used, see Tailoring Presentation of General Ledger Balances.
An accounting structure is a hierarchical model that in theory can consist of up to nine levels. However, in reality a structure with three or four levels is sufficient in most cases (for example, level 1 Employee, level 2 Department, and so on). Begin by defining the one set of levels to use for the company or division. In practice, this means that you assign a name or heading to each level per language and specify for which accounting dimension it is reserved.
Where defined: 'Accounting Structure. Define Level' (CRS647).
Once the levels are named, start building the accounting structures by connecting accounting identities (for example, cost centers) or other accounting structures to each level, beginning from level 1 and upwards. The structures can then be included in the balance keys.
Where defined: 'Accounting Structure. Open' (CRS645).
As mentioned above, you use balance keys to retrieve any view of ledger or budget information and for sorting and totaling purposes. The keys determine which fields are included as well as the sequence in which they appear. Once they keys are activated, you can select them for online monitoring in the General Ledger or when creating reports in the M3 Report Generator, either for an entire report or for a specific report line.
Balance keys 1 to 8 are predefined, consisting of accounting dimensions in various combinations, and activated automatically. In addition to those, you can create and manually activate up to 91 user-defined balance keys. Apart from the seven accounting dimensions, you can chose among 22 other key values (so-called balance dimensions) to include, apart from the accounting structure levels defined.
Where defined: 'GL Balance File Key. Open' (GLS690).
To review General Ledger balances in 'GL Balance File. Display' (GLS215), you select a period, a balance key, and a column template.
The template defines what you want to show in each column, for example, actual or budgeted values (amount or quantity), currency amount or amounts in local currency, or a calculation of two columns.
Where defined: 'Column Template – Balance Inquiry. Open' (GLS216).
Some of the basic functions in the financial system are configured in a separate program for General Ledger settings. This include settings for:
Where defined: 'Settings – General Ledger' (CRS750). See Enable General Ledger Management.
In order to make the entry of new transactions as smooth and automated as possible, settings or rules specific to certain types of entry are collected in entry templates called FAM functions. The FAM function is applied automatically in certain situations, for example at the period calculation of exchange rate gains or losses. In complex flows, where transactions are entered manually and a high degree of flexibility is needed, you chose among different variants – detail records – of a FAM function to find the one matching the particular type of transaction.
Each FAM function has at least two parts: a predefined main entry (the overall ID) and one or more user-defined detail records containing the rules. All detail records contain information on voucher number series, voucher name, and valid date range. Also, they can contain parameters specific to a function such as invoice accounting template, exchange rate type, and which panel layout to use at manual posting. Every main entry is predefined and generated during configuration or when upgrading the system. You then configure the detail records.
Where defined: 'FAM Function. Open' (CRS405)– press F14 to retrieve the standard set.
A company may have to process many different categories of customer payments and supplier payments. In order to manage all these payments efficiently, they are grouped into classes and sub-classes with the following hierarchy:
This division not only enables you to sort and total payments for enhanced processing. On the payment type and payment method level, you can also add settings to minimize the manual work involved.
There are six fixed payment classes in M3, with two exceptions used in both Accounts Receivable (A/R) and Accounts Payable (A/P):
|1||=||Payments by check with separate allocation to invoice||Yes||No|
|2||=||Payments by check with direct allocation to invoice during entry||Yes||Yes|
|3||=||Payments by bank transfer (giro), manual or electronic||Yes||Yes|
|4||=||Payments by draft (bill of exchange). (This includes definite postdated checks, which are managed like drafts in M3.)||Yes||Yes|
|5||=||Payments by direct debiting||Yes||Yes|
To each payment class, many payment types – sub-classes – can be added. Most payment types contain one or more fields controlling additional aspects. For example, payment types under payment class 1, 2, 4 controls if and how checks and drafts are remitted to the bank for collection. Similarly, a payment type under payment class six specifies which factoring company to use and the factoring charges to be posted automatically at remittance.
Where defined: 'Payment Type. Open' (CRS078).
The third category is the payment method, specifying further the type of payment and how it should be processed. To each payment type, several payment methods can be added. In contrast to payment types, however, payment methods are defined separately for use in Accounts Receivable or Accounts Payable exclusively.
Both payment types and payment methods are available as selection criteria, when remitting customer payments for collection or selecting supplier invoices to be included in a supplier payment proposal.
Where defined: 'AR Payment Method. Open' (CRS076); 'AP Payment Method. Open' (CRS071).
M3 Tax Management provides the most powerful solution for international VAT and sales tax management on the market. Since each country has its own rates and exceptions and there are a great variety of more or less complex transaction scenarios, the configuration requires that you have a solid understanding of the legal requirements involved.
For more information, see the following topics:
Periodic trade statistics reporting is a requirement within the EU. The purpose is to submit details of trade with companies in other EU countries to local customs authorities. There are three types of trade statistics (TST):
For more information, see the following topics:
Some countries require companies to generate and report tax transactions for supplier tax withheld at source. M3 Business Engine offers two alternate methods, for more information, see the following topics:
Customers and suppliers are registered at company level. However, you can define division-specific exceptions for each one of them. These exceptions may include different currency or VAT code, for example. For both categories you specify the following values:
Apart from these standard values, you can also define additional values for each customer and payer such as:
If the collection of customer payments is outsourced to a factoring company, the factoring company buying the invoices is registered as a separate customer.
Where defined: 'Customer. Open' (CRS610).
Suppliers and payees are registered in a similar way with additional values for:
Where defined: 'Supplier. Open' (CRS620); 'Supplier. Define Purchase & Financial' (CRS624).
You register information about the banks and different types of bank accounts the company is in contact with. This includes the company's own banks as well as banks used by suppliers, customers, employees, etc.
The bank account is the basic bank component in M3, used in most programs where banks are involved. Only in a few programs the bank itself is entered. You always register the bank of the company's bank accounts. Whether you register banks for any other type of account is optional. However, by registering all common information for a group of accounts on the bank level, you do not have to enter the same information several times. When applicable, register local bank branches as well. The branch record contains similar information as the bank record.
Where defined: 'Bank. Open' (CRS690); 'Bank Branch. Open' (CRS691).
When registering the bank accounts, you group them into specific categories: The company's bank accounts, supplier accounts, customer accounts, employee accounts, and other accounts. If needed, you can also register division-specific variants of supplier bank accounts.
Where defined: 'Bank Account. Open' (CRS692); 'Bank Account. Open for Division' (CRS693).