Posting a Sales Invoice
A draft invoice is a work in progress — editable, deletable, invisible to your financial statements. Posting is the moment it becomes real: locked against edits, recorded in the ledger, counting toward the customer's balance and your revenue. This article walks through what posting checks, what it writes, and what changes the moment it succeeds.
Access you'll need. Posting Sales Invoices requires the Accounts Receivable v2 permission set (AR clerks & managers) or Accounting Admin v2 (system administrators). The Accounting Controller v2, Accounts Payable v2, and Read Only v2 sets can view invoices but not post them.
The checks that run first
Posting is guarded — better to be stopped now than to unpick wrong accounting later. In order:
| Check | What satisfies it |
|---|---|
| Approval | Approval Status is Approved or Not Required — otherwise: "This document requires approval before posting." |
| At least one line | "Sales Invoice must have at least one line before posting." |
| The right sign | Invoices and cash-sale Receipts must total positive; Credit Memos negative — each has its own verbatim stop. |
| Open books | The invoice date must be after the entity's AR closure date and inside an Open accounting period that contains it. |
| Healthy master data | Active entity, active GL accounts belonging to this entity (or global), a customer-class account. |
| Discount compliance | Any line-level discount requires the entity to have a Sales Discount account configured — several national accounting standards require discounts shown separately, and REDA Financials enforces it. |
Each of those checks speaks in an exact message when it stops you. The full list, with remedies:
| The message | What to do |
|---|---|
| "This document requires approval before posting. Approval Status must be Approved or Not Required." | Get the approval — credit memos start Pending automatically; ordinary invoices default to Not Required. |
| "Sales Invoice must have at least one line before posting." | Add what's being billed — an empty invoice records nothing. |
| "{0} must have a positive total. Current total: {1}" | An Invoice or cash-sale Receipt has come out zero or negative — check line amounts and credit-line flags. |
| "Credit Memo must have a negative total. Use Is_Credit lines to produce a negative total amount. Current total: {0}" | The mirror rule for memos — mark the lines as credit lines. |
| "Credit Memo total is zero — nothing to post." | The memo's lines cancel out; review quantities. |
| "Transaction Date {0} is on or before the AR book closure date {1}. Reopen the books to post." | The books are closed through that date — use a current date, or talk to your controller. |
| "Transaction Date {0} falls outside Accounting Period ({1} to {2})." | Date and period disagree — fix the date and let the period re-derive. |
| "Accounting Period status is "{0}". Only Open periods accept postings." | The period exists but isn't Open — an administrator opens it, or you date the invoice into an open one. |
| "GL Account is inactive. Activate it or select an alternative." | A line points at a retired account — pick a live one. |
| "GL Account belongs to a different Entity and cannot be used on this transaction." | Each entity posts to its own (or global) accounts — correct the line's account. |
| "Cannot post invoice with discount: Entity {0} has no Sales Discount GL Account configured. Set the entity's Sales Discount GL Account before posting any invoice that carries a line-level discount (required by FR PCG, DE SKR, IT piano dei conti, BR SPED, CN PRC GAAP)." | A one-time entity setup task — your administrator adds the discount account. |
What posting writes
For a standard invoice on an accrual-basis entity — say Corvus's $9,000 June rent:
| Account | Debit | Credit |
|---|---|---|
| Accounts Receivable — Trade | $9,000.00 | |
| Rental Income — Offices | $9,000.00 |
- Taxed invoice? The receivable is debited gross and each calculated tax credits its own tax-payable account — the full story is in Tax on Sales Invoices.
- Cash-basis entity? Revenue parks in Deferred Revenue until the money arrives — see Cash Basis Revenue Recognition.
- Cash-sale (Receipt-type) invoice? Posting also creates and posts its own Cash Receipt and applies it instantly — the invoice is born settled.
- Foreign-currency invoice? The exchange rate is stamped at posting, fixing the corporate-currency value of the document.
The cash-sale special: an invoice born settled
The Receipt-type invoice deserves its own moment, because posting one does three documents' worth of work. The instant it posts, REDA Financials creates a Cash Receipt for you — already posted, no draft step — and applies it to the invoice immediately:
| On the auto-created receipt | Filled with |
|---|---|
| Amount / Receipt Date | The invoice's total and the invoice's date — the sale and the money are one event. |
| Payment Method | Cash. |
| Bank Account / Cash Account | The invoice's bank account if one was chosen, else the entity's default bank — and that bank's ledger account. |
| Reference / Description | The invoice's reference (or its number), and a description naming its origin — "Auto-created from Receipt" plus the invoice number. |
| Original Invoice | The invoice itself — and the auto-apply flag is set, so the receipt settles it in the same breath. |
The result: a cash-sale invoice is never "outstanding" — balance due $0.00 from birth, with a real receipt behind it for the bank reconciliation. If the receipt can't be created (a configuration gap, usually the entity's default bank), the post itself stops with "Auto-CR creation failed:" and the reason — nothing half-happens.
What changes the moment it posts
- The invoice is locked: "Posted Sales Invoices cannot be edited. Use the Void action to reverse…" (a handful of harmless settings — auto-apply flags, the PDF template — stay editable).
- It can no longer be deleted — only voided: "Posted Sales Invoices cannot be deleted. Void the invoice instead."
- Aging starts: the Aging Bucket (Current / 1-30 / 31-60 / 61-90 / 90+), Days Past Due, and Is Overdue fields go live against the due date.
- Payments and credits can now be applied to it.
- If the entity has auto-PDF enabled, the customer-facing PDF generates itself in the background.
Reopening (unposting)
Posted → back to Draft is allowed and orderly: applications from receipts and credits are removed (balances restored on the other side), the accounting entries and tax records are deleted, auto-created receipts of cash-sale invoices are unwound, and any public PDF link is revoked. Fix the invoice and post again — everything recalculates. The same closed-books gate applies in reverse: you can't unpost into a closed period.
The cleanup runs in a strict order, which explains what you'll see disappear:
Applications come off first
Every receipt application and credit application touching this invoice is removed, restoring Unapplied Cash on the receipts and Remaining Credit on the memos — and taking their own accounting entries with them.
The invoice's own entries and tax records go
The posting entries are deleted and the calculated tax lines reset — a draft carries no tax until it posts again.
Auto-created receipts are unwound
A cash-sale invoice's born-posted receipt is unposted and deleted with it. If that receipt can't be removed (say it's bank-reconciled), the unpost stops: "Cannot unpost or void this Sales Invoice because its auto-generated Cash Receipt could not be removed:" plus the reason. Receipts you recorded yourself via Receive Payment are not deleted — the screen asks you what to do with them.
The PDF link is revoked
Any public link to the generated PDF stops working — a document under revision shouldn't circulate. The file itself stays on the record.
Common mistakes to avoid
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Leaving invoices in Draft for days | Drafts are invisible to aging, statements, and revenue — the books run behind reality | Post the day you issue; use Draft only while something is genuinely unresolved |
| Unposting an invoice the customer already received | The sent document and your books diverge silently — the customer reconciles against paper you've rewritten | Correct with a credit memo; unpost only what never left the building |
| Backdating to "put revenue where it belongs" | Closed-books and period gates will refuse it — and when they don't, prior reported figures shift | Date documents when they happen; period adjustments are your accountant's call |
| Using a Receipt-type invoice for money not yet in hand | It books cash that doesn't exist — a born-posted receipt claims the bank received it today | Receipt type is for point-of-sale reality; bill everything else as Invoice type and collect normally |
| Retrying a failed post without reading the message | Every message above names its exact cause — guessing wastes the afternoon | Fix what the message says, then post; the checks pass silently once satisfied |
Where to go next
- Voiding a Sales Invoice — when the document shouldn't stand at all.
- Applying Receipts to Invoices — the payment side.
- Sales Invoice PDF — the customer-facing document.
- Closing the Books — why the closure-date gate exists.
Frequently asked questions
Posting is a change to the invoice, so the same permission sets that edit AR documents: Accounts Receivable and Accounting Admin. Controllers and Read Only users see everything but post nothing.
The accounting period derives from the invoice date automatically. If the combination looks wrong, fix the date — the period follows. Posting into a period that isn't Open is refused with the period's status named in the message.
Auto-generation is per-entity opt-in; if it's off, generate on demand with the Generate PDF button (see Sales Invoice PDF). Auto-generation also never blocks a post — if it hits an error, the invoice still posts and the error is recorded on the record.
Yes — the Bulk Status Update tool posts a filtered batch of drafts in one run, with a per-document result report. See Bulk Status Update.
Only settings that don't touch the accounting: the auto-apply flags (Auto Apply Memo), Match Lines on Apply, Dimension Match, and the PDF Template. Amounts, dates, customer, lines — all locked. Anything substantive means unpost (if it never left the building) or a credit memo.
That's the Receipt-type behavior working as designed: posting created a born-posted Cash Receipt (Payment Method Cash) and applied it instantly. It's linked to the invoice via its Original Invoice field — and it unwinds automatically if you ever unpost the invoice.
Yes — but know what happens: the payment's application is removed, so the money returns to the receipt as Unapplied Cash. The receipt itself stays posted. When you repost the corrected invoice, re-apply the money (or let auto-apply do it).
Was this article helpful?