How to Set Up and View Classifications

A classification is a reporting dimension you tag onto transaction lines, such as Department, Location, or Project. Set one up when you want to slice financials by something your chart of accounts does not track, without adding an account per department. This guide covers creating a classification, requiring it, setting defaults for it, tagging lines with it, and reporting on it.

​

Before you start

Confirm four things before you create a classification: what the dimension is, that you can edit classifications, that a classification is the right tool for the data, and that the capability is enabled for your organization.

• Decide what the dimension is and what its values are. The dimension becomes the classification name (Department), and the values become its attributes (Engineering, Sales, Marketing).
• Confirm you have the classification create and edit permissions. Without view permission, Classifications is hidden from the Accounting Setup menu rather than shown empty.
• Check whether the value is a reporting dimension. A classification tags each transaction line with a value from a predefined list. A custom field stores other data, such as a receipt reference or an external ID, on the record header or on each line. If you are tagging that kind of value, use a custom field instead.
• Classifications are a subscribed capability. If the page is absent for everyone in your organization, check the subscription before assuming a permissions problem.

​

Create a classification

Create the classification first, then add its values as attributes on the same form.

1. Navigate to Configuration → Accounting Setup → Classifications.
2. Choose New classification.
3. Enter a Name. Names must be two to 128 characters and unique across your organization. The uniqueness check ignores case, so “Department” and “department” collide, and the name None is rejected.
4. In the Attributes section, choose Add attribute and type a value name. Repeat for each value. At least one attribute is required, and attribute names must be unique within the classification.
5. Leave each attribute’s toggle set to Active, or set it to Not Active to define a value you do not want assigned yet.
6. Set Classification status to Active.
7. Save the classification.

The new classification appears in the list with a Not required badge, and its attributes are immediately selectable on transaction lines. To change it later, open the three-dot (⋮) menu on its row and choose Edit. Selecting the row itself opens a read-only view instead. To add values later, edit the classification and add attributes. The Search attributes box above the table filters the rows in place, which matters once a classification carries dozens of values.

​

Build a parent-child hierarchy

Use a hierarchy when one dimension rolls up into another, for example Cost Center rolling up into Division, so reports can group at either level.

1. Edit or create the child classification.
2. In Parent classification, select the classification it rolls up into.
3. In the Attributes table, a Parent column appears. For each attribute, select the parent classification’s attribute it maps to. This mapping is required once a parent is set.
4. Save.

The list view indents child classifications under their parent and shows a badge naming the parent.

​

Require a classification on transaction types

Requiring a classification stops users from posting an untagged line, which is what keeps a reporting dimension complete enough to report on.

1. Edit the classification.
2. Turn on the switch next to the Required section header. The requirement controls stay hidden until you do.
3. Under Required on, select the record types. They are grouped as Transactions (journal entries, intercompany journal entries), Money-in (sales orders, cash sales, invoices, customer credits, customer deposits, customer payments), Money-out (purchase orders, bills, direct expenses, vendor credits, statistical journals), and Products & services (items). Select a group heading to take every record type in it.
4. Save.

All record types are selected by default on a new classification, so review the list rather than accepting it. The counter above the picker reads “n of 14 selected”, and Clear all empties the selection when you want to start from nothing. DualEntry enforces the requirement at the moment a record is posted, not when it is saved. A draft saves cleanly without any classification values; posting a record that is missing a required classification fails with an error naming the missing classifications. Two exceptions apply: records created by a connected third-party integration skip the check entirely, because integrations do not always supply classification data, and deactivating a classification removes it from the check even though its Required setting stays saved.

​

Scope the requirement to specific companies

Requirements by record type and by company are independent axes, and both are cumulative. Under Or Required on the selected companies, select the companies the classification is mandatory for. A record must then satisfy every classification required for its record type plus every classification required for its company. Setting one does not set the other, so a classification required only on bills is still required on every record in a company you name here. The list view reflects the combination: Required with a subtitle such as “For all companies”, or Partially when the requirement covers only some records or companies.

​

Set default classifications

Default classifications fill in a new transaction line’s classifications from the customer, vendor, item, or account on that line, so you don’t tag the same values by hand on every bill or invoice. Set them on the records your lines draw from, then check the organization settings that control them. For how DualEntry combines defaults from more than one source, see How Default Classifications Work.

1. Open the customer, vendor, item, or account and edit it.
2. Find the Default Classifications field: in the Defaults section on a customer or vendor, under Defaults → Other on an item, and in the Tax Details & Defaults section on an account.
3. Select one value for each classification type you want to default, for example Department = Marketing. Only active values can be selected.
4. Save the record.
5. Navigate to Settings → General Preferences and confirm Apply default classifications is on under Defaults. It’s on unless someone in your organization turned it off.
6. Under Prioritization, drag the sources, or use the arrows, into the order you want. The top source wins when two sources default the same classification type.
7. Save the settings.

To confirm it worked, create a new transaction for that customer or vendor and add a line. The line’s Classifications button shows a count badge with the defaulted values before you save. Defaults affect new lines only, so existing transactions keep their current values.

​

Tag transaction lines

