Multi-Site Accounting

In this article

Distributed companies and organisations have operations in different places.

  • In the same country.
  • In different countries.

They need to setup an accounting organisation that allows to have:

  • An acounting control for each entity (country or project)
  • Have a consolidated accounting.
    Data from the different accounting files need to be grouped together.

Multi-Site accounting

The Banana Accounting software is used by thousands of organisations and projects as a distributed accounting system.

Banana.ch has been a world pioneer in using blockchain technology, which faciltates the creation of a distributed accounting system.

Examples are:

  • Entities that keep track of accounting transactions in different places and integrate the data in one central accounting.
  • Projects accounting, with specific and detailed reporting, not available on the central system.
  • A Non-profit organization that has projects worldwide, lets each project keep their accounting, and the data are integrated in the central accounting system (See Helvetas - Blockchain decentralized accounting).
  • A large public organization that uses SAP, lets some organizations keep their accounting with Banana. (See Example of Kanton Basel City - German).
  • Companies with different branches, that operate in different countries, with different currencies and accounting setup.

When multi-site, distributed accounting makes sense

Organizations tend to centralize their accounting system, so that all data reside in one system only.
Cloud computing makes it easier for organizations to share a centralized system. But distributed accounting still is the best choice:

  • Connections are slow or costly. 
  • Using the central system is difficult:
    • Require specifically trained personal
    • Have high license costs.
    • It is not flexible.
    • Have a different workflow.
  • Local accountings have specific needs, and customizing the central system would be too difficult and costly:
    • different accounting plans and requirements
    • different legal requirements
    • different currencies.
  • Accounting documents are kept at the branch level.
  • Branches need a lot of flexibility but at the same time you do want to limit data access.
  • The different branches have few interactions.
  • There is no need to have all the detail-information in a central system.

In these cases it makes sense to have people in the branches use Banana Accounting.

Setting up the distributed accounting system

Organizations that use a distributed accounting system will then need to integrate the data in a central system, in order to have financial statements that include all branches and projects.

The data integration process must consider:

  • With what frequency the data need to be integrated (monthly, quarterly, yearly, ...).
  • The detail-transactions that need to be integrated in the central system.
  • Whether only summary data are being integrated in the main system.
  • How the data will be made available to the center.

Integrating all transactions into the central system

The requirements for working this way are:

  • The distributed accounting and the central accounting use the same account numbers, same currency.
    • In this case the integration process is done by importing the transactions from the branch into the central system.
    • In Banana you have a central accounting system and use the import function.
  • The distributed accounting and the central accounting have different account numbers or currencies
    • The transactions must be converted to a format that is suitable for importing.
      You can create a BananaApps that exports the data from the Banana Accounting file into the requested format's data.
    • Currency conversion.
      You need to define at what rate the amounts from one currency are converted to the other currency.
    • If you use Banana for the central and distributed accounting see

Integrating only the summary data into the central system

This approach facilitates the integration process and is particularly adequate when:

  • The central accounting system differs from the local one.
  • Local accountings use different settings (currency, accounting plan), making the integration complex.
  • There is no need to have detailed transactional information in the central system.
    Detailed information can easily be accessed with the Banana accounting file.
  • There are large quantities of data and integrating it makes managing the central system more complex and costly.

Therefore, in the central system only the summary data are integrated:

  • The period of the data that should be integrated (monthly, quarter, year) are defined
  • Defined is whether the integration is done at the accounting level or at the group level (see below).
  • Each branch accounting prints a summary of transactions (see BananaApps Trial Balance with blockchain) that includes:
    • accounts or group number
    • total debit and credit for the period.
    • these amounts are registered unto the central accounting:
      • Manually (directly from the report)
      • With the import function. In this case the data should be exported from Banana Accounting.

Using blockchain lock function

If you use a distributed accounting system, it is important that, once you have integrated the data into the central system, the local data are not changed. In case the local data have been changed you will have difficulty in reconciling the different systems. The situation will get complicated if you have many accounting files.

The branch cannot be prevented to modify the file, for the fact that they have the file on their local system.

The only way to make sure that the data have not been changed, is to use a blockchain security mechanism embedded in Banana and named Lock transaction:

Each branch, at the end of each period, is required to:

  • Check that the progressive lock of the previous period is the same as the one that has been printed.
  • Lock the accounting for the period.
  • Print the lock report, sign it and send it to the headquarters, together with the accounting file.

Once the accounting has been locked, the branch, should:

  • Continue to work on the same file.
  • Do not unlock or change the locked transactions.

The headquarter should:

  • Keep note of the progrLock and number when they integrate the data.
  • Keep a copy of the file that has been integrated previously.
    The best is to put in a directory with the date or have a date in the file name.
  • When they receive the file, check that the lockProgressive of the last period is the same.
    • If is not the same require the branch to fix the problem.
      • do not proceed with the data integration.
      • Use the BananaApps Compare two files to see the differences.
      • In this case, it will be worth it to return the previous file, so that they can start from this and add the new transactions.
    • If it is the same
      • Proceed with the integration.
      • Keep note of the last LockProgr and LockNumber.

Structuring the accounting plan to facilitate the data integration

Keep the same account numbers

If you need to use in the branch the same accounts number that you use in the central system, the best way is to use the same accounts number in the branch accounting file.

Using different account numbers

This is necessary in case local accounting should use a different accounting plan (local rules) or a more detailed accounting.

There are different options:

Add a column to the accounting plan for the central accounting number, so that each account will also have a corresponding central account number:

  • The account column will use a local account number.
  • In the columns Central account you enter for each account the number of the account used in the central system.
  • Different accounts can have the same central account number.

Use a grouping schema where the groups in the accounting table corresponds to the account number of the central accounting (see Helvetas example)

  • Each group in the accounting plan will correspond to an account number in the central accounting.
  • In the accounts table you will have the groups totals corresponding to the accounts in the central accounting.
  • You will end up having a lot of groups.
  • This approach is useful if the local accounting needs to create many local accounts. For examples many bank accounts.

Multiple levels

If your organization is complex it may make sense to have different level of integration (see Helvetas example) with different approaches:

  • Each country integrates the data of the local projects, by importing all transactions in one file.
  • The summary data of each country is then integrated in the central accounting system.

Cash Manager

If the local project only has one account to manage, it make sense to set up a Cash Manager

  • Create a Cash Manager file in which the branch keeps track of it's expenses.
  • Use the import Cash Manager function to integrate the data in the main Banana Accounting file.

 

 

 


 

 

 

 

Share this article: Twitter | Facebook | LinkedIn | Email