Metapattern for financial accounting

Pieter Wisse

abstract
The subtitle of my book Aspecten en Fasen (1991, published in Dutch; translated into English, the title reads Aspects and Phases) tries to capture its scope: “notes on relational accounting, organizational information, change, etc., vice versa.” It treats many subjects other than conceptual information modeling and models. Still, precisely such modeling and models are at its very core.
At the time Aspecten en Fasen was written, the term pattern had not yet been coined to indicate reusable conceptual information models. However, these are exactly what it provides-reusable models, or patterns. It also originated before what I myself developed as metapattern (Wisse, 2001). Here,¹ some of the ‘patterns’ from Aspecten en Fasen return but now in metapattern notation. As a result, they appear ‘updated and improved.’ Some new patterns have been added with increased conceptual coverage. A major contribution has been the increasingly deliberate application of some so-called compositions. Part I of this paper contains an overview of the ‘classic’ patterns while Part II outlines major improvements.

keywords
Metapattern, conceptual modeling, financial accounting.

Part I

The patterns were originally designed to overcome basic problems with the traditional method of fund accounting applied by Dutch ministries and other institutions of central government. This accounting method is called, in Dutch, Kameraalstijl.² The solution rests on a synthesis of Kameraalstijl and double entry accounting, making the resulting method of relational accounting suitable for both government institutions (public sector) and commercial organizations (private sector).

1. Prototype for interpretation management

Before presenting specific patterns, it is useful to emphasize an important characteristic of financial information systems in general, and of general ledgers in particular: its explicit orientation on time (with time even in a double meaning).

Suppose a transaction is registered as a journalizing group. Such a group will contain both the transaction date (more specifically: point in time) and the registration time. As strict requirements for auditability also exist, a fundamental rule holds that, once consolidated, a particular journalizing group and all of its entries must remain unchanged.

If a correction is necessary, the effects of original entries are reversed by new entries and then the correct information is registered. Should this new information also prove incorrect, this process of correction is repeated.

The combination of time points for (1) transaction proper, and (2) its registration secures a complete audit trail. It suffices, for example, to reconstruct that during a certain period-that is, between successive points in time-incorrect information has been held in (journalizing groups in) the information set thought to be valid. The inverse journalizing entries have neutralized the original entries, those discovered to be invalid. Such neutralization is an implicit mechanism to declare (other) information invalid.

The combined mechanisms of these four items have long held the status of immutable tradition in financial accounting: (1) double entry accounting, (2) double temporal orientation (both transaction time and registration time), (3) permanence of consolidated journalizing groups and their entries, and (4) correction through neutralizing entries. As a result, it has become difficult to unearth the actual objective those mechanisms supposedly serve. That objective is to guarantee an unbroken audit trail as far as interpretation of registered information related to time is concerned; that is, whether information is/was valid or invalid.

When this basic objective has been clearly restated, the next question is whether the mechanisms mentioned above are required to achieve it. Does an alternative exist? Do such concepts have their origin in efficiency, that is, in the limitations of the application of a particular technology? Or are they really (more) conceptual; that is, required for a tool's effectiveness?

Rhetorical or not, the answer to such questions is that, indeed, metapattern supplies an elegant, compact alternative. The double temporal orientation is standardized, as a matter of principle, with metapattern (Wisse, 2001). Every information object has, according to metapattern, other information objects connected to it which reflect changes in both its existence and in registration thereof. A property of every existence entry is the point in time at which the existence value starts to be valid. There is a choice between two existence values: existence, and non-existence.

Besides one or more existence entries, every ‘regular’ information object is supplied with one or more validity entries. Each of these also contains, among other information, the point in time at which a validity value (valid or non-valid) starts to be ‘valid,’ and the corresponding point in time of registration.

As far as financial accounting is concerned, the mechanism of double entry accounting plus such standard mechanisms of metapattern as described above provide an alternative guarantee for completeness of audit trail. Taking this as a reference point for further modeling, the meaning of what a consolidated journalizing group is can change. Even any part of a journalizing group and/or entry may be changed independently. What remains to be controlled is that the user involved is appropriately authorized. And when double entry accounting is applied, the whole of every journalizing group must retain its monetary balance. But inverse journalizing groups are no longer required; any correction may be limited to the original mistake (with, if necessary, any information exceeding the journalizing group’s monetary balance registered by one or more additional journalizing groups). Such simplicity is most logical for anyone not acquainted with the tradition in financial accounting. Inverse journalizing was once convenient. It has become an obsolete mechanism when the manual tradition of accounting is critically investigated, since properties of existence and validity may now be practically handled at a more fundamental level, as with metapattern. In fact, conceptually, modeling should always concentrate on what the prospective tool implies for the user, rather than on the tool's internal workings.

However, traditions or paradigms are difficult to change. One reason for inertia is that awareness about the relationship between objective (in this case: comprehensive audit trail) and mechanisms (from double entry accounting to inverse journalizing) has disappeared. With the objective out of controlled reach, the need to cling to familiar mechanisms is often established more firmly. In general, such power of tradition is also an obstacle for consistent application of metapattern.

In order to make the exchange of ideas as rational as possible, the presentation of alternatives has begun with explicit modeling of the double temporal orientation, corresponding to historical reality. After all, that is how patterns for financial accounting in Aspecten en Fasen originated, without consideration of metapattern. Those patterns, therefore, are to a large extent well within a powerful tradition of interpretation management, of which the general ledger, supported by an elaborated combination of control mechanisms, is an important prototype.

