Posting Dimensions
A posting dimension is an extra way to slice your numbers — by department, project, cost centre, property, region, or anything else your business reports on. Your chart of accounts tells you what a transaction is (revenue, rent, salaries). A dimension tells you which part of the business it belongs to — without exploding your chart into hundreds of near-duplicate accounts like “Rent – London”, “Rent – Paris”, “Rent – New York”.
REDA carries your dimensions all the way down to the individual ledger entry, automatically, using a configurable posting map — the list of fields that flow from a document to the ledger. This article is the complete reference: which records carry the posting map, how the dimension match runs at posting time for every kind of document (including assets), and how an administrator sets one up — all with no code.
Why dimensions instead of more accounts
Imagine you rent offices in three cities and want rent reported per city. You have two choices:
| More accounts | One account + a dimension | |
|---|---|---|
| Chart of accounts | Rent – London, Rent – Paris, Rent – NY… (grows forever) | One “Rent” account |
| To add a city | Create new accounts, retrain everyone | Just pick the new city in the Location field |
| Reporting | Sum groups of accounts manually | Group the one account by the dimension |
| Cross-analysis | Hard — account explosion multiplies | Easy — slice the same ledger by any dimension |
Dimensions keep your chart of accounts clean and your analysis flexible — standard practice in every serious ERP. REDA just makes it configuration, not a project.
Where the posting map lives
The posting map exists on 16 record types, and they don’t all play the same part. There’s one destination, a set of posting sources the engine reads at post time, and a few records that carry the posting map purely so your dimensions stay consistent for reporting and matching. Know which is which and the whole system makes sense.
1. The destination — where dimensions land
| Record | Role |
|---|---|
| Accounting Transaction | The target. Every dimension you want on the ledger must exist here as a field and be listed in this record’s posting map. The standard accounting fields (Entity, GL Account, Period, Ledger) are not dimensions — the engine maps those directly, so never add them to the posting map. |
2. Posting sources — read at post time
When you post one of these, the engine reads its posting map and stamps the values onto the resulting transactions:
| Record | Level | Notes |
|---|---|---|
| Sales Invoice | Header | Also covers Credit Memos (a Sales Invoice of that type). |
| Purchase Invoice | Header | Also covers Vendor Memos (a Purchase Invoice of that type). |
| Journal Entry | Header | Pairs with the line below — the only document with per-line dimensions. |
| Journal Entry Line | Line | Line values override the JE header for the same field. |
| Cash Receipt | Header | Feeds both the receipt’s own entries and its applications. |
| Cash Disbursement | Header | Feeds both the payment’s own entries and its applications. |
| Fixed Asset | Header | Source for all asset entries — depreciation, disposal, impairment, capitalization. |
| Purchase Order | Header | Not posted directly — dimensions propagate to matched Purchase Invoice lines (see below). |
3. Expense Allocation — propagated through a journal
| Record | Flows to |
|---|---|
| PI Allocation Batch | The generated Journal Entry header |
| PI Allocation | The generated Journal Entry line (overrides header) |
| Expense Allocation Item | Carries dimensions through the allocation calculation |
Expense allocation doesn’t post directly — it builds a Journal Entry and lets that post. The allocation’s dimensions ride onto the JE header and lines, so the final ledger entries inherit them exactly as any journal would.
4. Parity & matching — they carry dimensions, but no posting
| Record | Why it carries the dimensions |
|---|---|
| Budget & Budget Line | So budgeted figures carry the same dimensions as actuals — budget-vs-actual then compares like-for-like by department, project, etc. Budgets never create Accounting Transactions. |
| Aging Snapshot Line | Point-in-time AR/AP reporting rows carry the same dimensions so aging can be sliced the same way as the live ledger. |
| Bank Account Rule | Lets bank-reconciliation auto-match rules reference your dimensions when proposing matches. |
How matching runs — document by document
At posting, the engine merges the dimensions from a header source and (where one exists) a line source, then stamps the result on each transaction. What counts as the header and the line differs by document — and that difference is the single most important thing to understand here:
| When you post… | Header dimensions from | Line dimensions from | Net result |
|---|---|---|---|
| Sales Invoice / Credit Memo | The invoice header | — (SI lines carry no dimensions) | Every entry inherits the invoice’s dimensions |
| Purchase Invoice / Vendor Memo | The bill header | — | Every entry inherits the bill’s dimensions |
| Journal Entry | The JE header | The JE line | Per-line dimensions — line wins where set, else header flows down |
| Cash Receipt | The receipt header | — | Receipt’s dimensions on its entries |
| Cash Receipt Application | The parent Cash Receipt | — | Application entries inherit the receipt’s dimensions |
| Cash Disbursement | The payment header | — | Payment’s dimensions on its entries |
| Cash Disbursement Application | The parent Cash Disbursement | — | Application entries inherit the payment’s dimensions |
| Credit Memo Application | The parent Credit Memo | — | Inherit the memo’s dimensions |
| Vendor Memo Application | The parent Vendor Memo | — | Inherit the memo’s dimensions |
| Fixed Asset (depreciation, disposal, impairment, capitalization) | The Fixed Asset header | — | Every asset entry inherits the asset’s dimensions |
Assets: the dimension source is the Fixed Asset
Asset entries deserve a special mention because people expect them on the asset ledger. They’re not. The Asset Ledger record carries no dimensions of its own — instead, every asset transaction (a depreciation charge, a disposal gain/loss, an impairment, a capitalization) takes its dimensions from the Fixed Asset itself. And because an asset is usually born from a Purchase Order, dimensions cascade the whole way:
Set Cost Centre = Operations on the PO, and it flows onto the asset at creation, then onto every depreciation entry the asset ever generates — no re-keying, for the life of the asset.
Purchase Orders: dimensions propagate, they don’t post
A Purchase Order is off the balance sheet — it never creates ledger entries on its own. Its posting map exists so that when a Purchase Invoice is matched against the PO, the PO’s dimensions flow onto the matched PI lines. The dimensions then stamp onto the ledger when the Purchase Invoice posts — the PO seeds them, the PI delivers them.
The merge rule, precisely
For any post, the engine resolves each dimension like this:
Setting up a new dimension (administrator)
To analyse everything by, say, Cost Centre, an administrator does this once:
From the next post onward, every ledger entry carries the Cost Centre. No release, no developer, no downtime.
Dimensions, grouping, immutability & reporting
- They’re part of grouping. When grouped posting is on, lines are only summarised together if they share the same account and the same dimension values. Two rent lines for different cost centres stay separate — you never lose the breakdown to summarisation.
- They’re immutable like every ledger field. Once stamped, a dimension on an Accounting Transaction can’t be edited — and any dimension you add to the Accounting Transaction’s posting map is automatically locked, with no extra setup.
- They power your reports. Because the value lives on every entry, you can produce a P&L by department or a cost report by project — and, because Budget and Aging records carry the same dimensions, compare those to budget and trace them through aging.
- They can scope the year-end close. The Year-End Close screen offers optional Dimension Filters built from these same fields — you can close the profit and loss for selected dimension values only, and the closing journal lines carry the chosen values.
Where to go next
- How Posting Works — where dimensions attach during posting.
- Accounting Transactions — the lines dimensions tag.
- Grouped vs Line-Level Posting — how dimensions affect grouping.
- Chart of Accounts Setup Best Practices — dimensions instead of extra accounts.
- Report Filters — slice reports by dimension.
Frequently asked questions
No — and this is by design, not a limitation. Sales Invoices and Purchase Invoices stamp dimensions at the header level so the document stays balanced within every dimension: the receivable (or payable) side and the revenue (or expense) side carry the same dimension values, so each dimension nets to zero. Allowing different dimensions per invoice line would leave the single AR/AP line out of balance against the split revenue/expense lines. The Journal Entry is the one document with true per-line dimensions — because there the preparer authors each line and owns keeping the dimensions balanced. If you need genuinely line-by-line dimensional control, a Journal Entry is the right tool.
From the Fixed Asset record — not the asset ledger, which carries no dimensions of its own. Dimensions flow Purchase Order → Fixed Asset → ledger entry, so every depreciation, disposal, impairment, and capitalization entry inherits the asset’s dimensions automatically for the life of the asset.
Almost always one of three things: (1) the field’s underlying name differs between the source document and the ledger entry; (2) the field isn’t in the posting map in both places; or (3) you added it to a source that doesn’t post directly (e.g. a Purchase Order — its dimensions only appear once the matched Purchase Invoice posts). A value with no matching ledger field is skipped silently by design.
No. It’s pure configuration — create matching fields, add them to the posting map on both sides, and surface them on the form. The posting engine handles the copy with no code.
For parity. Budgets carry the same dimensions as actuals so budget-vs-actual compares like-for-like, and aging snapshots carry them so period-end AR/AP can be sliced exactly as the live ledger. They never create Accounting Transactions — the dimensions just keep your analysis consistent across the app.
Was this article helpful?