Why Use Business Rules For Accounting?

We’ve accumulated 15 years experience in the construction of BRMS based accounting systems. Back in July 2010 we summarised why we believe this technology is so well suited to this domain both in a blog article (in which we compared a BRMS based approach to a totally bespoke approach and one based on an off-the shelf accounting product) and our white paper WP211.

Here we consider some additional questions posed to us by clients in the past year.

1. Using a BRMS is overkill for accounting, surely a relational database with in mapping tables for generate postings is sufficient? After all, most accounting systems are just mappings of business events to postings.

• You can do this. But how will business users use such a system? If you elect to have IT edit the rules, you have lost a great opportunity for direct business stewardship of the accounting policies, which is turn means that your rules will be less agile (because all business rule changes will need to be mediated through IT) and more prone to error (because of the business/IT translation required).

• If you require business users to steward the rules you will need to wrap the database environment to support a user interface business users can work with. One that supports maintenance of rule integrity, version control, user friendly web interface, change audit, rule reporting and so on. One that prevents business users from common errors (e.g., accidental entering of mutually inconsistent rules) and that makes rule entry easier in the way that a database form is unlikely to. You will soon find the cost of this additional customisation mushrooms out of control and can easily exceed the cost of a vendor product. Then you will have to ask yourself: what business are you in finance or software development?

• Relational databases are very powerful tools, but they do not provide the same degree of flexibility is defining flexible rule formats and powerful conditions as a BRMS. Relational tables may be able to express simple, equality based, decision tables. But they cannot represent computational fact types, set membership, boolean operators and decision trees, neither can they support gap or overlap integrity checking without requiring considerable additional development. All of these futures give a BRMS tremendous power that is pertinent to the evolution of an accounting ruleset.

2. BRMS is about inference and accounting does not require inference, ergo accounting does not require a BRMS.

• Inference (and the use of algorithms like RETE to make inference computationally efficient) is a powerful technique in the armoury of many BRMSs. It allows a declarative expression of business rules that is well suited to some business domains. However, inference is only one aspect of the functionality of BRMS. Many BRMS packages have no support for it at all and not every business problem, including accounting, requires it. Most accounting rules can be, and are, expressed in strict, mutually independent sequences with no interactions between rule instances.

• However BRMS do provide many other features which are directly relevant to accounting, for example: safe agility, speed to market, visibility, business control, organisation, business optimisation, behavioural traceability, goal traceability, support for governance, safety and control, audit, performance and testability. This is further explained here.

3. Inference aside, accounting rules are not very complex, why should we require a rules management system to support them?

• Accounting rules need to accommodate many product types which have very similar, but not identical accounting treatments. As a result, accounting rule sets very repetitive and many related treatments need to be repeated across products for consistency. Therefore it makes sense to denormalise your rules because by so doing you can reduce the size of your accounting schema by 5-8 times. This increases the number of rules, but vastly decreases the size of each one.

• It is difficult to denormalise rules in a relational database without loss of integrity between them. This is because rule integrity and relational integrity are very different concepts. BRMS have this capability as standard. However, without a BRMS this has to be added by the client (through potentially expensive bespoke development), or omitted entirely (introducing new modes of inconsistency within your rule set and increasing the cost of management).

• In addition rulesets managed with a BRMS are better able to express reusable accounting treatments and variants from this norm triggered by specific product types or regions. Features like rule inheritance, dynamic ruleflows and categories help to make rulesets, based on a BRMS, very product scalable. This allows radically different products (e.g., fungible equities and non-fungible swaps), with careful design, to be handled by the same ruleset.

Conclusion
In short, just because you can cycle from Glasgow to Gibraltar to attend a business conference, that does not mean this is a very practical way to get there if you have aircraft or trains at your disposal and you are close to deadline. Similarly, you can support accounting rules without the aid of a BRMS and possibly save a few dollars, however when you look at the practicalities of enterprise accounting, a BRMS powered solution is easier, more robust, more scaleable and, we would contest, ultimately cheaper.

Tags: Business Rules, Accounting, Best Practice