2. System of systems

Usually, patterns for financial accounting start from a detailed assumption. They invariably lead to problems because that assumption lies within the modeled information system. The inability to externalize assumptions is typical of (over)specialist approaches.

The problems are caused by considering account to be the fundamental concept. Even when that concept is too narrow for requisite variety, it is still maintained. But an account is not an end; it is also a means for financial reporting. Such was no doubt its original purpose many centuries ago. Considering it as a means helps to reconsider it as a concept. Is it really fundamental to financial accounting? Might a different meaning not be more effective?

Here, accounts do not receive primary attention to arrive at relevant patterns. What is considered first is a complete financial accounting system, which helps to bring the accounting organizational entity into focus. It then becomes evident that several such entities may be relevant, and that those organizations are also related in some way. In fact, often an important, constituting reason for their close relationships is the fact that organizations exchange information obtained from their respective financial accounting systems. The independent organization and its independent financial system are, according to this view, not an exception but the simplest case of cohesion. So, as a rule, several related organizations exist. The simplest case is represented by a single organization; consequently, cohesion is reflected by a (boundary) value stating its ‘absence.’ In general, by using abstraction and corresponding boundary values intelligently, the modeler can always arrive at more compact, flexible models.

In the original patterns in Aspecten en Fasen, no explicit distinction is modeled between organization and (its) financial accounting system. The basic assumption, therefore, referred to the information system annex organization. The added assumption of related systems requires that, for each information system, all (other) information systems with which information may be exchanged are known. Figure 1 provides the model of networked accounting systems.³ Implicitly, such a model assumes equivalence between the system of organizations on the one hand, and the system of financial accounting systems on the other. This has proven to be too simple. But then, such were the assumptions of the original alternative.

Figure 1: A network of accounting systems.

At this stage of pattern development, it is still possible to connect to the accounting tradition. The obvious step, then, is to add (general ledger) accounts for every financial accounting system. However, that would bypass a vital opportunity for improved compactness and flexibility.

In order to recognize and appreciate the alternative, it is necessary to keep the model strictly focused on the administrative organization. A general question about an organization is: What does it do? An equally general answer is: It is involved in organizational processes. It appears that with process a very powerful concept has been introduced for patterns for financial accounting.

3. Dimensions and phases

What happens within processes? A general (but for acquisition of requisite variety, useful) answer is: transactions. It is obvious that complex processes generate transactions of all types and sizes.

In view of information requirements, the next question is whether there exists a single, meaningful criterion to classify transactions. By actually zooming in on the financial aspect of transactions, it is apparent that every transaction requires an explicit decision for its realization. This criterion holds, for example, for allocation of a budget, for agreeing on a contract, for a transfer of a payment, etc. Through abstraction, it is possible to postulate separate phases of decision making during overall processes. In the original alternative, those phases are strictly consecutive. Another early idea is to establish phase as a variable. This means that all processes need not follow a predetermined, absolute route of phases in decision making. Their possible sequence could be determined ad hoc; that is, separately for each organization annex financial accounting system. Each system thus acquires its characteristic series of (transaction) phases, as shown in figure 2. To control the information flow between a particular financial accounting system and its so called contact systems, the definition of relevant phases in different systems must be coordinated.

Figure 2: Characteristic (decision) phases for each accounting system.

A purely one-dimensional succession of phases, however, is untenable in more complex processes (with their correspondingly complex official rules for financial management and accounting, as in the central government ministries of the Netherlands). In hindsight, it seems extremely simple to label a straight succession of phases one-dimensional. But this concerns the very concept with which the pattern was enriched greatly: dimension. To understand how, a short introduction to the Fourth Amendment to the Government Accounting Law (Comptabiliteitswet) of the Netherlands is given first. That particular amendment replaces the single cash-oriented budget with two goal-setting amounts. In addition to, and given priority over, the cash budget, a contract budget is specified for organizations and their processes. Then, during the relevant budget period, an executive organization should not exceed either the allocated cash budget with its payments, or the allocated contract budget with its committed contracts. In popular terms, this is called the double lock on spending. The Fourth Amendment requires a double orientation to the financial aspect of transactions. To model these orientations, the concept of (temporal) dimensions is suited. It even leads to a more general abstraction, as there is no reason to limit its values to cash dimension and contract dimension. For example, investment dimension is often realistic; that is, an orientation focused on the time during which the investment budget is allocated.

Adding specific dimensions does not undermine phases. One phase still follows another, but now every series of phases is limited to a particular and primary dimension. In addition, phases across dimensions may be linked. Through such relationships, phases acquire one or more secondary dimensions. This means that, at the inspection level of phases, relationships may be unambiguously modeled. The phase of the cash budget, for example, is related to the phase of the contract budget. This relationship is necessary, as the contract budget for a particular period is distributed to form parts of the cash budget for one or more periods. As a distribution mechanism is involved, the phases of contract budget and cash budget, respectively, are linked through a distribution relationship. Inversely, it holds that all cash budget amounts which refer to the same contract period (which is a calendar year for government institutions in the Netherlands) must total the contract budget allocated for that period. In the same way as contract and cash budgets, the phases of actual contracts and their cash-flow estimates are linked through a distribution relationship. With the Fourth Amendment of the Government Accounting Law of the Netherlands still under consideration, it is logical that the phases of contract budget and contract are also related; the phases of cash budget and cash-flow estimates of contracts should also be related. These are called consumption relationships; actual contracts, for example, ‘consume’ the cash budget.

