A large multinational corporation paid two consultants for a year to prepare and execute financial training for its European rollout. After go-live, most people had forgotten the training, and a chaotic situation reigned for at least four months. Additional expensive support was essential to clean up mistakes and to raise administrative quality. I've found that this is not an exception, but very much the rule — an expensive rule causing cost, frustration, and hostility toward a new SAP system. Of course, go-live is stressful, but some simple actions can alleviate most of the pain. This article provides six tips I've gathered during go-lives that you can adapt to your business to get your financial employees off to a good start. These tips also apply when you add new functionality or upgrade your system.

1. Send a "favorites" file to users. Favorites files help to cut down searching time in the extensive SAP tree, but to create them, users first need to find the transactions. At a recent project, we introduced favorites during training. We entered each transaction that was part of the training in a favorites folder. After concluding the training, the favorites structure was downloaded to a file and sent by email to participants. They uploaded the favorites when the production system became available. We created a go-live kit that was mailed to all users on the first day, which included a reminder about uploading the favorites file.
   
   After you create a favorites structure, you can download it through the menu path Favorites>Download to PC (Figure 1). Uploading the file is done through Favorites>Upload from PC. The new favorites are added to the existing ones. This means that distribution of favorites can also be used later.
   
   
   
   

   Figure 1

   Download favorites to local PC
   
   Remember that you can add documents and URLs to favorites folders. In this way, you provide users with a complete starting kit, including full documentation and instructions. A bundle of transactions and documentation is more efficient than an email message that might be lost or go unread.
2. Create a structure for work routines. Working in a new system or with new functionality disturbs existing work routines. It is a fallacy to suppose that users know what actions are expected from them once they enter the SAP system. A risk is that control functions begin late in the day when mistakes related to go- live have already accumulated. The result is a rapidly increasing correction workload threatening both efficiency and the quality of financial figures. This in turn prevents an efficient month-end closure. For example, in a Nordic company, nobody realized that a report existed for billing documents that had not been transferred to finance. When they encountered this transaction (VFX3), three weeks had elapsed and more than 3,000 order lines had to be corrected.
   
   To relieve the pressures of month-end activities and to ensure a high-quality control from day one, my company is in the habit of creating a simple work structure to guide the main activities in the first months. The operative word is simple. We sit with the financial managers and propose a minimum set of daily and weekly activities. Often we modify this to fit the particularities of a company, but the main principle does not vary wildly. Make sure that names are attached to tasks. Responsibility tends to be fluid after go-live or major system changes. Typically, these stressful periods cause some of the key employees to leave.
3. Make important daily checks. Some daily activities that should be addressed are shown in Figure 2.
   
   
   
   

   Figure 2

   Daily transactions
   
   Regular users will be surprised: that simple? Yes, that simple! However, in many go-live situations, it takes a long time to put these routines in place. Could you add transactions to the list? Of course, but the aim of these interventions is not completeness, which can overload employees. Instead, simple, short lists are more helpful.
   
   Here's a quick look at these transactions:
   
   

   •	V23: SD documents blocked for billing. Typically, these are credit notes created in the SD module that receive an automatic system block that needs to be removed. Or they could be caused by incomplete prices. Executing this control right away ensures that credit memos are issued in a timely way to customers and that mistakes in the system (e.g., missing prices) are discovered before much damage is done
   •	VFX3: Release documents for accounting. This transaction identifies those billing documents that did not result in a financial posting. During the first phase of a system implementation, this report provides information on missing or wrong tax settings, incompleteness in the automatic account assignments, etc.
   •	SM35, SM37: Batch input: session overview, to check batch jobs. Even in a perfect world, not every planned batch job runs smoothly from the start. Yet most people assume otherwise. A quick daily check prevents undiscovered problems that otherwise surface when they are most unwelcome, such as during the first month- end.
   •	F.13: Automatic clearing. This should be a regular activity for cleaning up accounts and providing a view on items that are not yet cleared. This facilitates the checking activities of the financial department. This department typically checks the goods receipt/invoice receipt account and the goods in transit account to monitor the two main SD processes: procurement and sales.
   •	VKM1: Blocked SD documents. Manages sales orders and deliveries that are blocked for credit reasons. Companies tend to be overly enthusiastic about the possibilities of credit management. The result is a large number of orders/deliveries that are blocked for credit once the system goes live. Review these orders/ deliveries from day one to ensure that business processes are not hampered and that adjustments of settings in master records or customizing can be discussed as early as possible.
   •	MRBR: Release blocked invoices. This is the central transaction to release incoming invoices that have been blocked for payment, generally due to discrepencies in quantity or prices.
   •	V.21: Log of collective run. This contains an error log for all of your billing runs. The outgoing invoices often need additional work in the start of an SAP system.
   •	FV50, FV65: Parked documents, credit memos. It is a good idea to check for parked documents in the system. These documents receive numbers taken from the financial document ranges and should be dealt with in a timely fashion.
   •	MB5S: List of GR/IR balances. This generates a report with GR/IR balances that serves as an early alert for issues in the purchasing area.
   •	FF68, FEBA, F-28, F110: Check registry, post processing, incoming, and outgoing payments. Test the incoming and outgoing payments as early as possible with small volumes.