Tag lines as you enter a transaction, on the line rather than the header.

1. Open or create the transaction, for example a bill or a journal entry.
2. On the line you want to tag, choose Classifications.
3. Select one attribute per classification you want to record on that line. The button shows a count badge once values are selected, and the line’s tooltip reads back each classification and its value.
4. Post the transaction.

New lines with no classifications are filled from the default classifications of the customer, vendor, item, or account on the line. You can change or clear the filled values before you save, and what the line shows when you save is what’s stored. Defaults apply only to records entered in the app or through the public API. Integrations, CSV import, recurring transactions, and revenue recognition schedules never apply them, so those paths must set classifications explicitly. See How Default Classifications Work for which sources each record type uses. Classification tags are metadata. They do not change account routing, amounts, or the debit and credit structure of the transaction, so tagging a line never moves a balance.

​

View classification values on a saved transaction

Read a saved transaction’s classification values from the tooltip in its lines table, or from a report or the public API when you need values for many entries at once. On a saved journal entry, bill, invoice, or other transaction, the Classifications column of the lines table shows how many classifications each line carries, not their names. To read the names and values without editing the record, hover over the count, or move keyboard focus to it. A tooltip lists each classification and its value, one per row, such as Department: Marketing. A line with no classifications shows a dash instead of a count. Selecting the count in view mode does not open anything. The transaction detail view has no separate panel that lists classification names, so the tooltip is the only read-only view of them on the record itself. Choosing Edit also shows the values, but it puts the record into edit mode, so use it only when you mean to change them. Use one of these instead when you need classification values for many lines or entries at once:

• Reports: add the classification as a column in a report, or group and filter by it. See Filter and group a report by classification. The journal entry list has no classification column or filter, so a report is the way to review tags across entries in the app.
• Public API: GET /public/v2/journal-entries/{record_number}/ returns each line in items, and each line’s classifications array gives the classification name and the selected value in line_name. GET /public/v2/journal-entries/{record_number}/lines/ returns the same per-line data as a paged list. See Get journal entry.

To change values on posted records, use the bulk Edit classification action described in Correct classifications on posted records rather than editing each record.

​

Filter and group a report by classification

Every active classification is available to reports as a grouping dimension, a details column, and a filter.

• Group by classification: in the report’s pivot controls, each classification appears as Classification: name. Place it on rows or columns, up to three grouping levels deep. A dimension placed on one axis can be flipped to the other without rebuilding the report.
• Filter by classification: apply the classification filter in the report header to restrict the report to selected attributes.
• Show it as a column: add the classification through the report’s column picker to read the tag beside each line rather than grouping by it.
• Start from a prebuilt report: Report Center → Sales by Classification Summary and Sales by Classification Detail are already grouped by classification.

Save the result as a custom report so the grouping and filters come back the next time, and add it to a report package if it belongs in the monthly reporting set. Inactive classifications still appear on historical records and in reports, so retiring a dimension does not blank out prior periods.

​

Correct classifications on posted records

Reclassify rather than reversing and reposting. The list-level Edit classification action is available on bills, direct expenses, vendor credits, purchase orders, invoices, customer credits, cash sales, journal entries, and intercompany journal entries. Sales orders reclassify through the API rather than from a list view.

1. Open the list view for the record type.
2. Select the records using the row checkboxes.
3. In the bulk action bar, choose Edit classification.
4. Set the classification values in the Edit Classifications modal and confirm.

The new values replace the prior values on each affected line. This is also how to bring existing transactions in line after you change a default, because changing a default never updates transactions already saved. On every record type except sales orders and purchase orders, reclassifying re-runs the same required-classification validation that applies at posting, so clearing a required classification on a posted bill is rejected. For larger corrections, Accounting Intelligence bulk reclassification previews the change across up to 500 posted records before committing it.

​

Retire or delete a classification

Deactivate a classification you no longer use rather than deleting it. Set Classification status to Inactive, or set an individual attribute to Not Active. Inactive classifications and attributes stay on historical records and in reports, drop out of required-classification checks, and cannot be assigned to new records. Deletion is available only for classifications that were never used. DualEntry blocks deleting a classification when any of its attributes appears on a general ledger entry, a transaction line, or a budget, and when any of its attributes has child attributes. The same protection applies to a single attribute: one that has been used anywhere cannot be removed from the classification.

• Delete one classification: open the three-dot (⋮) menu on its row and choose Delete.
• Delete several at once: select their row checkboxes, then choose Delete from the bulk action bar that appears at the bottom of the list.

​

Troubleshooting

Most classification problems trace back to how requirements are scoped, when enforcement runs, an attribute already in use, where a default came from, or how values display on saved records. The table below lists the symptom, the cause, and the fix for each.

​

Related reading

• Key concepts for how classifications differ from custom fields and where they sit in the data model.
• How Default Classifications Work for how customer, vendor, item, and account defaults combine and where they don’t apply.
• Custom fields for record-level or line-level data that is not a reporting dimension.
• Custom report builder for saving a classification-grouped report.
• Approval workflows for gating an approval step on a classification value.
• Create classification for provisioning classifications over the API instead of by hand.