Accounting Rules Setup and Usage

This document explains what accounting rules are and provides an overview of the configuration workflow.

Outcome

After reading this document you understand the purpose and structure of accounting rules and will be able to configure accounting rules on an overall level.

Use the information to define accounting rules in 'Accounting Rule. Set' (CRS395).

What Is an Accounting Rule?

An accounting rule is a definition of which accounting string M3 will use when account entries are automatically created in a financial activity. Most of the integration between the financial system and other M3 applications is managed by the use of accounting rules.

Many financial activities in M3 result in the creation of at least two balancing account entries: one credit and one debit. Sometimes the account to use is entered manually during transaction entry, for example, when recording supplier invoices. However, in most cases the account is selected automatically based on an accounting rule. Thus, the complete set of accounting rules is a fairly complete reflection of the company's chart of accounts.

Benefits

Once accounting rules are configured, they reduce manual transaction entry to a minimum, speeding entry and minimizing key-in errors.

The Building Blocks of Accounting Rules

M3 provides a standard set of accounting rules. They are downloaded and configured in 'Accounting Rule. Set' (CRS395). Each accounting rule consists of the following building blocks:

  • A predefined combination of accounting event and accounting type.
  • Start date from which the accounting rule is valid.
  • The accounting string to apply when you create account entries. The accounting string can contain a combination of fixed accounting IDs and dynamic values such as item number, meaning that the item number in question will be stored in the accounting string of the account entry.
  • If applicable, any exceptions to the accounting string in certain situations such as using a different revenue account for non-domestic revenues based on districts.

Accounting Events and Accounting Types

Both accounting events and accounting types are predefined in M3 Business Engine.

What Is an Accounting Event?

An accounting event is a financial activity in which account entries are created to reflect an increase or decrease in the company's assets and liabilities. Examples of accounting events are reporting received goods, recording customer payments, and depreciating fixed assets.

What Is an Accounting Type?

An accounting type represents a specific category of account entries that are automatically created during an accounting event. Examples are cash discounts and specific types of VAT. The same accounting type can be used in several accounting events.

Accounting Rule IDs

The ID of an accounting rule consists of the combined IDs of the accounting event and accounting type. For example, accounting rule AR30-130 creates account entries for cash discounts after manual entry of customer payments in 'Payment Received. Record' (ARS110). AR30 is the accounting event for manually recorded payments and 130 is the accounting type for cash discounts.

