Version Note: In previous versions of Tabs3, changing the Report Date for the Detail A/R Report would change the aging period shown. However, this did not provide an accurate picture of historic A/R. Beginning in Version 19, the aging period is always based on either the system date or the A/R as of date for historic A/R.

The following steps are used to calculate the historic A/R value. Note that no changes are made to the data stored in Tabs3 when calculating this value.

  1. Process all ledger and WIP payment records that are on or before the specified date into a temporary Historic Ledger file. Records after the specified date are ignored.
  2. Review all statements in the Historic Ledger file and undo any allocations that were made after the specified date. This includes write offs, payments, and statement credits.
  3. Review all payments in the Historic Ledger file and undo any allocations that applied to ledger records after the specified date. Examples would include payments that remained unallocated until a statement dated after the specified date was generated.
  4. Review all payments in the Historic Ledger file that were refunded after the specified date, and reapply the amounts back to the original payment.
  5. Review all payments in the Historic Ledger file that were reversed after the specified date, and reapply the original payment allocations.

Due to the allocation records involved, any Ledger Integrity Check errors will likely cause incorrect historical information to be reported. If information is no longer present in the software, the historic A/R may not match any original Detail A/R Reports. For example, if a statement was final billed and updated on December 31, but unupdated on January 5, a Detail A/R Report run for historic A/R as of 12/31 will not match a Detail A/R Report that was actually run on 12/31 for current A/R, as the statement record no longer exists as part of the calculated A/R.