The payment phase occupies a special place in the configuration. As a rule, payment reflects the last decision phase of processes. Therefore, all dimensions converge in payment. As such, payment is connected with consumption relationships to all of its earlier phases.

The phased configuration of a financial accounting system, enriched by dimensions, is meant to support purposeful registration of transactions. Corresponding to phases, a separate ledger exists for every phase. Such ledgers are symbolized by cubes, making it simple to sketch an overview of dimensions and phases. Figure 3 presents the pattern for a single financial accounting system along the lines of the combined cash-/contract-flow requirements.

Figure 3: Minimal configuration for compliance with Dutch government accounting law (Fourth Amendment).

In figure 3, a consumption relationship between phase ledgers is represented by an unbroken line. A dotted line means a distribution relationship. The single (capital) letters represent phases as follows:

B - contract budget
K - cash budget
V - (actual) contracts
R - cash-flow estimates of actual contracts
X - payments (and receipts)

When B is replaced by I (investment budget), a model results which is suited for private sector enterprises. It should be noted that this involves the contract dimension changing to an investment dimension. The contract dimension focuses attention on the period during which actual contracts are agreed upon. With an investment dimension, attention is primarily given to whatever is considered an investment, from investment budget through contracts (and possibly other intermediary phases), up to payments. All transaction instances during these phases (also read: of these types) should also include a reference to the period during which the initial investment budget was/is approved. Until now, the Netherlands’ government has viewed contracts and the contract dimension, rather than the investment dimension, as sufficient to control ‘real’ investments.

4. Primary dimension

For registration of the financial aspect of a transaction, it’s necessary to first know in which financial accounting system the relevant journalizing group and its entries belong. Next comes the choice of the proper phase.

A rule states that a transaction/journalizing group is always limited to registration in a single phase ledger (and, by implication, in a single financial accounting system). Another rule is that each and every phase ledger is governed by the monetary equilibrium of double entry accounting. Balances hold on a smaller scale than the general ledger as a whole, and auditability is correspondingly simplified and improved.

A journalizing group consists of two or more entries, by definition of double entry accounting. A single journalizing entry refers to exactly one account in a general ledger; or, rather, in a phase ledger. All entries to all accounts of a particular phase ledger must have as property at least one shared dimension. This is called a phase's primary dimension. The primary dimension of entries to the contract budget phase ledger is the contract dimension. According to the Fourth Amendment explained earlier, this is also the primary dimension of the contract phase. In that specific model, the phases of cash budget, cash-flow estimates of actual contracts, and payments have the cash dimension defined as their primary dimension.

Theoretically, the number of primary dimensions in a financial accounting system is unrestricted. In figure 4, the investment dimension is included, while the contract dimension has been retained. Including the cash dimension, this makes for three primary dimensions. But take note that a more logical idea is to shift actual contracts from a place along the primary dimension of contracts to a place along the primary dimension of investments. However, in the Netherlands, the Fourth Amendment to the Government Accounting Law has not yet been superseded by new legislation. Based on dimensions and phases, an improved accounting model is already available. See Aspecten en Fasen for a (far) more detailed analysis.

Figure 4: Investment dimension added to minimal configuration of phase ledgers.

5. Related accounts

It may be specified, per individual account, whether a single journalizing entry contains one or more references to other dimensions (besides the mandatory reference to the primary dimension of the phase ledger in question). Suppose, phase ledger R holds an account for the distributed cash-flow estimates originating from a particular account in phase ledger V. Every entry onto that R-account will then include a cash control period, because the cash dimension is primary; but that same entry must also mention a contract control period. However, the balancing entry in the journalizing group for the transaction (with the cash-flow estimate of the actual contract here as the transaction) will most likely be posted at an R-account with no relationship to a V-account. In such a counter entry, just the relevant cash control period is required as information for dimension.

Even though the conceptual model has already been developed in some detail, what constitutes an account has still not been defined from within. Rather, it is the relationship between accounts which determines the essential information in journalizing entries.

Because each phase ledger may contain many accounts, all figures here abstract from individual accounts, showing only phase ledgers. Thus, only relationships between phase ledgers are visible, instead of the more detailed ones between accounts in different phase ledgers. It should be clear, however, that such relationships between phases only indicate the possibilities of account relationships. It may be concluded that account relationships sometimes skip phases. A payment account, for example, may be directly related to an account in the phase ledger of the cash budget, rather than through an account in the phase ledger of the cash-flow estimates of actual contracts. It all depends on the specific requirements of the accounting organization itself and of the larger system of stakeholders in which that organization participates.

6. Intersystem relationships

The relationships between accounts may cross the boundaries of financial accounting systems. In fact, as account relationships secure cohesion and constitute a configuration of phase ledgers within a single financial accounting system, they also hold the overall system of such systems together. Examples of types of relationships between accounts from different financial accounting systems are: delegation, reporting and informing. The rule for such intersystem relationships: they are allowed only between accounts in ledgers for identical phases. Figure 5 provides an example based on the models shown earlier in this chapter for separate accounting systems.

