Sector Accounts

Setting up Accounts in NA Builder

Sector accounts are cross-classifications of institutions by transactions with the additional breakdown of uses and resources. Such a complex tabular representation can be nicely modelled in NA Builder. There are different ways to do this as we will now show.

Whereas the SUT is relatively easy to understand conceptually, this is not so for sector accounts. For this reason we have provided a simple introduction here, using the SNA example, leading up to the full set of accounts as used below.

The first method is illustrated by the simplified institutional sector accounts example based on SNA 2008 which is contained in the application:

This example uses an "external sheet" where the structure has been prepared including formulas but without data. The procedure in NA Builder is as follows:

The template is very simple, consisting of a single partition "SA". The header and stub classifications contain the coding system with which the data are coded:

After setting up the framework for the SNA example the sheet "SNA_example" is as follows:

Note that in this example the data are stored inside the accounts, in the colored cells. An alternative method is illustrated in another example included in the application, containing the Eurozone 2014 accounts:

This also uses an external template. After setting up the framework the accounts are presented as follows:

In this example the data are not in the accounts themselves - as was the case for the SNA example - but in a simplified sheet from which are then included in the accounts with formulas:

As before, the data are stored in normalized fashion:

As can be seen from these two examples, the NA Builder work is relatively simple when external templates are used. The accounts can themsleves be prepared outside the application. The benefit of using the application is that data and accounts are separate, making data storage and accounts re-usability easier.

Of course, more complex templates can be made as well in NA Builder, with partitions for each of the separate accounts and for both left and right sides. Separate transactions classifications for each of these accounts are then needed. Formulas can then be explicitely made as well. This is certainly the more elegant solution, but it will take some time to develop such a framework.