A PDF version of this guide is attached at the bottom of this article for download.

Terms

Transactions

Dates for Transactions

Accu-Trax uses 3 types of dates to identify Transactions.

1. Transaction Date: This is the date that the Transaction is set to take place. This date can be set in the past or future, and it can be edited by any user with Transaction editing permissions.

• It is possible that a user can backdate a Transaction using this date into months that may have already been billed for or reported on, creating a discrepancy.
• The Transaction Date is the default date shown on the Transactions tab in Accu-Trax, though the Record Date can also be shown.
• For recurring Transactions that are posted automatically each time a Service is rendered (autoposting), a default Service Transaction Day is used as the Transaction Date, which can be set in the Company Settings menu under Posting.
  • For any manually posted Transaction, either using the Quickposting menu or the Batch Posting menu, the Transaction Date is manually set.
  • It is important to note that the Transaction Date (the date that this Transaction is set to take affect) for recurring Services are set in the Company. Even if the Service is technically taking place on a Thursday 4 times per month, for example, the entire monthly balance is charged on that set Transaction Date – it is not broken apart into 4 charges, 1 per each Thursday.

2. Record Date: This is the date that a Transaction was entered into Accu-Trax. It cannot be edited. It is used to when calculating customer balances (I.e., how many debits have been entered up until this point, and how many credits were entered up until this point that balance against them?).

3. Bill Date: This is the date that a Transaction first appeared on a bill.

1. It is possible for a single Transaction to appear on multiple bills.
2. The Bill Date is not displayed on the Transaction’s details and is only found in special reporting. However, it can be used for Transaction Aging purposes depending on the Bill Code settings.
3. The Bill Date is set when the bill is being generated, but it is not the date that the bill was generated. It is possible to backdate or forward date the Bill Date.

Groups of Transactions

Transactions in Accu-Trax can be grouped into 4 high-level groups. These groupings are not hierarchical and are unique (1 identifying group per 1 Transaction):

1. Bill Code: Transactions do not have a Bill Code assignment, but they can only be attached to a single customer account who can only possess 1 Bill Code at a time.

2. Service Area: Service Areas are unique to Customer Sites (Service Addresses), and a Customer Site must be assigned to a Transaction. 1 Transaction can only be assigned to 1 Customer Site and thus Service Area at a time.

3. Transaction Types: All Transactions have an assigned Transaction Type and may only possess 1 at a time.

4. Customer Types: Similar to Bill Codes, Transactions do not have a Customer Type assignment, but customers may only possess 1 Customer Type at a time.

Types of Transactions

Transaction Types in Accu-Trax can have 4 behavioral flags applied:

1. Service: This flag is generally used for recurring Transactions created from any type of Service, though it does not necessarily need to be recurring. However, Accu-Trax will seek to block the autoposting of all Service Transactions if a Service Transaction is posted. The assumption is that the recurring Service has already been posted for, and thus additional Transactions should not be automatically posted. If the Service Transaction was autoposted, further autoposting is automatically blocked until the following period. If the Service Transaction was posted manually, the user is prompted to block autoposting for the period or continue without blocking.

2. Extra: This flag is generally used for extra Transactions (Transactions that are abnormal/additional to the recurring Service). They will always be displayed on the next bill regardless of their Transaction Date, given that they have not appeared on a bill before.

3. Fee: Fees are special charges for items unrelated to the Servicing of customers altogether, such as payment processing fees, NSF fees, startup fees, etc. They have a similar behavior to Extras.

4. Payment: This flag is generally used for any type of payment received. It’s only assigned behavior is to determine whether the Transaction will be displayed on a bill. If the Bill Code is configured to include payments on the bill, then Transactions with this flag will be displayed, otherwise they will not.

Billing

• Billing in Accu-Trax can be performed using the default process (Billing Process > Create Bills) and by using Instant Bills. The default Billing Process will autopost all Service Transactions for the Billing Period, post any applicable finance charges, and generate the bills. The Instant Bill process will only post Transactions to that specific customer for the Transactions and total amount listed.
  • Billing Periods in the default Billing Process are determined by the arrears/ahead month assignments set in the Bill Code.
  • Instant Bill Periods are determined manually from the “Billing Period From:/To:” fields.

    It is incredibly important to note that the Instant Bill provides the user with the ability to manipulate Transaction amounts, descriptions, and Transactions on the bills. While they can never post additional charges through the Instant Bill (that must be done by actually posting a Transaction), they can manipulate what the Instant Bill shows. This is likely not in accordance with fair accounting principles. Just like how a user can errantly apply false Transactions to an account, they can also apply false bills. It is the company’s responsibility to oversee the fair use of this feature in compliance with any regulatory accounting body.