Figure 5: Linked phase ledgers in different accounting systems.

In figure 5, two financial accounting systems are shown, on two hierarchical levels. Phases I, B and K are concerned with (financial) objectives; that is, they contain amounts which may/must be spent. Therefore, information flows through delegation relationships between accounts in phase ledgers. As drawn above, direction flow of these relationships follows tradition from top to bottom. What may not be apparent is that one level is more important than another.

Phases V, R and X are ‘filled’ with transactions during execution/implementation by the operational organization, sketched at the lower level; the information, aggregated as specified, flows ‘up’ through corresponding reporting relationships.

The internal requirements for financial consolidation should inspire a particular organization to choose a characteristic configuration for its overall financial accounting system. To keep in step with external requirements in a minimal fashion, identical dimensions and phases must be shared between constituting elementary accounting systems. Figure 5 shows complete correspondence. A realistic departure might be that the R-phase ledger is omitted at the upper level.

Without even specifying an account, a rich foundation for a conceptual information model has been laid. It may even be considered a result of not specifying the concept of account in anything but a general fashion. The ideas and arguments presented so far in this chapter may be summarized with metapattern as shown in figure 6.

Figure 6: Overview of original pattern for relational accounting.

This pattern yields a more specific and at the same time (much) wider meaning to the concept of chart of accounts. Traditionally, such a chart, or classification scheme, holds the rules about which accounts may/need be instantiated.

The system of accounts presented thus far governs the dimensional orientation between phase ledgers in a single financial accounting system, as well as the flow of information between financial information systems in an overall financial consolidation system. To a certain extent, such configurations are often coded implicitly through account numbers. However, this does not result in generic, flexible conceptual models. Particularly where variety is large and changeable, explicit account relationships must be favored.

In general, a sure sign of a conceptual modeler's professionalism is in completely abstaining from proposing external meanings to provide internal structure for the information set. Information uniquely identifying an information object at the technological level should not be based on any of a real object's properties.

7. Subject classification of transactions

A transaction can be seen as an overall object, in which a journalizing group, one of its partial objects, represents the financial aspect of the transaction. Stated more clearly in terms of metapattern, the journalizing group is the transaction in the context of financial management. As other relevant partial identities of the overall object appear in the information set with their contexts and corresponding intexts, information per context may be kept to a minimum. This raises the question of how elaborate a journalizing group and its entries should be. Overview is guaranteed, even without any duplication. Information about partial identities from different contexts can always be combined. Figure 7 provides examples of traditional functional contexts, which can now be integrated because they all reflect partial identities of an overall transaction.

Figure 7: Functional contexts for partial identities of transaction.

However, a journalizing entry must also contain references to particular subjects. With metapattern, there is no difference between a reference to a ‘normal’ information object and a reference to an information object created for selection and retrieval. The latter would constitute an element from a thesaurus.

The rule underlying the patterns here: a journalizing entry may contain an indefinite number of subject references. Actually, it is often possible to structure subject classification of transactions to a (very) large extent. This opportunity is rooted in the existence of relationships between transactions. A possible denominator for specific transactions is, for example, a case. With respect to a particular case, an organization could commit itself through a contract; that agreement would then count as a transition. Another transaction which the organization constitutes is probably payment of the bill, received after products or services have been delivered as contracted. Those transactions can be related when both the contract entry and the payment entry refer to the same case-as-subject.

Special subjects, deserving a separate status in journalizing entries, are quantity and all references to relevant dimensions. They have been added to the pattern shown in figure 8, applying the rules for dimensions as explained earlier in this paper.

Figure 8: Entries to accounts.

8. Accounts

In part I, the patterns for financial accounting end with general ledger accounts, which traditional information models are almost entirely based upon. Use of the account concept must, when expressed mathematically, be necessary and sufficient to establish (a) dimensional differentiation within financial accounting systems; and, (b) information flow between financial accounting systems constituting an overall consolidation system. To serve these purposes, accounts may be given ‘names’ which, for flexibility’s sake, should exclude any external system references. What is needed, then, is for all required ‘systematic’ relationships to be explicitly determined. Reports do not require any such meaningfully ‘coded’ account identifiers; the unrestricted possibilities of subject classification offer all the reporting flexibility required.

However, to improve acceptance by persons who cherish accounting tradition, it is recommended creating conceptual account identifiers with which they themselves will be able to identify. A successful tactic for change is to view an account identifier as a composition. Its constituting elements are: phase, cost type, cost center and cost activity, as shown in figure 9. Of these Cartesian product elements, only phase and cost type should be considered mandatory. Therefore, when no (other) value for cost center and/or cost activity is registered, they retain their default value of indeterminate.

Figure 9: Ledger account as Cartesian product.

Part II

The patterns for financial accounting presented in Part I are oriented at integration with other aspects of organizational processes and their corresponding information requirements. Together with an emphasis on process phases, the ideas behind the title Aspecten en Fasen (aspects and phases) should be clear. Since its publication in 1991, the author has continued to develop financial accounting patterns resulting from the increasingly explicit formalization of metapattern. The multicontextual approach serves particularly to optimize information integration. Superficially observed, model changes and enhancements often seem minor. What counts is the real increase in variety made available through improved patterns.