4. Perform weekly checks of intermediate accounts. At least once a week, check the important intermediate accounts to monitor activities (or the lack of activities) in the system:
   
   

   •	The cash-in account to check if incoming payments are cleared on a regular basis — balances often indicate difficulties in working with the new system.
   •	The GR/IR account to check if both incoming invoices and goods are processed correctly.
   •	The GIT account to check if deliveries are billed in a timely fashion (old items indicate otherwise).
   •	The manual adjustment accounts for revenues. Revenue accounts are posted to "automatically" when sales orders are billed. In general, these accounts cannot be posted to "manually." If corrections are needed, this often is done to a special adjustment account that allows for manual postings. If these accounts are used more then incidentally, it often indicates confusion about the right procedures to cancel or correct billing documents.

5. Prepare for disaster. Comparatively small issues upset people's trust in the system and they quickly build up into a growing additional workload for a group that has already been stressed by the go-live. It is wise to be prepared as follows:
   
   

   •	Authorization needs quick adjustments. Make sure that during the first month you have a speedy method in place to announce issues and to adapt authorization.
   •	Master records will show errors. Make sure that this can be mended as quickly as possible. Having just one master data officer can be a bottleneck.
   •	Documents, most notably invoices and documents that accompany goods, in complicated flows often are designed late in the day. After go-live, they will show imperfections such as a missing legal clause or a distortion of the layout. Some prices could be loaded incorrectly in the system. The first invoices should always be checked thoroughly before sending them out. It is advisable to have a clear view of how you will deal with them. If, for example, a customer master contains the wrong payment term, the correction will only be effective in new sales documents. Cancelling your billing document and regenerating a new one does not work in this case. Making a credit note with reference to the sales order followed by a debit note picks up the correct payment term. On the other hand, changes in a customer address or VAT number are effective at once. In these cases, cancelling the billing document and rerunning VF04 (process billing due list) does the trick.
   •	Manage the issues. During the first month, many issues surface at once and a tired team plods through them one at a time, guided by their own guess at priorities. Users tend to give everything a high priority. It often helps to have management identify areas of priority. A simple guideline such as this suffices: First, deliveries to customers should run properly. If necessary, billing documents can be retained for some time. After that, all legal, fiscal, and pricing/billing issues should be dealt with.
   •	Designate one or two managers to operate as process owners and train them to deal with financial administration issues. Uncertainty about whom to address causes problems and loss of time.

6. Prepare for your month-end closure. If you start thinking about month-end closure around day 25, you might as well not have bothered. If you have an existing procedure, make sure it is translated into a sequence of R/3 transactions and discuss the requirements of each step. A well-documented month-end procedure is a cornerstone for transparent and trustworthy financial data, a theme that has grown in prominence with the Sarbanes-Oxley legislation.
   
   Whatever fancy tools are used later on to increase the quality of your month-end, the process always starts with a simple report detailing timing, actions, and responsibilities. It is an absolute minimum requirement. Once the content of the month-end is agreed upon, it should be published, preferably on a company intranet.
   
   Many month-end processes can be run as a batch job, minimizing the risk of human error. You also should create variants for transactions and reports that are generally run only once a month. Employees will forget the correct setting or wonder about alternatives. The same goes with holiday replacements. Make sure these variants are created prior to the first month-end.