Accounting Transactions

Core Concept 8 min read Updated July 2026

An Accounting Transaction is a single line in your general ledger — one debit or one credit, against one account, in one entity, on one date. They are the atoms of your books. A sales invoice might produce three of them (receivable, revenue, tax); a journal might produce a dozen. Add them all up and you have your Trial Balance, your P&L, and your Balance Sheet.

You never create these by hand. They are written only by the posting engine when you post a document, and once written they never change. This article explains what’s inside an Accounting Transaction, why it’s locked, and how to read one.

Getting there. You don’t open raw transactions from a tab — you read them through the reports they feed. Open the App Launcher (the grid icon at the top-left of any page) → REDA Financials AI → the Financial Center tab for the Trial Balance, or open a GL account or a customer/vendor account to see its ledger. Each report drills back to the underlying transaction and its source document.
Access you'll need. Any REDA Financials permission set can view Accounting Transactions and run the reports that read them — what you see is limited to the records your role can read. No permission set (not even Accounting Controller) can create, edit, or delete them by hand; the posting engine alone writes them.

One document → many transactions. Think of the document (invoice, bill, payment) as the story, and the Accounting Transactions as the bookkeeping behind it. The document is what you edit; the transactions are what the engine derives and posts.

Anatomy of a transaction

Every Accounting Transaction carries four kinds of information.

1. The accounting core

Field	What it holds
GL Account	The account this debit/credit lands in.
Entity	The legal entity whose books this belongs to.
Ledger	The book it’s recorded in (Transaction or Budget; usually your one default ledger).
Accounting Period	The calendar period it falls in.
Transaction Date	The effective date of the entry.
Transaction Type	Original or Reversal — whether this is a first posting or a mirror entry backing one out. A reversal also carries a Reversal Reason (User Edit, User Delete, Void, or Period Adjustment) explaining why it exists.
Account Type	The GL account’s type (Asset, Liability, Equity, Revenue, Expense), mirrored onto the entry for fast reporting.

2. The amounts — three currency tiers

REDA stores every entry in three currencies at once, so currency translation never has to be re-derived later:

Tier	Debit / Credit fields	What it is
Transaction (document)	Transaction Debit / Transaction Credit + Transaction Exchange Rate + Transaction Currency	The currency the document was raised in.
Entity (functional)	Debit / Credit	The entity’s own currency — the primary books.
Corporate (reporting)	Corporate Debit / Corporate Credit + Corporate Exchange Rate	The group’s consolidation currency.

Single-currency orgs: all three tiers hold the same number and every exchange rate is 1. The structure is identical — you just never notice it. This is what lets the same app run unchanged whether you operate in one currency or twenty.

3. The source link — provenance

Every transaction points back to exactly the document and line that produced it, so you can always answer “where did this number come from?” The engine stamps a typed link to the source header (Sales Invoice, Purchase Invoice, Cash Receipt, Cash Disbursement, Journal Entry, their applications, and fixed-asset records) and, in line-level mode, to the individual source line. A Source Type field names the document kind at a glance — Journal Entry, Sales Invoice, Purchase Invoice, Cash Receipt, Cash Disbursement, Credit Memo, Vendor Memo, Cash Receipt Application, Cash Disbursement Application, or Fixed Asset.

4. Flags & dimensions

Field	Meaning
Auto-Generated	True when the engine created the line itself (e.g. an intercompany offset or a cash-basis release) rather than from a document line you typed.
Is Intercompany	Marks the cross-entity offset entries.
Is Control Account	A reporting marker for control accounts (AR, AP, intercompany, deferred…).
Is Recoverable	For tax lines — distinguishes reclaimable input tax.
Account	The customer or vendor, where relevant — powers AR/AP subledger views.
Posting dimensions	Your custom analysis fields (department, project…), copied from the document — see Posting Dimensions.
Posted By / Posted Date	Who posted it and when — part of the audit trail.
Line Count	How many source lines this entry summarises — 1 in line-level mode; higher when grouped posting merged several lines into one entry.
Ledger Description	An auto-built narrative — the description, any reference, and the GL account name — so a ledger listing reads like a story without opening each source document.

A worked example: one journal, two transactions

Meridian Properties Group’s US entity opened its books with journal entry MJE001001 — $750,000 of opening capital paid into the company. Posting that one document writes exactly two Accounting Transactions:

Account	Debit	Credit
Cash and Cash Equivalents	$750,000.00
Contributed Capital		$750,000.00

