Dashboard Tips - What data is used for this dashboard?

The CU*BASE Dashboards are great analysis tools for seeing the “Big Picture” and for determining trends. Use them to ask questions about the effectiveness of policies and strategies at your credit union.

From time to time, our Client Services Representatives receive calls from clients asking what data is used to create a specific dashboard or to ask why one report’s results might not exactly match the results given on a dashboard. Keep in mind that most Dashboards were not really designed as back-office tools for day-to-day balancing or settlement. But if you find them useful in that way, first take some time to thoroughly understand what data is actually being analyzed, so you don’t end up trying to compare apples to oranges. This topic is designed as a starting point to answer the reason for the differences. First are listed some questions to ask, followed by specific examples of when this question was used to answer a client question.

  • Documentation Hint: To view topics for all dashboards screens, use Index Keyword “Dashboard” in the CU*BASE Online Help.

Specific Examples of Questions for Dashboard Comparisons

Questions to Ask When Comparing a Dashboard with another Report or Dashboard

  • Are all of the records fitting the filter requirements included in the totals on the screen?  Is there a limit to the number of records that are shown?

  • Does the report/dashboard include data from a snapshot taken as of the end of the month or is it from current data?

  • Is the report/dashboard generated at Beginning-of-Day or End-of-Day?

  • Is the report/dashboard counting certificate issue date or reissue date?

  • Is the comparison report/dashboard reporting on a different date range?

  • Is the comparison report/dashboard using different files/sources?

  • Are the accounts included only accounts of memberships opened during a specific time frame?

  • Are the delinquent loans included grouped by number of months delinquent or by credit union delinquency configuration?

  • Are only loans of a certain status, application type or review date included in the report/dashboard?

  • Are the balances of loans currently in collections included in the results?

Specific Examples for the Questions Above

  • Are all of the records fitting the filter requirements used to calculate the totals on the screen?  Is there a limit to the number of records that are shown?

CU*BASE shows a maximum of approximately 9,990 records in the listing; however, all records fitting the filter are used in the analysis and total figures on the screen.  If 75,000 records fit the filter requirements, then all of these records are used to calculate the data, including the totals on the screen.

  • Does the report/dashboard include data from a snapshot taken at as of the end of the month or is it from current data?

Some dashboards pull data from current data (and therefore pull from current balance totals), others from End-of-Month data (a snapshot taken at the end of the month). Selecting to view data from a previous month affects the balance totals on the New/Closed Membership dashboard. Watch for this documented at the top of many CU*BASE Online Help topics.

  • Is the report/dashboard generated at Beginning-of-Day or End-of-Day?

When run for the same date range, the Collections Dashboard (generated at Beginning-of-Day) may not include exactly the same results as the Loan Delinquency Analysis (generated at End-of-Day).

  • Is the dashboard/dashboard counting certificate issue date or reissue date?

The New/Closed Accounts Dashboard counts certificate issue date, not certificate reissue date.

  • Is the comparison report/dashboard reporting on a different date range?

This can be an issue since many reports or dashboards include data from different files. The collections of the data for these files may have begun on different dates. By adjusting the date ranges on the dashboard, you may be able to identify the difference.

  • Is the comparison report/dashboard using different files/sources?

The Collections Dashboard pulls data from the Collections file (COLL), and will not always provide the same results as the Delinquency Analysis Report which uses MEMBER5 and MEMBER6 as its source files.

  • Are the accounts included only accounts of memberships opened during a specific timeframe?

The New/Closed Membership Dashboard looks only at new memberships opened during a specific time frame. When evaluating savings/checking accounts opened, you cannot compare this dashboard with a query of MEMBER1, since this file includes all memberships, regardless of when the membership was opened.

  • Are the delinquent loans included grouped by number of months delinquent or by credit union delinquency configuration?

The Collections Dashboard pulls information from the credit union delinquency information and will not always provide the same results as the Delinquency Analysis, where loans are grouped according to the months delinquent.

  • Are only loans of a certain status, application type or review date included in the report/dashboard?

