> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dualentry.com/llms.txt
> Use this file to discover all available pages before exploring further.
# How to Set Up Classifications
> Create a classification in DualEntry, add attributes and hierarchy, require it on transaction types and companies, tag lines, and report by it.
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](../core-financials/general-ledger/chart-of-accounts) does not track, without adding an account per department. This guide covers creating a classification, requiring 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 belongs on the line or on the record. A classification tags one transaction line; a [custom field](./custom-fields) describes the whole record. If you are tagging a receipt reference or an external ID, 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.
The Classifications page carries a **Beta** badge. The setup and enforcement behavior described here is in place; the badge signals that the page itself is still changing.
## 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 2 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**. Clicking 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.
Changing the parent classification clears every parent-attribute mapping already selected in the Attributes table. Remap all of them before saving, or the mappings are lost.
## 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.
## 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](../core-financials/accounts-payable/bill-management) or a [journal entry](../core-financials/general-ledger/journal-entries).
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.
Lines entered for an [item](../core-financials/accounts-receivable/order-management) that carries default classifications inherit those values automatically when the line does not specify its own. That auto-fill applies only to records entered through the app or the public API. Lines created by integrations, CSV import, recurring transactions, and revenue recognition schedules are never defaulted this way, so those paths must set classifications explicitly.
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.
## 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](../reporting-analytics/custom-report-builder) so the grouping and filters come back the next time, and add it to a [report package](../reporting-analytics/report-packages) 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. 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](../ai-automation/bulk-update-and-reclass) 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.
If a connected third-party expense integration syncs this classification as a custom accounting field, deleting it here removes the corresponding field in that platform too. Deactivate instead if you want to stop using a classification without touching the integration.
## Troubleshooting
Most classification problems trace back to one of three things: the requirement is scoped differently than you expect, enforcement runs later than you expect, or an attribute is already in use somewhere. The table below lists the symptom, the cause, and the fix for each.
| Symptom | Cause | Fix |
| ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Posting fails with "missing required classifications" | A classification required for that record type or company has no value on one or more lines | Tag every line with the classifications named in the error, then post again |
| A draft saved without a required classification | Enforcement runs at posting, not at save | Expected behavior. Tag the lines before posting |
| **Classifications** is missing under Accounting Setup | The role lacks classification view permission, or the capability is not subscribed | Grant the permission, or check the subscription if no one in the organization can see the page |
| Saving the classification fails on the name | The name is under two characters, over 128, `None`, or already used by another classification in any casing | Choose a different name |
| Delete is rejected | An attribute is in use on a GL entry, transaction line, or budget, or it has child attributes | Set the classification to **Inactive** instead |
| Bills from an expense integration post untagged | Integration-created records are exempt from required-classification checks | Reclassify the records in bulk after they land |
| Parent attribute mappings disappeared | The parent classification was changed, which clears the mappings | Remap each attribute to a parent attribute before saving |
## Related reading
* [Key concepts](../get-started/key-concepts) for how classifications differ from custom fields and where they sit in the data model.
* [Custom fields](./custom-fields) for record-level data that is not a reporting dimension.
* [Custom report builder](../reporting-analytics/custom-report-builder) for saving a classification-grouped report.
* [Approval workflows](./approval-workflows) for gating an approval step on a classification value.
* [Create classification](/developers/api/resources-v2/classifications/create-classification) for provisioning classifications over the API instead of by hand.