Baseline Reconciliation

1. Prepare for this process by performing the steps listed below.

a. Validate all accounting setups. (For more information, please see Setting Up the Accounting Subsystem)

i. For the baseline reconciliation, it is only necessary to ensure that those accounts to which money will be applied for converted orders are accurate.

ii. It is a good idea to validate all other accounting setups at this time also because you will now be entering data into Personify360 and having valid accounts will result in a smoother month end reconciliation process.

b. Review and validate converted data.

i. It is recommended that data for conversion be pulled from your current system as of the end of the month. This will result in a smoother baseline reconciliation process.

ii. Orders and payments that were rejected should be entered manually in a batch that is backdated with the batch date on or before the conversion date. This batch should be posted before beginning baseline reconciliation.

c. Enter manually converted data.

i. There may be data in your current system that is needed in Personify360 but was not large enough in volume to be cost-effective for automatic conversion.

ii. This data, both the orders as well as the payments, should be entered in separate batches with the batch date on or before the conversion date.

iii. All these batches should be posted before beginning baseline reconciliation.

d. Lockbox batches

i. Lockbox batches are typically received a few days after the deposit date. Therefore, lockbox batches for dates before the conversion may be received after the final conversion.

ii. These batches are typically backdated to the deposit date and included in the previous month. In the case of conversion and the baseline reconciliation, these batches should not be included as part of the baseline reconciliation because they are not in your general ledger.

iii. Provide the batch IDs to the business analyst before the baseline reconciliation occurs so that they can be excluded from the GL transfer process for the converted data.

e. Run relevant account balances from your GL system.

i. In order to validate the account balances in Personify360, they will be compared to the account balances in your GL system as of the conversion date.

ii. Therefore, it is necessary to run a trial balance from your general ledger system. The typical accounts with balances are the receivable, PPL, and deferred accounts.

f. Run detail reports from your legacy system for balances to be reconciled.

i. This data will be matched to detail reports from Personify360 on the same account balances. Reports should be in customer number sequence with separate sections by module.

ii. If you did not have receivables in your old system, run a report of partial payments. This is explained in subsequent paragraphs in this section.

2. Run all relevant revenue recognition processes (FAR670) in edit mode, verify numbers and run in prod mode.

a. If orders (e.g., membership, subscription) were converted with nonzero dollars and if money is deferred (i.e., the revenue recognition method is other than “on invoice”), the revenue recognition process will need to be run for the baseline reconciliation.

b. The revenue recognition process brings forward revenue from deferred accounts as the association earns it.This process will need to be run through the last month it was run in your former system (usually the conversion date) in order to bring Personify360 in sync with your general ledger.

c. This is a self-correcting process. It will figure out how much money should have been earned up to the processing date and will then recognize the portion of that amount that has not yet been recognized. For example,

i. The last active member order from January, 2003 through December, 2003 was converted. The conversion date was August 31, 2003 and revenue is recognized on a monthly basis. The revenue recognition process will be run with a date of 8/31/2003 and will recognize revenue 8 months of revenue from January, 2003 through August, 2003.

ii. Another alternative is to run this once for each month if a monthly audit trail is needed.

d. For membership and subscription revenue recognition, you might be changing your revenue recognition method when implementing Personify360.

i. In this case, it will be necessary to create three special setups that includes selection criteria to take this into account:

· A setup for converted data for the baseline reconciliation.

· A setup for regular GL runs until the end of the year.

· A setup for regular GL runs starting the next year.

ii. For example, perhaps revenue used to be recognized through the end of the year (i.e., December) and will now be recognized on a monthly basis. When running the revenue recognition process for conversion, it will be run through the end of the year.

· When running the revenue recognition process on a monthly basis until the end of December, those converted transactions for which revenue was already recognized must be skipped. Otherwise, because this process is “self-correcting,” it will reverse the revenue that has already been recognized.

iii. This is only true for order lines where revenue has not yet been fully recognized. Once an order line has been fully recognized, it will be marked as such and this process will skip it.

e. This process should first be run in edit mode to verify the data. It should then be run in prod (production) mode to actually create the revenue recognition transactions.

