> For the complete documentation index, see [llms.txt](https://vendex.gitbook.io/ledgerise/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vendex.gitbook.io/ledgerise/01-getting-started/03-key-concepts.md). # key concepts This page explains the terms used throughout the Ledgerise documentation. Each entry gives you enough context to understand the concept and know where in the product it appears. For deeper detail, follow the links to the relevant sections. *** ## adapter A self-contained module that translates data between an external system and Ledgerise. There are two directions: An **inbound adapter** receives raw transaction data from a source system — your payment engine, a payment provider, a bank — and normalises it into the canonical transaction schema. It knows how to speak to one specific system; the rest of Ledgerise does not. An **outbound adapter** receives journal entries from the engine and delivers them to a target accounting system. It translates Ledgerise's internal format into whatever the accounting system expects. → See [adapters overview](/ledgerise/08-adapters/01-overview.md) *** ## canonical transaction schema The standard internal format that all inbound adapters must produce. Every transaction Ledgerise stores — regardless of whether it came from a webhook, a CSV file, or an API poll — is stored in this format. The schema captures the essentials of a transaction: amount, currency, direction, type, product line, biller, status, timestamps, and source information. Because every adapter produces the same format, the journal engine only needs to be written once. It does not know or care which payment provider sent the data. → See [transaction schema reference](/ledgerise/12-reference/01-transaction-schema.md) *** ## chart of accounts (COA) The structured list of account codes used in your accounting system — assets, liabilities, income, expenses, and so on. Ledgerise does not own or manage your chart of accounts. It imports a read-only copy from your accounting system (Zoho Books, or QuickBooks when supported) and uses it as a reference when your finance team configures mapping rules. You manage your COA in your accounting system. When you make changes there, import the updated list into Ledgerise from Settings → COA Reference. → See [chart of accounts](/ledgerise/05-mapping-rules/04-chart-of-accounts.md) *** ## double-entry bookkeeping The accounting method Ledgerise uses for all journal entries. Every financial event affects at least two accounts: one account is debited and another is credited, and the total debits must equal the total credits. For example, when a customer pays an electricity bill: the cash or float account is debited (money came in), and the electricity revenue account is credited (income was earned). Ledgerise validates every journal entry before posting it. If the debits and credits do not balance, the entry is held and flagged — it is never submitted to the accounting system in an invalid state. *** ## engine run A scheduled execution of the journal engine. During a run, the engine fetches all completed, unposted transactions, applies mapping rules, generates journal entries, and submits them to the outbound adapter. By default, the engine runs every hour. You can adjust the schedule in Settings → System. The Journal Log shows the timestamp of the last engine run and a summary of what was processed. You can also trigger a run manually from the Journal Log page. → See [journal log overview](/ledgerise/06-journal-log/01-overview.md) *** ## evidence package A single timestamped document that captures the full record for one transaction or reconciliation break. It is designed to be shared with auditors, partner banks, or regulators. An evidence package contains the canonical transaction record, the reconciliation result (matched or break — and if a break, the resolution), the mapping rule version that was active when the journal entry was posted, the journal entry with its debit and credit lines, the full posting history, and any flag record and resolution if applicable. You can generate an evidence package from the detail drawer of any transaction, match record, or break record. → See [evidence packages](/ledgerise/04-reconciliation/07-evidence-packages.md) *** ## journal entry A double-entry accounting record generated by the Ledgerise engine for a completed transaction. Each journal entry has one or more debit lines and one or more credit lines. The total debits equal the total credits. Journal entries are what gets posted to your accounting system. Every journal entry in Ledgerise is traceable back to the source transaction that produced it, and to the mapping rule that determined which accounts were used. → See [journal entries](/ledgerise/06-journal-log/02-journal-entries.md) *** ## mapping rule A configuration record that tells the journal engine which COA accounts to debit and credit when it encounters a transaction matching specific criteria. Rules are defined by your finance team through the Mapping Rules page — no code changes are required. A rule matches on a combination of product line, biller, and biller category. The engine evaluates rules in priority order — most specific first — and uses the first match it finds. If no rule matches, the transaction is sent to the suspense account. → See [mapping rules overview](/ledgerise/05-mapping-rules/01-overview.md) *** ## product line The label your organisation uses to classify a group of related transactions — for example, `bill-payment`, `wallet`, `agency`, or `lending`. Product line is the primary key the engine uses when resolving mapping rules. Every transaction must carry a product line value. This is set by the inbound adapter based on the source data, or configured as part of the field mapping for generic adapters. *** ## biller and biller category A **biller** is a specific payee in a bill payment transaction — for example, `ikeja-electric` or `dstv`. A **biller category** is a broader grouping — for example, `electricity` or `cable-tv`. Ledgerise uses biller and biller category as secondary matching keys in mapping rule resolution. This allows you to define a general rule for an entire category — all electricity billers — while overriding it with a more specific rule for individual billers that require different accounting treatment. *** ## suspense account A designated account in your chart of accounts where Ledgerise posts transactions that cannot be matched to a mapping rule. Transactions in the suspense account are flagged as unmapped and appear in the Transactions page for your finance team to review and reassign. The suspense account is a safety net. No transaction is ever dropped or silently misposted. You configure the suspense account code in Settings → System before going live. *** ## reconciliation run In the Ledgerise core loop — Transactions in → Reconciliation → Classification → Journal entries out — reconciliation is the verification stage. It sits between ingestion and journal posting: internal transaction records are compared against external counterparty statements before mapping rules classify and post them. A reconciliation run is triggered when you import an external statement — from a payment provider or bank — into Ledgerise. The run compares your internal transaction records against the external records for the same period to find matches and discrepancies. Each run produces a set of match records (confirmed pairs) and break records (discrepancies). A reconciliation run is not a scheduled background job — it is initiated by your operations or finance team when an external statement arrives. → See [reconciliation overview](/ledgerise/04-reconciliation/01-overview.md) *** ## break A break is a discrepancy identified during a reconciliation run that could not be automatically resolved. Common break types include: * **Missing internal** — the counterparty has a record, but Ledgerise does not. * **Missing external** — Ledgerise has a record, but the counterparty statement does not. * **Amount mismatch** — both records exist, but the amounts differ beyond the configured tolerance. * **Timing mismatch** — both records exist, but the settlement dates differ beyond the configured window. Breaks are the exception queue for reconciliation. Each one must be reviewed and closed by your finance team with a resolution type and a note. A break cannot be closed without both. → See [resolving breaks](/ledgerise/04-reconciliation/04-resolving-breaks.md) *** ## match record A confirmed pair between an internal Ledgerise transaction and a corresponding record in an external counterparty statement, where all matching conditions were satisfied within configured tolerances. Match records are informational — they represent completed verification and require no further action. *** ## posting status The posting status tells you what Ledgerise has done with a transaction from the perspective of journal generation and accounting system delivery. | Status | Meaning | | ----------------- | ------------------------------------------------------------------------------------------------------- | | `unposted` | Waiting for the next engine run. No journal entry exists yet. | | `generated` | Journal entry has been created. Submission to the accounting system is about to begin. | | `posting` | Submission in progress. Brief transient state. | | `posted` | Journal entry was created and successfully submitted to the accounting system. | | `unmapped` | No matching mapping rule found. Posted to the suspense account. | | `failed` | Posting was attempted but the accounting system returned an error. Ledgerise is retrying automatically. | | `retry_exhausted` | Failed and retried the maximum number of times. Requires manual action. | → See [transaction statuses](/ledgerise/03-transactions/06-transaction-statuses.md) *** ## transaction status The transaction status reflects what happened to the transaction in the source system — independent of what Ledgerise has done with it. | Status | Meaning | | ----------- | -------------------------------------------------------------------- | | `pending` | The transaction has not yet been finalised in the source system | | `completed` | The transaction settled. It is eligible for journal posting | | `failed` | The transaction did not complete. Stored but never posted | | `reversed` | A previously completed transaction has been reversed | | `disputed` | The transaction is under dispute. Posting is held pending resolution | Only transactions with status `completed` are ever picked up by the journal engine. → See [transaction statuses](/ledgerise/03-transactions/06-transaction-statuses.md) *** ## source environment Every transaction record carries an environment label: `live` or `test`. Transactions marked `test` are stored in Ledgerise normally, but the journal engine will never post them to your accounting system. They are permanently excluded from posting. This allows you to safely connect a test or sandbox integration from your payment provider without risking any entries in your live books. *** ## report source A saved identity for a counterparty statement type, used in reconciliation. A report source combines the counterparty name and the statement type into a display label — for example, `Paystack — Settlement Report` or `GTBank — Collection Account Statement`. Report sources are created the first time you import a statement and can be managed in Settings. Reconciliation rules are organised by report source so the correct rules are applied when you run each statement type.