The Contingent Liability Dashboard includes data on credit card loans that meet specific criteria. For this reason, there may not be a one-to-one correlation with the credit union G/L balance for credit cards.

  • Are the balances of loans in currently in collections included in the results?

The results of the Loan Share Trial Balance Report may not be the same as the balance of the PCNTRB report in CU*Spy since the first report does not include the balances of loans in collections.

As with all dashboards, ultimately most cases of data differences will come down to one of two possible reasons:

1) Timing (data as of EOM being compared to current, for example)

2) Logic choices based on purpose or intent of the dashboard.

These ones are sometimes a little harder to figure out right away. Check CU*BASE help pages for individual dashboards for information on data sources, hard-coded exclusions, and occasionally details of business decisions made in designing the dashboard

The Difference Between "Member" Transactions and "Teller" Transactions

Understanding the difference between these two definitions is CRUCIAL to correctly understand or analyze certain dashboards in CU*BASE. Examples of dashboards that are commonly misunderstood without this knowledge:

Teller Activity (#843 thru #848) vs. Where Your Members Branch (#977)

Teller Activity (#843 thru #848) vs. Transaction Activity by Branch (#865)

Teller Activity (#843 thru #848) vs. Transaction Count by Delivery Channel (#867)

At a basic level, a teller transaction in CU*BASE is considered one "audit key”. An example of an audit key is Outside Check, Withdrawal/Disb, etc and a teller often has more than one of these audit keys within a member interaction.

Then a member transaction is the final posted transaction as a consolidated item which then shows up on their account’s transaction history. These are organized and processed under origin codes, transaction codes, and transaction types.

So, teller transactions you see in any of the Teller Activity dashboards are the items or actions handled by the teller. The goal behind the design and development of these tools is to assist with evaluating true throughput on the teller line. Hypothetically, an example member came in yesterday to the Main Street branch and in that one visit he deposits 4 outside checks, and takes $100 out of the account as 1 withdrawal/disb for a total of 5 teller transactions in this example.

That same person’s visit is also picked up over in Where Your Members Branch where member transactions are being counted here based on those origin and transaction codes. These are what you’d see as a member’s transaction history within Phone Operator or Inquiry. Remember, our example member came in to the Main Street branch yesterday and the visit involved those 5 total teller line items, but his entire teller interaction is considered 1 member transaction.

On any member transaction history, you can drill into the teller receipt details where we’d find exact information on all 5 of our example member’s actions yesterday, but the interaction itself only claims 1 line as a member account transaction.

Difference Between Member Counts

These dashboards are extremely valuable for anyone looking to analyze where/when members are choosing to visit you, what types of things they do with you when they do come in, and even assist with staffing or operational decisions at each branch.

But before you begin analyzing – Take a minute to familiarize yourself with the intent of each dashboard. Member counts will follow differing logic based on the purpose intended for each dashboard.

Teller Activity Dashboards

The member counts in these dashboards are intended to represent teller line volume of member visits so any individual person can be double, triple, quadruple, etc counted in here. If they visited any branch 4 times in the period, they impact the total by a count of a 4.

When true volume is the goal, # of Members is the number of actual members represented by those transactions. If a member does transactions at different times during the day, or at different branches, the same member is counted once for each and is included within more than one of the counts. The idea here to see the number of member interactions served, regardless of who they were or how often they came back in.

Where Your Members Branch

The intent behind this dashboard and other member-based transaction information is generally to create a profile of where the member chooses to visit regardless of how often. This, and other related dashboards, will generally have options to analyze the profile of these members groups via Common Bonds or other built-in analysis screens. What products are they coming in for transactions on, what is the breakdown of deposits vs withdrawals for the group? For the individual?

If a member does 3 transactions at one branch he is counted as a member only once for that location. This is his preferred location and we are noting the fact that he chose to physically visit this branch at least once.

However, it’s also very important to realize that if the person visits a 2nd branch location at least once in the same period it will count him under that branch as well for an impact on the overall total of 2.