How Posting Works

Posting is the moment a business document — a sales invoice, a bill, a payment, a journal — turns into accounting. Until you post, a document is just a record of intent: it sits in Draft, you can edit it freely, and it has no effect on your financial statements. When you post it, REDA writes the matching double-entry bookkeeping — equal debits and credits — into your general ledger, and from that instant the document shows up in your Trial Balance, your P&L, and your Balance Sheet.

The posting engine is the heart of REDA Financials. Every number on every financial report traces back to it. This article explains the whole machine in plain language: the statuses a document moves through, the single gateway every entry passes through, the events that trigger posting, the checks that run before anything is written, and worked examples for each kind of document — including the automatic entries REDA generates behind the scenes for cash-basis and intercompany accounting.

The three statuses every document moves through

Almost every source document in REDA lives in one of three states — Cash Receipts are the one exception, covered below. The status is the single source of truth for “has this hit the ledger yet?”

One gateway, one set of books

No matter which document you post, the entries are written by a single internal service — the posting engine. There is no second way in. Every debit and credit in your entire general ledger was created by this one gateway, which is exactly why your books stay consistent: the same rules, balancing checks, currency handling, and ledger stamping apply to every transaction without exception.

The entries themselves are stored as Accounting Transactions — the individual debit and credit lines that make up your ledger. They have two defining properties:

• They can only be created by the engine. You cannot type an Accounting Transaction by hand, import one, or build one in a spreadsheet tool and push it in. The only door is posting a source document.
• Once created, they never change. An Accounting Transaction is immutable — its account, amounts, date, and dimensions are frozen. If something is wrong, you don’t edit the entry; you void or reverse the document, and the engine writes a fresh, balancing set of entries.

When does posting happen? The four events

Posting isn’t only the “Post” button. The engine reacts to four distinct events in a document’s life. Understanding them explains why REDA sometimes stops you from editing a record, and what happens when you change a status.

The checks that run before anything is written

Posting is “all or nothing.” Before the engine writes a single entry, a fixed battery of validations runs against the document. If any fail, nothing is posted and REDA shows you all the problems at once, so you can fix everything in one pass rather than discovering issues one at a time.

These are the canonical pre-posting checks, grouped by what they protect:

Worked examples: what the engine actually writes

Here is what posting produces for each common document, with real debits and credits. In every case the engine derives the accounts from the document and your configured default GL accounts, so you rarely pick them by hand.

1. Sales Invoice — accrual basis

You invoice a customer $1,000 for services, plus 10% VAT. On posting:

Revenue is recognised now, at invoice date — that’s what “accrual” means. The customer owes you (AR), and the tax you collected is a liability you owe the tax authority.

2. Purchase Invoice (bill) — accrual basis

A supplier bills you $500 for an expense, plus 10% recoverable VAT. On posting:

The expense hits your P&L immediately, the recoverable VAT becomes an asset (you’ll reclaim it), and you owe the supplier (AP).

3. Sales Invoice — cash basis (deferred revenue)

Some small businesses recognise revenue only when they’re paid, not when they invoice. If an entity’s accounting basis is Cash, the same $1,000 + 10% VAT invoice posts differently — revenue is parked until the cash arrives:

Step A — on posting the invoice:

No revenue yet — it sits in Deferred Revenue. (Tax is always recognised at invoice date, on either basis.)

Step B — when the customer pays and you apply the receipt: the engine books the cash and automatically releases the revenue:

The second pair is the magic: REDA moves $1,000 out of Deferred Revenue and into Revenue at the moment of payment. Pay half the invoice and only half the revenue is released — the rest stays deferred. This is all automatic; you simply apply the receipt.

4. Intercompany settlement — automatic offsets

Suppose Entity B raised an invoice, but Entity A collected the cash and you apply Entity A’s receipt to Entity B’s invoice. The cash is in A; the receivable was in B. To keep each company’s books self-balancing, REDA automatically posts an intercompany offset:

Now Entity B’s receivable is cleared — replaced by an intercompany receivable from A (A owes B the money it collected). Entity A holds the cash and shows an intercompany payable to B. Each entity balances on its own (validation #12), and the two intercompany accounts net to zero when you consolidate.

The automations you don’t see

Several things happen automatically every time you post, so you don’t have to think about them:

• Tax lines. VAT/GST and other taxes are calculated and posted to the correct tax accounts — output tax as a liability on sales, input (recoverable) tax as an asset on purchases.
• Withholding tax. Where applicable, the engine splits out withholding and books it to the right account at the right moment.
• Cash-basis deferral & release. As shown above, revenue is parked and released automatically on cash-basis entities.
• Intercompany offsets. Cross-entity settlements generate their balancing IC entries with no manual journal.
• Multi-currency. Every entry is stored in three currency tiers (document, entity/functional, and corporate/reporting) with the exchange rates used, so currency translation is built in.
• Posting dimensions. Your custom analysis fields (department, project, property…) are copied from the document straight onto each ledger entry — see Posting Dimensions.

Void vs Reverse — two ways to undo

Both undo a posting, but they leave different audit trails. Choose based on whether the original entry should disappear or stay visible.

Where to go next

1. Accounting Transactions — the ledger lines posting creates.
2. Grouped vs Line-Level Posting — control the number of entries.
3. Posting Dimensions — tag entries as they post.
4. Accounting Periods — the period each posting lands in.
5. Creating a Journal Entry — post a manual entry yourself.

Frequently asked questions