9. Positional accounting systems

In the original patterns, no explicit relationship is modeled between organization and financial accounting system. When, inversely, an organization is defined to serve as a unit of financial management, a simple model results (figure 10). As the same organizational element can appear in multiple organizations-that is, in various contexts in the corresponding homogeneous classification hierarchy-it is possible to define organizations separately for financial management. For that purpose, even relationships may be used as a mechanism for differentiation.

Although the possibility now exists, it should be actively discouraged to invoke too many definitions of what amounts to the same organization. Even when organizations coincide with financial accounting systems, their underlying concepts or types should be separately modeled.

Figure 10: Making the organization as accounting entity explicit.

Next, does the concept of organization (with actual organizations represented by nodes in a homogeneous classification hierarchy) provide sufficient variety? A comprehensive answer is impossible to give. The inverse approach leads to the assumption of relating a financial accounting system to a position rather than organization as shown in figure 11. The question is what the extra variety, provided by the constituting elements of person and job, consists of. And do real information requirements exist which are served by the richer model?

It’s evident that a far more finely-grained system of accounting systems may be configured, and purely organization-oriented accounting systems continue to be possible. For ‘just’ organizations may be considered a subset of all positions (where the values for person and job are both indeterminate). However, based on the compositional nature of position, a financial accounting system can also be defined for a particular person holding a certain job, or even for a person only. All such accounting systems would still fit within their overall system of financial accounting. An individual sales person, for example, might completely administer her or his ‘own’ financial accounting system; it would, then, maintain information flows with one or more financial accounting systems of a more organizational nature. The organization employing the sales person allocates sales budgets and must be informed about negotiated sales contracts, perhaps establishing one or more phases in between for additional management and control of sales processes.

Anyway, there are no restrictions introduced when moving from a strictly organization-based to a position-based system of (financial accounting) systems.

Figure 11: Again, introducing position for increased flexibility.

This positional perspective should also be applied to the information flows between separate financial accounting systems. The obvious rule is that two such systems may maintain a flow relationship, only when a relationship has been formed between their underlying positions. Those positional relationships have been described elsewhere (Wisse, 2001; see § 12.5). Figure 12 shows some more details of the intext of the positional relationship.

Figure 12: Control of information flow between accounting systems.

The possible differences emphasize that large variety is characteristic for conceptual modeling, too. The modeler tries to construct a general framework, then attempts to make changes necessary for the conceptual information model to fit the actual requirements of a particular case. Patterns are meaningful as starting points; a really useful model often needs at least some customization.

10. Configuration management

As Part I described, information objects belonging to several types determine the overall behavior of a particular financial accounting system. Which dimensions exist? Which phases? What are the (internal) relationships between phases? And, based upon the latter, which relationships have been defined between accounts? How are the accounts identified externally or conceptually? Which subjects may be referred to in journalizing entries?

All of this information provides structure to an accounting system. Although many different systems may exist, several of those accounting systems probably share structural characteristics in their overall configurations, and, therefore, they also share structural information. Those correspondences must be recognized to simplify management of a configuration of financial accounting systems.

It might appear the easiest solution when a pointer information object, referring to an instance of a financial accounting system, is defined as a mandatory subject for every journalizing entry. Essentially, this guarantees that reports may be generated based on that particular criterion.

However, each financial accounting system is first and foremost part of a context which determines behavior of accounts and journalizing entries posted to them. Every relevant context, therefore, must be differentiated into an ordered collection of information objects, necessary and sufficient to uniquely determine appropriate (additional) behavior.

Again, how can configuration management be simplified when those behavioral parameters are identical? It turns out that the variety of position-based financial accounting systems may require additional measures. Suppose the explosion onto position instances from its homogeneous classification hierarchy occurs as in Figure 13.

Figure 13: A tree of position instances.

When one or more financial accounting systems have been defined for position 5, they may get their behavioral parameters supplied by position 2, its defined financial accounting system. However, such inheritance is only unambiguous when position 2 maintains a single accounting system. Without a guarantee to this extent, the financial accounting system from which behavioral parameters must be derived should be explicitly referred to. As such, this is just an example of the possibility of multiple inheritance.

Of course, position 2 (and its financial accounting systems) may not have (all) behavioral parameters available itself. Then, at least in this example, the route in search of parameters leads to position 1.

There is an alternative. The hierarchy in financial management, as represented by the configuration of position instances, does not presuppose correspondences in the behaviors of their respective financial accounting systems. Instead, just one of the constituting elements of position may provide superior orientation for behavioral similarities. In practice, it seems logical to view inheritance of behavioral parameters from an organizational perspective. Starting from a particular position instance, the values for person and job should both be replaced by indeterminate. This yields the position instance which might provide the required information objects as part of its intexts. Sticking to this example, organizations are nodes in a homogeneous classification hierarchy. Starting from a particular node, the intexts of superior nodes may also be inspected in search of parameters.

Combined, several mechanisms establish a wide horizon for inheritance. What all kinds of inheritance share is the (largely) implicit nature of how successive (potential) sources of parameters are addressed. The horizon widens following the route through an information network which has probably been defined for different purposes. It is more of a bonus when previously structured information also serves the purpose of supporting configuration management in financial accounting. However, are divergent purposes well served in the long term by merged mechanisms?

