XBRL-based structured digital financial reporting - Blog: Digital Financial Reporting (using XBRL)

The most suscinct definition of business rules that I have come across is this:

Business rule: A formal and implementable expression of some user requirement.

This definition of what a busines rule is comes from the Business Rules Group which is a good source of information about business rules, particularly their Business Rules Manifesto.

There really is no standard definition for what a business rule is. Here are some definitions which others use to help you get a sense for what business rules are:

A formal statement that defines or constrains some aspect of a business that is intended to assert business structure, or to control or otherwise influence the behavior of the business
A way of expressing the business meaning (semantics) of a set of information
A formal and implementable expression of some business user requirement
The practices, processes, and policies by which an organization conducts its business

Business rules exist in the form of relationships between pieces of business information. Some examples can help you better understand exactly what they are:

Assertions: For example asserting that the balance sheet balances or Assets = Liabilities + Equity.
Computations: For example, calculating things, such as Total Property, Plant and Equipment = Land + Buildings + Fixtures + IT Equipment + Other Property, Plant, and Equipment.
Process-oriented rules: For example, the disclosure checklist commonly used to create a financial statement which might have a rule, "If Property, Plant, and Equipment exists, then a Property, Plant and Equipment policies and disclosures must exist."
Regulations: Another type of rule is a regulation which must be complied with, such as "The following is the set of ten things that must be reported if you have Property, Plant and Equipment on your balance sheet: deprecation method by class, useful life by class, amount under capital leases by class . . ." and so on. Many people refer to these as reportability rules.
Instructions or documentation: Rules can document relations or provide instructions, such as "Cash flow types must be either operating, financing, or investing."
Relations: How things can be related, such as whole-part relations. For example, how the business segments of an economic entity are related.

Business rules can be grouped into two broad categories: data quality logic related and business logic related. In their Decision Model, Knowledge Partners International points out the important difference between data quality logic and business logic:

Data quality logic: is the logic used against data elements to determine if they meet various data quality dimensions such as completeness, reasonableness, etc.
Business logic: is the logic that uses data elements as conditions leading to business-oriented (not data-validation-oriented) conclusions such as compliance, eligibility, etc.

Business rules are important. Why? Because the only way a meaningful exchange of information can occur is the prior existence of agreed upon technical syntax, domain semantics, and process/workflow rules rules. you cannot create business rules after-the-fact and then expect information to follow those rules. Business rules need to be agreed upon in advance.

Business rules implemented in most business systems are a mess for two reasons. (This one hour videowalks you through this.) First, the business rules are imbedded within the system. This causes to problems: (1) the business rules need to be created by progammers and not business people, (2) you cannot exchange the business rules between business systems. The second reason that the rules are very hard to manage. There are no groups or patterns utilized. I won't go into this further, watch the video for more details.

Business rules are implemented in XBRL using XBRL Calculations, XBRL Definitions and XBRL Formulas. XBRL calculations are fairly well understood and used. Basically these articulate roll up type relations. But lots of other mathematical relations exist such as a roll forward, adjustment, or variance. There are even more complex computations. To express these and other mathematical type relations something more powerful is necessary, and that is why XBRL Formula exists.

There are other business rules which have little or nothing to do with mathematical computations that need to be expressed. XBRL definition relations are available to express these types of business rules.

For example take the whole-part relation. The document A Taxonomy of Whole-Part Relations goes into detail. This presentation (on slide 9) explains the difference between a taxonomy and a partonomy and provides these general categories of relations:

component-integral object: for example (pedal – bike)
member-collection: for example (ship – fleet)
portion-mass: for example (slice – pie)
stuff-object: for example (steel – car)
feature-activity: for example (paying – shopping)
place-area: for example (Everglades – Florida)

While XBRL can express these sorts of whole-part relations, there are no real standard approaches within XBRL for doing this. For example, while XBRL Dimensions was created using XBRL definitions to be a standard approach to expressing allowed and disallowed dimensional relations; nothing exists to express other sorts of relations. I thought that something like OWL could fill this gap, but while OWL is powerful it does not fulfil 100% of what is required and OWL is extremely hard for business users to understand.

In 2003 the paper, Business rules validation - the Standard the W3C Forgot, pointed out that there was no real way to articulate business rules using XML. Since then, many different business rules syntaxes have been created: RuleML, SPIN, RIF, SWRL. I looked into all these things before and I reached two conclusions: this is very confusing, this is very complicated.

So the question is this: What is the best approach to expressing 100% of the business rules necessary to provide the appropriate level of semantic clarity for digital financial reporting and digital business reporting? What is the best syntax for expressing all these rules? How will these business rules be mantained and managed by business users?

To get a good grasp of the types of business rules which will be important to business users, read this blog post, this blog post, and this blog post.