Bill Codes

The primary function of Bill Codes is to group customers based on billing behavior. Bill Codes dictate the Arrears or Ahead assignment for billing in monthly intervals.

• Bill Codes can determine the minimum balance required to send a bill (it is blank if all customers should be billed regardless of balance).
• Bill Codes can also set a minimum balance, in conjunction with the aging bucket, required to send a customer the delinquent bill form, if desired. This would be a special bill form that is designed separate from their regular bill form that is used to emphasize the delinquency of the customer’s account.
• Bill Codes configure finance charges and set the charge rate in annual percentages (whole number: 18.50 for 18.5%), the minimum charge, the minimum balance (in conjunction with the aging bucket) required to apply the charge, how the charge is categorized, and the months to apply the rate.
• Bill Codes determine whether a payment should be printed on the bill or not.
  • It is important to note that if payments are not printed on the bill, then payments do not have an associated Bill Date.
• Bill Codes have a “Bill Detail Level” that determines how Transactions will appear on a bill.  This is affected by the Company Setting in the Posting tab called Service Post Method. See Settings for more information on this configuration.

  Bill Codes have a very important, hidden configuration that must be adjusted by the Accu-Trax support team due to their major implications:

• Aging of Transactions based on their Transaction Periods. This is applicable for Services, Extras, Finance Charges, and Rolloffs, and can applied to each one exclusively. See the Aging section for more information.

Settings

The following Company Settings may be helpful in identifying Transactions and their configurations:

Posting

• Service Type: The default Transaction Type assigned to Transactions that were generated automatically from Service Items (autoposted). Generally set to the Type: “Service”
• Service Post Method: Determines how Transactions should be shown to the customer on a bill.
  • Individual: Transactions can be shown with every possible detail separated by Customer Site.
  • Combined: All Service Transactions from a particular Billing Period can be grouped together into a single detail line (I.e., “January Service” rather than “Jan – 1 32G Weekly”).
  • Per Service: All Service Transactions that share the same description will be grouped together into a single detail line, separated by Customer Site.
• Partial Rate Calculation: Determines how Service Transactions should be prorated if they are started/stopped mid-cycle.
  • Partial Rate Calculations include:
    • Per Service (Actual) – Prorate calculates based on the number of services (pickups) in a month, including 5-week months.
    • Per Service (4 Weeks) – Prorate calculates based on the number of services (pickups) in a month, assuming only 4 weeks per month.
    • Per Day (Actual) – Prorate calculates based on the number of days into a month, including 28-, 30-, and 31-day months.
    • Per Day (30 Days) – Prorate calculates based on the number of days into a month, assuming only 30 days per month.
    • Full Rate – Prorates are not considered and the full monthly rate is always charged.

• Service Transaction Day: The default Transaction Date assigned to Transactions that were generated automatically from Service Items (autoposted).
  • If set to Current Date, then the autopost date is set to the Record Date of the action that created the autoposted Transaction.
  • If set to any static day of the month, then the autopost date will reflect that day of the month for the respective month that the Transaction takes place.
    • For example, if I bill a customer for January, February, and March on December 29^th, and I set the Service Transaction Day to 1, then the Transaction Dates for each month will be January 1^st, February 1^st, and March 1^st for the respective Transactions.

Display Options

• Transactions: Separate Credits/Debits; Show Customer Site; Show Record Date; Show Running Balance; Show Units; Show Unit Amount
• Service Item: Show Service Name; Show Description; Show Rate; Show Start Date; Show Stop Date; Show Quantity; Show On Call

Aging

The aging of Transactions is heavily dependent on two features in Accu-Trax: Bill Codes and various time-period values. Bill Codes have an Ahead/Arrears assignment that dictates the period that Transactions are invoiced for, and they also have a hidden configuration that dictates how Transactions should begin aging. The System, Invoice, and Transaction Periods are impacted by the billing periods and Finalizing.

Periods

