This article contains the following topics:
- What are transaction attributes
- Why use a transaction attribute
- How to create a transaction attribute
- Examples and use-case
- Best practices
In Catalyst data is entered into the system either automatically via automation integration or manually via upload. That data is rooted in some type of transaction, either a journal entry (financial) or an invoice (profitability). Hierarchies are the primary means of organizing that data, but only work when there is a 1:1 relationship between a transaction type and a category. If certain data needs additional organization to supplement the 1:1 hierarchical structure, you can create a transaction attribute at a lower level of granularity.
What are transaction attributes?
Think of TAs as an additional way to tag or categorize data that comes into Catalyst when hierarchies aren't enough.
- Transaction Attributes essentially create a new column header or dimension in the transaction table. So when data is loaded into Catalyst a new column header will exist as an option for any transaction. The cells in that new column may remain blank (or not) based on the transaction, but that column is now available as an option.
- Each transaction that arrives in Catalyst is unique. It has a unique transaction type underneath it, it has dimensions, and it has an amount. Think of dimensions as column headers in a table, such as ID, posted date, location, account, department, customer, company, etc. When there are 1:1 relationships between a dimension and a category or a definition, hierarchies work great. But sometimes hierarchies aren't enough. This is where TAs come into play.
Why would I use a transaction attribute?
The main purpose of using a profitability or financial transaction attribute is to introduce a way to define structure at the transaction level, in order to capture and categorize your data in a meaningful way if the default method isn't doing the trick. So rather than defining structure based on an individual dimension, we're defining it for the individual transaction. Transaction attributes are used when data is present in relationships that are inherently 1:many, rather than 1:1.
- Financial Attributes: Used for additional journal entry detail attribution. Less commonly used.
- Profitability Attributes: Used for additional sales and invoice detail attribution. More commonly used.
How to do I create a transaction attribute?
- Navigate to Administration.
- Select either Profitability Attribute or Financial Attribute based on your need.
- Fill out the simple form. Essentially you're just naming the attribute something.
- For profitability attributes, you have the option to link it to a hierarchy.
- Click add.
- You now have a new column in your export/upload Catalyst templates.
* Note that the system may need to refresh before you see the change in Excel.
Examples and use-case
1:1 relationships are great, which is why hierarchies work so well. But the reality is that they're not always possible. Here are some examples and use-case of when this can happen and what to do.
Common examples of hierarchical relationships
Hierarchies are used for 1:1 relationships between dimensions and a definition, such as the following common examples:
- Geography: Customer 1 is located in Minnesota, therefore Customer 1 = MN. So, any time a transaction comes in for Customer 1 it will get tagged with MN.
- Item: A product or item is known to be one thing, such as apples. Item 13 = Apples. Therefore, any time a transaction comes in for Item 13 it will get tagged with Apples.
- Another common category and hierarchy we see is Channel, which we'll define as the method by which a product moves from producer to consumer, such as Direct, Online, and Retail. Maybe we have a customer that always and only buys via the Retail space. That's a 1:1 relationship and a hierarchy will work great for that: Customer A = Retail Channel. Easy!
- But what if it's not that simple? Maybe it'll depend based on what product that customer is buying. For example, if Customer A buys bananas we want to put them in the Retail Channel, but when they buy shampoo we want to put them in the Online channel.
- When that happens we no longer have a 1:1 relationship, but rather a 1:many relationship (one customer is purchasing via many channels). We now have multiple variables required that define what channel that transaction should go into. So it would make sense to create a TA that could help capture this detail.
- In this example, you'd want to create a new profitability transaction attribute called "Channel". Each record is then categorized into a Channel, and this attribute is attached directly to the record. Since a 1:many relationship exists, we cannot use a hierarchy to assign Customer A to a given Channel, therefore we will use a TA so that each record for Customer A will be attributed to a Channel. Customer A will then appear in both the Retail channel and the Online channel.
- Sales Rep is another use-case for a transaction attribute.
- If you think about a car dealership for example, you have customers and sales reps. If a customer were to only buy one vehicle at that dealership from one rep, then a transaction attribute wouldn't be necessary and you could simply use a hierarchy for Sales Rep. But oftentimes the same customer will go back to that same dealership and buy another car, maybe from a different rep. Here's where a TA could help you.
- Since our 1:1 relationship between the customer and sales rep is no longer intact, you would create a profitability transaction attribute for Sales Rep instead of a hierarchy. This creates a new column in the data table for Sales Rep, which can then be drawn from via the invoice data or entered manually, so that the customer will appear under multiple sales reps.
Financial TA example
Used less often than profitability transaction attributes, financial attributes help provide further attribution to journal entry detail level transactions.
- One common use-case for using financial attributes are for Adjustments and Add Backs.
- Rather than categorizing a certain GL account as an add back, you may want to record that at the invoice or transaction level.
- Such an example might be for Legal Expense.
- Some legal expenses you may add back, some you won't.
- In this example, you would want to tag which legal expenses are considered an add back and this can be done by creating a new financial transaction attribute.
- Note: This type of work would likely occur in an automation via the integration between your ERP and Catalyst, rather than you manually doing so in Excel.
- Invoice number is commonly used as a Transaction Attribute. This is because it is wholly unique and a good way to drill down into sales data. Because invoices are very difficult to try to roll up to in something like a hierarchy, Invoice Number is a natural use-case for transaction attributes because it works well as something to drill down into at the most granular level.
- In general, we recommend using Hierarchies whenever possible, rather than TAs in order to keep your processing speeds quick and timely. TAs can impact processing speed because they essentially create an additional dimension or variable that hit each and every transaction that comes through Catalyst. That could mean multiplying the number of variables that must be processed in Catalyst by many millions depending on the size of your dataset.
- Transaction attributes, when used in combination with overrides, can become complex. Trying to override something that has TAs may require assistance from our team to help you walk through.