Special reconciliation programs are required for objects that are credited with each settlement. These reconciliation programs ensure the following consistency conditions:

• If the balance for a settled object was zero before the Euro changeover, it should also be zero following the changeover. This is important as the system can usually only archive an object with a balance of zero.
• Even after the Euro changeover, settlement must be able to settle an object completely. To enable this, you need to reconcile the control tables from the settlement with the actual credit lines for an object.

To reconcile the balance, the system needs to determine which objects had a balance of zero before the changeover. To do this, start the RKASAL01 program in the FILL phase. For each object that has already been settled at least once, this program determines the balance of every individual posting period, using the COSP and COSS tables. These values are then saved in the EWUCOSUM table. The system does not change the EWUCOSM table during the subsequent changeover.

Once the actual changeover has ended, you must start the reconciliation program RKASAL02 in the RECON phase. For each settled object, the program uses the EWUCOSUM table to determine certain posting periods. These are the posting periods whose cumulated balance was zero before the changeover, cumulated meaning the balance of all the previous periods, and the period being processed. The program recalculates the current balance for each of these periods. If rounding differences occur, the system adjusts the settlement credits so that the balance returns to zero. This adjustment only takes place in the totals records created by the settlement. The program does not change any other totals records, nor does it produce any new line items.

When you settle an object, the system does not just create credit lines for this object. It also creates special settlement documents (AUAK, AUAA, AUAS, and so on) and creates another object management record (COSPD or COSSD) for each debit line. These control records determine which amount the system has already settled. After changeover, this data is not reconciled again. This could mean that an object can no longer be settled completely. In that case, the system settles either too much or too little.

The RKAABR02 reconciliation report adjusts the control tables for the settlement so that an object can always be settled completely. If you repeat a settlement after the changeover, the system can also create postings for it, providing no postings have meanwhile been made on the object. If the object had more than one settlement receiver or more than one settlement cost element, rounding differences can occur. These require repostings between receivers and/or cost elements.

You can start the RKAABR02 report after production operations resume (POST phase). You must, however, run the report before the next settlement. If the system finds rounding differences of more than 10 EUR during the reconciliation, the corresponding object is not reconciled and a message is created in the log. You need to analyze the unreconciled objects closely (if required, in cooperation with the SAP Hotline).

For each settled object, the total of the settled amounts in the control records COSPD, COSSD and COSBD, must correspond with the total for the settlement credits (COSP, COSS). If this is not the case, the system distributes the difference proportionally on the control records. The system does not change the credit lines. This procedure ensures that no residual balance exists if you settle the object fully.

For periods in the current fiscal year, where no cutoff period is set for the transaction "Actual settlement" (KOAO), the system compares the settlement credits with the settlement documents, especially with the values in the AUAS file. If the system detects differences, it corrects the AUAS records automatically. This ensures that there is no balance left on an object, even if period-based settlement is repeated.

After the changeover, the values in the totals records usually differ from the total for the corresponding line items. However, no differences are allowed to exist between totals records and line items for commitments (COSP, value types 21/22/23) and down payments totals records (COSP, value types 12). Otherwise for commitments, this would mean that even after the complete reduction of commitments to zero, there would be a residual balance in the totals record (in the report). You cannot archive the object.

For down payments, no residual balance may remain in Controlling once the down payment in the FI component has been cleared. This is especially important for capital-investment measures for which down payments are settled to an asset under construction (AUC).

The RKACOR10 report recreates the commitments totals records (COSP) from the commitments line items (COOI). The RKACOR19 report Recreates the down payment totals records (COSP) from the down payment line items (COEP, value type 12) You should start both programs following resumed of production operations in the POST phase. However, these programs should be run at a time in which no postings are being made that change the values of down payments or commitments.

The reconciliation ledger (COFIT table) contains summarized information regarding all value flows into, within and from Controlling. The system creates the reconciliation ledger using the CO line items (COEP). However, it no longer contains any information about the individual CO objects. It does contain summary of the values for the following characteristics:

• Company code
• Business area
• Functional area
• Cost element
• Object type
• Object class

The reconciliation ledger also registers value flows between these characteristics, such as, between two company codes. You can post these CO internal value flows back to the FI component, either manually or automatically. If you implement cost-of-sales accounting, you can for example, post value flows between functional areas from the CO component back to the cost-of-sales accounting ledger.

During reconciliation posting from CO to FI, the system posts the value flows from the reconciliation ledger back to FI. It creates control records from the totals records in the reconciliation ledger for this purpose. These control records contain the amounts posted to FI. For legal reasons, the values in these control records must match up to those in the FI documents created after the changeover. To achieve this, you should start the RKACOFI2 report in the POST phase, following the Euro changeover. This report adjusts the control records for the reconciliation ledger (COFIT and COFIS) to the FI documents.

After the control records from the reconciliation ledger have been matched up to the FI documents, it is still possible that these differ from the totals records in the reconciliation ledger. You can repeat the reconciliation posting to reconcile CO and FI completely.

Within a budget structure (such as a work breakdown structure) the system can distribute a budget from higher hierarchy levels to lower levels. However, the distributed budget may not exceed the original budget. The same rule applies when an overall budget is distributed over several fiscal years. To minimize such budget overruns during the EURO changeover, the system always rounds budget values down.

Nevertheless, it can still happen that the total of the distributed budget overruns the overall budget of the higher-level nodes. In this case, the system displays error messages during the budgeting transactions. To clean up such inconsistencies, you start the RBPEWU1P report following the Euro changeover. This report corrects the values of the budget hierarchies affected, for work breakdown structures in the BPGE and BPJA tables.

The system does not pass budget adjustments that occurred during reconciliation on to the availability control. If you want to inform availability control of the budget adjustments, you must recreate the assigned values.