• Transaction Period: All Transactions have a Transaction Period, the month period that they are assigned to. This is determined by their Transaction Date. Whichever month the Transaction Date is set to is the Transaction’s “period” value.
• Invoice Period: All Transactions also have an Invoice Period, which is impacted by the customer’s Bill Code configuration. The Invoice Period is the period that determines the age of a Transaction. Please see the Bill Code Configuration section for more information about how the Invoice Period is used for aging.
  • Note: In Accu-Trax, this “Invoice” is not the same as the bill – it is a 1:1 Transaction record used to determine aging. A single Transaction may have both an Invoice ID and a Bill ID.
• System Period: The Accu-Trax Office software itself has a “System Period” which is the current month period that the software is in. This period is impacted by the Finalize Month feature – Finalizing the month advances the system to the following month.
  • Aging is thereby determined by the difference between the System Period and the Invoice Period.
• Bill Period: Each bill that is generated, whether through the Generate Bill process or through Instant Bills, has a start and end period. This start and end period is the date range that the bill is accounting for.
  • For bills generated using the standard Billing Process, the Bill Period is determined using the Bill Code’s Arrears/Ahead assignment. For example, billing 1-month Arrears in October has the Bill Period of October to October. Billing 3-months Ahead in October has the Bill Period of October to December.
  • For bills generated using the Instant Bill, the Bill Period is determined by the user’s input in the Billing Period From: / To: fields.

Ahead/Arrears

Customers with different Arrears/Ahead assignments may have different aging appearances in their balance buckets, though the behavioral logic is generally the same.

• Arrears is typically billed at the very end of the current month or the beginning of the following month – but in both cases the System Period is still in the current month. For example, billing for October generally takes place around October 31^st or November 1^st, but the system is still in October.
• Ahead is typically billed at the beginning of the new month or the very end of the previous month – but in both cases the System Period is still in the previous month. For example, billing for October generally takes place around September 30^th or October 1^st, but the system is still in September.

Finalizing

Finalizing automatically advances the aging bucket in month intervals for all Transactions that are configured to begin aging.

• Finalizing generally takes place after the billing is complete, regardless of the Arrears/Ahead assignment.
• Even if a Transaction has not begun its aging due to the Bill Code’s aging configuration, Finalizing still advances the system 1 month closer to that occurrence.
  • The start or “beginning” of a Transaction’s aging is determined by the Bill Code’s configuration.
  • For more information about how the Transaction ages based on the Bill Code’s aging configuration, see the section below.

Bill Code Configurations

Bill Codes have an aging configuration that is hidden from the user interface and requires assistance from our support team to configure. These configurations can be applied to Services, Extras, Rolloffs, and Finance Charges independently from one another; however, it is most common (and recommended) to keep them unified with the same configuration.

• The aging of any Transaction is still dependent on the difference between the System Period and the Invoice Period. These configurations, however, determine how the Invoice Period is assigned.

  The possible Bill Code configurations for aging include:

Source

Transactions will begin aging as soon as they are created based on their assigned Transaction Date. With the Source configuration, the Transaction’s Invoice Period is equal to its Transaction Period. In other words, the Invoice Period is equal to the month period that the Transaction Date is set in.

Using this method, a Transaction with the Transaction Date set to October will have an Invoice Period of October. Since aging is determined by the difference between the System Period and the Invoice Period, the further we move from October, the older the Transaction becomes. Below are some examples:

• The October Transaction previous described will be included in the ‘Current Balance’ bucket while the system is in October. When the system moves into November, it will then age into the ‘30-60 Balance’ bucket.
• A Transaction can be created in October and have the Transaction Date set to July 1^st, resulting in it appearing in the ’90-120 Balance’ bucket. This is because the Invoice Period is now July 1^st and the difference between the System Period (October) and the Invoice Period (July) is within 3-4 months (90 to 120 days).
• A Transaction can be created in October with a Transaction Date set to December 1^st  and the balance will be included in the ‘Total’ bucket but will not begin aging until the system is in December, since the difference between the System Period (October) and the Invoice Period (December) is negative. The total exists but it is not included in the “days old” buckets, since it is yet to “be born,” so to speak.
• A quarterly ahead Bill Code may have October, November, and December Transactions autoposted when billed for on October 1^st, but each month’s Transactions will begin aging in their respective months because each Transaction has a Transaction Date (and thus an Invoice Period) for those respective months.

Current

