Fun with Financial Controlling

"Any inconsistency in a large system will keep biting you until you fix it.
So don't start off with inconsistent stuff!"

That's an old developer's truth. However, there is sometimes a fine line between real inconsistencies and a complex reality.

Financial Project Controlling Basics

Today's discussion comes from the area of financial controlling, also called management accounting, analytical finance, or simply controlling. To me, controlling is the interesting part of financial management, with its goal of supporting management decisions; discussions of accounting, by contrast, tend to deal more with compliance issues and the sometimes Kafkaesque tax rules.

In particular, project controlling deals with calculating reasonable profit & loss (P&L) figures for each project in a company. This is very important, because it allows a company's managers to identify unprofitable customers and sometimes to detect budget overruns before these problem projects have had the chance to crash.

]project-open[ vs. Other ERP Applications

Most ERP applications are build on an "accounting" financial base, simply because these systems have been written for companies who are producing, buying and selling physical goods. Tracking the value of physical goods through a value chain is the domain of accounting.

However, ]project-open[ has been built exclusively for service companies. For service companies, accounting is nothing but a hassle twice or four times a year. Instead of looking at accounting measures such as circulating working capital, warehouse stock levels, and the like, service companies worry about things like keeping their knowledge workers in the company, perceived customer service levels, and detecting project cost overruns early. And yet these figures don't even appear in accounting balance sheets or income statements.

Controlling with SAP

Large ERP systems such as SAP, Oracle, and Dynamics-NAV also provide controlling functionality to companies' financial managers, but this controlling is built on top of the accounting base. In SAP, for example, controlling is based on reclassifying invoice items based on a number of business rules in order to come up with contribution margins per product class. This is why controlling is an optional module for SAP and the other ERP systems: The core is always accounting.

Controlling with ]project-open[

In ]project-open[ we have designed our financial system the other way around: Invoices and other financial documents produced in ]po[ are first created in and associated with a project. This way, we achieve two major advantages:

• Less information = Better usability:
  We don't need to ask the user to provide the system with the detailed and difficult to understand accounting information
  
• Real-time project controlling:
  By associating financial information directly with a project, all stakeholders get real-time financial information.
  

Export to Accounting

The missing accounting information — account numbers, tax codes, and such — are added in a second step when exporting the financial documents to a separate accounting system twice or four times a year. This step is usually supervised by an accountant who knows his job, so that none of the business managers have to spend their time crunching numbers.

Reassigning Controlling Documents

Up to this point, everything seems fine. But there is one area that causes trouble in ]project-open[: Financial documents that are related to more than one project.

This issue appears in particular in projects with many large sub-projects, where it's necessary to bill more then one sub-project in a single invoice, or when a provider writes a cumulative bill for services delivered for more than one project.

A simple solution could be to split a financial document in two and assign these parts to their respective projects. But by doing this, we would lose the 1:1 matching between ]po[ invoices (and invoice numbers) and accounting invoices.

The correct solution for this issue is to mark a re-distributed invoice as "redistributed" and to create separate financial document "pieces." However, ]po[ V3.3 and V3.4 don't yet support this relatively complex procedure.

The Need for Human Decisions

Instead, we have decided to require a "human decision" in these cases now. So we currently present accountants with an error message if an invoice relates to more then one project.

Inconsistency or Complex Reality?

To come back to the beginning of this article: Is this need for a "human decision" a fix for an inconsistency in the system, or is it part of a complex reality where only a responsible human has the necessary knowledge to make a decision?

We believe that the second option is correct, and that the ]po[ financial system suits its domain better then any of its competitors.

Please let us know your opinion!