Maintaining the General Ledger Balance File

This document explains how you analyze, repair, or rebuild the general ledger balance file in order to ensure that there are no discrepancies between the general ledger and the balance file or between a budget and the balance file.

Why Required

Discrepancies between the general ledger and the general ledger balance file indicate that the balance file (the FBAVAL table) was not updated properly after the general ledger (the FGLEDG table) was updated, probably due to interrupted jobs. A discrepancy is a serious problem, since several reports and programs providing supporting documentation for strategic decisions are based on the figures of the balance file.


The general ledger balance file contains only correct and updated values.

The balance file (the FBAVAL table) is updated with balances from the general ledger (the FGLEDG table) or the budget transactions table (FBUDET).

Before you start

Follow These Steps

  1. Analyze and Repair Balance File

    As part of the company's period end routines, verify that the general ledger and the balance file are in agreement with each other by running 'GL Balance File. Analyze' (GLS940).

    (GLS940) enables you to perform an online analysis for a range of periods and balance keys – both fixed ones and user-defined – without having to block the system from ongoing transactions.

    M3 automatically calculates the balances of the selected balance keys and periods and compares them to the general ledger. The progress of the analysis is displayed online. Since each analysis is labeled with a timestamp, only transactions up to the timestamp are included in the analysis, thus making it possible to enter new transactions while the analysis is running. You can pause an ongoing analysis and complete it later. After the analysis is completed, any discrepancies between the general ledger and the balance file are displayed for each balance key, period, and balance dimension 1. By using the Repair option in (GLS940/B), M3 automatically repairs the balance file by adding or subtracting the calculated difference.

    The same procedure can be used for budgeted balances. The analysis is then made against the budget transaction table, FBUDET.

    Note: To maintain high system performance during the analysis, the following recommendations apply:
    • Run the analysis after normal office hours. The analysis is performance demanding and might result in longer response times when the system is processing other transactions. If the analysis is started in the evening and it is not completed by the following morning, you do not have to interrupt the job. However, if you rebuild the balance file as described below, you must interrupt the job.
    • Base the analysis on a wide range of balance keys – preferably all of them – for a narrow range of periods rather than the opposite. Run the analysis often and regularly, preferably periodically. Occasional analysis runs that are based on single balance keys and span several periods are very performance demanding.
    • Avoid analyses involving two fiscal years. For example, instead of running an analysis that spans from period 11 in 2009 to period 1 in 2010, run two analyses, one for periods 11 and 12 in 2009 and one for period 1 in 2010.
  2. Rebuild Balance File

    The introduction of new balance keys requires that you rebuild the balance file and repopulate it with general ledger or budget balances. A rebuild might also be required in the rare case of serious structural problems in the balance file. Note that the system must be blocked from ongoing transactions before the rebuild.

    • Update with Outcome

      Repopulate balance keys with updated outcome in 'GL Balance File. Update with Outcome' (GLS915) for selected periods and a range of balance keys. This is usually done when a new balance key should also apply to historical values. You can choose to delete the balance file entries within that range before transfer to the balance file instead of adding the new values to the current ones.

      By using period ranges you can limit the number of transactions and perform the update in several runs, if the number of transactions to process is large.

    • Update with Budget

      Update the balance file with budget values in one of the following cases:

      • When a new balance key should apply to historical values
      • When you want to include a new budget, for which the 'Update balance file' check box previously was not selected in 'Budget. Open' (BUS100).

      You update the balance keys in 'GL Balance File. Update with Budget' (GLS920) for the selected budgets, periods, and a range of balance keys. You can choose to delete the existing balance file entries for those balance keys before the transfer.

  3. Delete Transactions from Balance File

    Delete outcome or budget values for specific periods and a range of balance keys in 'GL Balance File. Delete Records' (GLS930) in the following cases:

    • When an entire balance key must be deleted
    • When the definition of a balance key or accounting structure is changed.

    When transactions are deleted due to any changes, new balance transactions should be created immediately before any new transactions are entered in the system. This is especially important when the current period is deleted and re-created. As mentioned above, previous transactions may also be deleted when transferring new transactions.

  4. Generate Opening Balance in Balance File

    As part of the company's year end routines, generate an opening balance in 'GL Balance File. Start Annual Run' (GLS905) by specifying the year from which the closing balance is retrieved.

    By totaling previous transactions to generate opening balances for the next fiscal year from the closing balances of the current year, you increase system performance during queries and report generation. This is the only purpose of the annual run in M3. The opening balances are saved in period 00, a period that you never have to define manually. Do not generate an opening balance for the current fiscal year or future fiscal years, since that would result in decreased system performance.

    Most of the transactions from the previous year should be entered before the opening balance is generated. However, transactions for the new year can be entered before this activity and transactions for the previous year can also be entered afterwards. If transactions are entered in a previous year after an opening balance is generated for a new year, that balance is automatically adjusted.

    If an annual run is not done, the previous opening balance will be added to existing transactions. If no opening balance has been calculated before, all transactions from when the system was configured will instead be totaled to create the opening balance for the new year.

Related topics