Configuration workflow - Activity descriptions

  1. Download Accounting Events and Accounting Types

    Download accounting events by pressing F14 in 'Accounting Event. Open' (CRS375). Download accounting types by pressing F14 in 'Accounting Type. Open' (CRS385).

    For both accounting events and accounting types, you can delete records that you are not going to use in order to have fewer combinations to maintain. For example, if you are not paying your suppliers by check, delete the corresponding accounting event, AP30. Or, if the accounting types for VAT receivable 2 and VAT payable 2 are not applicable, delete them. If you delete an accounting event or accounting type that is in use, M3 will create an account entry with an error account, stating the missing accounting event and accounting type.

  2. Download Accounting Rules

    Download the predefined but empty accounting rules for all remaining combinations of accounting events and accounting types by pressing F14 in 'Accounting Rule. Set' (CRS395).

    Note

    • Accounting events and accounting types are only downloaded for modules you have indicated as installed in 'Company. Connect Division' (MNS100).
    • After each upgrade of the system, press F14 to download any new records of accounting events, accounting types, and accounting rules. The download only retrieves new and deleted records but does not change the existing ones.
    • Remember to download new accounting rules for the same date as the existing accounting rules. Otherwise you will get a complete and empty set of accounting rules for the new date, thus overruling the existing definitions.
    • You can press F14 to copy an old set of accounting rules or to copy accounting rules from a certain date.
    • To delete any old accounting rules, press F15.

  3. Download Dynamic Objects

    If dynamic objects were not already downloaded, download the objects to use in the accounting strings by pressing F14 in 'Field Group. Open' (CRS108). You can remove any fields from the CRACC field group that you do not want to be available as dynamic objects. Dynamic objects enable you to follow up and analyze costs based on factors other than accounting IDs.

    An example of a dynamic object is item type. By inserting this dynamic object in an accounting dimension in the accounting rule, the ID of the particular item type in question is saved automatically in the accounting string of the account entries created based on that accounting rule.

  4. Assign Accounting Strings to Accounting Rules

    After the dynamic objects are downloaded, the empty accounting rules are displayed with their respective start date in (CRS395/B). You can assign an accounting string to each combination of accounting rule and start date. On the E panel, two columns of empty fields are displayed.

    Left-Hand Column: Fixed Accounting IDs

    The left-hand column consists of one field for each accounting dimension in the standard accounting string. The fields are reserved for fixed accounting IDs, that is, accounting IDs registered in 'Accounting Identity. Open' (CRS630). The top field – accounting dimension 1 – is always reserved for the account itself.

    Tip: Use the seventh accounting dimension to enter the ID of the accounting rule (for example, AR30-130). This ID is then stored in that accounting dimension for each account entry created based on that accounting rule. This helps identify the accounting rules during troubleshooting.

    Right-Hand Column: Dynamically Retrieved Values

    The right-hand column consists of fields for accounting dimensions 2 to 7. This column is reserved for values other than fixed accounting IDs. Which values – dynamic objects – are available vary from accounting rule to accounting rule. If you use dynamic objects, you leave the corresponding fields in the left-hand column blank.

    There are two categories of dynamic objects: 1) objects that represent a field in a table, and 2) non-field objects. Only objects that belong to the former category can be generated into and stored in the accounting string. Non-field objects are only used to define exceptions (see below).

    Example of Dynamic Objects in Accounting String

    We assume that the second accounting dimension in the company's accounting string is reserved for cost center and the third for product group. The accounting rule to define is OI20-120 (Revenues from customer order invoicing).

    By entering dynamic object CKSDST – which is the field that represents the district in the customer master file – in the accounting dimension for cost center in the right-hand column, the cost center is retrieved from the District field in 'Customer. Open' (CRS610/F) and saved in the accounting string of the revenue account entry when invoicing a customer.

    By entering dynamic object MMITGR – which represents the item group in the item master file – in the third accounting dimension, the product group is retrieved from the 'Item group' field in 'Item. Open' (MMS001/F).

  5. Define Accounting Rule Exceptions

    Since you might need different accounts for different occasions, the standard accounting rules with their fixed accounting IDs are sometimes insufficient for effective follow-up. For example, you might want to use a different revenue account for non-domestic invoicing of customer orders. In (CRS395/F) you define such exceptions to the rule based on one or more fields (dynamic objects) in various tables. For each exception you can define a different accounting string.

    The exceptions are defined using lines in a matrix in (CRS395/F). Each line can consist of up to five fields. Different fields are available depending on the accounting rule and are displayed when you press F4 in one of the exception fields.

    In (CRS396) you then determine the valid values for every field and the different accounting string to apply for them. For example, you can apply a different accounting string for a specific range of districts. All valid values will have to be fulfilled to trigger the new accounting string.

    You can define exceptions in several steps by using more than one exception in (CRS395/F). If M3 does not make a match on the first step, it will try to fulfill the definition on the next step. For example, if there is no hit on a district, you may want to look at the value in the item class field in the item master table. The priority you selected for each line determines the order in which M3 tries to match the exception.

    An asterisk is displayed in (CRS395/B) for accounting rules with one or more exceptions.

    Instead of using a regular account for normal transactions in the accounting string in (CRS395/E) and defining exceptions in (CRS395/F) and (CRS396), many companies switch these steps. Companies use a special error account in (CRS395/E) – originally intended for the "normal" account – for all unacceptable account entries. An error account is an account that is labeled as blocked in 'Accounting Identity. Open' (CRS630/E). They then cover all acceptable situations in which account entries can be created in the exceptions part. An account entry would then only be created for the error account when a situation occurs outside the scope of the approved exceptions. Since the error account is blocked, the incorrect transaction is placed in 'Transaction Work File. Restart Erroneous Jobs' (GLS037) before the general ledger is updated. This helps alert the financial department at an early stage that someone is not complying with the approved process.

    Note: For example, you want to alert the financial department before any unacceptable balances occur in the general ledger due to the use of unauthorized order types. In accounting rule MM20-907 (representing the offset account for stock transactions at internal stock issue) you select the dynamic object for order type, MGTRTP. In (CRS396) you then define exceptions for each one of the authorized order types, stating that order type 1 is used for requisitions, order type 2 for claims, order type 3 for scrap, and order type 4 for subcontracting. Any account entries created outside of that scope would be using the error account, an indication to the financial department that someone was using an unauthorized order type.

  6. Define Additional Settings for Dynamic Objects

    If an accounting rule has exceptions defined but none matches the transaction in question, either the standard accounting string defined in (CRS395/E) is used or the account entry is labeled with an error code. You define in 'Settings – Accounting Error Methods' (CRS736) which procedure to use.

    In the same program you define two other values related to the use of dynamic objects:

    • Whether to use the payer or the customer when M3 reads the customer master file. For example, should the payer or customer from the customer order be used when retrieving the district for the revenue transaction?
    • Which part of an order number should be used in the accounting string, the first or the last eight digits. You can select order numbers as dynamic values or exceptions for an accounting rule. However, since each accounting dimension is eight positions long, whereas some order numbers consist of ten positions, you need to abbreviate the order numbers to include them in the accounting string.

  7. Define Automatic Replacement of Dynamically Retrieved Values

    In 'Field. Update Control Values' (CRS388) you define automatic replacement of dynamically retrieved values. For example, if the company uses the district from the customer master file as the dynamic object in the accounting dimension reserved for cost center, the districts can here be "translated" into cost centers: Districts 100 and 101 will be replaced automatically by cost center AAA, and so on. Note that this replacement does not work retroactively. It is only applied to future account entries.

  8. Simulate Accounting Strings

    You can simulate the results of a specific accounting rule in two ways:

    • Create a dummy transaction and review the results in the general ledger.
    • Simulate the result of an accounting string applied on an existing transaction such as an invoice or order transaction in 'Accounting String. Simulate' (CRS399). This program can be started from the menu or by selecting the option 'Simulate accounting string' for an accounting rule in (CRS395/B).

    In (CRS399/E) the accounting string as it would be for that particular transaction is displayed. You are informed whether the accounting string is based on the standard accounting string in (CRS395/E) or on an exception. If an error is detected, an error code is displayed. You can also combine the two methods by first creating a dummy transaction and then, if an error occurs, use the same transaction when simulating the accounting string.

Related topics