Financial Tags: The Handbook
What are financial tags?
Let’s start from the beginning…
Financial tags let us add information to the accounting. The goal is to be able to analyze accounting data in quite a lot of detail, without having to create many main accounts for the same type.
They allow us to query transactions directly in the accounting to understand the origin of each entry, without having to review them one by one.
For example, we can use them to record ticket or document numbers (whether from system lists or free text), derived masters such as employees or prospect customers, purchase or sales orders.
We can also customize lists: for example, I still remember having to report the tax jurisdiction on some transactions to file them with the tax authorities when I was implementing in Latam, or we can have regions (different from the country) for billing data.
Sounds familiar, right? What are financial dimensions?
We use financial dimensions to add information to the accounting and classify accounting data. In the same way, we can reduce the number of main accounts for the same type of transaction nature.
And as a super important point we always have to keep in mind: we use them (or rather, we should use them) in organizational hierarchies and approval workflows.
We have different types of financial dimensions: custom ones and entity-based ones, both from main forms and from operating units.
We can use them, for example, to enter what type of cost originated an expense or which business line generated revenue, along with customer and vendor information. We can also reflect the particularities of each business; for example, in a bookstore, which edition of the book we are buying or selling.
And with organizational hierarchies, to define the structure of an organization according to its operating units.
So… what’s the difference?
| Differences | ||
|---|---|---|
| Aspect | Financial Dimensions | Financial Tags |
| Maximum amount | Currently unlimited. Maximum of 11 segments per account structure. For more dimensions per transaction, they are included in advanced rules. | Up to 20 per legal entity. |
| Activation | Must be activated and included in an account structure (or via advanced rules) before use. The system must be in maintenance mode. | Activated directly from D365FnO. They are not part of any account structure. |
| Assignment order | In journals, according to the order assigned in the account structures. In purchase/sales orders and main forms, alphabetically. | By creation order. |
| Validation | Values are validated against the account structure upon posting: mandatory fields, valid combinations. | No validation. Any free value can be entered, even if the tag is of type List or Custom list. Cannot be made mandatory. |
| Default values | Carried over from master data or main forms (customers, vendors, products, projects) and from header to lines. | Not propagated from master data. Only from header to lines. |
| Trial balance / balances | Included in dimension sets to calculate totals and generate trial balances by dimension. | Not included in dimension sets. Trial balance by tag cannot be generated. |
| Post-posting editing | Cannot be edited on already posted transactions. Any change would directly affect financial reports and accounting audit. | Can be added, edited, or deleted after posting using ‘Edit internal subledger data’. An audit trail is maintained. |
| Delete | Cannot be deleted if referenced in any transaction or entity. | Cannot be deleted either, but can be deactivated. Historical values are kept in the database even if no longer visible. |
| Scope | Configured globally and assigned to each legal entity through account structures. | Configured at legal entity level. Can be shared using table sharing. |
| Org hierarchies & workflows | Used especially for operating units. | Cannot be used. The functionality is not enabled. |
| DB storage & performance impact | Each unique combination of account + dimensions generates a new record. The tables are global, shared across all legal entities. Growth is combinatorial. | Values are stored as flat columns directly in the accounting entry. DB growth is linear relative to the number of transactions, not combinatorial. |
Setup — let the party begin 😉
First, to have financial tags available across all transactions, we need to enable them depending on the system version — the rest will be enabled by default.
- (Preview) Enable financial tags for expense reports
- Enable financial tags for project financial transactions
- Add support for financial tags to the free text invoice entity within data management
- Enable financial tags for Accounting Source Explorer
- Enable financial tags for purchase order invoicing
- Enable financial tags for sales order invoicing
General Ledger module > General ledger parameters > Financial tags
We will also need to define a delimiter that separates financial tag values.
Also, the delimiter is shared across all companies — we can’t have different delimiters per company. So it’s super important to consider all the legal entities that make up the organization and how they report their information to the authorities, to avoid conflicts in electronic reports and filings.
Financial tag types
Value types define what the user can enter in a tag when posting a transaction. There are five in total:
Completely free text field. We can write whatever we need, with no restrictions. With a maximum of 100 (one hundred) characters.
Values are automatically pulled from an existing entity in the system (workers, vendors, projects, fixed assets, etc.). We can choose from that list or manually enter a different value (or add information). Even though the values come from the list, we can edit them.
The source is the same as the List type values, but with validation: the system only accepts values that exist in the system entity. Values cannot be edited or entered if they haven’t been previously created from the entities.
The values to be filled in on transactions are custom ones, they must be created manually to be selected later (for example, values related to each company’s business or specific information to be reported). The user can choose from that list, add more information, or enter something different.
Same as Custom list, but with validation: only values from the defined list are accepted. It does not allow entering values or data that are not on the list.
Create financial tags
We click on the ‘New’ option and fill in the information:
For example:
Selecting the ‘Custom list’ type, we’ll see that the ‘Tag values’ option is enabled on the action pane:
And from here we’ll create all the custom list values we need. It’s a grid-type form, so we can create values manually, copy and paste, or upload the values using the Excel Add-In:
Activate or deactivate tags
To be able to use financial tags, we first need to activate them. To do so, we need to select the ‘Activate or deactivate tags’ option from the action pane.
From the Activate or deactivate financial tags form, we mark the tags we want to enable from the inactive tags section and move them to the active tags section using the right arrow.
Once the batch process finishes, we’ll see that the ‘Active’ checkbox that was previously unchecked is now enabled:
To deactivate tags, we follow the same process but in reverse: we select the active tags we want to deactivate and move them to the inactive tags section using the left arrow.
How values are filled in on transactions
Logic without financial tag rules
If the ‘Default financial tag rules’ feature is disabled, the behavior is as follows:
Whenever we have the same combination of financial tag values in the transaction, we can fill in the values from the header so they replicate automatically across all lines, both for account and offset account. This is very useful when we need to post journals with many lines.
If we can’t fill them in from the header because we’ll have several combinations in the journal, entering the values from the account will automatically fill them in on the offset account.
If we have several lines to balance the journal (when using Debit and Credit), the tag values will not be filled in automatically from the account, so we need to enter them manually (we always have the option to copy and paste data from grid-type forms).
In all forms that have a header and lines view, the logic is the same: we fill in the information from the header and it will automatically carry over to all lines.
Up to this point, as we can see, the behavior is what we’d expect considering how we’ve been working with financial dimensions. But watch out! We don’t have the functionality available for changes made to a value from the header to carry over to the lines, nor will tags be automatically filled in on already-created lines if we load them afterwards.
In the case of tax lines or accounting entries generated automatically by the system, the tags will be filled in without any manual input at the time of posting, depending on the transaction type.
Financial tag rules
Financial tag rules allow us to define default values so that tags are filled in automatically on transactions. This helps us speed up the process, ensure uniformity and efficiency in tagging, and load them much faster.
The rules are available from v.42 and to use them we need to enable the feature: Default financial tag rules.
Set up financial tag rules
To create a new financial tag rule, we start by clicking the ‘Create’ button on the action pane. Then, we fill in the fields (in this order):
As we fill in these fields, the name will be automatically completed with a description of the rule.
If we want this condition to take precedence over values manually entered by the user or another condition we have for the same field, we need to enable the ‘Overwrite existing value’ option.
The language used to define and execute them is Microsoft Power Fx. We have a generator with Copilot available, and as we configure the rules we can see a formula guide.
But anyway, let me share how I’m understanding it.
For me, it’s the same as the ‘IF’ function we use in Excel, with the difference that in the first part of the condition we’re going to indicate the origin within the transaction in the system. Then we need to indicate what happens if it finds the value we want to fill in that tag, and then what happens if it doesn’t find it.
For example:
What we want here is that if the offset account of the journal is of type ‘Bank’, the tag is filled in with that same value, and if it’s not of type Bank it stays blank.
- Doc: represents the current document, meaning the journal line being processed at that moment (we normally always start with doc)
- OffsetAccountType: is the field that indicates the type of offset account. It can be Bank, Customer, Vendor, etc.
- LedgerJournalACType.Bank: checks that the field we are pointing to is of type ‘Bank’.
- Doc: same as in the first part, we’re telling it to look for the value in the journal line we’re working on.
- OffsetBank: is the field from which it has to take the value. Here we’re referring to the offset bank.
- Account: this is the value to be written in the financial tag. In our example, it’s the bank ID (Account field).
If the offset account is not of type Bank, the financial tag CuentaBancariaCP is left empty without generating any error. This is important because the same rule is evaluated on all journal lines, not just the ones that have a bank as offset account.
Simulate a financial tag rule
We can test whether we’re setting up the rule correctly before activating it using the ‘Simulate’ rule functionality. We need to select an existing transaction in the system and with the simulator we’ll see if there are any errors, which condition is being evaluated, and the value that will be filled in on the tag.
Once we’re sure we can use it, we just need to enable the ‘Enabled’ checkbox:
Let’s see everything together…
Copy financial tags
If the rule turned out great and we need to reuse it, we can copy it to another legal entity or to another transaction type.
To copy it to another transaction, for example if we have a rule for sales orders and we want to replicate it for purchase orders, we need to select the option ‘Copy >> Copy within legal entity’ and follow the wizard.
Here it’s important that the tags are enabled and we have the tags configured in the other company (otherwise it will be empty).
It doesn’t need to be the same name and type because we have to select the equivalent in the other company, but we can simplify the process by having the same tags across all companies.
Queries & reports
To filter transactions by a financial tag from the advanced filters, we can add the following options:
Or we can filter directly from the query by entering the value or values we need.
We have tag information available from:
- 🌿 Voucher transactions
- 🌿 Accounting Source Explorer
- 🌿 Main account transactions
Show inactive financial tags
If a financial tag has been deactivated, we can see the information that had been recorded by selecting the ‘Show inactive financial tags’ option.
Edit financial tags
Once the transactions have been posted and, as a result, the accounting entry has been created, we can edit the tag values that were filled in. D365FnO stores the audit information of who modified this data, in case we need to track the information.