f. The revenue recognition process creates revenue recognition transactions (type 7) in Personify360. The amount for a Type 7 transaction will always be zero. This is because AR or PPL accounts are not involved in this transaction. Normally, type 7 transactions will be a debit to the deferred account and a credit to the actual revenue account (will be reversed for recognition of discounts).

g. If subscriptions are recognized by issue, the subscription fulfillment process (SUB670) will need to be run for issues that were previously fulfilled before running the revenue recognition process.

h. After all revenue has been recognized for an order line, a view of the distribution summary will show the deferred revenue accounts to be zero.

3. Run the GL transfer process (FAR700) in edit mode.

4. Make sure there is no exception report (FAR_Exceptions).

a. If there are exceptions, a report titled FAR700_Exceptions will be on the Output tab of the status review screen.

5. Reconcile accounting entries from account summary report (FAR700_Summary) of FAR700 run.

a. The GL transfer process will produce an account summary report that contains the GL accounting entries.

b. This report will be reviewed for account balances and compared to your general ledger system through the conversion date.

i. Matching and reconciling these numbers is the bulk of the baseline reconciliation process. The general approach to reconciliation will be as follows:

· Many times your former system works differently from Personify360 from a financial perspective and it may be like “comparing apples to oranges.” The goal is to get it to be like an “apple to apple” comparison as much as possible.

· When the numbers do not match, they will be divided into smaller groupings to determine if this is limited to a particular group or a pervasive discrepancy.

· The next step is to review the detail and match the transactions one-for-one to determine if a pattern is detected. If there is a pattern, sometimes a script can be written to apply a change across the board.

· Sometimes it will be necessary to make changes to Personify360 transactions one-by-one.

· For certain accounts, it just might be necessary to perform a reasonableness check on the amount. A journal entry in your general ledger system to get the amounts in sync might then be necessary.

ii. Receivables

· The significant issue in the baseline reconciliation is whether there should be receivable balances and how much they should be. Almost all associations accept partial payments even if it is an exception rather than a rule. Being an accrual-based system, the choices in Personify360 are that there will be a receivable balance for the remainder of the order amount or the entire partial payment amount will go into prepaid liability. Therefore, there will typically be a balance in either the receivable account or the PPL account.

· Some examples of a discrepancy in the receivable balance are as follows:

o Erroneous payments in your old system. For many clients, the reason you are changing systems is that the financial data from your old system was unreliable. This may require a carefully review of payments from your former system or a business rule that can be applied to all order lines.

o If your short pay setup is Reject, orders with partial payments should be converted with a status of Proforma (it is up to you to pass this status if you are converting with templates) for them to conform to the business rules you will be using in Personify360. If they are converted as Active, the remaining balance will be in the receivable account.

iii. Prepaid liability:

· The section on Accounts Receivable and Prepaid Liability in this workbook contains information on the reasons for a balance in the PPL account.

· Unapplied receipts are typically used in instances where you do not know what the payment is for. These types of payments usually wouldn’t be converted. Therefore, the unapplied receipts account should not have a balance.

iv. Deferred balance:

· The balance remaining in deferred after running the revenue recognition processes in Personify360 should match the remaining balance in the deferred account in your general ledger.

v. Real income accounts:

· These accounts will typically be reviewed for a reasonableness check depending upon how much history was converted.

c. Run the GL Transaction Analysis (FAR504), ACCOUNT setup, for the particular account to be reconciled. This will contain the detail transactions for that account through the conversion date. The grand total should match to the account summary report from FAR700.

d. Review the details of the FAR504 run initially researching some of the order lines in Personify360 to determine if you recognize the problem. If not, compare the details on this report to the report from your general ledger system.

6. Enter any adjustment transactions to reconcile data.

a. An adjustment batch with the conversion date should be used to backdate adjustment transactions. See Batch Concepts.

7. Rerun GL transfer process (FAR700) in edit mode after adjustments have been entered.

a. Perform the same steps as in the previous edit run.

8. Run GL transfer process (FAR700) in prod mode.

a. Check to make sure that all numbers are the same as in the previous edit run.

The output file will not be passed to your GL system because the accounting entries already exist in your GL system.

9. Update month end close date on the GL Account setup screen to the conversion date.