It will always be more resilient when a separate, characteristic support structure is created for configuration management for financial accounting. Rather than inherit parameters through more or less implicit relationships, explicit references should be included. Their only objective is to support common use of behavioral parameters for financial accounting throughout an overall configuration of accounting systems.

One extreme on the spectrum of common use is when a particular financial accounting system is structurally identical to another. The other extreme consists of the case of the two accounting systems being completely different structurally.

When structures correspond completely, and the structure of one system is already known, a single reference suffices for the structure of the second, the idea behind figure 14. Any accounting system may have a multitude of behavioral parameters listed. But for some systems, only a single parameter is sufficient; that is, the reference to another system whose structure is completely adopted. In fact, it is advisable to create a separate, even semi-virtual, accounting system whose only purpose is to serve as reference for structural information to other systems. The variety of such structural references is determined by the requirements for optimal accounting systems’ configuration management.

Figure 14: A parameter may be a reference.

When the number of differences between behavioral/structural parameters is small, it could still be efficient to take another accounting system's structure as a starting point. If so, all differences must be explicitly stated. A cost type, for example, may not be used in the derived accounting system. Such exceptions help to clarify the problem that shared parameter use requires mutual understanding. It does not matter where the possible prohibition on use is registered, that is, at one or the other financial accounting system. Whenever information is shared, coordination is necessary. Where such coordination information is physically located, and how coordination mechanisms are technologically implemented, are not conceptual issues.

In figure 15, any differences are included in the intext of the financial accounting system which inherits behavioral parameters from another accounting system.

Figure 15: Making differences between configurations explicit.

As the number of differences with respect to the reference accounting system grows, configuration management increases in complexity. Dependent on the circumstances, a particular number of differences will prove critical in the sense that a reference for behavioral/structural parameters is no longer advantageous. Along this stretch of the spectrum, however, not all parameters are different between the two accounting systems under consideration. It might thus be useful to group structural information by parameter type. Dimension, phase, phase relationship, account, etc., would all be instances of such a parameter type. Again, it should be stressed that the reference might not be completely relevant. So, even with this more limited horizon for inheritance it should be possible to include differences.

Figure 16: A variety of sources for configuration parameters.

As figure 16 indicates, for a particular parameter type, it is possible to refer to several sources; that is, to more than just one other financial accounting system. Of course, management of differences is correspondingly complicated.

Differences have a right to exist, that is, they are really relevant, whenever one or more (other) financial accounting systems serve as examples (also read: prototypes) for behavior, including structure. Besides references to other systems, and any differences which might be necessary to define as a result of those references, it should always be possible to define behavioral parameters directly for every financial accounting system. In Part I, this has already been ruled for dimensions, phases, phase relationships, accounts and account relationships.

Here in Part II, all patterns for configuration management are general, as the real variety in configurations of financial accounting systems is extremely large. That variety can only be generally indicated; more details would distract from major design choices. But even such general ideas about configuration management are not available in most patterns presented elsewhere. Why they are lacking is adequately explained by their respective perspectives. It is difficult to start modeling with individual accounts, and then bring their configuration into the model. This more general level of inspection can only be properly brought into models by giving the overall configuration a conceptual status of its own. In order to arrive at an elegant result, this should be done at the start of modeling.

11. Constituting elements of account

Information processing by fast, modern technology contributes to a significant decrease in the practical importance of independent account identifiers in general, and of account numbers in particular. To produce a wide range of reports, subject references registered through journalizing entries provide a superior mechanism. Still, the possibility of more variety in account identifiers-achieved simply by modeling an account as a Cartesian product-offers advantages. The number and types of constituting elements are impossible to determine universally. But a way exists that proves adequate in most cases, in which a particular account identifier consists of references to instances of at least phase and cost type. Constituting elements may be added instances of cost center and cost activity (see figure 9).

As stated, the practices of financial management are so varied that it becomes unrealistic to universally define what cost type, cost center, and cost activity mean. These concepts may be given their meanings within a separate financial accounting system as a context, since explicit account relationships regulate information flows between accounting systems and serve to translate between different meanings.

In the original patterns documented in Aspecten en Fasen, specific cost types appear as atomic information objects, as do cost centers, cost activities and phases. The variety of the information set is greatly increased when all those concepts are changed and modeled as nodes in as many homogeneous classification hierarchies (see figure 17).

Figure 17: A foundation for accounts with increased variety.

A hierarchical classification, however, introduces overlap by definition. A cost type at a particular hierarchical level, for example, encompasses all cost types reachable at lower levels from that node. When all such nodes may also act as constituting account elements, journalizing entries may represent an enormously complex mix of aggregation choices. A solution: authorize only the lowest-level nodes to be used as constituting elements of accounts to which journalizing entries may be posted. By definition all other accounts are summary accounts, much like they are traditionally defined. But this solution raises the question as to whether subject classification in journalizing entries should not be preferred to a multilayered chart of accounts. The answer: constituting elements which are compositions in their own right (such as a homogeneous classification) cause more problems then they solve. Therefore, the pattern shown in figure 17 should be interpreted as an attempt at testing conceptual limits, rather than as an operationally viable model. Through research into ever new opportunities, persistent patterns result. Often, the earlier patterns are maintained, and sometimes a new pattern is substituted for an old.

