Skip to content
  • There are no suggestions because the search field is empty.

Deleting Data Loads

Occasionally, it may be necessary to delete data loaded to Pereview, for example as part of the data validation process. If a period was loaded twice, loaded from the incorrect statement, loaded on the incorrect accounting basis, or loaded into the incorrect period, the incorrect data stays in Pereview until it is deleted. This part covers how to tell whether a deletion is necessary, how to define what to delete, and how to confirm the correction worked.

Confirm a Deletion Is Actually Necessary

Not every correction requires a deletion. Whether a reload will resolve the issue is determined by whether the corrected file will overwrite the incorrect data or not.

  • Trial Balance Uploads Overwrite: if the initial data in question was loaded from a Trial Balance, simply load the corrected Trial Balance. The previous data for that property and period are overwritten, so no deletion is needed.
  • General Ledger, Budget, and Rent Roll Data May Not Overwrite: for these, a reload can add a second set of data alongside the first rather than overwriting it, which will overstate the affected balances. Unless you have confirmed that your specific package overwrites, assume the incorrect data must be deleted before the corrected file is loaded.

 Important: An overwrite only happens where the new load collides with the original: same property, same period, same book type, same scenario. If the original data was loaded with any of those incorrect, the corrected file lands somewhere else and the incorrect data remains. This is why a deletion is always required when data was loaded to the incorrect period or date, under the incorrect book type such as Cash where Accrual was expected, or under the incorrect scenario such as Actuals where Budget was intended, no matter which template was used.  

 Use the table below as a quick test of the above:

Situation

Data deletion required prior to upload?

Trial Balance loaded with incorrect figures (or missing a prior period adjustment), everything else correct

No. Load the corrected file alone. The data will be overwritten for the same property and period.

GL Transaction or Budget data loaded with incorrect figures

Yes. Delete first, unless you have confirmed your package overwrites on reload.

Any data loaded to the incorrect period or date

Yes. Delete first. The corrected load will not collide with the incorrect data.

Any data loaded under the incorrect book type (Cash where Accrual expected)

Yes. Delete first. The corrected load posts under a different book and both remain.

Any data loaded under the incorrect scenario (Actuals where Budget intended)

Yes. Delete first. The corrected load posts under a different scenario and both remain.

The same file was loaded twice

