Dimensions

Sometimes the chart of accounts isn't enough. You need to see Marketing's spend separately from Sales's, even though both post to Software & Subscriptions. You need to see Boston-office vs Atlanta-office revenue, even though both post to Service Income. You need to track cost-per-project for time-and-materials work without making a separate revenue account for every client.

That's what dimensions are for. Solid Accounting's dimension system lets you tag every transaction line with up to three dimensions — Class, Location, and Project — and run reports filtered or grouped by them.

Dimensions are available on Professional and Accountant tiers.

The three dimensions

Each is a separate list with its own values. They're orthogonal — a single transaction line can have all three.

Dimension	Typical use
Class	Department, business segment, product line, profit center
Location	Physical office, warehouse, region, geographic territory
Project	Client project, internal initiative, contract, grant

You don't have to use all three. Most files use one (often Class) or two (Class + Location for multi-office companies). Adding a dimension you don't intend to use just adds a field to ignore on every transaction.

When to use dimensions vs separate accounts

This trips a lot of people up. Quick decision rules:

Use separate accounts when...	Use dimensions when...
Different accounting treatment	Same accounting treatment, different category
Different tax-line designations	Same tax-line, different segment
External audience (banker, regulator, tax)	Internal audience (management report)
You'd actually want to see them on different lines of the IRS form	You'd want them combined on the IRS form, split for management

Examples:

Office Supplies and Software Subscriptions — different accounts. They're both expenses but different IRS categorizations.
Office Supplies — Sales and Office Supplies — Engineering — same account, different class. The IRS just wants total office supplies.
Boston Office Rent and Atlanta Office Rent — same account Rent Expense, different location.
Acme Project Revenue and BetaCo Project Revenue — same account Service Revenue, different project.

Dimensions stay invisible to outside readers (your tax forms see total Rent Expense, not the per-location breakout) but visible internally on dimensional reports.

What a dimension stores

Dimension	Schema fields
Class	`id`, `name`, `description`, `parent_id` (hierarchy), `is_active`
Location	Same shape
Project	Same shape, plus `start_date`, `end_date`, `customer_id`, `budget_amount`

The parent_id field on classes and locations supports hierarchy: Engineering with sub-classes Backend, Frontend, DevOps. Projects can have customer linkage so all of a customer's projects roll up together.

Where dimensions apply

A dimension is set on a journal entry line, not on the journal entry itself. This means a single transaction can split across dimensions:

Invoice 1042 — Acme Consulting
  Line 1: Strategy work        4,500.00   class=Sales       location=Boston
  Line 2: Implementation       8,500.00   class=Engineering location=Boston
  Total                       13,000.00

This is correct accounting: revenue from one invoice gets attributed to two different classes if the work covered both.

The Solid line model supports class, location, and project per line; the underlying GL line table has those fields directly.

Setting up dimensions

In Lists → Classes (or Locations / Projects):

Add the dimension values you'll use — start small (5–10 classes max)
For hierarchies: create the parent, then children with parent_id set
Mark inactive any you won't use

Inactive dimensions don't appear in pickers but their history stays on transactions that referenced them.

Applying dimensions to transactions

Three places where dimensions apply:

Location	How
On a transaction line	Pickers for Class / Location / Project on every line. Most flexible; explicit per line.
On an item default	An item can default to a class — every line using that item inherits it (override per line)
On a customer/vendor default	Less common; some files default a customer to a project so all that customer's invoices auto-tag

Dimension assignment is optional per line. Lines without a dimension show as "no class" (etc.) on dimensional reports.

Dimensional reports

Standard reports gain dimensional flavors:

Profit & Loss by Class — P&L grouped by class instead of (or in addition to) account categories
Profit & Loss by Location — same for locations
Profit & Loss by Project — same for projects, often with budget-vs-actual comparison
Class Detail — every transaction tagged with a specific class for a period
Project Profitability — for any project: revenue, direct costs, indirect costs (allocated), net profit

Reports support filtering: "show me just the Sales class" or "show me the Boston location's Operating Expenses." This is where dimensions earn their keep — answering "what's my margin on this project?" or "which department is over budget?"

Project-specific behavior

Projects have a few things classes and locations don't:

Budget amount — set a budget on the project; reports show actual-vs-budget
Start and end dates — projects can be flagged as completed; closed projects don't appear in pickers but their history stays
Customer link — every transaction on a customer-linked project auto-gets that customer's tag too, easing project-by-customer roll-ups

Dimensional budgets

Budgets (see Budgets module) can be dimensional:

A class-only budget targets each (account, period, class) cell
A class + location budget targets each (account, period, class, location) cell

Variance reports filter by the dimensions on the budget — comparing actual to its corresponding dimensional target.

API access

The REST API exposes dimensions:

GET /classes · POST · GET/PUT /classes/{id}
GET /locations · POST · GET/PUT /locations/{id}
GET /projects · POST · GET/PUT /projects/{id}

Transaction-creating endpoints (POST /invoices, POST /bills, etc.) accept class_id, location_id, project_id per line.

Common gotchas

Used dimensions inconsistently and reports look noisy. Common when first adopting them — some transactions have classes, some don't. Run a "no class" filter on the P&L to find the unclassified ones, then back-tag.

Project profitability looks too good — direct costs are missing. Direct costs were posted without the project tag. Edit those transactions to add the project.

Class hierarchy: a sub-class's spending isn't rolling up to the parent on reports. The roll-up depends on report settings. Some reports show flat (every class on its own line); others show hierarchical. Look for a "consolidate sub-classes" toggle on the report.

Migrated dimensional data from QuickBooks/Xero — some classes got merged. Migrations bring class lists across, but if both apps had a "Sales" and a "Marketing" class they'd be one each in Solid. Manually split if needed; the audit trail shows which migrated entries each class came from.

Dimensions on Standard tier — not available. Correct; dimensions are Pro/Accountant. The Standard-tier UI hides class/location/project fields entirely. Upgrading unlocks them; existing data wouldn't have dimensions.

Inactive dimension still appears on a report. Inactive only hides from pickers — historical reports correctly show all dimensions ever used. To exclude inactive dimensions from a report, filter to active only.

Cross-references

General Ledger module — the GL line model with dimensional fields
Reports module — the reports that use dimensions
Budgets module — dimensional budgeting
REST API — API access to dimension management