> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# The accounting cycle

> How transactions, journal entries, the ledger, trial balance, and financial statements fit together as one repeating cycle that keeps the books trustworthy.

You've met the pieces one at a time: [debits and credits](/en/fundamentals/accounting/debits-and-credits), [journal entries](/en/fundamentals/accounting/journal-entries), the [chart of accounts](/en/fundamentals/accounting/chart-of-accounts), the [financial statements](/en/fundamentals/accounting/financial-statements). This page is the one that puts them in a line. The **accounting cycle** is the repeating routine that takes a single thing that happened in the real world and turns it into a report you can trust — and then starts over.

## One event, all the way through

***

Every figure on a financial statement started life as something tiny and concrete: a sale, a payment, a bill. The cycle is just the path that event travels, step by step, until it shows up in a report.

* **Transaction** — something happens. A customer pays, you cover the rent, a bill arrives.
* **Journal entry** — you write it down as matching debits and credits, so both sides of the movement are recorded.
* **Ledger** — each entry is sorted into the right account, so every account gathers its own running history.
* **Trial balance** — you add up all the accounts and check that total debits still equal total credits.
* **Financial statements** — the balanced totals are arranged into the Balance Sheet, Income Statement, and Cash Flow Statement.

Then the cycle repeats — for the next transaction, the next day, the next period. It never really stops; it just keeps turning.

```mermaid theme={null}
flowchart LR
  T["Transaction<br/>something happens"] --> J["Journal entry<br/>debits = credits"]
  J --> L["Ledger<br/>sorted by account"]
  L --> TB["Trial balance<br/>check it still balances"]
  TB --> FS["Financial statements<br/>the reports"]
  FS -.->|"next transaction · next period"| T
  classDef bal fill:#fff8e1,stroke:#f4b400,color:#333;
  class TB,FS bal;
```

## Walking one transaction around the loop

***

Say a customer pays you \$2,000 for a sale you make right then — so the revenue is earned at that moment. Follow it through:

1. **Transaction.** The sale happens and the customer pays — money arrives.
2. **Journal entry.** You record it: **Cash** debited \$2,000, **Revenue** credited \$2,000. Debits equal credits, so the entry balances.
3. **Ledger.** That \$2,000 debit joins the running history of the Cash account; the \$2,000 credit joins the Revenue account. Do this for every entry and each account always knows its own total.
4. **Trial balance.** Add every account's debits and credits across the whole book. If the two grand totals match, the records are internally consistent — a quick health check before you report anything.
5. **Financial statements.** The Cash balance feeds the Balance Sheet; the Revenue feeds the Income Statement. The same \$2,000, now part of the big picture.

Nothing new is invented along the way. Each step just **reorganizes** the same balanced movement into a more useful shape — from a single event, to a record, to a sorted history, to a verified total, to a readable report.

## Why the order matters

***

Each step depends on the one before it, which is exactly why the sequence is fixed:

* You can't sort an entry into the **ledger** until you've written the **journal entry**.
* The **trial balance** is only meaningful once every entry has landed in the ledger.
* The **financial statements** are only trustworthy once the trial balance confirms debits equal credits.

That dependency is the cycle's quiet safeguard. The balancing rule from [double-entry](/en/fundamentals/accounting/double-entry-bookkeeping) rides along at every stage, so a mistake shows up early — at the trial balance — instead of hiding inside a finished report.

<Note>
  **See also in Core Banking**

  See how this whole flow lands in a real ledger system in [Designing your ledger plan](/en/fundamentals/core-banking/designing-your-ledger-plan) and [Where to go next](/en/fundamentals/core-banking/where-to-go-next).
</Note>

## In short

***

* The **accounting cycle** is the repeating path from a real event to a finished report: **transaction → journal entry → ledger → trial balance → financial statements**.
* Each step just **reorganizes** the same balanced movement into a more useful shape — nothing is invented or lost along the way.
* The steps run in a **fixed order** because each depends on the last, and the **debits-equal-credits** rule is checked at the trial balance before anything is reported.
* Then it **repeats**, transaction after transaction, period after period.

<Note>
  **Next up**

  You've seen how these ideas connect in the abstract. Now see how they map onto a real ledger system in [Accounting in Lerian](/en/fundamentals/accounting/accounting-in-lerian).
</Note>