Yes. Delete first. Loading a third time does not undo the duplicate.

    Identify Exactly What Is Incorrect

    Before deleting anything, establish what is incorrect and what is correct. Loads performed at different times are often built differently, and it is common for an early historical load to be incorrect while later monthly loads are fine.

    • Run the GL Transaction Detail report for the property and the full period range in question.
    • Group the Results by Session ID and Insert Date: each distinct session is a separate load. This tells you how many loads contributed to the data you are looking at and when each one happened.
    • Determine Which Loads Are Incorrect: compare each line item against the source statement. Identify exactly what is incorrect so that you leave correct data loads in place.
    • Write Down the Expected End State: record what the ending balances should be once the correction is complete and check that against the partner statement. Deleting more data than necessary can create additional problems.

    Define What Data to Delete

     Deletions are defined by asset and date range, together with the attributes described below.

    • Cover the Full Range: if you are replacing January through June, the range is the whole period, not only the months you were looking at.
    • Do Not Delete Correct Data: set the end of the range so that data you have confirmed is correct remains untouched.
    • Select the Relevant Attributes: if data was erroneously loaded under the incorrect book type or the incorrect scenario, that is where the data is sitting.

           Note: Session IDs are useful for determining what happened, but they are not how data is deleted. There is no function to delete financial or Rent Roll data by Session ID; the Session ID appears in the GL Transaction Detail report for your reference only.  

          Warning: Because a deletion is defined by a date range rather than the Session ID, the range must cover exactly what you intend to overwrite, including system-generated entries such as Retained Earnings. These entries are created by a balance recalculation If your range stops short of them, they are left behind, the reload posts fresh figures on top, and the result is overstated. Ensure precise outlining before proceeding with deletion.  

           

          Performing the Deletion

          Deletions are performed from the Site Administration section of Pereview, which requires the "Admin" permission group to access. Users in the Read Only group cannot access these pages. If the pages below are not visible to you, check with your system admin or contact Pereview for assistance.

          Financial data

          The GL Accounting Data screen can be accessed in Admin > Site > Data Management > GL Accounting. This page allows you to delete financial data for an asset across a specified date range. Asset, Accounting ID, Book Type, Scenario, and the Start and End Post dates are required parameters, and each parameter narrows the data removed. Account is optional: leave it blank to delete every account in the range or select one to delete data for a single account.

            

           

          Rent Roll data

          The Rent Roll Data screen can be accessed in Admin > Site > Data Management > Rent Rolls. This screen offers two options. The first deletes Rent Roll data for an asset at a single effective date. To delete several months of Rent Roll data, repeat the deletion for each effective date.

          The second option, Delete All Rent Roll and Unit Details, deletes all historical rent roll and unit detail for the selected asset. This is not defined by date and cannot be undone. Use it only when you intend to rebuild an asset’s rent roll history from scratch.

           Note: The Reset Charge Schedule maps the charge codes on the rent roll file, such as “Rent”, “PetRent,” and “Parking” together with their monthly charges, to the Rent metric and other KPIs in Pereview. It determines whether pet rent, parking, CAM, and other charges are included in your Monthly Rent figure or reported separately. Because of that, resetting it changes how rent is reported. Leave this set to No when you are simply removing rent roll data. Choose Yes only when the charge code mapping itself is what needs rebuilding. The mapping is configured in Admin > Site > Configuration > Tenant Lease.  

            

           

          Requesting a Deletion from Pereview Suport: If your permissions do not include deletion, or you need Pereviews assistance to delete, contact Support@PereviewSoftware.com. Please include the following:

          • The property name and its Pereview accounting code.
          • The data type to be deleted, such as General Ledger, Budget, or Rent Roll.
          • The date range to be deleted, or the effective dates for rent roll data.
          • The Book Type and Scenario the data was loaded under, if known.
          • The exact issue with the current data, and how you determined it.
          • Any correct loads that must be preserved.
          • Whether you have a corrected file ready to load, or need the data deleted first.

          Reloading the Corrected Data

          If you will be reloading corrected data after deletion 

          Review the Corrected File Before Loading It

          Do not load a file simply because it looks correct. Each check below looks for a different class of defect, and it is common for a corrected file to pass many of them while still failing a one of them.

          • Completeness: every activity row in the source appears in the file, and every row in the file corresponds to a source row.
          • No Duplication: the file does not contain the same activity twice, which is a common artifact of assembling a corrected file from multiple exports.
          • Period, Book Type, and Scenario: these are the attributes that determine whether the load replaces or sits alongside the existing data, so confirm all three before loading rather than after.
          • Account Coverage: every account code in the file is mapped in your PMC Chart of Accounts.
          • Balance Check: the file’s ending balances match the source statement before you load it.

           

          Confirm the Correction Worked

          After reloading, run Tier 1 and Tier 2 validation again for the affected property and periods rather than assuming the reload resolved it. Pay particular attention to the following:

          • Balance Sheet is Balanced: Confirm that Assets = Liabilities + Equity.
          • Retained Earnings Ties: if Retained Earnings is now overstated, the likely cause is rows left behind because the deletion range did not cover them. Revisit the range.
          • Ending balances tie to the partner Trial Balance across the full corrected range.
          • Early Periods Report Balances: confirm the earliest corrected period returns balances rather than appearing empty.

          Recommended Best Practices: Deleting and Reloading Data

          ☐ Confirm whether the affected data overwrites on reload or requires deletion first.

          ☐ Check Period, book type, and scenario, since any mismatch requires deletion regardless of template.

          ☐ The GL Transaction Detail has been grouped by Session ID and Insert Date to identify which loads contributed.

          ☐ Incorrect loads have been distinguished from correct loads that must be preserved.

          ☐ The expected end state has been documented and checked against the partner statement.

          ☐ The deletion is defined by a date range across the full replacement window, using the Book Type and Scenario the data was loaded under.

          ☐ The range has been checked for stray rows sitting in unexpected periods.

          ☐ The corrected file has been reviewed for completeness, duplication, period, book type, scenario, and account coverage.

          ☐ The deletion has been performed or requested from Pereview with the full detail above.

          ☐ The corrected file has been loaded, if applicable.

          ☐ Tier 1 and Tier 2 validation have been re-run across all affected properties and periods.

          ☐ Retained Earnings has been checked specifically for overstatement.