Transactions will age as though they were created during the current month, regardless of the Transaction Date that is assigned. With the Current configuration, the Transaction’s Invoice Period is equal to the System Period. In other words, whichever month period the system is in is the Invoice Period that is assigned to the Transaction.

• This is essentially aging based on the Record Date rather than the Transaction Date.

Until Billed

Transactions will not begin aging until they have appeared on a bill, at which point they will be assigned to the first month of the Billing Period. With the Until Billed configuration, the Transaction’s Invoice Period is not assigned until it first appears on a bill. The Invoice Period is then assigned to the first Bill Period.

In other words, the Transaction does not have an Invoice Period and thus does not age until it appears on a bill where it adopts the first (earliest) Bill Period. Since aging is the difference between the Invoice Period and the System Period, the Transactions have no age before appearing on a bill, at which point they can be aged all at once.

• Using this method, a Transaction may have any Transaction Date and will appear in the ‘Total’ bucket but will not age until it appears on the bill.
• The first month of the Billing Period is determined either by the Ahead/Arrears assignment configured in the Bill Code if using the Billing Process or is determined by the ‘Billing Period From:/To:’ configuration in the Instant Bill window.
  • For example, if the Transaction is for a customer with a 1-month Arrears Bill Code, and they are billed on October 31^st, then that Bill’s Period is October (start/from) to October (end/to). Thus, the Transaction’s Invoice Period is October.
  • If the Transaction is for a customer with a 3-month Ahead Bill Code, and they are billed on October 1^st, then that Bill’s Period is October (start/from) to December (end/to). Thus, the Transaction’s Invoice Period (for all 3 months) is October.
• A quarterly ahead Bill Code may have October, November, and December Transactions autoposted when billed for on October 1^st, but they will all age together starting in the October period. Since the System Period is generally still in September when billing for the months ahead, these Transactions appear in the ‘Total’ bucket until the system Finalizes into the October System Period, at which point they will appear in the ‘Current Balance’ bucket.
• A 1-month arrears Bill Code will have the October Transactions autoposted appear in the ‘Current Balance’ bucket when billed for on October 31^st. Since Finalizing generally occurs after billing, the balances will be advanced into the ’30-60 Balance’ bucket as the System Period advances from October to November.
• Since the Instant Bill allows the user to set a Billing Period far in the past, it is possible to bill a Transaction that has a Transaction Date in October but have the ‘Billing Period From:’ set to July, thus automatically aging the Transaction from no aging to the ’90-120 Balance’ bucket.

Until Billed Source

Transactions will not begin aging until they have appeared on a bill, at which point they will age based on their Transaction Date. With the Until Billed Source configuration, the Transaction’s Invoice period is not assigned until it first appears on a bill (identical to the Until Billed configuration). The Invoice Period is then assigned to the Transaction Period (identical to the Source configuration).

In other words, the Transaction does not have an Invoice Period and thus does not age until it appears on a bill where it adopts the Transaction Period, also known as the month period that the Transaction Date is set in. Since aging is the difference between the Invoice Period and the System Period, the Transactions have no age before appearing on a bill, at which point they can be aged all at once based on the set Transaction Date.

• For example, a Transaction may be dated for August 1^st, September 1^st, and October 1^st. These Transactions do not have an Invoice Period, even if the oldest are from August, but they do have Transaction Periods set for their respective months (August, September, and October). On October 31^st, while the System Period is in October, they all appear on a bill. (In this example, these are likely Extras that remained unbilled throughout the months, probably for a Quarterly Ahead customer.) Since Finalizing generally takes place after billing, the System Period is then advanced into November. The August Transaction becomes 3 months old (90-120 days), the September Transaction becomes 2 months old (60-90 days), and the October Transactions becomes 1 month old (30-60 days).
• Another example is for a Quarterly Ahead customer that is billed on October 1^st. They receive an October, November, and December Service Transaction. Each month’s Service Transaction has an Invoice Period for their respective months. Since the System Period is generally still in September when billing for the months ahead, and the Invoice Periods are staggered in October, November, and December, all the Transactions appear in the ‘Total’ bucket until the System Period is Finalized into October. At this point, the October Transaction appears in the ‘Current Balance’ bucket (October Invoice Period = October System Period), but the November and December Transactions are still in the ‘Total’ bucket and do not have an age. When the System Period is Finalized into November, then the October Transaction ages to ‘30-60 Days’ (1 month between October Invoice Period and November System Period), the November Transaction appears in the ‘Current Balance’ bucket (matching Invoice and System Periods), and the December Transaction is still without an age in the ‘Total’ bucket. The logic continues as the System Period advances.
• If the Bill Code is configured for either of the Until Billed settings, then the Billing Period for either the Billing Process or the Instant Bill becomes integral in the aging process for Transactions that appear on those bills.
  • This is because the Transaction is assigned a Transaction Period date that matches the first period of the Billing Period. As a result, the Transaction begins aging when the System Period advances forward in time. However, with the Until Billed setting, the Transaction ages in the background until it appears on a bill, after which is advances the entire period between its Transaction Period and the System Period.

