Nordlet

Docs / Glossary

What Is a General Ledger? Structure, Examples, and How Software Models It

What the general ledger is, how accounts, transactions and entries fit together, and how modern accounting software models a ledger as data.

The general ledger is the complete record of everything that has happened in a company's books: every account, and under each account, every debit and credit ever posted to it. The balance sheet, the profit and loss statement, the VAT return — all of them are views computed from the general ledger. It is not one report among many; it is the dataset the reports are computed from.

The structure: accounts → transactions → entries

A general ledger has three layers:

  1. Accounts — the categories, defined by the chart of accounts: bank, trade receivables, share capital, service revenue, salary expense. Each has a code, a name, and a type (asset, liability, equity, income, expense).
  2. Transactions — the business events: an invoice issued on 12 March, a bank payment on 15 March. Each transaction carries a date and a description.
  3. Entries — the lines inside a transaction: this account, debited or credited, by this amount. A transaction has at least two entry lines, and their debits and credits are equal — that is double-entry bookkeeping.

An account's balance is nothing more than the sum of every entry posted to it. Ask "why is trade receivables 9,300 €?" and the ledger answers with the exact list of invoices and payments that add up to it. This decomposability is the ledger's defining property — every number in every financial statement can be traced down to individual entries.

A ledger account, on paper

The traditional presentation is the T-account. Trade receivables (2410) over a month:

Date Description Debit Credit
03-01 Opening balance 4,200
03-12 Invoice S-1041 1,210
03-15 Payment, invoice S-1038 2,400
03-28 Invoice S-1042 605
Closing balance 3,615

Every line here is one side of some transaction — the other side lives on another account's page (revenue and VAT for the invoices, bank for the payment). Reading a single account's history like this is still the fastest way to answer "what happened here", which is why every accounting system ships a general-ledger detail report.

Subledgers: detail kept out of the way

In practice, high-volume detail lives in subledgers that summarize into the general ledger. Accounts receivable tracks per-customer invoices; accounts payable tracks per-supplier bills; inventory tracks per-item quantities and costs; payroll tracks per-employee amounts. The general ledger holds the control totals — one receivables balance, one payables balance — while the subledger holds the breakdown. If the subledger total and the control account disagree, something posted to one but not the other; finding that difference is a routine part of closing an accounting period.

How software models a ledger

Strip away the terminology and a general ledger is a small, rigid data model:

  • an accounts table — code, name, type, position in the chart hierarchy;
  • a transactions table — date, description, link to the source document;
  • an entries table — transaction ID, account ID, debit, credit.

Everything else is derived. Balances are sums over entries; a trial balance is that sum grouped by account; a balance sheet is the trial balance mapped into a statutory layout. Well-designed systems treat the entries table as append-only: posted entries are never edited or deleted, and corrections are made by posting reversing entries. That is what makes the ledger an audit trail rather than a mutable spreadsheet — the history of the books is itself part of the books.

This is exactly how Nordlet models it. Accounts, journal transactions and journal entries are first-class API objects: POST /v1/ledger/accounts/list returns the chart, POST /v1/ledger/journal/transactions/create posts a balanced transaction (unbalanced ones are rejected before anything is written), and every document — sales invoice, purchase, payroll run, bank import — posts into the same ledger through configurable rules. The reading side is a set of reports: POST /v1/reports/general-journal lists transactions chronologically, POST /v1/reports/gl-detail reconstructs the per-account view shown above, and POST /v1/reports/trial-balance summarizes it. Posted entries are immutable, and locked periods cannot be posted into — the append-only ledger is enforced, not assumed.

General ledger vs general journal

Two words for two orderings of the same data. The general journal is chronological — every transaction in date order, as it was recorded. The general ledger is the same entries organized by account. Historically these were two physical books and posting meant copying between them; in software they are two queries over one entries table. The distinction survives in report names, not in the data.

FAQ

What is a general ledger in simple terms?

The master record of all of a company's accounts and every debit and credit posted to them. Financial statements are not written — they are computed from the general ledger.

What is the difference between the general ledger and the general journal?

The same entries in two orderings: the journal is chronological, the ledger is grouped by account. In modern software both are views over one dataset.

What is a subledger?

A detail book that summarizes into one general-ledger control account — per-customer invoices behind the receivables balance, per-supplier bills behind payables, per-item stock behind inventory. The general ledger stays readable; the detail stays available.

Can entries in a general ledger be edited?

In a well-built system, no. Posted entries are append-only; a mistake is corrected by posting a reversing entry, so the correction itself is on the record. Systems that allow silent editing of posted entries cannot produce a trustworthy audit trail.

How do balances get into the general ledger?

They don't — balances aren't stored, they're computed. An account's balance is the sum of all entries posted to it, which is why every reported number can be traced back to the transactions that produced it.