The next step is to build the formulas that the report is based on. The problem I’ve found with writing financial reports for companies is that when given the initial specifications (and I use that term loosely), the person requesting the report says something like, “For the account descriptions and classifications, just use what is stored in the database.” I can tell you from experience that this is usually said by someone who hasn’t taken the time to look at the database, and doesn’t want to be bothered with it right now. Once you present them with a draft of the report to review, they are all too eager to rename the groups, change descriptions, and consolidate multiple accounts into a single account. This is to be expected because financial reports serve different purposes for different people. What is in the database can’t fit the needs of everyone. Public reports generally follow a strict format while internal reports are tweaked to meet the needs of different managers. Since you are the report designer, you have to be flexible to account for change requests as the report is being designed. Depending upon how you designed the report, this can will either be no problem or cause you a lot of frustration.

I like to set up the report so that no actual database fields are used directly on the report. Instead, I create a formula for each database field and display that formula on the report. Initially, the formula simply returns the exact value of the database field. Since the formulas just repeat the data field, the report doesn’t suffer a performance hit. This might seem a little wasteful, but as the report is reviewed and revised, the formulas can be easily tweaked to make custom changes where necessary. For example, the final formula for the account name will usually consist of a bunch of If-Then statements that modify the account name for specific account numbers.

What most report designers are tempted to do is drag and drop all the database fields onto the report designer. When it comes time to change account names or merge multiple accounts into a single group, they then have to create new formulas that make these changes and swap out the original fields with the new formulas. This creates a lot of extra work as you reposition the fields and fix the formatting. I suggest taking the extra two minutes in the beginning to create a few simple formulas that mimic the original fields. In the long run, you won’t need to buy as much aspirin and you will have a much quicker turn-around time for change requests.