Reports

When reporting out of Accu-Trax, the preliminary filtering is vital in producing consistent reports. Since filters can vary widely, it may be confusing to look at two reports with differing values since it is unclear which filters were provided on the exported report. We recommend that a filter layout is saved and loaded to ensure consistency.

It is also important to understand which reports are best suited for accounting preferences. While Accu-Trax Office is a CRM and billing software and not accounting software, financial figures can still be obtained in the context of accounting preference.

The two most common accounting preferences we encounter are reporting on Transactions based on the period that the Transactions were billed for (Bill Date) and reporting on Transactions based on the period that the Transactions take place (Transaction Date).

• We use Transaction Reports to accommodate reports based on Transaction Dates, and we use Bill Reports to accommodate reports based on Bill Date.
• For example, if a customer is billed in a quarterly ahead Bill Code on October 1^st for October, November, and December, we may want to report on all 3 months of Transactions in the October period (the date the billing takes place); or, we may want October’s Service Transaction to be in the October period, November in November’s period, and December in its period.
  • In the provided example, the former reporting preference is best handled with Bill Reports, whereas the latter reporting preference is best handled with Transaction Reports.

    All Transaction-based reports use the Transaction Date to filter and organize Transactions. The Transactions on these reports may be billed or unbilled, and their date is based on the set date that the Transaction takes place, as defined by the user.

• For Services (rendered on a recurring basis – AKA autoposting), this is the Service Transaction Day defined in the Accu-Trax Settings menu. For all manually posted Transactions, this is the date set by the user manually.

  All customer balances as seen on the main account page are calculated using the Record Date, or the date that the Transaction was entered into Accu-Trax.

• As of the time of writing, it is not visible to the user whether a Transaction has appeared on a bill or not through the User Interface.
• Accu-Trax does not consider the accounting methods used by the company (I.e., accrual, cash basis, GAAP). Settings can be configured in Accu-Trax to provide the necessary information for preferred accounting principles.

Transaction Reports

Transaction Reports are the most common reports for Transactions and contain 10 variations. They are found in Reports > Transaction Reports. They use a pre-report filter interface where the date range (based on Transaction date), Transaction Amount, Batch Numbers, Users, Transaction Types, Service Areas, Customer Types, Subdivisions, Transaction Sources, Bill Codes, and Account Numbers can be filtered. Layouts of commonly used filter settings can be saved and loaded for future use.

• The most commonly used filters include the date range, Transaction Amount (for finding credits versus debits exclusively), Transaction Types, Service Areas, Bill Codes, and Customer Types.

  Users can choose from the following report variations:

• Batch Report: Displays the Transaction Count, sum of Debits, and sum of Credits grouped first by Batch Numbers and then by Batch Date.
  • Note: The Date seen on the report is the Batch Date. However, the Date Range that filters this report is based on Transaction Date. Thus, it is possible to see a Batch that was performed on October 31^st with Transactions dated for November 1^st in the November 1^st to November 30^th filtered Batch Report.
  • Furthermore, it is possible to set the Transaction Date to October 31^st for one Transaction in a Batch and set the Transaction Date to November 1^st for a second Transaction within the same Batch. The first Transaction will not appear in the November Batch Report, but the second Transaction will, even if they were both in the same Batch that was posted at the same time, because the Transaction Dates were separated. We recommend that Transaction Dates do not differ within the same Batch for this very reason.
