General Ledger

The general ledger is the foundation underneath every other module in Solid Accounting. Every invoice, bill, payment, deposit, transfer, and manual entry posts to it. Every report reads from it. This page is the reference for how it works.

If you're new to double-entry, the very short version: every transaction has at least two sides — what increased and what decreased — and the two sides are equal. The accounting industry has been doing it this way for ~600 years because it's the only model that catches a whole category of bookkeeping errors automatically.

Account types

Solid ships with eleven built-in account types, organized into five categories:

Every account in your chart of accounts is one of these types. You can have many accounts of the same type — Operating Checking and Money Market are both Cash and Bank; Office Supplies and Software Subscriptions are both Expense.

Why types matter: they drive the normal balance (which side increases the account), which report the account appears on (assets/liabilities/equity → Balance Sheet; revenue/expense → P&L), and which transactions reasonably touch it. Solid uses the type to suggest sensible defaults but never blocks you — accountants regularly need to post unusual entries that cross type lines, and the GL allows it.

Debits and credits — what they actually mean

The terms are confusing because in everyday speech "credit" usually means "more money for me" and "debit" means "less." In accounting, that's only true for some accounts:

A single rule that explains all five: debit the side that absorbs value coming in; credit the side that releases value going out. Money comes into the bank account (debit increases the bank), and the same dollar comes from somewhere — owed to a customer (credit revenue), or pulled from a loan (credit liability), etc. The two sides always balance because every dollar shows up on both sides of the same transaction.

Chart of Accounts

Your Chart of Accounts is the list of every account in the file, grouped by type. Each account has:

• A number (optional — you can run an account-numberless COA if you'd rather work by name only)
• A name — what shows on reports and pickers
• An account type — one of the eleven above
• A parent — accounts can nest. Bank might have Operating Checking and Savings as children
• A currency — defaults to the file's base currency; override per-account for multi-currency tracking
• A description — free-text, shown on hover and in account drilldowns
• An active flag — inactive accounts don't appear in pickers but their history stays intact

The numbering scheme is up to you — common patterns are 1000s for assets, 2000s for liabilities, 3000s for equity, 4000s for revenue, 5000s for expenses. Sub-accounts often add decimals or extra digits (1010 Operating, 1020 Savings, 1030 Money Market).

You can rename, renumber, and reparent accounts freely; the GL stores the account by its internal ID, so historical transactions follow the rename automatically.

Journal Entries

Every transaction in Solid is a journal entry — a header plus two or more lines. The lines must balance: total debits equal total credits, to the penny.

Solid generates journal entries automatically from every shipped transaction type. You almost never write a journal entry by hand — but the model is the same regardless of whether you wrote it directly or it came from posting an invoice:

Every journal entry stores: who created it, when, what file version, and (where applicable) which source document produced it. That last bit is what makes drilldowns work — every report line can be clicked back to the entry that produced it, which can be clicked back to the invoice/check/bill that created the entry.

The audit trail

Solid Accounting is append-only at the GL level. You don't edit a posted journal entry; you post a correcting entry, which leaves a trail showing both:

• The original entry and its date
• The correction, who made it, and when
• Optionally a memo explaining why

Voiding a transaction posts a reversing entry (same accounts, opposite amounts) on the void date. The original entry stays in the file forever — you can run reports for any historical period and they show what was posted at the time, not the current edited state.

This is the property that lets a CPA or auditor trust the books. If anyone could rewrite history, the books would be worth nothing under audit.

Cash vs. accrual basis

Solid tracks both. Every transaction has the data needed to produce reports in either basis:

• Accrual basis — revenue is recognized when the invoice is issued (DR AR / CR Income); expense when the bill is received (DR Expense / CR AP). Used for GAAP, for management reporting, and for any business with material AR/AP.
• Cash basis — revenue is recognized when the customer pays (DR Bank / CR AR, then CR Income); expense when the bill is paid. Smaller, simpler businesses sometimes elect cash basis for tax purposes.

The reporting basis is a setting on each report run — you can switch back and forth without rebuilding the GL. The same underlying transactions produce both views; the difference is just which side of an invoice or bill counts as the recognition event.

Periods and closing

A period is a span of time you're treating as a unit — typically a month, sometimes a quarter, always a fiscal year. Closing a period:

1. Locks the GL — no new entries can post with dates inside the period (Admin can override with audit)
2. Triggers any automatic period-end entries (depreciation runs, accrual adjustments, etc.)
3. Carries the period's net income to Retained Earnings on the start date of the next period
4. Marks the file's "books closed through" date

You can re-open a closed period if you find an error — closing isn't permanent, just a tripwire that keeps people from accidentally posting to a settled month. Reopening is logged in the audit trail.

The close itself is a mechanical operation in Solid; the judgment about what to accrue, defer, depreciate, or reclassify happens before close as adjusting journal entries.

Trial Balance — the integrity check

The trial balance is the simplest GL report and the one that proves the books are intact:

• Every account, its current balance, in the column matching its normal side
• Total debits and total credits at the bottom

They must equal. If they don't, something is broken at a level below normal use — a bug, a corrupt file, a manual SQL edit. In a healthy file the trial balance always balances; if it doesn't, stop entering data and contact support.

We run an automatic trial-balance check after every batch import (IIF, CSV, OAuth pulls). If a batch import would unbalance the GL, the entire batch is rolled back — Solid never leaves the file in a partially-imported, unbalanced state.

Multi-currency

Solid tracks accounts in their native currency and a base currency for the file. Reports run in either:

• Native — every account in its own currency; useful for foreign-bank reconciliation
• Base — every line translated at the transaction's exchange rate; the basis for consolidated P&L and Balance Sheet

Currency revaluation (the periodic adjustment for unrealized gain/loss on foreign-currency holdings) posts as journal entries you can review and accept or override. The exchange rate used for each transaction is stored on the transaction, not derived after the fact, so historical reports stay reproducible.

The current limit: imported multi-currency history (from QuickBooks IIF, QBO, Xero, etc.) carries the base-currency amount only. Re-running revaluation after import rebuilds the unrealized gain/loss from scratch.

Drilldown — every number is clickable

Every number on every report in Solid is clickable. Click a P&L line and you get the journal entries that produced it. Click a journal entry line and you get the source transaction (the invoice, bill, etc.). Click a source transaction and you get its full detail with the underlying entry breakdown.

This is non-negotiable in good accounting software — and it's the thing that lets a bookkeeper or auditor answer the question "why is this number what it is?" in seconds instead of hours.

Performance characteristics

The GL is the workhorse — it's the largest table in your .solid file by row count, and every report and reconciliation reads from it. Some practical numbers:

• A typical small business has ~10K–100K journal-entry lines per fiscal year
• Reports run from indexed views and stay fast at 1M+ lines (multi-year files in active service)
• Period-aware queries hit indexes on (account_id, transaction_date) and stay sub-second on commodity hardware
• The full GL detail report on a 5-year file regenerates in under a minute on most laptops

When you do hit slow reports — usually because of a custom date range against the entire file — the fix is usually adding a filter (a single account, a smaller date range), not a hardware upgrade.

Reference — account-type code list

For developers and integrators, the underlying account-type codes (used in import mapping and the API):

These are stable; they don't change between versions. New types can be added in future major versions but existing codes will keep their semantics.