Here's some info for you cross-disciplined accounting/computer people:
There is an article on page 43 of Byte Magazine this month, August 1997,
entitled "Data Warehousing's Credibility Crisis". It discusses the problem
that many data warehouses constructed in large businesses do not reconcile
with revenue and expenses in the accounting system or the reported financial
results after adjustments.
All those marvellous detailed analyses of expense and income don't equal
what really happened. Not by a mile.
There is a great opportunity today for accountants to get more involved
in the management of enterprise data. This is one example where a little
bit of cooperation and support by the controller can go a long way
towards making the expensive data mining efforts pay off.
Controllers have a core responsibility as watchdogs, over the basic accuracy
and credibility of financial aspects of reports from a data warehouse.
You can't say "it's not my job" any more. Even if the database is
an IT department project, it is in controllers' best interest to see
rock-solid accuracy to the last dollar, backed up by audit. Line managers
won't be able to snipe at the reports to avoid taking painful actions,
but more importantly, the data will be less prone to major inaccuracies
that can drive bad decisionmaking.
Articles from the computing press, such as the Byte article, appear fairly
frequently and they indicate the database people are aware of the huge
discrepancies that arise out of different cutoffs, different accounting
systems in various locations, different cost or revenue codes, broken
mapping between various charts of accounts when they change, currency
conversion or translation differences. Database people need accountants'
help, so let's give it to them.
Monitoring data in the data warehouse and speaking out about inaccurate
reports is one example of the changing responsibilities of accountants and
CPA's which in my opinion, are not being adequately met by them.
What can we do?
A. Be aware that in multinational companies, accounting data is a
hypercube with the following groupings and dimensions, as a minimum:
- Account group, and Account code - Lets say Rows.
- Period, year and month, - Columns.
- Reporting entity, division, dept - 3rd dimension= cubes (multiple spreadsheets)
- Actual, Budget, Forecast - Stacks of 3-dimension cubes of sheets.
- Currencies - Pallets of stacks of boxes of sheets
- By product line, product, etc. - getting beyond usability....
- by executive, manager, supervisor responsible
- by professional or employee, depending on industry, etc. etc.
The only possible way to administer the company is with a relational database.
B. Be aware that for a relational database to work, it must have accurate metadata,
"data about the structure of the data", e.g. the names of the
dimension labels listed above. The database also needs the meanings of all of
the reference codes that occur within your accounting data (account code, department,
C. Everybody's codes in various systems, in different operating units of the
company, are typically different. Nobody's codes are probably being used in
the reporting database. It is done by mapping your codes against some
theoretical master code scheme.
D. Just be aware that whenever you change the way you classify transactions
(account code, department, product, etc) or move them to a different grouping,
it will always break the existing mapping into the database. Thus, every
controller has a responsibility to maintain records of all of your codes,
and the way you group them into reporting subtotals.
In my opinion, a competent controller should have an accurate history of the
changes in your metadata: dates and details of how your business unit has added
codes, dropped codes, re-labeled transactions retroactively, changed the usages of
codes, etc. This is not something you can do after yearend, during audits,
or when I.T. system analyst asks you about your data. It has to be done
contemporaneously, and even then it requires an uncommon level of discipline.
You can see why controllers take refuge in saying, "not my job". But it
is definitely your job. The challenge of correct revenue and expense
totals was the challenge of a previous generation. They rose to their
responsibility and now, we should rise to ours. You don't have to build
the data warehouse - but you have to understand your data, communicate the
issues to computer nerds, and understand what is needed to make it work.
Finally, in my opinion, the controller is responsible to read the reports
from the database and insist that they be correct.