• Service Area Report (Transaction Summary by Area): Displays the Transaction Count, sum of Debits, and sum of Credits grouped by Service Area.
• Type Report (Transaction Summary by Type): Displays the Transaction Count, sum of Debits, and sum of Credits grouped by Transaction Type.
• Detail Report (Transaction Full Detail): Displays each Transaction in the filtered range along with the Account Number, Transaction ID, Transaction Type, Description, [Transaction] Date, Amount, User (that posted it), Service Area, Source (labeled as “S”. This indicates how it was posted), and Batch (number).
• Account and Name (Transaction Detail – Name): This report is the same as the Detail Report except it displays the customer’s Name in lieu of the Transaction ID.
• Type by Service Area (Transaction Summary by Area): This report is the same as the Type Report except that it has a higher-level grouping by Service Area. It displays the grouping of Transaction Types for each Service Area.
• Transaction Detail Summary: Displays the Average Transaction Amount, Sum Transaction Amount, and Transaction Count grouped first by the unique Transaction Descriptions (I.e., 95-Gal RC) and then grouped at a higher level by Service Area.
• Type by Customer Type (Transaction by Customer Type): This report is the same as the Type Report except that it has a higher-level grouping by Customer Type. It displays the grouping of Transaction Types for each Customer Type.
• Summary by Customer Type: Displays the Transaction Count, sum of Debits, and sum of Credits grouped first by Transaction Type, then grouped at a higher level by Service Area, then grouped at the highest level by Customer Type.
• Accrual Report Combined: Displays the sum of Debits and sum of Credits grouped by Transaction Type based on the selected month chosen when selecting “Report.”
  • Contrary to its name, it does not report on the money earned that has not yet been received as is defined in accounting terms. It simply reports on the accrued totals of Transactions based on their Type.

    The most used report variations are the Transaction Detail Summary, Type Report, and Type by Service Area.

Bill Reports

A second set of financial reports can be added upon request, including 4 groups of reports:

Bill Details

These reports are used for seeing all Transactions that occurred on a particular bill. They are similar to the Transaction Detail report in that manner but configured specifically for billed Transactions.

All of these reports contain a From and To Date parameter that filters by the Bill Date (the day that the Transactions first appeared on a bill; the user-defined Bill Date for the bill); an optional Transaction Minimum and Maximum filter; an optional dropdown filter list of Bill Codes, Service Areas, Transaction Types, and Customer Types; and a Bill Source filter (Both/All, Instant Bills only, or Bill Runs only). They also feature an expand/collapse button for each Bill Run grouping to easily navigate large sets of Transactional data.

• Bill Details: Displays the Transaction Description, sum Transaction Total, Transaction Count, Bill Code, Service Area, and Transaction Type grouped by the Bill Run (i.e., the entire Bill Run from the Generate Bills feature or the Instant Bill).
  • It also displays the Bill Run Id, Bill Date, Bill Source, and the Bill Period (in yyyy-mm format) for each of the Bill Run groupings.
  • It provides the Bill Run sum Transaction Total and Count as well as a Transaction Total and Count for the entire report.
• Bill Details by Service Area: Same as the Bill Details reports except that it includes a higher-level grouping for Service Area. An additional Transaction Total and Count is included for the Service Area grouping.
• Bill Details by Customer Type: Same as the Bill Details report except that it includes a higher-level grouping for Customer Type. An additional Transaction Total and Count is included for the Customer Type grouping.

Bill Totals

These reports are used for seeing a summary of the charges generated by a Bill Run grouped by various identifiers.

All of these reports contain a From and To Date parameter that filters by the Bill Date (the day that the Transactions first appeared on a bill; the user-defined Bill Date for the bill); an optional dropdown filter list of Bill Codes, Service Areas, Transaction Types, and Customer Types; and a Bill Source filter (Both/All, Instant Bills only, or Bill Runs only).

• Bill Totals: Displays the New Charges (sum of Debits), Transaction Count, and the Start and End period grouped by the Bill Codes that were billed in the Bill Run.
  • It also displays the Bill Run Id, Bill Date, and Bill Source for each Bill Run.
  • It provides the Bill Run sum Transaction Total and Count as well as a Transaction Total and Count for the entire report.
• Bill Totals by Service Area: Same as the Bill Totals except that is displays the grouping by Service Area rather than Bill Code. Unlike the Bill Details variations, it does not include an additional level of grouping; rather, it replaces the grouping. The following reports follow the same logic.
• Bill Totals by Customer Type: Same as the Bill Totals except that it displays the grouping by Customer Type rather than Bill Code.
• Bill Totals by Transaction Type: Same as the Bill Totals except that it displays the grouping by Transaction Type rather than Bill Code.

