FAQ - Effective Date vs. GL Report Date

Retroactive Transactions and Historical Reporting

When working with Tenant Certifications and compliance issues, you will find yourself correcting a Tenant's certification that was effective some date in the past.  For example, a tenant comes in with new income that they started receiving a few months ago.  With this new information, you need to correct the certification that was effective back then or add an Interim Recertification as of the time of the change.  This retroactive correction will create events for each of the past months impacted by the change.  In this example, the tenant will end up owing more rent and receiving less subsidy.  All of the adjustments from the retroactive certification will have effective dates in the past.

Property Manager gives you the ability to make changes to a tenant's open items with the changes being displayed and reported for those effective dates (changes shown in "real time").  For example, if because of a retroactive transaction, a tenant owes $20 more a month starting 3 months ago, these new open items will be aged on a report run by Effective Date as if they existed 3 months ago.  While this shows a true picture of what is going on at a property, the Accountant needs a way to run reports that reflect how GL Entries from these open items are posted/recorded to the General Ledger.

Accounting people tend to live in the past which necessitates Historical Reporting.  With Historical Reporting you need to be able to run an A/R Report back on December 31st, for example, and then run it again today as of the same December 31st date and have the report show the same results each time.

To be able to satisfy both audiences Property Manager gives you the ability to run many of the accounting/transactional reports by either Effective Date or GL Report Date.

Effective Date is the date given to an event.  For example, Property Manager generally bills rent at 11pm on the last day of the month for the following month (April’s rent will be billed on March 31st).  The effective date, in this case will be April 1st.

GL Report Date is the later of the date the event and underlying GL Entries were entered/created or the Effective Date.  When a pending GL Entry is processed, the user has the ability to change the GL Report Date (Process GL Batches).  For example, if you create an event on 04/02/2008 with an effective date of 03/25/2008, then the GL Report Date will be 04/02/2008 (unless changed to 03/25/2008 on the processing of the GL Entry to the General Ledger).  If you create an event on 04/02/2008 with an effective date of 05/01/2008, then the GL Report Date will be 05/01/2008.  The chart below further illustrates this relationship:

What the GL Report Date does is give you a way to run a more static report.  If you run an A/R Report by Effective Date with an effective date of 03/31/2008 on 03/31/2008, then run the same report again on 04/02/2008 after making the 04/02/2008 adjustment (with a 03/31/2008 effective date) mentioned above, the A/R Report will have changed for this adjustment.  If you run an A/R Report by GL Report Date with a GL report date of 3/31/2008 on 3/31/2008, then run the same report again on 04/02/2008 after making the 04/02/2008 adjustment (with a 03/25/2008 effective date) mentioned above, the A/R Report will give you the same results as when it was run on 3/31/2008.

GL Report Date when a Cutoff Day is Defined (System Administration > Accounting Setup - Export Information Setup).  When you set a Cutoff Day for a community, the GL Report Date of the event and its GL Entry is set based on the Cutoff Day.  For example, if the cutoff day is set to the 25th, GL entries created on 10/26/08 will have a GL Report Date of 11/01/08.  In other words, all GL Entries created after the 25th of a month will have a GL Report Date set to the 1st of the next month.

If the Cutoff Day is changed while GL Entries are still pending, then the GL Report Date for those GL Entries will be updated based on the new Cutoff Day.  With the above example, the Cutoff Day is changed to the 27th, the Pending GL Entries will now have a GL Report Date of 10/26/08.  Once a GL Entry is processed to your accounting application, the GL Report Date is set and changing the Cutoff Day will not change the GL Report Date of Processed GL Entries.

When processing GL Entries from Accounting Detail > General Ledger using the Process Selected Batches task, the user will have the option to change the GL Report Date and override the Cutoff Day (i.e. - the ability to process GL Entries into a prior period instead of into the Report Month specified by the Cutoff Day.

Reporting by Effective Date

When the ’r;GL By Date’ parameter on a Report is set to Effective Date the resulting report will return transactions that are effective within the defined date range. In this way transactional reports run by Effective Date are dynamic in that they will be updated to include any applicable retroactive transactions processed up through the day the report is run. This also means that running the same report with the same parameters may return different results over time as retroactive transaction are executed in the system. That is, a report run on Wednesday may look differently than it did on Monday if retroactive transactions were processed on Tuesday.

Reporting by GL Report Date

Setting the ’r;GL By Date’ parameter on a Report to GL Report Date will result in a report that is not effected by retroactive activity. Because of this, reports run by GL Report Date are constant and will return the same results.  For example, the 01/01/2007 Household Balance Report will look the same in December as it did in July or February regardless of retroactive transactions processed in the interim. It is often useful to run reports by GL Report Date when trying to tie balances to General Ledger as, in most cases, the GL activity created for a retroactive transaction will be posted in the current month (the month it is entered in the system) rather than prior months as those periods are usually already closed.

Changing the GL Report Date on Processing GL Entries

The GL Report Date for an Event and its underlying GL Entries can change when a user changes the GL Report Date when processing the GL Entries to the General Ledger (Process GL Batches).  When processing GL Entries, the GL Report Date will default to being left unchanged, but the user does have the option to change it.  Giving the user to option of posting a GL Entry as a prior period adjustment or posting it into the current period.  If posted as a prior period adjustment, the GL Report Date of the Event and underlying GL Entries will change to match this date.  That way the GL Report Date will allow you to always be able to run a report by GL Report Date that matches the balance of a GL Account in your General Ledger.

Auto Process

For those who don't use the General Ledger process to export GL Entries to your accounting system, the Export Type for your communities should be set to Auto Process, which will ensure that the GL Report Date on all Events/GL Entries will remain unchanged from when they were originally created.