I constructed the process for verifying the consistency of the fundamental accounting concepts incorrectly. While the process does work just fine, it is harder to maintain and debug than it needs to be.
The basic mistake that I made is that I used a forward chaining approach to creating the system when I should have used a backward chaining approach. This article by Dustin Huntington, Back to Basics – Backward Chaining: Expert System Fundamentals, explains the difference between backward chaining and forward chaining well.
A backward chaining inference engine makes system development and maintenance much easier. Traditional code, which generally uses forward chaining, becomes very complicated as complexity increases making maintenance of the system and even developing the system harder and therefore more costly.
Further, using an off-the-shelf backward chaining engine is better than creating your own engine. Why? Two reasons. First, working off-the-shelf backward chaining engines are proven. They have already been debugged. Second, the cost of off-the-shelf solutions can often be less than creating your own backward-chaining engine. Pretty much a "make or buy" decision.
And so, if you are implementing the fundamental accounting concepts; don't make the mistake I made. Use backward chaining. This becomes even more important when you implement additional digital financial reporting consistency or verification checks or an expert system for creating digital financial report creation software.
Also, consider using some sort of off-the-shelf backward chaining inference engine such as PROLOG, DATALOG, an OWL 2 DL reasoner, or even a proprietary reasoner such as FLUENT.