Each of those two rows is a complete, self-describing record: it knows its entity (Meridian’s US company), its ledger, its period, its date, its amounts in all three currency tiers, and — through the source link — exactly which journal produced it. Ask “why does cash show $750,000?” in any report, and the answer is one drill-down away: the transaction, then MJE001001 itself.

Why they’re immutable

Accounting Transactions are write-once. After the engine inserts one, its account, amounts, date, currency tiers, classification, source links, and dimensions are all frozen. REDA enforces this at the deepest level — not as a page setting you could relax, but as a hard rule on the object itself:

No manual insert. The only thing that can create an Accounting Transaction is the posting engine. Any other attempt is refused.
No edits. Every meaningful field is locked after creation. (The free-text Description is the only thing left adjustable.)
No manual delete. You can’t hand-delete a ledger entry. The engine removes its own entries when you unpost or void the document.

This is the backbone of REDA’s audit integrity. A ledger that can’t be quietly altered is a ledger an auditor can rely on. Corrections never overwrite history — they appear as their own posting (a void or a reversal), so the full story is always visible. This satisfies the tamper-evidence expectations of SOX, IFRS, and GAAP without any extra effort on your part.

Extending the lock to your own fields. If your administrator adds a custom dimension to the Accounting Transaction’s posting map, that field automatically becomes immutable too — no code, no extra configuration. Client-added analysis fields get the same protection as REDA’s built-in ones.

The lock in the system’s own words

If anyone — a person, an import tool, or an integration — tries to bypass the engine, these are the exact refusals they meet:

You try to…	The message
Create one directly	“Accounting Transactions cannot be created directly. All GL entries are managed by the posting engine.”
Edit a locked field	“Accounting Transactions are immutable once posted. Field … cannot be changed. Unpost the source document to correct the entry.”
Delete one directly	“Accounting Transactions cannot be deleted directly. Unpost the source document to remove GL entries.”

Each message points at the same remedy: go back to the source document and act there. The ledger only ever changes through the front door.

So how do I fix one?

You don’t touch the transaction — you act on the document:

Wrong amount or account? Move the document back to Draft (this unposts it and removes the entries), correct it, and post again. The engine writes fresh, correct entries.

Document raised in error? Void it — the entries are removed and the document is marked Void for the record.

Need to unwind in a later period while keeping history? Reverse it — the originals stay and a mirror entry cancels them in an open period.

See Void vs Reverse for choosing between the last two.

Where to see them

You rarely open a raw Accounting Transaction — you read them through the reports they feed: the Trial Balance, the GL Account Ledger (every entry hitting one account in a period, with a running balance), and the customer / vendor account ledgers for the AR/AP subledger view. Each report drills straight back to the underlying transactions and, from there, to the source document.

Read-only for everyone. Because no one posts to the ledger by hand, none of REDA’s permission sets grant write access to Accounting Transactions — not even the Accounting Controller. Everyone can read them (subject to their access); the engine alone writes them.

Where to go next

How Posting Works — how documents become these ledger lines.
Grouped vs Line-Level Posting — control how many lines a document produces.
Posting Dimensions — extra ways to slice each line.
Ledger Management — the ledger stamped on every transaction.
Trial Balance — where these lines roll up.

Frequently asked questions

No — immutability is enforced on the object itself, not via a permission an admin can grant. To change anything that flows into a transaction, change the source document and re-post. Only the free-text Description on a transaction can be adjusted.

Multi-currency. REDA stores the document currency, the entity’s functional currency, and the group’s reporting currency on every line, with the rates used. In a single-currency org all three match and the rate is 1 — so consolidation and currency reporting work the same everywhere.

It marks entries the engine produced on its own rather than from a line you typed — for example intercompany offsets, or the deferred-revenue release on a cash-basis receipt. It helps you tell system automation apart from document-driven lines.

No. Deleting (or voiding) a posted document routes through the engine’s unpost path, which removes the document’s entries cleanly first. The ledger never keeps dangling entries for a document that’s gone.

No. If any entry belonging to a document fails to write, the engine removes that document’s already-written sibling entries before finishing — so the ledger never holds an unbalanced fragment. When you post in bulk, one failed document doesn’t stop the others; each document either lands complete or not at all.

They are plain-number copies of the entity-currency Debit and Credit, captured at posting. Reports and totals built on them always sum the amounts exactly as booked, without any behind-the-scenes currency re-conversion — a safeguard that matters in multi-currency organisations.

Was this article helpful?