Outstanding Balance

These reports provide a snapshot of the balances outstanding for various groups of customers as of the specified dates and using the different date filters.

All of these reports include a Payment/Credit Cutoff Date and Charge/Debit Cutoff Date which determine up until what point should the debits be accrued and what point should the credits be considered to balance against the accrued debits; a date type filter for both credits and debits exclusively (Filter Credit/Debit Transactions by) which specifies whether the cutoff date should consider the Transactions’ Record Dates, Transaction Dates, or Bill Dates; and optional dropdown filter lists for Bill Codes, Customer Types, and Statuses.

• Accu-Trax utilizes the Record Date type when determining the customer balances. Because of this, the Record Date is the default date type as this is representative of what is shown in Accu-Trax. Similarly, since the Accu-Trax balance is calculating balances as of the current date by Record Date, the current date is the default for cutoff dates. A note at the bottom of the report is included explaining this.
• These reports also display the filter lists at the very bottom of the report along with the chosen cutoff dates and date types at the top of the report for easy reference.

  Note that since the cutoff date can be set into the past that the Bill Code and Status is displayed using whichever Bill Code and Status were active as of the cutoff date – this may differ from what the customer has currently. Further, the Customer Type does not contain a log of historical Types, so this is always the current Customer Type and cannot display historically.

• Outstanding Balances: Displays the Account Number, Name, Balance, Customer Type, Status, and Bill Code for all customers. The total of outstanding balances is displayed at the bottom.
• Outstanding Balances by Bill Code: Displays a sum of the outstanding balances grouped by Bill Codes. The total of outstanding balances is displayed at the bottom.
• Outstanding Balances by Status: Displays a sum of the outstanding balances grouped by Status. The total of outstanding balances is displayed at the bottom.
• Outstanding Balances by Customer Type: Displays a sum of the outstanding balances grouped by Customer Types. The total of outstanding balances is displayed at the bottom.

  A common use of the date type filter is to filter the Debit Transactions by Bill Date and the Credit Transactions by Record Date to see what the total outstanding balances are that have been billed for but are yet unpaid. However, the Record Date for both Debit and Credit Transactions is the most common.

Credit Balance

• These reports are an exact replica of the Outstanding Balance reports except that the Transaction Amount sign if flipped from positive to negative to report on the total credits due to customers. The same filters are available, the same notes are applicable, and the same report variations are used.

All reports contain a list of the filters chosen at the very bottom of the report so that any filters applied are easily visible for future reference.

Yearly Transactions by Type

A beneficial report that can be added upon request to view the year’s Transactions broken down by each month and grouped by the Transaction Type. It includes both debits and credits and can easily export into CSV for further analysis, if desired.

The report provides two parameters, a “Year” parameter and a “View Transactions By” parameter. The “Year” parameter allows the user to select any date within a year (the report defaults to the first day of the current year) to display the entire year’s data. The “View Transactions By” allows the user to view these Transactions from four different perspectives:

• Transaction Period (default): View the year’s Transactions by their Transaction Period. The Transaction Period will often be the same as the month that the Transaction Date is set for. However, there are certain exceptions that may exclude some Transactions from reporting if they were transacted before the year begins or after the year ends, even though the system has allocated the Transaction for a month within the annual reporting range.
  • For example, if the Posting > Service Transaction Day setting is set to Current Date, then the Transaction Date is set as the same day as the Record Date (the autopost date), but the Transaction Period is still set for the month that the Transaction is going to take place. If I bill a customer on December 29 for January, February, and March, then the Transaction Dates would all be set for December 29, but the Transaction Period would reflect Jan, Feb, and Mar dates.
• Transaction Date: View the year’s Transactions based on their Transaction Date. Keep in mind that if the Posting > Service Transaction Day setting is set to Current Date, then the Transaction Date might differ from the Transaction Period and the Transactions will instead be grouped more akin to the Record Date.
• Record Date: View the year’s Transactions based on their Record Date. Keep in mind that if billing for January takes place on December 29^th, these Transactions will be reflected in the December month.
• Bill Date: View the year’s Transactions based on their Bill Date. Keep in mind that this view may not reflect all the transactions recorded in Accu-Trax Office as the reported transactions must have appeared on a bill to generate a Bill Date. This view is more akin to a true accrual where the Transactions are reported based on if-and-when they appear on a customer-facing bill.