Skip to main content

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.

​
Key Concepts: DualEntry’s Data Model

DualEntry is built around a small set of interconnected concepts. Understanding how they relate to each other makes every other feature in the platform easier to reason about.

​
Entities and the entity hierarchy

A DualEntry tenant contains one or more companies (legal entities). Each company maintains its own general ledger, functional currency, and fiscal calendar. You create companies in Settings → Organization. Companies can be arranged in a parent-child hierarchy. The hierarchy drives intercompany eliminations and consolidated reporting - the parent entity rolls up balances from its children. If you operate a single legal entity, you still have a hierarchy; it just has one node. Each company in the hierarchy operates independently for day-to-day transactions. Users post entries to a specific company, and reports scope to that company by default. When you need a consolidated view, DualEntry aggregates the child companies’ balances into the parent, applying elimination entries for intercompany activity automatically. For multi-entity configuration details, see Multi-Entity Consolidation.

​
Transactions and how they post

Every financial event in DualEntry is a transaction: an invoice, a bill, a journal entry, a payment, or a bank transfer. Each transaction contains one or more lines, and every line carries a debit or a credit to a GL account. A transaction is either draft or posted. While in draft, you can edit it freely. Posting writes the debits and credits to the general ledger and makes the transaction immutable. To correct a posted transaction, you create a reversal or an adjusting entry - you never edit the original. This immutability is the backbone of DualEntry’s audit trail. Every posted record is permanent, timestamped, and linked to the user who posted it. You can view the full history of any transaction - including who created it, who approved it, and when it was posted - from the transaction detail screen.

​
The chart of accounts

Your chart of accounts defines the GL structure for a company. Every account has a number, a name, and an account type - asset, liability, equity, revenue, or expense. Account types determine how balances roll up on financial statements. Accounts can optionally carry sub-types (for example, current asset versus non-current asset) and be organized into groups for reporting. Sub-types give you more granular control over balance sheet and income statement presentation without requiring separate account types. You build or import your chart of accounts when you first set up a company, and you can add accounts later as your reporting needs evolve. DualEntry does not allow you to delete an account that has posted transactions - you deactivate it instead, which hides it from selection while preserving historical data. See Chart of Accounts for the full guide.

​
Periods and period locking

DualEntry organizes time into fiscal periods - typically months, but configurable to match your fiscal calendar. Periods serve two purposes: they scope financial reports, and they control when transactions can be posted. You lock a period to prevent anyone from posting new transactions into it. This is how you protect closed months during and after the month-end close. If you need to post an adjustment to a locked period (for example, during an audit), you unlock the period, post the entry, and relock it. Only users with the appropriate role can lock or unlock periods. DualEntry generates periods automatically based on the fiscal calendar you select during organization setup. You manage period status from Settings → Periods, where each period shows whether it is open, locked, or closed. For step-by-step instructions, see Period Locking.

​
Classifications and dimensions

Classifications (also called dimensions) are tags you attach to individual transaction lines. Common examples include department, location, project, and product line. Classifications give you granular reporting without inflating your chart of accounts. Instead of creating separate expense accounts for every department, you create one expense account and tag each line with the relevant department. You can then filter or group any report by classification. You define the classification types that matter to your organization in Settings → Classifications and assign values when you create transactions. Each classification type contains a list of values - for example, a “Department” classification might contain values like Engineering, Sales, and Marketing. You can make a classification required on certain transaction types so that users cannot post without tagging the line.

​
The Inbox

When you import transactions - via bank feed, CSV upload, or OCR document scan - they land in the Inbox. The Inbox is a staging area where you review, categorize, and match transactions before promoting them to the general ledger. Items in the Inbox are not yet posted. You review each one, assign the correct GL account and classifications, and then either post it directly or send it through an approval workflow. The Inbox keeps unreviewed data out of your books until you are ready. You can process Inbox items one at a time or in bulk. DualEntry groups related items - for example, multiple charges from the same vendor - so you can categorize them together. The Inbox also shows matching suggestions when an imported transaction corresponds to an existing draft or expected entry.
The Inbox also powers DualEntry’s AI categorization. As you categorize transactions, the system learns your patterns and begins suggesting accounts and classifications automatically.

​
Approval workflows

An approval workflow is a configured chain of one or more approval stages that a transaction must pass through before it can be posted. You configure workflows per transaction type - for example, bills over a certain amount might require controller approval, while small journal entries post immediately. Each stage specifies who can approve (by role or by named user) and what conditions trigger the stage. You can chain multiple stages together - for instance, a bill over ten thousand dollars might require both a manager and a controller to approve sequentially. DualEntry tracks the approval status of every transaction and notifies approvers when action is needed. Approval workflows are optional - if you do not configure one for a transaction type, any user with posting permission can post directly. For setup instructions, see Approval Workflows.
Last modified on May 28, 2026