DualEntry changes many records at once in two different places. Transaction lists carry structured bulk actions you drive with pickers, and the AI accounting copilot runs bulk operations you describe in plain language, previewing them before anything commits. Which one to reach for depends on whether you can express the change as a field and a value.
Bulk actions on a list
Open a transaction list, select rows with the checkboxes, and the bulk action menu appears in the toolbar. These actions are structured rather than conversational: you pick a value and it applies to every selected row.
Two list-level actions exist:
- Edit classification: Set or replace classification values, which is how you apply department, location, or project tags in bulk. Available on bills, direct expenses, vendor credits, purchase orders, invoices, customer credits, cash sales, journal entries, and intercompany journal entries.
- Archive: Retire the selected records from day-to-day views. Available on most lists.
There is no list-level bulk action for GL account or company; those only exist at the line level, inside a single open record. Journal-entry lines expose Edit classification only. Bill, direct-expense, and vendor-credit lines add Edit account. Statistical-journal lines expose all three, Edit account, Edit company, and Edit classification; Edit company doesn’t appear on any other record type’s lines.
Reach for these when the change is one field to one value. There is nothing to interpret, so there is no preview step: the change applies when you confirm it.
Selection drives the scope, which means the filters you have applied to the list matter. Narrow the list first, confirm the row count is what you expect, then select and apply. That ordering is the closest equivalent to a preview that the list-level actions offer.
Bulk operations through the copilot
When the change is easier to describe than to express as a field and a value, ask the copilot instead. Two kinds of bulk operation are available to it, and both preview before they commit.
Mass-applying a field to master data standardizes one whitelisted field across many vendors, customers, accounts, or items: payment terms or 1099 eligibility on vendors, payment terms or default currency on customers, currency on accounts, or default classification on items. A request like “set NET 30 on all vendors with no payment terms” resolves to a filter, a field, and a value. The copilot runs it as a dry run first and shows you what would change. Confirming re-runs the same filter live rather than replaying the exact preview, so a record that changes between preview and confirm can enter or drop out of the batch. It commits all-or-nothing, and a single run is capped at 500 records.
Bulk reclassification changes classifications across transactions: bills, direct expenses, vendor credits, cash sales, invoices, customer credits, journal entries, intercompany journal entries, sales orders, and purchase orders. Payments and refunds aren’t covered. Only posted records are eligible; the list-level Edit classification action has no such restriction. The copilot returns a preview table listing each record, its ID, its date, its current classifications, and the classifications it would receive. Like mass-apply, a single run is capped at 500 records.
Read the preview before confirming. Unlike mass-apply, a bulk reclassify preview is issued with a receipt that the apply step must present, so confirming always applies exactly what you were shown rather than a freshly re-evaluated filter.
Bulk archive
Bulk archive is a list action. Open a transaction list view (journal entries, bills, invoices, payments, purchase orders, fixed assets, items, paper checks, and other archivable record types), select the rows to archive, and choose Archive from the bulk action menu.
Two behaviors to keep in mind before running a bulk archive:
- Archive is not delete. Archived records still exist in the database, still appear on prior-period reports, and can be restored where the record type supports restore. Use archive to retire records from day-to-day views, not to remove them from history.
- Archive does not block resync. If a record originated from an integration, archiving it in DualEntry does not stop the source system from re-creating it on the next sync. Resync deduplicates by external ID, so a still-active record in the source (QuickBooks, Gusto, and others) can be re-pulled. To keep a record from returning, address it at the source or adjust the integration’s mapping instead of relying on archive.
Some record types support paired Recover or Restore actions in bulk. For example, archived paper checks can be recovered in bulk from the row menu, the toolbar, or the check detail page. Restored records return to the active tab with their original status.
Batch size and failures
A copilot mass-apply is capped at 500 records per run, and the cap is a hard limit rather than a default you can raise. Tighten the filter and run it more than once when the change is larger than that, rather than expecting one request to sweep the whole table.
Splitting by a stable attribute, one company or one vendor group at a time, is more reliable than splitting by an arbitrary count, because each run then has an obvious description you can check against its preview.
Both copilot bulk operations commit all-or-nothing. Every row is validated before anything is written, so a single row that fails validation stops the operation and nothing is applied. That is safer than a partial write, but it does mean a large run can be blocked by one bad record, and the fix is to exclude it in the filter and rerun.
Undoing a bulk change
There is no reverse-batch action and no batch identifier to reverse against. To undo a bulk change, run the opposite change: select the same records and apply the previous value, or ask the copilot to reclassify them back.
Every individual record modification is still recorded in the audit trail under the user who made it, so the history of what changed and when survives even though the operation is not reversible as a unit.
That asymmetry is worth internalizing: the preview is the control, and the audit trail is only the record. Read the preview before confirming rather than relying on being able to roll the change back. Be especially careful with records in a period you are about to lock, since reopening a locked period to correct a bulk change is a more visible event than getting the change right the first time.