12. Positional exchange rate types

An important measurement of money is currency. The ratio needed to compute an amount stated in one currency into an amount in another currency is called the exchange rate.

Traditionally, transactions represented by journalizing groups and entries are consolidated into a general ledger using a single, fixed currency. Any calculations are applied before the consolidated registration. The ratio used is called something like consolidation (or registration) exchange rate.

Again, the increased processing power of information technology now warrants the conceptual conclusion that amounts in foreign currencies should not be transformed at registration. Instead, any calculations should only follow from the requirements of reports. Calculations at reporting times are also optimally oriented at relevant requirements.

When currency differences are always dealt with at reporting time (as often as a particular report is produced), transactions are registered with the original monetary amount and corresponding currency as properties. This improves the quality of the audit trail. In general, auditability is enhanced by eliminating as many constructs as possible that have gained conceptual status because of inherent limitations of manually administering large volumes of accounting information.

The application of modern information technology has also lifted a practical obstacle to frequent changes of exchange rates. Metapattern in particular makes such changes simple, as mechanisms for time management are inherently available.

Without any obstacle for frequent change, exchange rates can remain realistic. In many circumstances it is also realistic to distinguish between several types of exchange rates. As before, practical differentiation can be based on the concept of position. It could well be, for example, that one position applies different exchange rates for advances on business trips than does another position. The exchange rate type they have in common might be called advance/business travel. When those positions apply different exchange rate instances, it is only realistic that different positional exchange rate types are defined first (see figure 18).

Figure 18: Exchange rates for different positions.

Variety of positional exchange rate types is useful for applications supporting organizational processes directly (as contrasted to the configuration of financial accounting systems which together comprise the general ledger). Yet, when a transaction is consolidated into the general ledger, it must be possible to transfer amounts from rates in one exchange rate type to amounts specified in rates in another exchange rate type.

It is efficient to define a particular currency as a base. A base currency is needed for each positional exchange rate type (with an explicit reference to another type possibly included when their base currencies are identical; of course, the positional exchange rate type must be regarded as an instance of a parameter type, as explained in § 10). By definition, the exchange rate of the base currency equals 1. Then, the exchange rate of all other currencies need only be articulated with respect to the base currency (see figure 19).

It may happen that the base currency changes. When this occurs at t₁, the exchange rate of all other currencies must be adjusted from that same point in time, relative to the new base.

Figure 19: Establishing a base currency for expressing exchange rates.

13. Defaults for entries

It has been shown in a previous paragraph (§ 7, above) that transactions may be ordered in many ways. One or more such orders may be used to simplify registration by first determining the structure and then (as far as possible) the contents of journalizing entries. The concept of process offers a general starting point, particularly when this concept is modeled by nodes in a homogeneous classification hierarchy.

As always in modeling, it makes sense to first abstract from any specific process and investigate how groupings of processes may be useful, bringing the concept of process type into the model. A particular process type may then encompass one or more (possible) transaction types. Next, for a particular transaction type, a template may be defined to support registration of journalizing entries about transaction instances (see figure 20).

Figure 20: Support of registration by supplying defaults.

This pattern can be made more compact under the assumption that an individual transaction is the smallest appearance of an individual process. It allows for process type and transaction type to be subsumed under a single concept, including its modeling implementation as a hierarchical classification hierarchy. Once achieved, the correspondence between the adjusted concept of process type and transaction type (Wisse, 2001; see § 14.4) should be clear. The original perspective is authorization, and an elegant enhancement for defaulting information is presented. Here, instead, defaulting is the original perspective. Not dealt with explicitly in that earlier chapter: further differentiation to support journalizing groups and entries for financial accounting systems.

With metapattern, it seems logical to specify defaults for entries within the context of a particular financial accounting system. But defaults are often more generally valid. The solution is to model, as one of the defaults, the reference to the financial accounting system to which the entry should be posted. This is the favored perspective for the pattern shown in figure 21. The defaults at the level of a process type first determine ‘something’ for the financial accounting system; then ‘something’ for the whole journalizing group, and finally ‘something’ for the individual journalizing entries. Default values for an entry are concerned with the account, the quantity, the dimensions, and the possible subjects (see figure 7).

Figure 21: Process as generalization for transaction.

At the level of process type, which now includes transaction type, what can be determined in advance as the contents of specific entries is mostly limited to (equally) categorical references. The account may almost always be fully specified for every future journalizing entry matching the criterion of process type (transaction type). But as far as quantity, default values will probably not exceed direction and currency. With respect to a subject, it is likely that a specific information object acting as subject instance is too detailed as a default. However, its subject type may be known, and, according to metapattern, that type already provides the context of the subject instances to be chosen for journalizing entries. Finally, for dimensions, the defaults contain values for what should be called, under scrutiny, dimension types-references to, for example, investment dimension and cash dimension. The temporal information must be specified for each journalizing entry. Dimension types to be defined as defaults should correspond with the (internal) account relationship in which the default account participates. Validation of dimension type defaults should preferably occur at the time of their own registration, not each time a journalizing entry based on them is created.

Starting from authorization, defaults may be reached The inverse direction applied here shows that a remark is in order about whether defaults are mandatory or not. Is a default merely a suggestion? Is there no room for any alternative? And why not refer to another information object, rather than copying? Because these are reasonable questions, such differentiation must be included in the conceptual information model. This can be achieved by explicit orientation at default nature, as shown in Figure 22.

