This process does not take into account write-offs, cancelled order lines or financial transactions performed through the advanced adjustment screen.Prepare for this process by performing the steps listed below.
1. Validate all accounting setups. (For more information, please see Setting Up the Accounting Subsystem).
a. Even if accounting setups were validated before the baseline reconciliation, there might be additional setups that were subsequently completed because they did nothave any converted data.
2. Complete the baseline reconciliation.
a. The balance in the balance sheet accounts (e.g., AR, PPL, Deferred) between Personify360, and the GL should match as of the conversion cutoff date.
3. Post all batches.
a. All batches for the month will need to be closed and posted.
i. You can query for unposted batches by performing a search for all statuses except posted.
ii. If there are any unposted batches for the month, they should then be posted. See Batch Reconciliation section for more detail.
4. Obtain bank statement for the month or online access to the bank statement.
a. In order to reconcile cash, we will need your bank statement for the month or online access to the bank statement.
5. Review credit card settlement processes.
a. Credit card settlement should also be run before closing the month. Again, this is generally a daily process.
6. Enter all shipping for the month into Personify360.
a. Shipping for inventoried products will produce a GL entry for the sale. All inventoried products orders that were shipped during the month need to be entered into Personify360 with a date in the month being closed.
7. Fulfill all subscription issues for the month, if revenue recognition is by issue.
a. When a subscription product is set up to recognize revenue by issue, the revenue will only be recognized if the issue with an issue date in the month being closed has been fulfilled.
8. Run back issue processing.
a. When a subscription product is set up to recognize revenue by issue and there were backdated subscription orders entered for the month end being closed, back issue processing needs to be run for revenue recognition purposes to perform “catch-up” processing.
9. Run advertising invoicing process, ADV620.
10. Run automatic scheduling process, FAR680, for scheduled payments.
11. Set up GL & AP mapping definitions.
a. In order to interface to your GL and AP systems, the layouts of the files to be input to these systems need to be defined on the Interface Definition Mapping screen.
b. The mapping and the testing of the mapping (into the GL and AP systems) needs to be completed in order to automatically interface with your GL and AP. Otherwise, journal entries and vouchers will need to be manually input to the GL and AP.
12. Run the write-off process (FAR695), if appropriate.
13. Run the GL transfer process (FAR700) in edit mode.
14. Make sure there is no exception report (FAR_Exceptions).
15. If there are exceptions, a report titled FAR700_Exceptions will be on the Output tab of the Status Review screen.
16. Exceptions should be immediately reported to Personify.
17. Reconcile accounting entries from account summary report of FAR700 run.
18. The GL interface will produce an account summary report that contains the accounting entries that will be passed to the general ledger.
19. This report should be reviewed for anomalies and a reasonableness check. Examples are as follows:
a. The transfer account is a flow-through account and should always be zero. If it is not zero, it is a system issue and should be reported to Personify.
b. The unapplied account – this account is typically only used for those receipts for which there are no accompanying orders. Therefore, the balance should usually be relatively low.
c. Deferred and real income accounts – revenue recognition transactions will affect these accounts.
d. AR balances – possible reasons for AR balances are:
i. Overpayments
ii. If the short pay code is AR, payments on former debit balances.
iii. It is possible that there would be a credit hitting the AR for the receipt before the sale hits to debit the AR. This could be a data entry issue and would need to be investigated.
e. PPL balances – possible reasons for PPL net activity are:
i. If the short pay code is Reject.
· Partial payments would be reflected as a credit balance.
· Payments on former partial payments would be reflected as a debit balance.
ii. Prepayments for inventoried products that have not been shipped. If the order is then shipped within the month, the account would be debited. Therefore, if orders are shipped on a timely basis, the net in this account should be relatively low.
iii. Prepayments on exhibit orders where the booth has not been assigned.
· After the booth has been assigned, you will see a debit to this account to eliminate the credit balance.
iv. Prepayments on advertising orders where the advertising invoicing process (ADV620) has not yet been run.
· Prior to the issue being fulfilled and the advertising invoicing process being run, payments would credit this account.
· After fulfillment and invoicing, you will see a debit to this account to eliminate the credit balance.
v. Payments for wait listed meeting orders.
vi. If the short pay code is AR or adjust, there should not be a balance in the PPL account for other than the scenarios mentioned above.
f. Due from accounts should typically not have credits.
i. Receipt reversals, refunds and transfers will assume that this company has been paid and will create a due from entry for this company. In other words, the original due from entry for the receipt will not be reversed (i.e., credited).
g. Due to accounts should typically not have debits.
i. Receipt reversals, refunds and transfers will assume that this company has paid the other company and will create a due to entry for this company. In other words, the original due to entry for the receipt will not be reversed (i.e. debited).
20. Reconciling the cash account should be performed on a daily or weekly basis (see Cash Reconciliation section). Therefore, these accounts should easily reconcile.
21. Run the GL Transaction Analysis (FAR504), BALANCE setup, to reconcile the AR and PPL accounts and any other accounts that have both debits and credits. This setup will only show those order lines with a net balance for the account.
22. Run the GL Transaction Analysis (FAR504), ACCOUNT setup, to reconcile the others accounts.
23. The GL Transaction Analysis (FAR504) will contain the detail transactions for that account for the specified period.
a. Make sure that the grand net total matches the net for that account on the account summary report from FAR700.
b. Two possible reasons for them not matching are:
i. A transaction from a prior period was picked up and is being posted to the current period.
ii. There were entries for the month being closed after the FAR700 and before the FAR504 run.
c. If the net totals don’t match, run the FAR504_ACCOUNT setup as follows:
i. Enter a begin date of 01/01/2000.
ii. Keep the same end date.
iii. Add the following to the filter: …and far_txn.gl_txn_no=0.
d. If the net totals still don’t match, rerun FAR700.
24. Review the details of the FAR504 run to determine if the transactions are valid.
25. Enter any adjustment transactions to reconcile data.
26. An adjustment batch with the last date of the month being closed should be used to backdate adjustment transactions. See Batch Concepts.
27. Rerun GL transfer process (FAR700) in edit mode after adjustments have been entered.
28. Perform the same steps as in the previous edit run.
29. Run the revenue recognition process for all modules (FAR670) in edit mode and then in prod mode.
This process does not take into account write-offs, cancelled order lines or financial transactions performed through the advanced adjustment screen.
30. If a skipped report is produced, review the skipped report, make any necessary corrections and rerun the revenue recognition process.
31. Review the summary report for reasonableness.
32. Review the detail report for a few transactions for each account.
33. The revenue recognition process brings forward revenue from deferred accounts as the association earns it. These processes should first be run in edit mode to verify the data. It should then be run in prod to actually create the revenue recognition transactions.
34. It 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.
35. 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).
36. 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.
37. See the Deferred Revenue section for an explanation of the various types of recognition methods.
38. Run GL transfer process (FAR700) in edit mode.
39. The only difference from the previous run (before revenue recognition was run) should be the debits to the deferred accounts and the credits to the real accounts. These differences should match the entries on the summary report of the revenue recognition run, FAR670, in prod mode.
40. Run GL transfer process (FAR700) in prod mode.
41. Check to make sure that all numbers are the same as the previous edit run.
42. Update month end close date on the GL Account setup screen to the last day of the month closed.
43. Import the file into your GL system. The details of how to do this are not included in this document. Please reference your GL system documentation for this.
44. The FAR700_dt1 line on the output tab of the TRS submission status screen contains the file.
45. If two files were specified in the mapping, the second file is the FAR700_dt2 line.
46. Compare the balance sheet accounts (AR, PPL and Deferred) between Personify360 and your GL to make sure they match.
47. This assumes that your receivable accounts in your GL system only contain Personify360 transactions.
48. The report parameters below may vary if you use the same AR, PPL or deferred accounts for different modules.
49. AR & PPL balances
a. Run the GL Transaction Summary, FAR505, in Personify360.
i. A setup with the following parameters needs to be created:
· Begin date of 01/01/1900
· End date of the last day of the month being closed
· Primary break of txn function code
· Secondary break of module
· Filter as follows: far_txn_detail.txn_function_code in(‘AR’,’PPL’).
b. Run the Aged Receivables report, FAR610, in Personify360.
i. A setup with the following parameters needs to be created:
· Run mode = SUMMARY
· Begin date of 01/01/1900
· End date of the last day of the month being closed
· Include receipts before invoicing as Y
· Unapplied credits as Y Include customer 0 balances as Y Include order 0 balances as N 0 in all minimum balances Aging method = invoice date.
c. Run the Trial Balance from your GL.
d. Reconcile the balances from all 3 sources.
e. If the FAR505 doesn’t match your GL:
i. Make sure you have uploaded all files into your GL.
ii. Run the FAR505 with a break of gl txn no and match the total amount for the gl txn no to the relevant entry in your GL.
iii. Each gl txn no will correspond to a particular month. If there were multiple feeds for a month, there would be multiple gl txn nos for that month.
iv. To determine which gl txn no corresponds to which month, review the account summary report of the prod run for the month and the gl txn no will be in the title of the report.
f. If the FAR610 doesn’t match the FAR505 or your GL:
i. Make sure the Print Customer with Zero Balance and Print Orders with Zero Balance parameters are set to "Y" to include all AR transactions. When either of these parameters are set to "N", FAR505 and FAR610 do NOT match. The reason is that these two parameters exclude orders, order lines, and transactions when the total nets zero. So within an order, there may be order lines that have an AR debit balance and an AR credit balance, but those transactions are not included in the FAR610 run because the parameters are set to exclude.
ii. Review the exception report.
iii. Notify Personify that there are exceptions.
g. Deferred balances
i. Run the GL Transaction Summary, FAR505, in Personify360.
ii. A setup with the following parameters needs to be created:
· Begin date of 01/01/1900
· End date of the last day of the month being closed
· No primary break
· No secondary break
· Filter as follows: far_txn_detail.txn_function_code in (‘DEFREV’,’DEFDISC’,’DEFAGDIS’,’DEFSHIP’).
h. Run the Deferred Revenue Analysis report, FAR675, in Personify360.
i. Run the FAR675_A setup entering the last day of the month being closed as the end date.
i. Run the Trial Balance from your GL. Reconcile the balances from all 3 sources.
i. If the FAR505 doesn’t match your GL:
· Make sure you have uploaded all files into your GL.
· Run the FAR505 with a break of gl txn no and match each entry to the entry in your GL.
ii. If the FAR675 doesn’t match the FAR505 or your GL:
· Review the exceptions on the report.
· The exceptions will be in red and there will also be an amount in the difference column.
· Notify Personify that there are exceptions.
See Also:
· Overview: Accounting Best Practices
· Daily Financial Reporting Best Practices
· Weekly Financial Reporting Best Practices
· Financial Data Entry Best Practices
· Batch Creation Best Practices