Skip to main content
A default classification is a classification value stored on a customer, vendor, item, or account, such as Department = Marketing on a vendor. When you add a line to a new transaction, DualEntry uses the defaults of the customer, vendor, item, or account on that line to fill in the line’s classifications, so lines that always belong to the same department or location don’t need tagging by hand every time. Defaults are a starting point, not a rule: the values on the line are what DualEntry saves and posts, and you can change or clear them before you save. This page explains where defaults come from, how DualEntry chooses between them, and where they don’t apply. For the steps to set them up, see Set default classifications. For what a classification is, see How to Set Up Classifications.

​
Where default classifications come from

Four kinds of records can carry default classifications. Each one holds at most one value per classification type, so a vendor can default Department = Marketing and Location = NYC, but not two departments. The table below shows where each default lives and which lines it usually feeds. A child customer doesn’t inherit its parent customer’s defaults. Set defaults on each customer you want them on.

​
How DualEntry combines defaults: classification priority

A single line often has more than one source. An invoice line has a customer and an item, and a bill expense line has a vendor and an account. DualEntry combines the sources’ defaults one classification type at a time:
  • Different classification types are combined. If the customer defaults Region = West and the item defaults Department = Finance, the line gets both values.
  • For the same classification type, the higher-priority source wins. If the vendor defaults Location = NYC and the account defaults Location = Remote, the line gets whichever value comes from the source ranked higher.
The priority order is an organization setting, Prioritization, under Settings → General Preferences → Defaults. The default order is Customer/Vendor, then Item, then Account. See General Preferences for the setting itself. The order is configurable because there’s no single right answer. Some teams treat a department as belonging to the customer relationship, so a sale to a given customer always lands in that customer’s department whatever was sold. Others treat it as belonging to the product line, so the item should win. The default order favors the party (customer or vendor), and you can move Item or Account to the top instead. The losing value is dropped without a warning on the form. The line shows only the winning value, so if a line shows an unexpected value, check whether a higher-priority source has a default of the same type.

​
Which sources each record type uses

Not every record type draws on all four sources. The table below lists the record types that apply default classifications and the sources each one uses. Priority decides between them when they set the same classification type.

​
When defaults fill a line

Defaults fill a line only when the line is new and has no classifications yet. How that works depends on where the record is created. In the app, defaults appear on the form as you build the transaction, before you save. When you choose the customer or vendor, or pick an item or account on a line that has no classifications, DualEntry fills the line from the matching defaults. From then on:
  • Changing the line’s item or account replaces the values that came from the old item or account with the new one’s defaults.
  • Changing the record’s customer or vendor adds any classification types the line is missing and keeps the ones already there.
  • Once you edit a line’s classifications yourself, including clearing all of them, DualEntry stops changing that line. Whatever the line shows when you save is what’s stored.
Through the public API, defaults are applied when the record is created. A new line with omitted or empty classifications gets the defaults. A line that includes even one classification gets no defaults at all, because DualEntry treats a line with any explicit classification as deliberately coded rather than filling the gaps around it. On an update, existing lines are never changed, and new lines added in the update get defaults the same way. Everywhere, inactive classification values are skipped, and the Apply default classifications setting in General Preferences turns all of this off, item and account defaults included. With the setting off, the app fills nothing and new lines are saved with whatever you enter.

​
Records created from another record

When you create a record from another record, such as an invoice from a sales order or a bill from a purchase order, the new lines carry the source lines’ classifications. Those values take priority over any defaults, so a bill matched to a purchase order keeps the purchase order’s coding even if the vendor’s defaults have changed since. If a source line has no classifications, the result depends on the record:
  • Invoice from a sales order: the new invoice line is filled from the customer and item defaults, as for any new line.
  • Bill lines linked to a purchase order line: the bill line stays empty. Defaults aren’t applied to lines that are tied to a purchase order line, so tag them on the bill or fix the purchase order first.

​
Default classifications in the API, CLI, and MCP

Default classifications work the same way for records created programmatically, with a few differences in how you set and control them.
  • Public API: set defaults on customers and vendors with classification_line_ids, and on items and accounts with default_classification_line_ids. Each takes a list of classification line IDs, one per classification type. Omitting the field leaves the existing defaults unchanged, and [] clears them. To create a record without defaults, pass apply_default_classifications=false as a query parameter on the create request: DualEntry then stores the submitted classifications exactly, including an empty list. The parameter exists on create (POST) only, and it can’t turn defaults on when the organization setting is off.
  • DualEntry CLI: create and update send the JSON file you provide, so you can set classification_line_ids on a customer or vendor in that file. The CLI has no option for apply_default_classifications, so records created with create always get defaults on lines without classifications. To keep a line untagged or coded differently, include its classifications in the file. See the CLI reference.
  • DualEntry MCP: save_entity accepts classification_line_ids on a customer or vendor, and default_classification_line_ids on an item or account, in their data. Records created with save_record don’t get defaults, so include each line’s classifications in the request. See MCP Server: Tools, Permissions, and Troubleshooting.

​
Changing a default

Changing or removing a default on a customer, vendor, item, or account affects only lines created after the change. Posted transactions and saved drafts keep the values they were saved with, and DualEntry doesn’t backfill history when you add a default for the first time. To bring existing transactions in line with a new default, reclassify them with the bulk Edit classification action described in Correct classifications on posted records, or use Accounting Intelligence bulk reclassification for larger corrections.

​
Where default classifications don’t apply

Several record types and creation paths never apply default classifications. Lines on these records keep exactly the classifications they’re created with, so set classifications on them explicitly.
Last modified on October 20, 2026