Figure 22: Allowance for different kinds of defaults.

The contents of future journalizing entries may acquire further details by changing the perspective from process type to process instance. Process at its most specific level equals a transaction instance, which means that all previously explained notions can be simply extended to apply to defaults for process instances. In figure 23, the enhancements are sketched generally, and any overlapping and/or contradictory defaulting information is abstracted from. Validation rules must be available to keep defaults for process type and process instance, respectively, in line.

Figure 23: The extreme case of unique defaults; that is, for process instances.

The subpattern for defaulting in the context of a process/transaction instance is identical to the one for process type (see figure 23). The specification of defaults values is correspondingly more detailed for process instances than for process types. For example, it is to be expected that (many) subject references are known in detail for a process instance. This is also probable for the temporal aspect of dimensions. Suppose the context of journalizing is a particular investment project. This predefines, for all relevant journalizing entries, the period to be registered for the investment dimension. Again, this raises the question as to whether the (implicit) mechanism, offered by the homogeneous classification hierarchies for both process type and process, should also be exploited for the purpose of inheritance of journalizing defaults. They can, indeed, but it is advisable to limit such additional use to dimensions.

14. Conclusion

The patterns presented here result from long, ongoing development. The first versions of what is called relational accounting, created as early as 1982, incorporated only successive phases in a single series. In light of the later extension by dimensions, the original was implicitly one-dimensional. Starting in 1984, the Ministry of Foreign Affairs of the Netherlands successfully applied that version to its operational financial accounting. At the time, the author was employed by the Ministry as an internal consultant and coordinator of information systems. In 1986, in his capacity as an external consultant, he revised the conceptual information model so as to accommodate the Fourth Amendment-then a draft proposal-to the Government Accounting Law of the Netherlands. The increased complexity was countered by the introduction of the concept of dimension, which greatly increased the variety. In the Netherlands, implementation started in the late nineteen eighties; the Ministry of Housing, Geographical Planning and the Environment based its operational configuration of financial accounting systems on that extended pattern.

Although both are on a large scale, they remain thus far the only two operational applications. A familiar obstacle to acceptance of innovation that incorporates the advantages of digital information technology is that information processing is often still governed by strong traditions rooted in manual practices. This can only be changed when conceptual information models are more … conceptual. A sensitivity to truly conceptual models is often lacking. In fact, in the Netherlands, the Ministry of Finance recently coordinated development and publication of some reference models. But differences in meaning (contents) are still largely uncritically transferred to differences in form, so that the variety those ‘official’ models support is far from optimal. An opportunity for renewed conceptualization has been missed.

The power of a phase-directed structure, on the contrary, results from acknowledging the different meanings (contents) which transactions derive from phases, as well as from establishing uniformity of registration-that is, of all transactions in all phases. With a phase ledger as a module, all modules are formed identically. Simultaneously, their contents have different meaning for each phase.

Without recognition of the possibilities of (very) different contents while preserving a single form, conceptual information models elsewhere continue to be based on differences in contents. The reasoning goes that a contract budget, for example, is something different from an actual contract and therefore separate modules are required. The first part of such reasoning is correct. Yes, there is a real, lasting difference. But the second part does not necessarily follow from the first. The abstraction into form makes even dimensions and phases into variables. This multiplies flexibility; more can be achieved with significantly less.

Another major advantage is won in the area of dependency. After the single module has proven to function properly, all of its implementations are equally certain to perform. As mentioned before, all of this has already been documented extensively in Aspecten en Fasen.

In the private sector, complex configurations of financial accounting systems can also be made (much) more transparent and more manageable (thus keeping the focus), with variability based on dimensions and phases. To date, no operational applications have been reported. The conjecture seems safe enough, however, that systematic variables will greatly simplify traditional charts of accounts, etc., in any sector.

The importance for financial information of robust mechanisms-for temporal references, reconstructing information and for auditability-cannot be overstated. All are standard mechanisms with metapattern. It also provides strong support for designing innovative patterns for financial accounting systems. Previous pattern versions have been successfully applied. The improvements described here, made possible or, at least, inspired by metapattern, have led to an even more powerful pattern (family) for financial accounting.

notes

1. This paper is largely derived from part IV, A Case of Financial Accounting, of Metapattern: context and time in information models (Wisse, 2001).
2. A name which is derived from the word chamber. The original meaning of room was transferred to indicate the institution governing from it, as in Chamber of Commerce. No equivalent accounting method exists, for example, in the United States of America where fund accounting is also based on double entry accounting.
3. Metapattern’s visual language is fully explained in Wisse (2001). See also www.informationdynamics.nl.

literature

Wisse, P.E., Aspecten en Fasen: aantekeningen over relationeel boekhouden, organisatorische informatievoorziening, verandering enzovoort en omgekeerd, Information Dynamics, 1991.
――――, Metapattern: context and time in information models, Addison-Wesley, 2001.

author

Dr. Pieter Wisse ( pieter@wisse.cc; www.informationdynamics.nl/pwisse) is the founder and president of Information Dynamics, an independent company operating from the Netherlands and involved in research & development of infrastructure for complex information systems and services. He is also affiliated with the PrimaVera research program in Information management of Amsterdam University.